Re: [Sdcc-user] pointer target lost const qualifier -warning

[Raphael Neider <rneider@we...>]

Hi,

regarding the warning: This seems to be a bug. We have

__data void *
memcpypgm2ram (__data void *dst, __code void *src, size_t acount)
{
  char __data *d = dst;
  char __code *s = src;
  /*
   * copy from lower addresses to higher addresses
   */
  while (acount--)
    *d++ = *s++;
  return dst;
}

src and s should have const qualifiers, no? One might think that _code
should imply const - but if i remember correctly, that was true in most but
not all cases... Maybe we imply a const in the return of your function but
not in the arguments? Strange...

You could try copying the library function to your project and adjust the
arguments (and s) just to see if it helps?

Regarding the second issue: Do you link main.o twice by any chance? Maybe
by compiling main.c once as part of the sources and again to trigger
linking with all .o files including main.o?
Could you post all relevant build output - with verbose enabled to see the
files being linked?
If the error occurs during compilation - could you provide the .asm file?
(sdcc with -S and -o foo.asm could do the trick)?

I'll be unavailable for the next week or so and may not be able to read or
answer mail :-(.

Raphael

Am 21.07.2017 19:57 schrieb "Kustaa Nyholm" <kustaa.nyholm@...
>:

I'm runnin sdcc 3.4.0 and targeting PIC18F45K50


I get this warning:

main.c:670: warning 196: pointer target lost const qualifier

from this:

memcpypgm2ram(&hid_tx_buffer.uint8[0],get_toad4_config(),63);

with these defs:

__code void* get_toad4_config();

volatile hid_buffer_t hid_tx_buffer;

this however does not produce any warning:

memcpyram2ram(&hid_tx_buffer.uint8[0], &g_toad4_status.steppers[0],8);

so I'm thinking it is the get_toad4_config() that produces the warning.

I don't get it.

Also slightly related:

I get this:

../obj/main.asm:3683:Error[154]   Each object file section must be
contiguous: ".code"
../obj/main.asm:3683:Error[116]   Address label duplicated or different in
second pass: "_g_toad4_config"
Error[181]   System error while writing object file.

if I have anything like this:

__code int g_toad4_config = {0};


in my main.c but not if I have it in any other source file.


confused, Kusti
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)

[Raphael Neider <rneider@we...>]

Hi,

i just checked crt0i:


/* The cinit table will be filled by the linker. */
extern __code struct
  {
    unsigned short num_init;
    struct
      {
        unsigned long from;
        unsigned long to;
        unsigned long size;
      } entries[1];
  } cinit;


Maybe your initialised variable section is empty because you have none?
Could you try adding some

static char foo = 42;

and try again?

Raphael


Am 21.07.2017 21:45 schrieb "Raphael Neider" <rneider@...>:

Hi,

you seem to pass --no-crt to sdcc and pass in your own crt0iz_toad4.o.
Could this be the problem? Can the order be bad? Maybe have the linker look
at crt0iz last? I'm not sure where _cinit is supposed to come from...

Best regards,
Raphael


Am 21.07.2017 19:56 schrieb "Kustaa Nyholm" <kustaa.nyholm@...
>:

When linking my code I get this (same line seven times):

warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000004] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000008] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000004] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000008] has no section. (pass 0)'

This is with sdcc 3.4.0 targeting PIC18F45K50.

I'll include the complete build output at the end.

cheers Kusti

...

/Users/nyholku/sdcc-3.4.0/bin/sdcc "-Wl -f 0xffff" --no-crt --ivt-loc=0x800
-V -L /Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -Wa,-S,0
-Wl,-m,-s18f45k50.lkr -mpic16 -p18f45k50 --disable-warning 85 --std-sdcc99
--obanksel=3 --use-non-free -o ../obj/toad4.hex ../obj/main.o
../obj/toad4.o ../obj/usb_hid.o ../obj/usb_core.o ../obj/usb_pic_defs.o
../obj/usb_user_config.o ../obj/command_queue.o ../obj/crt0iz_toad4.o
libc18f.lib libio18f45k50.lib libm18f.lib libsdcc.lib  ../obj/hi_speed_irq.o
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting
interrupt vector addresses 0x800
+ gplink -I/Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16
-I/Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/lib/pic16
-I/usr/local/share/sdcc/lib/pic16 -I/Users/nyholku/sdcc-3.4.0/bi
n/../share/sdcc/non-free/lib/pic16 -I/usr/local/share/sdcc/non-free/lib/pic16
-f 0xffff  -m -s18f45k50.lkr  -w -r -o ../obj/toad4.hex  ../obj/main.o
../obj/toad4.o ../obj/usb_hid.o ../obj/usb_core.o ../obj/usb_pic_defs.o
../obj/usb_user_config.o ../obj/command_queue.o ../obj/crt0iz_toad4.o
../obj/hi_speed_irq.o   libc18f.lib libio18f45k50.lib libm18f.lib
libsdcc.lib libdev18f45k50.lib libsdcc.lib
warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000004] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000008] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000004] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000008] has no section. (pass 0)
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)

[Raphael Neider <rneider@we...>]

Hi,

you seem to pass --no-crt to sdcc and pass in your own crt0iz_toad4.o.
Could this be the problem? Can the order be bad? Maybe have the linker look
at crt0iz last? I'm not sure where _cinit is supposed to come from...

Best regards,
Raphael


Am 21.07.2017 19:56 schrieb "Kustaa Nyholm" <kustaa.nyholm@...
>:

When linking my code I get this (same line seven times):

warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000004] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000008] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000004] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000008] has no section. (pass 0)'

This is with sdcc 3.4.0 targeting PIC18F45K50.

I'll include the complete build output at the end.

cheers Kusti

...

/Users/nyholku/sdcc-3.4.0/bin/sdcc "-Wl -f 0xffff" --no-crt --ivt-loc=0x800
-V -L /Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -Wa,-S,0
-Wl,-m,-s18f45k50.lkr -mpic16 -p18f45k50 --disable-warning 85 --std-sdcc99
--obanksel=3 --use-non-free -o ../obj/toad4.hex ../obj/main.o
../obj/toad4.o ../obj/usb_hid.o ../obj/usb_core.o ../obj/usb_pic_defs.o
../obj/usb_user_config.o ../obj/command_queue.o ../obj/crt0iz_toad4.o
libc18f.lib libio18f45k50.lib libm18f.lib libsdcc.lib  ../obj/hi_speed_irq.o
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting
interrupt vector addresses 0x800
+ gplink -I/Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16
-I/Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/lib/pic16
-I/usr/local/share/sdcc/lib/pic16 -I/Users/nyholku/sdcc-3.4.0/
bin/../share/sdcc/non-free/lib/pic16
-I/usr/local/share/sdcc/non-free/lib/pic16
-f 0xffff  -m -s18f45k50.lkr  -w -r -o ../obj/toad4.hex  ../obj/main.o
../obj/toad4.o ../obj/usb_hid.o ../obj/usb_core.o ../obj/usb_pic_defs.o
../obj/usb_user_config.o ../obj/command_queue.o ../obj/crt0iz_toad4.o
../obj/hi_speed_irq.o   libc18f.lib libio18f45k50.lib libm18f.lib
libsdcc.lib libdev18f45k50.lib libsdcc.lib
warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000004] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000008] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000004] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000008] has no section. (pass 0)
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user

[Sdcc-user] pointer target lost const qualifier -warning

[Kustaa Nyholm <kustaa.nyholm@sp...>]

I'm runnin sdcc 3.4.0 and targeting PIC18F45K50


I get this warning:

main.c:670: warning 196: pointer target lost const qualifier

from this:

memcpypgm2ram(&hid_tx_buffer.uint8[0],get_toad4_config(),63);

with these defs:

__code void* get_toad4_config();

volatile hid_buffer_t hid_tx_buffer;

this however does not produce any warning:

memcpyram2ram(&hid_tx_buffer.uint8[0], &g_toad4_status.steppers[0],8);

