Thanks for helping keep SourceForge clean.
Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
Small Device C Compiler suite
sdcc-user — Help and Discussion for SDCC users
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(27) |
Apr
(107) |
May
(32) |
Jun
(45) |
Jul
(79) |
Aug
(61) |
Sep
(94) |
Oct
(89) |
Nov
(133) |
Dec
(45) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(81) |
Feb
(57) |
Mar
(85) |
Apr
(80) |
May
(79) |
Jun
(85) |
Jul
(97) |
Aug
(104) |
Sep
(60) |
Oct
(82) |
Nov
(49) |
Dec
(57) |
| 2002 |
Jan
(46) |
Feb
(80) |
Mar
(112) |
Apr
(93) |
May
(72) |
Jun
(89) |
Jul
(118) |
Aug
(130) |
Sep
(67) |
Oct
(49) |
Nov
(58) |
Dec
(99) |
| 2003 |
Jan
(281) |
Feb
(141) |
Mar
(231) |
Apr
(109) |
May
(128) |
Jun
(166) |
Jul
(243) |
Aug
(64) |
Sep
(44) |
Oct
(67) |
Nov
(70) |
Dec
(68) |
| 2004 |
Jan
(71) |
Feb
(88) |
Mar
(60) |
Apr
(84) |
May
(79) |
Jun
(168) |
Jul
(92) |
Aug
(72) |
Sep
(51) |
Oct
(102) |
Nov
(35) |
Dec
(73) |
| 2005 |
Jan
(65) |
Feb
(48) |
Mar
(86) |
Apr
(64) |
May
(107) |
Jun
(93) |
Jul
(40) |
Aug
(117) |
Sep
(82) |
Oct
(65) |
Nov
(63) |
Dec
(85) |
| 2006 |
Jan
(36) |
Feb
(81) |
Mar
(74) |
Apr
(131) |
May
(92) |
Jun
(71) |
Jul
(71) |
Aug
(54) |
Sep
(26) |
Oct
(77) |
Nov
(55) |
Dec
(55) |
| 2007 |
Jan
(112) |
Feb
(88) |
Mar
(105) |
Apr
(46) |
May
(28) |
Jun
(53) |
Jul
(29) |
Aug
(34) |
Sep
(74) |
Oct
(83) |
Nov
(67) |
Dec
(39) |
| 2008 |
Jan
(40) |
Feb
(105) |
Mar
(42) |
Apr
(25) |
May
(91) |
Jun
(32) |
Jul
(47) |
Aug
(128) |
Sep
(188) |
Oct
(54) |
Nov
(19) |
Dec
(41) |
| 2009 |
Jan
(145) |
Feb
(88) |
Mar
(117) |
Apr
(38) |
May
(53) |
Jun
(9) |
Jul
(47) |
Aug
(10) |
Sep
(28) |
Oct
(65) |
Nov
(97) |
Dec
(36) |
| 2010 |
Jan
(55) |
Feb
(87) |
Mar
(81) |
Apr
(30) |
May
(37) |
Jun
(15) |
Jul
(85) |
Aug
(31) |
Sep
(1) |
Oct
(69) |
Nov
(69) |
Dec
(32) |
| 2011 |
Jan
(37) |
Feb
(49) |
Mar
(55) |
Apr
(27) |
May
(67) |
Jun
(30) |
Jul
(43) |
Aug
(73) |
Sep
(65) |
Oct
(89) |
Nov
(59) |
Dec
(15) |
| 2012 |
Jan
(27) |
Feb
(48) |
Mar
(14) |
Apr
(18) |
May
(38) |
Jun
(59) |
Jul
(46) |
Aug
(11) |
Sep
(21) |
Oct
(28) |
Nov
(18) |
Dec
(51) |
| 2013 |
Jan
(35) |
Feb
(68) |
Mar
(56) |
Apr
(21) |
May
(62) |
Jun
(43) |
Jul
(12) |
Aug
(34) |
Sep
(28) |
Oct
|
Nov
(11) |
Dec
(33) |
| 2014 |
Jan
(15) |
Feb
(36) |
Mar
(33) |
Apr
(45) |
May
(8) |
Jun
(52) |
Jul
(30) |
Aug
(7) |
Sep
(38) |
Oct
(76) |
Nov
(19) |
Dec
(26) |
| 2015 |
Jan
(67) |
Feb
(42) |
Mar
(6) |
Apr
(12) |
May
(13) |
Jun
(17) |
Jul
(10) |
Aug
(9) |
Sep
(26) |
Oct
(24) |
Nov
(8) |
Dec
(2) |
| 2016 |
Jan
(19) |
Feb
(2) |
Mar
(33) |
Apr
(56) |
May
(10) |
Jun
(12) |
Jul
(38) |
Aug
(69) |
Sep
(10) |
Oct
(7) |
Nov
(20) |
Dec
(26) |
| 2017 |
Jan
(10) |
Feb
(10) |
Mar
(4) |
Apr
(4) |
May
(16) |
Jun
(13) |
Jul
(16) |
Aug
(21) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: R0b0t1 <r030t1@gm...> - 2017-08-18 19:30:15
|
On Fri, Aug 18, 2017 at 12:35 PM, Maarten Brock <sourceforge.brock@...> wrote: >> On Fri, Aug 18, 2017 at 10:39 AM, R0b0t1 <r030t1@...> wrote: >>> What is the status of EFM8 support? They are an 8051 based >>> microcontroller, so I expect code generation to be a nonissue. What >>> difficulties might I experience porting the manufacturer's device >>> headers? >>> >> >> Sorry list, I checked some older posts and people are using the older >> Silicon Labs parts without much issue. I guess I have no reason to >> expect problems. >> >>> http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants is >>> inconclusive, or I don't understand it. >>> >>> I would also like to indirectly reply to >>> https://sourceforge.net/p/sdcc/mailman/message/35269929/ - use the >>> integrated Segger J-Link on the EFM8 starter kits. Eventually, the >>> Black Magic Probe firmware may support EFM8 targets. Currently it only >>> supports EFM32 ARM devices. >>> >>> Thanks in advance, >>> Rob0t > > > The biggest problem usually is the watchdog that is enabled by default. > With sdcc you can disable it in sdcc_startup as described in the manual. > Thanks for the heads up. I invariably seem to spend a day or two troubleshooting an issue like this. Sadly my Mouser order was help back to do an export controlled part, can't wait to try these parts out. They're nice and cheap. On Fri, Aug 18, 2017 at 2:03 PM, Philipp Klaus Krause <pkk@...> wrote: > Am 18.08.2017 um 17:39 schrieb R0b0t1: >> What is the status of EFM8 support? They are an 8051 based >> microcontroller, so I expect code generation to be a nonissue. What >> difficulties might I experience porting the manufacturer's device >> headers? >> >> http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants is >> inconclusive, or I don't understand it. > > I've added a clarifying sentence at the top of that page. > Thank you for the clarification. I understand what the page originally said now, but that might be because of your update. Cheers! R0b0t1. |
|
From: Philipp Klaus Krause <pkk@sp...> - 2017-08-18 19:03:12
|
Am 18.08.2017 um 17:39 schrieb R0b0t1: > What is the status of EFM8 support? They are an 8051 based > microcontroller, so I expect code generation to be a nonissue. What > difficulties might I experience porting the manufacturer's device > headers? > > http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants is > inconclusive, or I don't understand it. I've added a clarifying sentence at the top of that page. Philipp |
|
From: Maarten Brock <sourceforge.brock@ds...> - 2017-08-18 17:35:25
|
> On Fri, Aug 18, 2017 at 10:39 AM, R0b0t1 <r030t1@...> wrote: >> What is the status of EFM8 support? They are an 8051 based >> microcontroller, so I expect code generation to be a nonissue. What >> difficulties might I experience porting the manufacturer's device >> headers? >> > > Sorry list, I checked some older posts and people are using the older > Silicon Labs parts without much issue. I guess I have no reason to > expect problems. > >> http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants is >> inconclusive, or I don't understand it. >> >> I would also like to indirectly reply to >> https://sourceforge.net/p/sdcc/mailman/message/35269929/ - use the >> integrated Segger J-Link on the EFM8 starter kits. Eventually, the >> Black Magic Probe firmware may support EFM8 targets. Currently it only >> supports EFM32 ARM devices. >> >> Thanks in advance, >> R0bot The biggest problem usually is the watchdog that is enabled by default. With sdcc you can disable it in sdcc_startup as described in the manual. Maarten |
|
From: Maarten Brock <sourceforge.brock@ds...> - 2017-08-18 17:27:49
|
Hello Philipp, > I haven't been using the keyword __at much. > But now I have a case where I want code to be placed in the 0x0000 to 0x9fff range. > > However, at the specific location 0x1ff0 I want 16 specific header bytes. The linker should just put the code around the header (which might require leaving a few bytes unused), but it doesn't work for me so far. > > I tried > > const struct header __at(0x1ff0) header = ...; > > but the linker creates an overlap: The header gets put into the > binary at the correct location with the correct data. But that > means the data ends up in the middle of a function. > > Philipp > I'm afraid the Z80 backend is still broken in this area. Look at the generated .area line and check for the property CON. If there is none make the backend generate it. Maarten |
|
From: R0b0t1 <r030t1@gm...> - 2017-08-18 16:54:25
|
On Fri, Aug 18, 2017 at 10:39 AM, R0b0t1 <r030t1@...> wrote: > What is the status of EFM8 support? They are an 8051 based > microcontroller, so I expect code generation to be a nonissue. What > difficulties might I experience porting the manufacturer's device > headers? > Sorry list, I checked some older posts and people are using the older Silicon Labs parts without much issue. I guess I have no reason to expect problems. > http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants is > inconclusive, or I don't understand it. > > I would also like to indirectly reply to > https://sourceforge.net/p/sdcc/mailman/message/35269929/ - use the > integrated Segger J-Link on the EFM8 starter kits. Eventually, the > Black Magic Probe firmware may support EFM8 targets. Currently it only > supports EFM32 ARM devices. > > Thanks in advance, > R0b0t1 |
|
From: R0b0t1 <r030t1@gm...> - 2017-08-18 15:39:55
|
What is the status of EFM8 support? They are an 8051 based microcontroller, so I expect code generation to be a nonissue. What difficulties might I experience porting the manufacturer's device headers? http://sdcc.sourceforge.net/mediawiki/index.php/8051_variants is inconclusive, or I don't understand it. I would also like to indirectly reply to https://sourceforge.net/p/sdcc/mailman/message/35269929/ - use the integrated Segger J-Link on the EFM8 starter kits. Eventually, the Black Magic Probe firmware may support EFM8 targets. Currently it only supports EFM32 ARM devices. Thanks in advance, R0b0t1 |
|
From: Philipp Klaus Krause <pkk@sp...> - 2017-08-16 07:24:06
|
Am 15.08.2017 um 23:58 schrieb Erlo Haugen: > On 2017-08-15 23:22, Philipp Klaus Krause wrote: >> Am 14.08.2017 um 23:47 schrieb Erlo Haugen: >>> What library must I link to in order to access printf or puts? >>> >>> Command: >>> >>> erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690 >>> --use-non-free dreje.c >>> message: Using default linker script "/usr/share/gputils/lkr/16f690_g.lkr". >>> error: Missing definition for symbol "_puts", required by "dreje.o". >>> >>> br >>> Erlo >> >> Do other std library functions work for you? From a quick look at >> sdcc/device/lib/pic1?, it seems that the pic14 doesn't really have a >> library (expect for support functions and floating-point math functions) >> and the pic16 has its own library, separate from what all the non-pic >> backends use. >> >> Philipp >> > > Actually, I am not using other library functions as far as I know. > > Erlo Well, the pic backends are still considered "work in progress". And that is even more true fro pic14 than for pic16. I suggest you try just taking puts() from sdcc/device/lib/puts.c and see if it works for you for pic14. Philipp |
|
From: Erlo Haugen <erlo.haugen@gm...> - 2017-08-15 21:58:26
|
On 2017-08-15 23:22, Philipp Klaus Krause wrote: > Am 14.08.2017 um 23:47 schrieb Erlo Haugen: >> What library must I link to in order to access printf or puts? >> >> Command: >> >> erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690 >> --use-non-free dreje.c >> message: Using default linker script "/usr/share/gputils/lkr/16f690_g.lkr". >> error: Missing definition for symbol "_puts", required by "dreje.o". >> >> br >> Erlo > > Do other std library functions work for you? From a quick look at > sdcc/device/lib/pic1?, it seems that the pic14 doesn't really have a > library (expect for support functions and floating-point math functions) > and the pic16 has its own library, separate from what all the non-pic > backends use. > > Philipp > Actually, I am not using other library functions as far as I know. Erlo |
|
From: Erlo Haugen <erlo.haugen@gm...> - 2017-08-15 21:22:49
|
On 2017-08-15 23:12, Philipp Klaus Krause wrote: > Am 14.08.2017 um 23:47 schrieb Erlo Haugen: >> What library must I link to in order to access printf or puts? >> >> Command: >> >> erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690 >> --use-non-free dreje.c >> message: Using default linker script "/usr/share/gputils/lkr/16f690_g.lkr". >> error: Missing definition for symbol "_puts", required by "dreje.o". >> >> br >> Erlo > > Which version of SDCC? > > Philipp > > 3.6.0 #9615 Erlo |
|
From: Philipp Klaus Krause <pkk@sp...> - 2017-08-15 21:22:16
|
Am 14.08.2017 um 23:47 schrieb Erlo Haugen: > What library must I link to in order to access printf or puts? > > Command: > > erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690 > --use-non-free dreje.c > message: Using default linker script "/usr/share/gputils/lkr/16f690_g.lkr". > error: Missing definition for symbol "_puts", required by "dreje.o". > > br > Erlo Do other std library functions work for you? From a quick look at sdcc/device/lib/pic1?, it seems that the pic14 doesn't really have a library (expect for support functions and floating-point math functions) and the pic16 has its own library, separate from what all the non-pic backends use. Philipp |
|
From: Philipp Klaus Krause <pkk@sp...> - 2017-08-15 21:12:32
|
Am 14.08.2017 um 23:47 schrieb Erlo Haugen: > What library must I link to in order to access printf or puts? > > Command: > > erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690 > --use-non-free dreje.c > message: Using default linker script "/usr/share/gputils/lkr/16f690_g.lkr". > error: Missing definition for symbol "_puts", required by "dreje.o". > > br > Erlo Which version of SDCC? Philipp |
|
From: Philipp Klaus Krause <pkk@sp...> - 2017-08-15 21:11:38
|
Am 15.08.2017 um 22:41 schrieb Gál Zsolt: > Did you find this? > > http://sdcc.sourceforge.net/wiki/index.php/List_of_the_SDCC_library > That page seems very much out of date. Philipp |
|
From: Gál Zsolt <tralitoverin@fr...> - 2017-08-15 20:41:35
|
Did you find this? http://sdcc.sourceforge.net/wiki/index.php/List_of_the_SDCC_library 2017-08-14 23:47 GMT+02:00 Erlo Haugen <erlo.haugen@...>: > What library must I link to in order to access printf or puts? > > Command: > > erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690 > --use-non-free dreje.c > message: Using default linker script "/usr/share/gputils/lkr/ > 16f690_g.lkr". > error: Missing definition for symbol "_puts", required by "dreje.o". > > br > Erlo > > > ------------------------------------------------------------ > ------------------ > 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 > -- ~~~~~~~~~~~~~~~~ |
|
From: Philipp Klaus Krause <pkk@sp...> - 2017-08-15 19:26:19
|
I haven't been using the keyword __at much. But now I have a case where I want code to be placed in the 0x0000 to 0x9fff range. However, at the specific location 0x1ff0 I want 16 specific header bytes. The linker should just put the code around the header (which might require leaving a few bytes unused), but it doesn't work for me so far. I tried const struct header __at(0x1ff0) header = ...; but the linker creates an overlap: The header gets put into the binary at the correct location with the correct data. But that means the data ends up in the middle of a function. Philipp |
|
From: Erlo Haugen <erlo.haugen@gm...> - 2017-08-14 21:48:00
|
What library must I link to in order to access printf or puts? Command: erlo@...:~/MPLABXProjects/interrupttest.X$ sdcc -mpic14 -p16f690 --use-non-free dreje.c message: Using default linker script "/usr/share/gputils/lkr/16f690_g.lkr". error: Missing definition for symbol "_puts", required by "dreje.o". br Erlo |
|
From: Erlo Haugen <erlo.haugen@gm...> - 2017-08-07 19:42:21
|
I opened a ticket (2636) regarding a fatal compiler error when compiling for 16f690. Do I need to supply more information? BR Erlo |
|
From: Erlo Haugen <erlo.haugen@gm...> - 2017-08-07 18:31:51
|
On 2017-08-07 18:20, Augusto Fraga Giachero wrote: > PIC microcontrollers (PIC12/PIC14/PIC16) doesn't have a general purpose > stack (it has a hardware stack used only to sub-routines and interrupts > return). I don't known how the sdcc implements local variables for these > targets (may be a software stack or fixed allocation). > > Augusto The compiler allocates memory from the general purpose registers, as far as I can see. But the names may change if another variable is defined or the order of definition is changed. > > On 08/06/2017 07:12 PM, Maarten Brock wrote: >>> Access to global variable is no problem, just use _varname, but how can >>> I access local variables? Is there no other way than using the >>> compiler-generated names (which may change if the code is changed)? >>> >>> BR >>> Erlo >> This highly depends on the target and compiler options. Local >> variables on >> stack don't even have a name in assembler. >> >> Hav you considered using static variables? >> >> Maarten Not static, but a global variable. The issue with both approaches is the variable can not be overlayed/reused in another function and memory is sparse in the small PICs. Erlo |
|
From: Augusto Fraga Giachero <augustofg96@gm...> - 2017-08-07 16:19:59
|
PIC microcontrollers (PIC12/PIC14/PIC16) doesn't have a general purpose stack (it has a hardware stack used only to sub-routines and interrupts return). I don't known how the sdcc implements local variables for these targets (may be a software stack or fixed allocation). Augusto On 08/06/2017 07:12 PM, Maarten Brock wrote: >> Access to global variable is no problem, just use _varname, but how can >> I access local variables? Is there no other way than using the >> compiler-generated names (which may change if the code is changed)? >> >> BR >> Erlo > This highly depends on the target and compiler options. Local variables on > stack don't even have a name in assembler. > > Hav you considered using static variables? > > Maarten > > > ------------------------------------------------------------------------------ > 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 |
|
From: Maarten Brock <sourceforge.brock@ds...> - 2017-08-06 22:34:22
|
> Access to global variable is no problem, just use _varname, but how can > I access local variables? Is there no other way than using the > compiler-generated names (which may change if the code is changed)? > > BR > Erlo This highly depends on the target and compiler options. Local variables on stack don't even have a name in assembler. Hav you considered using static variables? Maarten |
|
From: Gál Zsolt <tralitoverin@fr...> - 2017-08-06 20:34:10
|
Hello, I think that is the only way using global variables if you want to use inline assembly. Better solution is writing time critical function in assembly and compile source codes into object files and linking them. There is some help in the sdcc manual how is it working and how can you give parameters to assembly functions. Regards, Zsolt 2017-08-06 22:20 GMT+02:00 Erlo Haugen <erlo.haugen@...>: > Access to global variable is no problem, just use _varname, but how can > I access local variables? Is there no other way than using the > compiler-generated names (which may change if the code is changed)? > > BR > Erlo > > ------------------------------------------------------------ > ------------------ > 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 |
|
From: Erlo Haugen <erlo.haugen@gm...> - 2017-08-06 20:21:06
|
Access to global variable is no problem, just use _varname, but how can I access local variables? Is there no other way than using the compiler-generated names (which may change if the code is changed)? BR Erlo |
|
From: Kustaa Nyholm <kustaa.nyholm@sp...> - 2017-07-28 12:38:06
|
> On 21 Jul 2017, at 23:07, Raphael Neider <rneider@...> wrote: > > 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)? > Below is the output from the verbose build. Something fishy why the make clean invokes the compiler, something I'm doing wrong there ?! I will investigate but feel free to chime in. cheers Kusti make clean /Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701 setting interrupt vector addresses 0x800 rm -f ../obj/*.rel rm -f ../obj/*.lnk rm -f ../obj/*.S19 rm -f ../obj/*.map rm -f ../obj/*.mem rm -f ../obj/*.asm rm -f ../obj/*.rst rm -f ../obj/*.sym rm -f ../obj/*.lst rm -f ../obj/*.o rm -f ../obj/*.dep rm -f ../obj/*.hex rm -f ../obj/toad4.hexmake Makefile:125: ../obj/main.dep: No such file or directory Makefile:125: ../obj/toad4.dep: No such file or directory Makefile:125: ../obj/usb_hid.dep: No such file or directory Makefile:125: ../obj/usb_core.dep: No such file or directory Makefile:125: ../obj/usb_pic_defs.dep: No such file or directory Makefile:125: ../obj/usb_user_config.dep: No such file or directory Makefile:125: ../obj/command_queue.dep: No such file or directory Makefile:125: ../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" --verbose --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 Processor: 18f45k50 sdcc: Calling preprocessor... + /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 sdcc: Generating code... main.c:671: warning 196: pointer target lost const qualifier sdcc: Calling assembler... + 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" --verbose --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 Processor: 18f45k50 sdcc: Calling preprocessor... + /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 sdcc: Generating code... sdcc: Calling assembler... + 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" --verbose --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 Processor: 18f45k50 sdcc: Calling preprocessor... + /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 sdcc: Generating code... sdcc: Calling assembler... + 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" --verbose --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 Processor: 18f45k50 sdcc: Calling preprocessor... + /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 sdcc: Generating code... sdcc: Calling assembler... + 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" --verbose --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 Processor: 18f45k50 sdcc: Calling preprocessor... + /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 sdcc: Generating code... sdcc: Calling assembler... + 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" --verbose --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 Processor: 18f45k50 sdcc: Calling preprocessor... + /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 sdcc: Generating code... sdcc: Calling assembler... + 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" --verbose --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 Processor: 18f45k50 sdcc: Calling preprocessor... + /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 sdcc: Generating code... sdcc: Calling assembler... + 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" --verbose --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 Processor: 18f45k50 sdcc: Calling preprocessor... + /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 sdcc: Generating code... sdcc: Calling assembler... + 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" --verbose --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 Processor: 18f45k50 sdcc: Calling linker... + 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) /Applications/microchip/mplabx/v3.55/mplab_ide.app/Contents/Resources/mplab_ide/bin/hexmate -o../obj/toad4-normalized.hex -fill=0xFF@...:0x7FFF r0800-7FFF,../obj/toad4.hex /Applications/microchip/mplabx/v3.55/mplab_ide.app/Contents/Resources/mplab_ide/bin/hexmate -o../obj/bootloader-normalized.hex -fill=0xFF@...:0x07FF r0000-07FF,../diolan-plus2/bootloader.hex r000802-FFFFFF,../diolan-plus2/bootloader.hex /Applications/microchip/mplabx/v3.55/mplab_ide.app/Contents/Resources/mplab_ide/bin/hexmate -o../obj/toad4-pickit.hex -fill=0xFFFF@...:0xF000FF -fill=0xA5@...:0xF00000 -fill=0x00@...:0x30000D ../obj/toad4-normalized.hex ../obj/bootloader-normalized.hex java -cp ~/EazyCNC-Project/classes:/Users/nyholku/PureJavaHidApi/bin/purejavahidapi.jar:/Users/Nyholku/PureJavaHidApi/lib/jna-4.0.0.jar diolanupdater.UpdateFirmware ../obj/toad4-encoded.hex java.io.FileNotFoundException at diolanupdater.Uploader.<init>(Uploader.java:47) at diolanupdater.UpdateFirmware.updateFirmware(UpdateFirmware.java:20) at diolanupdater.UpdateFirmware.main(UpdateFirmware.java:116) MacBook-Pro:src nyholku$ |
|
From: Kustaa Nyholm <kustaa.nyholm@sp...> - 2017-07-28 12:32:42
|
> On 21 Jul 2017, at 23:07, Raphael Neider <rneider@...> wrote:
>
> 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 don't think I link main twice, here is my Makefile:
#-------------------------------------------------------------------------------
# Everyone should have this
.SUFFIXES:
UPLOADER := java -cp ~/EazyCNC-Project/classes:/Users/nyholku/PureJavaHidApi/bin/purejavahidapi.jar:/Users/Nyholku/PureJavaHidApi/lib/jna-4.0.0.jar diolanupdater.UpdateFirmware
ENCODER := /Users/nyholku/diolan-plus2/encoder/build/encoder
HEXMATE := /Applications/microchip/mplabx/v3.55/mplab_ide.app/Contents/Resources/mplab_ide/bin/hexmate
# The output file name
TARGET = toad4
# The source files that make up the project go here
SRCS = main.c toad4.c usb_hid.c usb_core.c usb_pic_defs.c usb_user_config.c command_queue.c crt0iz_toad4.c
# The libraries that are used go here
LIBS = libc18f.lib libio18f45k50.lib libm18f.lib libsdcc.lib
# Where to find the compiler
SDCC = /Users/nyholku/sdcc-3.4.0/bin/sdcc
# Compiler flags go here
# --use-crt=crt0.o
SDCCFLAGS = "-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
# Where to store the target/intermediate/temporary/object files
OBJDIR = ../obj
#
#-------------------------------------------------------------------------------
#
# This ensures that the object directory exists and re-creates it if necessary
#
# This requires make 3.81 or later, delete this section and all expressions that
# refer to .f if you have an older make
#
.SECONDEXPANSION:
# Uses a .f file as a flag file in each directory
%/.f:
mkdir -p $(dir $@)
touch $@
# dont' let make remove the flag files automatically
.PRECIOUS: %/.f
#
#-------------------------------------------------------------------------------
#
# Actual rules
#
# Compile the C-files
$(OBJDIR)/%.o: %.c $$(@D)/.f
@echo $(PATH)
$(SDCC) -c $(SDCCFLAGS) $< -o $@
# Link the compiled files and libraries
$(OBJDIR)/$(TARGET).hex: $(addprefix $(OBJDIR)/, $(SRCS:.c=.o)) $(OBJDIR)/hi_speed_irq.o
$(SDCC) $(SDCCFLAGS) -o $(OBJDIR)/$(TARGET).hex $(addprefix $(OBJDIR)/, $(SRCS:.c=.o)) $(LIBS) $(OBJDIR)/hi_speed_irq.o
# normalize the code filling un-used code memory with 0xFF so that encoding always works on known data
$(HEXMATE) -o$(OBJDIR)/$(TARGET)-normalized.hex -fill=0xFF@...:0x7FFF r0800-7FFF,$(OBJDIR)/$(TARGET).hex
# sanitise the bootloader by keeping only the first 2kB (there is an extra jump code at 0x800 which overlaps with firmware code)
$(HEXMATE) -o$(OBJDIR)/bootloader-normalized.hex -fill=0xFF@...:0x07FF r0000-07FF,../diolan-plus2/bootloader.hex r000802-FFFFFF,../diolan-plus2/bootloader.hex
# combine the bootloader and firmware to one hex file that can be programmed with pickit ready to run
$(HEXMATE) -o$(OBJDIR)/$(TARGET)-pickit.hex -fill=0xFFFF@...:0xF000FF -fill=0xA5@...:0xF00000 -fill=0x00@...:0x30000D $(OBJDIR)/$(TARGET)-normalized.hex ../obj/bootloader-normalized.hex
# encode the bootloader for bootloading purposes, suppress output so as NOT to reveal the secret key
@$(ENCODER) -ix $(OBJDIR)/$(TARGET)-normalized.hex -ox $(OBJDIR)/$(TARGET)-encoded.hex -e ${TOAD4PLUS_DIALON_KEY2}
# upload the encoded hex file using the bootload process
$(UPLOADER) $(OBJDIR)/$(TARGET)-encoded.hex
# Compile the high speed interrupt asm file
$(OBJDIR)/hi_speed_irq.o: hi_speed_irq.asm
gpasm -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o $(OBJDIR)/hi_speed_irq.o -c "hi_speed_irq.asm"
#
#-------------------------------------------------------------------------------
#
# Automatic generation of dependencies
#
# This magic code fragment from GNU make manual uses the SDCC compiler -M option
# to create a Makefile fragment for each C-source file describing the dependencies.
#
# Traditionally these fragments have the type '.d' but SDCC seems to delete them
# when it compiles files, so I use '.dep' here.
#
# Also SDCC '-M' option produces wrong dependency for the file being compiled
# in the sense that it does not contain the path, only the filename. Hence
# the 'sed' command has been mangled to inject the missing path to the fragment.
#
# First include the dependencies
include $(addprefix $(OBJDIR)/, $(SRCS:.c=.dep))
# Then recreate them
$(OBJDIR)/%.dep: %.c $$(@D)/.f
@set -e; rm -f $@; \
$(SDCC) -c -M $(SDCCFLAGS) $< > $@.$$$$; \
sed -e '1 s,^,$(OBJDIR)/,' -e 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \
rm -f $@.$$$$
#------------------------------------------------------------------------------
#
# pretty standard default target
#
all: $(OBJDIR)/$(TARGET).hex
#
#-------------------------------------------------------------------------------
#
# pretty standard clean that attempts to delete all that this Makefile may left behind
#
clean:
rm -f $(OBJDIR)/*.rel
rm -f $(OBJDIR)/*.lnk
rm -f $(OBJDIR)/*.S19
rm -f $(OBJDIR)/*.map
rm -f $(OBJDIR)/*.mem
rm -f $(OBJDIR)/*.asm
rm -f $(OBJDIR)/*.rst
rm -f $(OBJDIR)/*.sym
rm -f $(OBJDIR)/*.lst
rm -f $(OBJDIR)/*.o
rm -f $(OBJDIR)/*.dep
rm -f $(OBJDIR)/*.hex
rm -f $(OBJDIR)/$(TARGET).hex
#
# cleanall deletes all in the object directory, do not use this if target dir == source dir
cleanall:
rm $(OBJDIR)/*
#-------------------------------------------------------------------------------
|
|
From: Kustaa Nyholm <kustaa.nyholm@sp...> - 2017-07-28 12:28:05
|
> On 21 Jul 2017, at 23:07, Raphael Neider <rneider@...> wrote:
>
> You could try copying the library function to your project and adjust the arguments (and s) just to see if it helps?
>
Hi,
I copypasted the def from your mail to my main.c where that
function is used and changed the name to memcpypgm2ram_test:
_data void *
memcpypgm2ram_test (__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;
}
This procudes these errors, maybe they tell you more than what they tell to me.
main.c:689: error 78: incompatible types
from type 'struct __00000981 near* data'
to type 'const-void code* fixed'
main.c:690: error 78: incompatible types
from type 'struct __00000981 near* data'
to type 'const-void code* fixed'
main.c:691: error 78: incompatible types
from type 'struct __00000981 near* data'
to type 'const-void code* fixed'
main.c:692: error 78: incompatible types
from type 'struct __00000981 near* data'
to type 'const-void code* fixed'
wbr Kusti
|
|
From: Raphael Neider <rneider@we...> - 2017-07-21 20:07:47
|
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
|
11 messages has been excluded from this view by a project administrator.