Raphael Neider

int is probably a 16 bit wide signed type, range - 32768 to 32767. 40000 thus equals -25536, which is immediately < 0, so your outer loop is never entered. Again, if you only tell us that something is wrong, we can only guess. What did you expect to happen (some led toggles every 40 seconds), what did you observe instead (the led is continuously on but only dim)? You may also be lacking __asm nop __endasm in the body of your inner loop to prevent the compiler from optimizing the loop away (it has...

Hi, unless I missed something, your request for help lacks relevant information - such as the (stripped down) source code, the intended behavior, the observed behavior, whether you obtain a flashable .hex (or, in your case, .sys) file, and what exactly "is not working". From the earlier posts in this topic, I'd conclude that the warnings are harmless (but that assumption may be wrong already). Kind regards, Raphael

Somewhere in the (non-free) include/pic16 directory, there should be a file pic16devices.txt which lists (among other things) the addresses of the configuration words... Or was that for pic14? If such a file exists, you can try fixing the addresses in there for the relevant (family) record. If I can manage, I'll try and post more useful instructions.

Your first attempt seems to lack semi-colons at the end of the code char at()... lines. code and at (like all non-standard keywords) have been superseeded by variants prefixed with double underscores: __code and __at(). Including pic16 (sixteen) stdint.h seems like an unintended hack. It may work (since stdint.h only defines types and stuff that are identically useful on both pic14 and pic16), but I'd generally advise against doing it. If pic14 does not have one, rather copy a suitable stdint.h to...

Your first attempt seems to lack semi-colons at the end of the code char at()... lines. code and at (like all non-standard keywords) have been superseeded by variants prefixed with double underscores: __code and __at(). Including pic16 (sixteen) stdint.h seems like an unintended hack. It may work (since stdint.h only defines types and stuff that are identically useful on both pic14 and pic16), but I'd generally advise against doing it. If pic14 does not have one, rather copy a suitable stdint.h to...

Greetings, I hope that this is the correct place to post this issue. If not, please forgive. I am using the SDCC-toolchain 2.0.5 in MPLABx 4.01 for PIC16F1826. When I set the memory views in MPLAB X. The following is generated: * // PIC16F1826 Configuration Bit Settings // 'C' source line config statements code char at CONFIG1 CONFIG1 = FOSC_INTOSC & WDTE_OFF & PWRTE_OFF & MCLRE_ON & CP_OFF & CPD_OFF & BOREN_ON & CLKOUTEN_OFF & IESO_OFF & FCMEN_OFF code char at CONFIG2 CONFIG2 = WRT_OFF & PLLEN_OFF...

Hi, Generally, the linker should ignore object files that provide only unused symbols. If you implement your potentially unused functions in separate .c files and link your binary (not by #include'ing the .c files into one compilation unit, but by using the linker) from the resulting .rel or .obj or .o files, unused files (and thus functions) should be ignored. Reportedly, some linkers unconditionally include all object files given on the command line - so you may have to collect them into a library...

PIC memory is split into banks of 256 bytes by default. Your arrays do not fit into one of these banks, so the linker fails. You can either split your arrays into chunks no more than 256 bytes or modify the linker script to yield larger regions. The latter requires great care: If the linker puts anything but an array (or a struct), say a uint32 across the bank boundary, that would be hidden by the enlarged section, access to the data may not work correctly. This is because sdcc assumes that all bytes...