so I'm thinking it is the get_toad4_config() that produces the warning.

I don't get it.

Also slightly related:

I get this:

../obj/main.asm:3683:Error[154]   Each object file section must be contiguous: ".code"
../obj/main.asm:3683:Error[116]   Address label duplicated or different in second pass: "_g_toad4_config"
Error[181]   System error while writing object file.

if I have anything like this:

__code int g_toad4_config = {0};


in my main.c but not if I have it in any other source file.


confused, Kusti

[Sdcc-user] warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)

[Kustaa Nyholm <kustaa.nyholm@sp...>]

When linking my code I get this (same line seven times):

warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000004] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000008] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000004] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000008] has no section. (pass 0)'

This is with sdcc 3.4.0 targeting PIC18F45K50.

I'll include the complete build output at the end.

cheers Kusti

Makefile:119: ../obj/main.dep: No such file or directory
Makefile:119: ../obj/toad4.dep: No such file or directory
Makefile:119: ../obj/usb_hid.dep: No such file or directory
Makefile:119: ../obj/usb_core.dep: No such file or directory
Makefile:119: ../obj/usb_pic_defs.dep: No such file or directory
Makefile:119: ../obj/usb_user_config.dep: No such file or directory
Makefile:119: ../obj/command_queue.dep: No such file or directory
Makefile:119: ../obj/crt0iz_toad4.dep: No such file or directory
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
/Library/Frameworks/Python.framework/Versions/3.5/bin:/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/Users/nyholku/Desktop/ImageMagick-6.7.9/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Racket v6.5/bin:/opt/X11/bin:/usr/texbin:/Users/nyholku/android/tools:/sw/bin:/usr/local/share/npm/bin:/Applications/Wine/.wine/bin:/Applications/Racket v6.2/bin/
/Users/nyholku/sdcc-3.4.0/bin/sdcc -c "-Wl -f 0xffff" --no-crt --ivt-loc=0x800 -V -L /Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -Wa,-S,0 -Wl,-m,-s18f45k50.lkr -mpic16 -p18f45k50 --disable-warning 85 --std-sdcc99 --obanksel=3 --use-non-free main.c -o ../obj/main.o
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
+ /Users/nyholku/sdcc-3.4.0/bin/sdcpp -nostdinc -Wall -Dpic18f45k50 -D__18f45k50 -D__SDCC_PIC18F45K50 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -obj-ext=.o -D__SDCC_USE_NON_FREE -DSDCC_USE_NON_FREE -D__SDCC_ALL_CALLEE_SAVES -D__SDCC=3_4_0 -DSDCC=340 -D__SDCC_REVISION=8981 -DSDCC_REVISION=8981 -D__SDCC_pic16 -DSDCC_pic16 -D__pic16 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__ -D__STDC_NO_ATOMICS__ -D__STDC_NO_VLA__ -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include/pic16 -isystem /usr/local/share/sdcc/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16 -isystem /usr/local/share/sdcc/non-free/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include -isystem /usr/local/share/sdcc/non-free/include  main.c 
main.c:670: warning 196: pointer target lost const qualifier
+ gpasm -S 0 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o ../obj/main.o -c ../obj/main.asm
/Library/Frameworks/Python.framework/Versions/3.5/bin:/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/Users/nyholku/Desktop/ImageMagick-6.7.9/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Racket v6.5/bin:/opt/X11/bin:/usr/texbin:/Users/nyholku/android/tools:/sw/bin:/usr/local/share/npm/bin:/Applications/Wine/.wine/bin:/Applications/Racket v6.2/bin/
/Users/nyholku/sdcc-3.4.0/bin/sdcc -c "-Wl -f 0xffff" --no-crt --ivt-loc=0x800 -V -L /Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -Wa,-S,0 -Wl,-m,-s18f45k50.lkr -mpic16 -p18f45k50 --disable-warning 85 --std-sdcc99 --obanksel=3 --use-non-free toad4.c -o ../obj/toad4.o
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
+ /Users/nyholku/sdcc-3.4.0/bin/sdcpp -nostdinc -Wall -Dpic18f45k50 -D__18f45k50 -D__SDCC_PIC18F45K50 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -obj-ext=.o -D__SDCC_USE_NON_FREE -DSDCC_USE_NON_FREE -D__SDCC_ALL_CALLEE_SAVES -D__SDCC=3_4_0 -DSDCC=340 -D__SDCC_REVISION=8981 -DSDCC_REVISION=8981 -D__SDCC_pic16 -DSDCC_pic16 -D__pic16 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__ -D__STDC_NO_ATOMICS__ -D__STDC_NO_VLA__ -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include/pic16 -isystem /usr/local/share/sdcc/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16 -isystem /usr/local/share/sdcc/non-free/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include -isystem /usr/local/share/sdcc/non-free/include  toad4.c 
+ gpasm -S 0 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o ../obj/toad4.o -c ../obj/toad4.asm
/Library/Frameworks/Python.framework/Versions/3.5/bin:/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/Users/nyholku/Desktop/ImageMagick-6.7.9/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Racket v6.5/bin:/opt/X11/bin:/usr/texbin:/Users/nyholku/android/tools:/sw/bin:/usr/local/share/npm/bin:/Applications/Wine/.wine/bin:/Applications/Racket v6.2/bin/
/Users/nyholku/sdcc-3.4.0/bin/sdcc -c "-Wl -f 0xffff" --no-crt --ivt-loc=0x800 -V -L /Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -Wa,-S,0 -Wl,-m,-s18f45k50.lkr -mpic16 -p18f45k50 --disable-warning 85 --std-sdcc99 --obanksel=3 --use-non-free usb_hid.c -o ../obj/usb_hid.o
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
+ /Users/nyholku/sdcc-3.4.0/bin/sdcpp -nostdinc -Wall -Dpic18f45k50 -D__18f45k50 -D__SDCC_PIC18F45K50 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -obj-ext=.o -D__SDCC_USE_NON_FREE -DSDCC_USE_NON_FREE -D__SDCC_ALL_CALLEE_SAVES -D__SDCC=3_4_0 -DSDCC=340 -D__SDCC_REVISION=8981 -DSDCC_REVISION=8981 -D__SDCC_pic16 -DSDCC_pic16 -D__pic16 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__ -D__STDC_NO_ATOMICS__ -D__STDC_NO_VLA__ -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include/pic16 -isystem /usr/local/share/sdcc/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16 -isystem /usr/local/share/sdcc/non-free/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include -isystem /usr/local/share/sdcc/non-free/include  usb_hid.c 
+ gpasm -S 0 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o ../obj/usb_hid.o -c ../obj/usb_hid.asm
/Library/Frameworks/Python.framework/Versions/3.5/bin:/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/Users/nyholku/Desktop/ImageMagick-6.7.9/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Racket v6.5/bin:/opt/X11/bin:/usr/texbin:/Users/nyholku/android/tools:/sw/bin:/usr/local/share/npm/bin:/Applications/Wine/.wine/bin:/Applications/Racket v6.2/bin/
/Users/nyholku/sdcc-3.4.0/bin/sdcc -c "-Wl -f 0xffff" --no-crt --ivt-loc=0x800 -V -L /Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -Wa,-S,0 -Wl,-m,-s18f45k50.lkr -mpic16 -p18f45k50 --disable-warning 85 --std-sdcc99 --obanksel=3 --use-non-free usb_core.c -o ../obj/usb_core.o
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
+ /Users/nyholku/sdcc-3.4.0/bin/sdcpp -nostdinc -Wall -Dpic18f45k50 -D__18f45k50 -D__SDCC_PIC18F45K50 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -obj-ext=.o -D__SDCC_USE_NON_FREE -DSDCC_USE_NON_FREE -D__SDCC_ALL_CALLEE_SAVES -D__SDCC=3_4_0 -DSDCC=340 -D__SDCC_REVISION=8981 -DSDCC_REVISION=8981 -D__SDCC_pic16 -DSDCC_pic16 -D__pic16 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__ -D__STDC_NO_ATOMICS__ -D__STDC_NO_VLA__ -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include/pic16 -isystem /usr/local/share/sdcc/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16 -isystem /usr/local/share/sdcc/non-free/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include -isystem /usr/local/share/sdcc/non-free/include  usb_core.c 
+ gpasm -S 0 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o ../obj/usb_core.o -c ../obj/usb_core.asm
/Library/Frameworks/Python.framework/Versions/3.5/bin:/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/Users/nyholku/Desktop/ImageMagick-6.7.9/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Racket v6.5/bin:/opt/X11/bin:/usr/texbin:/Users/nyholku/android/tools:/sw/bin:/usr/local/share/npm/bin:/Applications/Wine/.wine/bin:/Applications/Racket v6.2/bin/
/Users/nyholku/sdcc-3.4.0/bin/sdcc -c "-Wl -f 0xffff" --no-crt --ivt-loc=0x800 -V -L /Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -Wa,-S,0 -Wl,-m,-s18f45k50.lkr -mpic16 -p18f45k50 --disable-warning 85 --std-sdcc99 --obanksel=3 --use-non-free usb_pic_defs.c -o ../obj/usb_pic_defs.o
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
+ /Users/nyholku/sdcc-3.4.0/bin/sdcpp -nostdinc -Wall -Dpic18f45k50 -D__18f45k50 -D__SDCC_PIC18F45K50 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -obj-ext=.o -D__SDCC_USE_NON_FREE -DSDCC_USE_NON_FREE -D__SDCC_ALL_CALLEE_SAVES -D__SDCC=3_4_0 -DSDCC=340 -D__SDCC_REVISION=8981 -DSDCC_REVISION=8981 -D__SDCC_pic16 -DSDCC_pic16 -D__pic16 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__ -D__STDC_NO_ATOMICS__ -D__STDC_NO_VLA__ -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include/pic16 -isystem /usr/local/share/sdcc/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16 -isystem /usr/local/share/sdcc/non-free/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include -isystem /usr/local/share/sdcc/non-free/include  usb_pic_defs.c 
+ gpasm -S 0 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o ../obj/usb_pic_defs.o -c ../obj/usb_pic_defs.asm
/Library/Frameworks/Python.framework/Versions/3.5/bin:/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/Users/nyholku/Desktop/ImageMagick-6.7.9/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Racket v6.5/bin:/opt/X11/bin:/usr/texbin:/Users/nyholku/android/tools:/sw/bin:/usr/local/share/npm/bin:/Applications/Wine/.wine/bin:/Applications/Racket v6.2/bin/
/Users/nyholku/sdcc-3.4.0/bin/sdcc -c "-Wl -f 0xffff" --no-crt --ivt-loc=0x800 -V -L /Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -Wa,-S,0 -Wl,-m,-s18f45k50.lkr -mpic16 -p18f45k50 --disable-warning 85 --std-sdcc99 --obanksel=3 --use-non-free usb_user_config.c -o ../obj/usb_user_config.o
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
+ /Users/nyholku/sdcc-3.4.0/bin/sdcpp -nostdinc -Wall -Dpic18f45k50 -D__18f45k50 -D__SDCC_PIC18F45K50 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -obj-ext=.o -D__SDCC_USE_NON_FREE -DSDCC_USE_NON_FREE -D__SDCC_ALL_CALLEE_SAVES -D__SDCC=3_4_0 -DSDCC=340 -D__SDCC_REVISION=8981 -DSDCC_REVISION=8981 -D__SDCC_pic16 -DSDCC_pic16 -D__pic16 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__ -D__STDC_NO_ATOMICS__ -D__STDC_NO_VLA__ -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include/pic16 -isystem /usr/local/share/sdcc/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16 -isystem /usr/local/share/sdcc/non-free/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include -isystem /usr/local/share/sdcc/non-free/include  usb_user_config.c 
+ gpasm -S 0 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o ../obj/usb_user_config.o -c ../obj/usb_user_config.asm
/Library/Frameworks/Python.framework/Versions/3.5/bin:/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/Users/nyholku/Desktop/ImageMagick-6.7.9/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Racket v6.5/bin:/opt/X11/bin:/usr/texbin:/Users/nyholku/android/tools:/sw/bin:/usr/local/share/npm/bin:/Applications/Wine/.wine/bin:/Applications/Racket v6.2/bin/
/Users/nyholku/sdcc-3.4.0/bin/sdcc -c "-Wl -f 0xffff" --no-crt --ivt-loc=0x800 -V -L /Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -Wa,-S,0 -Wl,-m,-s18f45k50.lkr -mpic16 -p18f45k50 --disable-warning 85 --std-sdcc99 --obanksel=3 --use-non-free command_queue.c -o ../obj/command_queue.o
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
+ /Users/nyholku/sdcc-3.4.0/bin/sdcpp -nostdinc -Wall -Dpic18f45k50 -D__18f45k50 -D__SDCC_PIC18F45K50 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -obj-ext=.o -D__SDCC_USE_NON_FREE -DSDCC_USE_NON_FREE -D__SDCC_ALL_CALLEE_SAVES -D__SDCC=3_4_0 -DSDCC=340 -D__SDCC_REVISION=8981 -DSDCC_REVISION=8981 -D__SDCC_pic16 -DSDCC_pic16 -D__pic16 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__ -D__STDC_NO_ATOMICS__ -D__STDC_NO_VLA__ -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include/pic16 -isystem /usr/local/share/sdcc/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16 -isystem /usr/local/share/sdcc/non-free/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include -isystem /usr/local/share/sdcc/non-free/include  command_queue.c 
+ gpasm -S 0 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o ../obj/command_queue.o -c ../obj/command_queue.asm
/Library/Frameworks/Python.framework/Versions/3.5/bin:/opt/local/bin:/opt/local/sbin:/usr/local/sbin:/usr/local/bin:/Users/nyholku/Desktop/ImageMagick-6.7.9/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Racket v6.5/bin:/opt/X11/bin:/usr/texbin:/Users/nyholku/android/tools:/sw/bin:/usr/local/share/npm/bin:/Applications/Wine/.wine/bin:/Applications/Racket v6.2/bin/
/Users/nyholku/sdcc-3.4.0/bin/sdcc -c "-Wl -f 0xffff" --no-crt --ivt-loc=0x800 -V -L /Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -Wa,-S,0 -Wl,-m,-s18f45k50.lkr -mpic16 -p18f45k50 --disable-warning 85 --std-sdcc99 --obanksel=3 --use-non-free crt0iz_toad4.c -o ../obj/crt0iz_toad4.o
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
+ /Users/nyholku/sdcc-3.4.0/bin/sdcpp -nostdinc -Wall -Dpic18f45k50 -D__18f45k50 -D__SDCC_PIC18F45K50 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -obj-ext=.o -D__SDCC_USE_NON_FREE -DSDCC_USE_NON_FREE -D__SDCC_ALL_CALLEE_SAVES -D__SDCC=3_4_0 -DSDCC=340 -D__SDCC_REVISION=8981 -DSDCC_REVISION=8981 -D__SDCC_pic16 -DSDCC_pic16 -D__pic16 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__ -D__STDC_NO_ATOMICS__ -D__STDC_NO_VLA__ -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include/pic16 -isystem /usr/local/share/sdcc/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16 -isystem /usr/local/share/sdcc/non-free/include/pic16 -isystem /Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include -isystem /usr/local/share/sdcc/non-free/include  crt0iz_toad4.c 
+ gpasm -S 0 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o ../obj/crt0iz_toad4.o -c ../obj/crt0iz_toad4.asm
gpasm -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o ../obj/hi_speed_irq.o -c "hi_speed_irq.asm"
/Users/nyholku/sdcc-3.4.0/bin/sdcc "-Wl -f 0xffff" --no-crt --ivt-loc=0x800 -V -L /Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -Wa,-S,0 -Wl,-m,-s18f45k50.lkr -mpic16 -p18f45k50 --disable-warning 85 --std-sdcc99 --obanksel=3 --use-non-free -o ../obj/toad4.hex ../obj/main.o ../obj/toad4.o ../obj/usb_hid.o ../obj/usb_core.o ../obj/usb_pic_defs.o ../obj/usb_user_config.o ../obj/command_queue.o ../obj/crt0iz_toad4.o libc18f.lib libio18f45k50.lib libm18f.lib libsdcc.lib  ../obj/hi_speed_irq.o
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800
+ gplink -I/Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -I/Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/lib/pic16 -I/usr/local/share/sdcc/lib/pic16 -I/Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/lib/pic16 -I/usr/local/share/sdcc/non-free/lib/pic16  -f 0xffff  -m -s18f45k50.lkr  -w -r -o ../obj/toad4.hex  ../obj/main.o ../obj/toad4.o ../obj/usb_hid.o ../obj/usb_core.o ../obj/usb_pic_defs.o ../obj/usb_user_config.o ../obj/command_queue.o ../obj/crt0iz_toad4.o ../obj/hi_speed_irq.o   libc18f.lib libio18f45k50.lib libm18f.lib libsdcc.lib libdev18f45k50.lib libsdcc.lib 
warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000004] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000008] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000000] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000004] has no section. (pass 0)
warning: Relocation symbol "_cinit" [0x000008] has no section. (pass 0)

[Sdcc-user] problem with volatile struct member

[Daniel Drotos <drdani@ma...>]

Hi,

I'm using sdcc-stm8 with following code:

struct FLASH_t { ... ; volatile uint8_t iapsr; ...};
#define FLASH ((struct FLASH_t *)BASE_ADDRESS_OF_FLASH_CONTROLLER)

Program waits end of flash operation in a busy loop:

while ((FLASH->iapsr & 5) == 0) ...;

it works well rereading value of iapsr in every check. But in 
following structure:

uint8_t r= FLASH->iapsr;
while ((r & 5) == 0)
   r= FLASH->iapsr;

iapsr is read just once and the cycle uses that value without 
rereading the register. Even the following code uses the value which 
has been read before the cycle:

uint8_t r= FLASH->iapsr & 5;
while ((FLASH->iapsr & 5) == 0) ...

It looks that "volatile"-ness of a struct member disappears in some 
situations. Is it OK in C, or is it a bug?

Daniel

Re: [Sdcc-user] ADCON0bits.CHS missing from pic18f45k50.h

[Gál Zsolt <tralitoverin@fr...>]

Hello,

The sddc headers are generated from Microchip assembly processor header
files (.inc).

Here is the source ( p18f45k50.inc ):

;----- ADCON0 Bits -----------------------------------------------------
ADON             EQU  H'0000'
GO_NOT_DONE      EQU  H'0001'

DONE             EQU  H'0001'

GO               EQU  H'0001'

NOT_DONE         EQU  H'0001'

another source ( p18f46k20.inc ):

;----- ADCON0 Bits -----------------------------------------------------
ADON             EQU  H'0000'
GO_NOT_DONE      EQU  H'0001'

DONE             EQU  H'0001'
CHS0             EQU  H'0002'
CHS1             EQU  H'0003'
CHS2             EQU  H'0004'
CHS3             EQU  H'0005'

NOT_DONE         EQU  H'0001'

GO_DONE          EQU  H'0001'

GO               EQU  H'0001'

I think Microchip missed the CHS bits from the .inc file and this is not
sdcc bug.

Regards,

  Zsolt

2017-07-13 10:01 GMT+02:00 Kustaa Nyholm <kustaa.nyholm@...>:

> Hi,
>
> ADCON0bits struct def seems to miss CHS bit field which is available for
> 18F4550 in pic18f4550.h
>
> Also CHS0..CHS3 are missing.
>
> Further pic18f4550.h defines GO_NOT_DONE, GO, NOT_DONE and DONE fields for
> ADCON0, last
> of which seems wrong because the bit  meaning is "go/not done" so DONE
> does not make sense.
>
> Where do these definitions come from, do they have Microchip origins or is
> this just
> a regular typo/bug in SDCC?
>
> Should I file a bug report?
>
> I'm using sdcc 3.4.0
>
> wbr Kusti
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>



-- 
~~~~~~~~~~~~~~~~
http://galzsolt.zzl.org

Re: [Sdcc-user] stm8 "far" pointer

[史斌 <powerstudio1st@16...>]

As far as I remembered , stm8 backend does not suppport far pointer, maybe only inline assembly can do it?


Ben Shi

> 在 2017年7月16日，05:52，Daniel Drotos <drdani@...> 写道：
> 
> 
> Hi,
> 
> I'm testing simulation of stm8 flash controller in ucsim. To start a program/erase operation flash area must be written as data. sdcc-stm8 uses 16 bit pointers, is it possible to address over 64k somehow?
> 
> Daniel
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user

[Sdcc-user] stm8 "far" pointer

[Daniel Drotos <drdani@ma...>]

Hi,

I'm testing simulation of stm8 flash controller in ucsim. To start a 
program/erase operation flash area must be written as data. sdcc-stm8 
uses 16 bit pointers, is it possible to address over 64k somehow?

Daniel

[Sdcc-user] ADCON0bits.CHS missing from pic18f45k50.h

[Kustaa Nyholm <kustaa.nyholm@sp...>]

Hi,

ADCON0bits struct def seems to miss CHS bit field which is available for 18F4550 in pic18f4550.h 

Also CHS0..CHS3 are missing.

Further pic18f4550.h defines GO_NOT_DONE, GO, NOT_DONE and DONE fields for ADCON0, last
of which seems wrong because the bit  meaning is "go/not done" so DONE does not make sense.

Where do these definitions come from, do they have Microchip origins or is this just 
a regular typo/bug in SDCC?

Should I file a bug report?

I'm using sdcc 3.4.0

wbr Kusti

Re: [Sdcc-user] Get the builtin macros list?

[陳韋任 <chenwj.cs97g@g2...>]

SDCC leverages GNU cpp I think, have you read [1] and gave it a try?

[1] http://sdcc.sourceforge.net/doc/sdccman.pdf

HTH,
chenwj


2017-06-14 4:38 GMT+08:00 Miklos Marton <martonmiklosqdev@...>:
> Hello all,
>
> I am trying to use the SDCC's STM8 port with the QtCreator IDE with the QBS
> build system.
>
> The QBS tries to get the predefined macros by running the compiler with
> "-Wp,-dM -E -x c /dev/null" arguments (in the case of gcc):
>
> mm@...:~$ gcc -Wp,-dM -E -x c /dev/null
> #define __SSP_STRONG__ 3
> #define __DBL_MIN_EXP__ (-1021)
> #define __UINT_LEAST16_MAX__ 0xffff
> #define __ATOMIC_ACQUIRE 2
> #define __FLT_MIN__ 1.17549435082228750797e-38F
> #define __GCC_IEC_559_COMPLEX 2
> #define __UINT_LEAST8_TYPE__ unsigned char
> #define __SIZEOF_FLOAT80__ 16
> #define __INTMAX_C(c) c ## L
> #define __CHAR_BIT__ 8
> #define __UINT8_MAX__ 0xff
>
> ....
>
> Is there any similar argument list with the same could be queried in SDCC?
>
> --
> Best regards,
> Miklos Marton
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user



-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj

Re: [Sdcc-user] OS X change preprocessor

[Erik Petrich <epetrich@iv...>]

On Fri, 30 Jun 2017, Maxwell Leiter via Sdcc-user wrote:

> Hi,On OS X, Apple has decided to symlink `gcc` to `clang` (and all related
> tools to their clang equivalents). So, I need to use `gcc-7` specifically to
> use `gcc`. Is there a way to pass options to sdcc to use `gcc-7` instead of
> `gcc`? Specifically, it uses `cpp` in SDCCmain.c

If you are just using SDCC, rather than trying to build it, you probably 
don't need to do anything at all. The references in SDCCmain.c to cpp will 
ultimately call an executable named "sdcpp" which is SDCC's customized 
version of gcc's preprocessor rather than use the system's generic C 
preprocessor.

   Erik

Re: [Sdcc-user] OS X change preprocessor

[Philipp Klaus Krause <pkk@sp...>]

Am 30.06.2017 um 18:43 schrieb Maxwell Leiter via Sdcc-user:
> Hi,
> On OS X, Apple has decided to symlink `gcc` to `clang` (and all related
> tools to their clang equivalents). So, I need to use `gcc-7`
> specifically to use `gcc`. Is there a way to pass options to sdcc to use
> `gcc-7` instead of `gcc`? Specifically, it uses `cpp` in SDCCmain.c
> 
> Thanks

According to ./configure --help output, setting CC, CXX, CPP and CXXCPP
should allow you to set the compiler and preprocessor used to compile SDCC.

Philipp

P.S.: I also use these on Debian GNU/Linux when I want to compile SDCC
with a GCC version newer than the default.

[Sdcc-user] OS X change preprocessor

[Maxwell Leiter <mleiter18@pr...>]

Hi,
On OS X, Apple has decided to symlink `gcc` to `clang` (and all related
tools to their clang equivalents). So, I need to use `gcc-7` specifically
to use `gcc`. Is there a way to pass options to sdcc to use `gcc-7` instead
of `gcc`? Specifically, it uses `cpp` in SDCCmain.c

Thanks

Re: [Sdcc-user] uCsim / asim: non-interactive serial port communication through netcat

[<tg9541@gm...>]

Hello Daniel,

thanks for your answer!


On 24/06/17 21:05, Daniel Drotos wrote:
> On Sat, 24 Jun 2017, tg9541@... wrote:
>
>> This means that a program outside of uCsim needs to monitor the reply 
>> from the µC code before the next line of input can be sent 
>> (handshake, half-duplex operation).
>
> Well, I don't have solution for this scenario. What about expect? I've 
> never used it, but it is for kind of similar problems.
I had looked into using `expect` but I think that it's not flexible 
enough for scripting test interaction.
>
>> * I need to interact with the same simulator process from different 
>> sides for an extended period of time (command, and serial)
>
> If you have to do it in sync, I don't know how could you do it. Once, 
> I've planned to implement a command which pushes data directly to 
> USART input, so every input would be controllable from one command 
> line. Combined with breakpoints, it could be some (complicate) solution.
Using the Python telnet library leads to surprisingly simple solutions:

```
#!/usr/bin/env python
import sys
import telnetlib

HOST = "localhost"
path = "f/inter.fs"
tn = telnetlib.Telnet(HOST,10000)
tn.read_until("menu\r\n")

with open(path) as source:
     for line in source.readlines():
         tn.write(line + '\r')
         print tn.expect(['(\v|\n)'])[2]
```

In this case the regexp in `tn.expect` line does the synchronization 
(either '\v' (pace) or '\n' are expected). The `tn.read_until` line 
deals with the `uCsum` telnet "hello message".

>> I tried using named pipes as an alternative to sockets but that 
>> didn't work.
>
> You know that opening of a pipe is blocked until other side is opened. 
> When you start ucsim:
>
> mkfifo i o
> sstm8 -Suart=1,in=i,out=o
>
> OS blocks it in open of "i". You have to go to an other window/login 
> etc, and open other side of i:
>
> cat prepared_input.txt >i
>
> (or nc, or your other program), now ucsim can go on and try to open 
> "o", but it blocks again, so you have to pick an other window and open 
> other side of o:
>
> cat o >grab.txt
>
> and ucsim can continue.
>
For most problems this is a good solution. However, I guess that for 
tightly coupled I/O the telnet approach works better.

>> Strangely, writing prepared simulator input to a file and using it 
>> with the "in" attribute didn't work either: the file specified with 
>> the "out" attribute was never written.
>
> Interesting, it works for me. Can you tell me more about it?
>

My second (quote overload) message to the list (sorry everybody!) 
contained the answer:

 > found the reason for the "strange" behaviour described below, which 
is maybe the key to a solution on my side:
 > `netcat` depends on TTY line processing, which means that newline 
gets consumed instead of being passed on to the UART simulation through 
the socket. A work around is inserting `CTRL-V` (verbatim) before 
`CTRL-M` (newline).
 > Note that the TTY's control character for "verbatim" can be read from 
the output of `stty -a` ("lnext = ^V;").

The Python library also has a solution to this complication.

> Daniel
>
> I forgot your problem about CTRL-x. It has a bug indeed, becouse it is 
> always interpreted, even if usart input file is non-tty. You can 
> workaround it by changing escape charater to somthing non-used one. If 
> the communication is non-binary, it probably can be zero. You can 
> change it with:
>
> expr uart1_esc_char=0

Your work is, as always, highly appreciated! Thanks!

Re: [Sdcc-user] uCsim / asim: non-interactive serial port communication through netcat

[Daniel Drotos <drdani@ma...>]

On Sat, 24 Jun 2017, tg9541@... wrote:

> This means that a program outside of uCsim needs to monitor the reply 
> from the µC code before the next line of input can be sent (handshake, 
> half-duplex operation).

Well, I don't have solution for this scenario. What about expect? I've 
never used it, but it is for kind of similar problems.

> * I need to interact with the same simulator process from different 
> sides for an extended period of time (command, and serial)

If you have to do it in sync, I don't know how could you do it. Once, 
I've planned to implement a command which pushes data directly to 
USART input, so every input would be controllable from one command 
line. Combined with breakpoints, it could be some (complicate) 
solution.

> I tried using named pipes as an alternative to sockets but that didn't 
> work.

You know that opening of a pipe is blocked until other side is opened. 
When you start ucsim:

mkfifo i o
sstm8 -Suart=1,in=i,out=o

OS blocks it in open of "i". You have to go to an other window/login 
etc, and open other side of i:

cat prepared_input.txt >i

(or nc, or your other program), now ucsim can go on and try to open 
"o", but it blocks again, so you have to pick an other window and open 
other side of o:

cat o >grab.txt

and ucsim can continue.

> Strangely, writing prepared simulator input to a file and using it 
> with the "in" attribute didn't work either: the file specified with the 
> "out" attribute was never written.

Interesting, it works for me. Can you tell me more about it?

Daniel

I forgot your problem about CTRL-x. It has a bug indeed, becouse it is 
always interpreted, even if usart input file is non-tty. You can 
workaround it by changing escape charater to somthing non-used one. If 
the communication is non-binary, it probably can be zero. You can 
change it with:

expr uart1_esc_char=0

Re: [Sdcc-user] uCsim / asim: non-interactive serial port communication through netcat

[<tg9541@gm...>]

OK, I found the reason for the "strange" behaviour described below, 
which is maybe the key to a solution on my side:

`netcat` depends on TTY line processing, which means that newline gets 
consumed instead of being passed on to the UART simulation through the 
socket. A work around is inserting `CTRL-V` (verbatim) before `CTRL-M` 
(newline).

Note that the TTY's control character for "verbatim" can be read from 
the output of `stty -a` ("lnext = ^V;").

Thanks again!

On 24/06/17 17:34, tg9541@... wrote:
> Hi Daniel,
>
> thanks for the answer!
>
> However, the STM8 code I intend to test implements an interactive 
> console. An important detail is that , and I've got the following 
> problems with the proposed solution:
>
> * The processing of serial input data by the simulator code takes 
> time. This means that a program outside of uCsim needs to monitor the 
> reply from the µC code before the next line of input can be sent 
> (handshake, half-duplex operation).
> * I need to interact with the same simulator process from different 
> sides for an extended period of time (command, and serial)
>
> I tried using named pipes as an alternative to sockets but that didn't 
> work. Strangely, writing prepared simulator input to a file and using 
> it with the "in" attribute didn't work either: the file specified with 
> the "out" attribute was never written.
>
> Best Regards,
> Thomas
>
> On 24/06/17 12:27, Daniel Drotos wrote:
>> On Fri, 23 Jun 2017, tg9541@... wrote:
>>
>>> I'd like to use the uC simulation uCsim for test automation, and my 
>>> use-case requires the uCsim serial port simulation to exchange 
>>> information through a script.
>>
>> You can find some examples for this usage in ucsim source code, see 
>> example, s51.src/test, stm8.src/test directories. Becouse they are 
>> hard to follow, I'll try to summarize a mini-HOWTO.
>>
>> Main rule is that you sould not use interactive terminals but use 
>> files instead. If ucsim detects non-tty files, it assumes 
>> non-interactivity and will not issue telnet commands, so that 
>> "garbage" will not appear.
>>
>> Using file for serial comminication is easy. Prepare input content in 
>> a file and start ucsim with:
>>
>> -Suart=1,in=prepared.txt
>>
>> option, or:
>>
>> -Suart=1,in=prepared.txt,out=grabbedout.txt
>>
>> Automation of command console is more problematic but there are some 
>> tricks for it.
>>
>> Do not use -Z option, but prepare commands in a file and pass this to 
>> simulator. If you do not need to execute commands after simulation, 
>> you can use -C option to pass command file:
>>
>> -C commands.txt
>>
>> Becouse it should not contain "run" command, you should use -g (or 
>> -G) as well:
>>
>> -C commands.txt -G
>>
>> ucsim will execute content of "commands.txt" and start the simulation 
>> after. If you use -G instead of -g, it will quit when the simulation 
>> stops somehow (see later).
>>
>> If you need commands after run, it is better to use redirection:
>>
>> cat "commands.txt"|sstm8 ...
>>
>> or
>>
>> sstm8 ... <commands.txt
>>
>> On windows, I recommend redirection instead of using pipe.
>>
>> Command script can contain preparation commands, run command, and 
>> status check commands after the simulation.
>>
>> Every command script which has "run" command, must be executed on a 
>> non-interactive console, otherwise the very first command line after 
>> the run will be recognized as "enter press" and stop the simulation. 
>> Redirection is a way to make the console non-interactive. Other way 
>> can be a command placed in the script itself:
>>
>> set console interactive off
>>
>> If you use status check commands (dump, etc.) and want to check the 
>> results later, redirect output as well:
>>
>> sstm8 <commands.txt >result.txt
>>
>> You can separate output of status check commands to different files, 
>> using ucsim command redirection:
>>
>> dc ... >out_of_dc.txt
>> dump ... >dump.txt
>>
>> dump command accepts file format specifier:
>>
>> dump /format params >out_file.txt
>>
>> format can be s (string), h (hex, this is the default), i (intel 
>> hex), b (binary).
>>
>> If you do not use other consoles (do not use -Z) simulator will quit 
>> after executing command script, so quit/kill command is not needed.
>>
>> Started simulation can be stopped in several ways: using fetch 
>> breakpoint, event breakpint, or simulator interface.
>>
>> Using fetch breakpoint needs some preparation:
>>
>> - compile with sdcc
>> - use -debug to generate debug info
>> - use -debug when link, to produce cdb file
>> - define a function to place a breakpoint on it
>> - call that function to stop the simulation
>>
>> when start ucsim, do not use .ihx file extension:
>>
>> sstm8 hex_file_name
>>
>> ucsim will load ihx file, and will automaticaly load cdb file with 
>> the same name. You can prepare the breakpoint using function name:
>>
>> break stopper_function_name
>>
>> when the program calls this function, breakpoint will stop the 
>> simulation, run command finishes, and script execution continues.
>>
>> Using event breakpoint is probably simpler, this method is used in 
>> sdcc regression tests.
>>
>> Select a memory location which is acessible but do not used by the 
>> real hardware. In simulator script, define an event breakpoint on the 
>> selected location, for example:
>>
>> break rom read 0x27fff
>>
>> in simulated program perform a read on that location to stop the 
>> program:
>>
>> volatile char c= *(char *)0x27fff;
>>
>> Using the simulator interface is the most flexible way. Select a 
>> memory location which is not used by the real hardware. Place the 
>> interface behind that location by turning it on. It can be turned on 
>> in two ways. Using -I option:
>>
>> -I rom[0x27fff]
>>
>> or in simulator script:
>>
>> set hw simif rom 0x27fff
>>
>> Simulated program can use this location to interact with the 
>> interface. "Stop" feature can be activated by sending "stop" command:
>>
>> unsigned char * volatile sif;
>> sif= (unsigned char *)0x27fff;
>> *sif= 's';
>>
>> Daniel
>>
>> ------------------------------------------------------------------------------ 
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Sdcc-user mailing list
>> Sdcc-user@...
>> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>>
>
>
> ------------------------------------------------------------------------------ 
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] uCsim / asim: non-interactive serial port communication through netcat

[<tg9541@gm...>]

Hi Daniel,

thanks for the answer!

However, the STM8 code I intend to test implements an interactive 
console. An important detail is that , and I've got the following 
problems with the proposed solution:

* The processing of serial input data by the simulator code takes time. 
This means that a program outside of uCsim needs to monitor the reply 
from the µC code before the next line of input can be sent (handshake, 
half-duplex operation).
* I need to interact with the same simulator process from different 
sides for an extended period of time (command, and serial)

I tried using named pipes as an alternative to sockets but that didn't 
work. Strangely, writing prepared simulator input to a file and using it 
with the "in" attribute didn't work either: the file specified with the 
"out" attribute was never written.

Best Regards,
Thomas

On 24/06/17 12:27, Daniel Drotos wrote:
> On Fri, 23 Jun 2017, tg9541@... wrote:
>
>> I'd like to use the uC simulation uCsim for test automation, and my 
>> use-case requires the uCsim serial port simulation to exchange 
>> information through a script.
>
> You can find some examples for this usage in ucsim source code, see 
> example, s51.src/test, stm8.src/test directories. Becouse they are 
> hard to follow, I'll try to summarize a mini-HOWTO.
>
> Main rule is that you sould not use interactive terminals but use 
> files instead. If ucsim detects non-tty files, it assumes 
> non-interactivity and will not issue telnet commands, so that 
> "garbage" will not appear.
>
> Using file for serial comminication is easy. Prepare input content in 
> a file and start ucsim with:
>
> -Suart=1,in=prepared.txt
>
> option, or:
>
> -Suart=1,in=prepared.txt,out=grabbedout.txt
>
> Automation of command console is more problematic but there are some 
> tricks for it.
>
> Do not use -Z option, but prepare commands in a file and pass this to 
> simulator. If you do not need to execute commands after simulation, 
> you can use -C option to pass command file:
>
> -C commands.txt
>
> Becouse it should not contain "run" command, you should use -g (or -G) 
> as well:
>
> -C commands.txt -G
>
> ucsim will execute content of "commands.txt" and start the simulation 
> after. If you use -G instead of -g, it will quit when the simulation 
> stops somehow (see later).
>
> If you need commands after run, it is better to use redirection:
>
> cat "commands.txt"|sstm8 ...
>
> or
>
> sstm8 ... <commands.txt
>
> On windows, I recommend redirection instead of using pipe.
>
> Command script can contain preparation commands, run command, and 
> status check commands after the simulation.
>
> Every command script which has "run" command, must be executed on a 
> non-interactive console, otherwise the very first command line after 
> the run will be recognized as "enter press" and stop the simulation. 
> Redirection is a way to make the console non-interactive. Other way 
> can be a command placed in the script itself:
>
> set console interactive off
>
> If you use status check commands (dump, etc.) and want to check the 
> results later, redirect output as well:
>
> sstm8 <commands.txt >result.txt
>
> You can separate output of status check commands to different files, 
> using ucsim command redirection:
>
> dc ... >out_of_dc.txt
> dump ... >dump.txt
>
> dump command accepts file format specifier:
>
> dump /format params >out_file.txt
>
> format can be s (string), h (hex, this is the default), i (intel hex), 
> b (binary).
>
> If you do not use other consoles (do not use -Z) simulator will quit 
> after executing command script, so quit/kill command is not needed.
>
> Started simulation can be stopped in several ways: using fetch 
> breakpoint, event breakpint, or simulator interface.
>
> Using fetch breakpoint needs some preparation:
>
> - compile with sdcc
> - use -debug to generate debug info
> - use -debug when link, to produce cdb file
> - define a function to place a breakpoint on it
> - call that function to stop the simulation
>
> when start ucsim, do not use .ihx file extension:
>
> sstm8 hex_file_name
>
> ucsim will load ihx file, and will automaticaly load cdb file with the 
> same name. You can prepare the breakpoint using function name:
>
> break stopper_function_name
>
> when the program calls this function, breakpoint will stop the 
> simulation, run command finishes, and script execution continues.
>
> Using event breakpoint is probably simpler, this method is used in 
> sdcc regression tests.
>
> Select a memory location which is acessible but do not used by the 
> real hardware. In simulator script, define an event breakpoint on the 
> selected location, for example:
>
> break rom read 0x27fff
>
> in simulated program perform a read on that location to stop the program:
>
> volatile char c= *(char *)0x27fff;
>
> Using the simulator interface is the most flexible way. Select a 
> memory location which is not used by the real hardware. Place the 
> interface behind that location by turning it on. It can be turned on 
> in two ways. Using -I option:
>
> -I rom[0x27fff]
>
> or in simulator script:
>
> set hw simif rom 0x27fff
>
> Simulated program can use this location to interact with the 
> interface. "Stop" feature can be activated by sending "stop" command:
>
> unsigned char * volatile sif;
> sif= (unsigned char *)0x27fff;
> *sif= 's';
>
> Daniel
>
> ------------------------------------------------------------------------------ 
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

Re: [Sdcc-user] uCsim / asim: non-interactive serial port communication through netcat

[Daniel Drotos <drdani@ma...>]

On Fri, 23 Jun 2017, tg9541@... wrote:

> I'd like to use the uC simulation uCsim for test automation, and my use-case 
> requires the uCsim serial port simulation to exchange information through a 
> script.

You can find some examples for this usage in ucsim source code, see 
example, s51.src/test, stm8.src/test directories. Becouse they are 
hard to follow, I'll try to summarize a mini-HOWTO.

Main rule is that you sould not use interactive terminals but use 
files instead. If ucsim detects non-tty files, it assumes 
non-interactivity and will not issue telnet commands, so that 
"garbage" will not appear.

Using file for serial comminication is easy. Prepare input content in 
a file and start ucsim with:

-Suart=1,in=prepared.txt

option, or:

-Suart=1,in=prepared.txt,out=grabbedout.txt

Automation of command console is more problematic but there are some 
tricks for it.

Do not use -Z option, but prepare commands in a file and pass this to 
simulator. If you do not need to execute commands after simulation, 
you can use -C option to pass command file:

-C commands.txt

Becouse it should not contain "run" command, you should use -g (or -G) 
as well:

-C commands.txt -G

ucsim will execute content of "commands.txt" and start the simulation 
after. If you use -G instead of -g, it will quit when the simulation 
stops somehow (see later).

If you need commands after run, it is better to use redirection:

cat "commands.txt"|sstm8 ...

or

sstm8 ... <commands.txt

On windows, I recommend redirection instead of using pipe.

Command script can contain preparation commands, run command, and 
status check commands after the simulation.

Every command script which has "run" command, must be executed on a 
non-interactive console, otherwise the very first command line after 
the run will be recognized as "enter press" and stop the simulation. 
Redirection is a way to make the console non-interactive. Other way 
can be a command placed in the script itself:

set console interactive off

If you use status check commands (dump, etc.) and want to check the 
results later, redirect output as well:

sstm8 <commands.txt >result.txt

You can separate output of status check commands to different files, 
using ucsim command redirection:

dc ... >out_of_dc.txt
dump ... >dump.txt

dump command accepts file format specifier:

dump /format params >out_file.txt

format can be s (string), h (hex, this is the default), i (intel hex), 
b (binary).

If you do not use other consoles (do not use -Z) simulator will quit 
after executing command script, so quit/kill command is not needed.

Started simulation can be stopped in several ways: using fetch 
breakpoint, event breakpint, or simulator interface.

Using fetch breakpoint needs some preparation:

- compile with sdcc
- use -debug to generate debug info
- use -debug when link, to produce cdb file
- define a function to place a breakpoint on it
- call that function to stop the simulation

when start ucsim, do not use .ihx file extension:

sstm8 hex_file_name

ucsim will load ihx file, and will automaticaly load cdb file with the 
same name. You can prepare the breakpoint using function name:

break stopper_function_name

when the program calls this function, breakpoint will stop the 
simulation, run command finishes, and script execution continues.

Using event breakpoint is probably simpler, this method is used in 
sdcc regression tests.

Select a memory location which is acessible but do not used by the 
real hardware. In simulator script, define an event breakpoint on the 
selected location, for example:

break rom read 0x27fff

in simulated program perform a read on that location to stop the 
program:

volatile char c= *(char *)0x27fff;

Using the simulator interface is the most flexible way. Select a 
memory location which is not used by the real hardware. Place the 
interface behind that location by turning it on. It can be turned on 
in two ways. Using -I option:

-I rom[0x27fff]

or in simulator script:

set hw simif rom 0x27fff

Simulated program can use this location to interact with the 
interface. "Stop" feature can be activated by sending "stop" command:

unsigned char * volatile sif;
sif= (unsigned char *)0x27fff;
*sif= 's';

Daniel

[Sdcc-user] uCsim / asim: non-interactive serial port communication through netcat

[<tg9541@gm...>]

Hi all,

I'd like to use the uC simulation uCsim for test automation, and my 
use-case requires the uCsim serial port simulation to exchange 
information through a script.

Entering commands through `netcat` works fine for the emulator console, 
it fails for the simulated serial interface (which works fine as an 
interactive telnet "serial console").

Here is an example script that demonstrates my use-case:

```

#!/bin/bash
# requires SSTM8 >= https://svn.code.sf.net/p/sdcc/code/trunk/?p=9924

./sstm8 -w -g -C/tmp/sstm8-start.txt -Z10001 -tS103 -Suart=1,port=10000 
out/MINDEV/MINDEV.ihx &
sleep 1

nc localhost 10000 <<EOF >out-console.txt
1 .

EOF

nc localhost 10001 <<EOF >out-memory.txt
dch 0x8000 0x9FFF 16

EOF

nc localhost 10001 <<EOF
kill

EOF

```

There is no noticeable difference of behaviour between interactive 
"simulation console" and "serial console" sessions, and some control 
character "garbage" appears on the output of a scripted "simulation 
console".

```

<FF><FB>^A<FF><FB>^C^@uCsim 0.6-pre30, Copyright (C) 1997 Daniel Drotos.
uCsim comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
3> dch 0x8000 0x9FFF 16

0x08000 82 00 80 83 82 00 80 a3 82 00 00 00 82 00 00 00 ................
0x08010 82 00 00 00 82 00 81 6f 82 00 81 6f 82 00 81 6f .......o...o...o
0x08020 82 00 81 6f 82 00 00 00 82 00 00 00 82 00 00 00 ...o............
0x08030 82 00 00 00 82 00 00 00 82 00 00 00 82 00 80 b6 ................
0x08040 82 00 00 00 82 00 00 00 82 00 00 00 82 00 00 00 ................

```

I can work around control characters, and the input echo in the output. 
However, even in a non-interactive "serial console" session, I can only 
enter text lines by inserting `CTRL-lowercase_L` after `new-line` (and 
that means working around a feature that's not needed in a complicated 
way).

It appears to me that the interactive `telnet` behaviour is by design 
(e.g. `sim.src/serial_hw.cc` has a line `i->set_telnet(true);`). There 
is also an (undocumented?) "simulation console" accessible through the 
"serial console" which makes no sense in non-interactive mode (`CTRL-x` 
in a "serial console" session).

For test automation the following features would be beneficial (in the 
order from "required" to "nice to have"):

* working non interactive "serial console" (at least like it's now in 
the "simulation console")

* proper non-interactive behaviour of "simulation console" and "serial 
console" (i.e. no echo, no telnet control characters)

* command line option for disabling console mode selection (`CTRL-x`) in 
the "serial console"

Thanks in advance!

/Thomas

[Sdcc-user] Get the builtin macros list?

[Miklos Marton <martonmiklosqdev@gm...>]

Hello all,

I am trying to use the SDCC's STM8 port with the QtCreator IDE with the 
QBS build system.

The QBS tries to get the predefined macros by running the compiler with 
"-Wp,-dM -E -x c /dev/null" arguments (in the case of gcc):

mm@...:~$ gcc -Wp,-dM -E -x c /dev/null
#define __SSP_STRONG__ 3
#define __DBL_MIN_EXP__ (-1021)
#define __UINT_LEAST16_MAX__ 0xffff
#define __ATOMIC_ACQUIRE 2
#define __FLT_MIN__ 1.17549435082228750797e-38F
#define __GCC_IEC_559_COMPLEX 2
#define __UINT_LEAST8_TYPE__ unsigned char
#define __SIZEOF_FLOAT80__ 16
#define __INTMAX_C(c) c ## L
#define __CHAR_BIT__ 8
#define __UINT8_MAX__ 0xff

....

Is there any similar argument list with the same could be queried in SDCC?

-- 
Best regards,
Miklos Marton

Re: [Sdcc-user] uCsim for STM8 question (0.6-pre28)

[Daniel Drotos <drdani@ma...>]

On Sat, 10 Jun 2017, Thomas Goeppel wrote:

> * Is there a "trace" feature in uCsim? Some use cases would greatly benefit 
> from a trace/log of all the executed instructions, e.g. between two triggers.

No (officialy), but there is a hidden/secret feature which works like 
this:-)

If you start ucsim with -J option, trace will be turned on, and 
_every_ instruction will print out cpu state like "info reg".

Tracing can be checked and turned on/off using "jaj" command which 
accepts a boolean parameter:

$ ./sstm8
uCsim 0.6-pre30, Copyright (C) 1997 Daniel Drotos.
uCsim comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
0> jaj
0
0> s 100
Stop at 0x0080c8: (109)
V-IHINZC  Flags= 0x2d  45 -  A= 0x00   0 .
0-101101  X= 0x0000   0 .    Y= 0x0000   0 .
SP= 0x17ff [SP+1]= 00   0 .
  ? 0x080c8 00 00          neg   (0x00,SP)
F 0x0080c8
Simulated 100 ticks in 0.000044 sec, rate=0.284939
0> jaj 1
1
0> s 2
V-IHINZC  Flags= 0x29  41 )  A= 0x00   0 .
0-101001  X= 0x0000   0 .    Y= 0x0000   0 .
SP= 0x17ff [SP+1]= 00   0 .
  ? 0x080ca 00 00          neg   (0x00,SP)

Stop at 0x0080cc: (109)
V-IHINZC  Flags= 0x2d  45 -  A= 0x00   0 .
0-101101  X= 0x0000   0 .    Y= 0x0000   0 .
SP= 0x17ff [SP+1]= 00   0 .
  ? 0x080cc 00 00          neg   (0x00,SP)
F 0x0080cc
Simulated 2 ticks in 0.000046 sec, rate=0.005433
0>

Daniel

[Sdcc-user] structs, array of structs, declaring and using, memory bank boundary, timers

[Ubirajara Marques da Cruz <biracruz@ce...>]

Hi all,

I´ve been trying to implement TDC(time delay close) and TDO (time delay open) contact relays into pic program and I am facing some trouble that I need to clarify. I am working with pic 16f877a and SDCC 3.6. I´m not an assembler programmer only C programmer.

What my program need to do.
It need to charge datas asynchronous event time into an array of timer event structures, sequences it, and order fastest event to slowest and change output relay into right time. I plan to use only one  pic timer to do this and I can have until 6 time contact relays.

1st) About struct
I created a typedef struct tmrevent that holds 5 int members to hold TMR1H, TMR1L, overflowtimertimes and another int datas. Into Gcc this array could be done like this:

Typedef struct tmrevent {
int member1;
int member2;
...
int member;
};

tmrevent  tv[4];

this code in Gcc works fine and I have an array of tmrevent struct with 4 structs. But in SDCC this code compiles but doesn't link. Why?
Is there another way to define an array of structs in SDCC? Could you tell me pls?

2nd) If I address only one struct my code works but I must declare it like an array like below and only one array element is possible to use. My sdcc installation doesn´t have MALLOC.H header file to declare a space to hold many struct in a pointer.

__at(0x0020) tmrevent tv[]; // compiles and linker but only one element works

3rd) I read sdcc 3.6.1 manual item 3.1.1 (only this item talk about structures in manual ) but I can´t clarify much about how structs could be declare with sdcc. Could you inform some book or tutorial that cover this subject. I will appreciate a lot.

4th) I did a test declaring many separate timer event structs addressing directly all of them respecting GPIO addressable memory. I try to use more than a memory bank and another problem occurs. It seems bank 1 is mirrored of bank 0. I found some posts that tell about this condition but none explain how to use direct address to write member structs in the correct bank. For example if I declare a struct in address 0x0020 (first gpio in bank 0 ) the code works fine. If I declare this struct into address 0x00A0 (first gpio in bank 1) sometimes the code works sometimes don´t. What could be? It seems when program counter is on bank 1 or bank 2 or 3 and interrupt overflow time occurs data that will be record in bank 0 isn´t correctly write. But in SDCC I didn´t find any example to solve this doubt.

I will appreciate a lot some answer.

Thank you all

Ubirajara Marques da Cruz
Email: biracruz@...<mailto:biracruz@...>

As informações contidas nesta mensagem e nos arquivos anexados são para uso exclusivo do destinatário aqui indicado e podem conter assuntos comerciais, de propriedade intelectual ou outras informações confidenciais, protegidas pelas leis aplicáveis. É expressamente proibido o uso não autorizado ou a disseminação desta mensagem ou parte dela. Caso não seja o destinatário correto, por favor, notifique o remetente.

Re: [Sdcc-user] Can't figure out how to write interrupt handlers for Z80 using SDCC

[alvin albrecht <alvin_albrecht@ho...>]

> but can't figure out how to use the above example crt0.s file with SDCC for a Z80 target. Using the --use-crt switch doesn't seem to work.
> unknown compiler option '--use-crt=crt0.s' ignored

Have a look here for an example of using a custom crt.s:
https://github.com/z88dk/z88dk/tree/master/libsrc/_DEVELOPMENT/EXAMPLES/benchmarks/dhrystone21/sdcc/verify

Read Winmake.bat to see how the program is compiled.

Re: [Sdcc-user] Can't figure out how to write interrupt handlers for Z80 using SDCC

[Maarten Brock <sourceforge.brock@ds...>]

Hello Adam,

I think you're supposed to take our crt.s and modifiy it to your needs
with the missing jumps.
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/lib/z80/crt0.s

Assemble it and then link it with the rest of your application.

Maarten

> Hi,
>
> I'm developing a program in C for the Z80 and compiling using SDCC. I
> can't
> figure out how to create interrupt handlers for the NMI interrupt that
> starts at 0x0066 and the IM1 interrupt that starts at 0x0038. I'm using
> these calls:
>
> void IM1_InterruptHandler(void) __interrupt
> and
> void NMI_InterruptHandler (void) __critical __interrupt
>
> and the resulting assembly looks about right but they aren't located at
> the proper addresses. I did spot this thread:
>
> https://sourceforge.net/p/sdcc/feature-requests/519/
>
> but can't figure out how to use the above example crt0.s file with SDCC
> for a Z80 target. Using the --use-crt switch doesn't seem to work.
>
> unknown compiler option '--use-crt=crt0.s' ignored
>
> Anyone experienced with Z80 development with SDCC that can provide some
> guidance?
> Perhaps I'm doing something incorrectly.
>
> Thanks!
> -Adam