Did the way to adress Config bits in SDCC change from 2.6.0 to 2.6.4? On the
2.6.4 build this code doesn't work anymore... what's wrong?:
typedef unsigned char config;
code char at __CONFIG1H config1h = 0xc2;
code char at __CONFIG2L config2l = 0x0a;
code char at __CONFIG2H config2h = 0x1f;
code char at __CONFIG3L config3l = 0x3c;
code char at __CONFIG3H config3h = 0x19;
code char at __CONFIG4L config4l = 0x81;
code char at __CONFIG5L config5l = 0x0f;
code char at __CONFIG5H config5h = 0xc0;
code char at __CONFIG6L config6l = 0x0f;
code char at __CONFIG6H config6h = 0xe0;
code char at __CONFIG7L config7l = 0x0f;
code char at __CONFIG7H config7h = 0x40;
is it a bug that it can't find the directives, or did something change
between 2.6.0 and 2.6.4?
Thanks in advance,
> Did the way to adress Config bits in SDCC change from 2.6.0 to 2.6.4?
> On the 2.6.4 build this code doesn't work anymore... what's wrong?:
> code char at __CONFIG1H config1h = 0xc2;
The __CONFIGnl defines have (unintentionally) been renamed to _CONFIGnl
(single underscore up front) while generating the device library files
for the 18f1 family.
For consistency, I committed a modified version of the header files with
the old naming scheme (__CONFIGnl) as SDCC r4684, although this is
inconsistent with the assembler's naming scheme (only one underscore).
Thanks for the notice.
Additional thanks for revealing to me that config bits should currently
be set using the `__code' modifier---not using it is currently causing
major trouble, as gputils silently relocate the resulting definitions to
ADDRESS/2, which in turn renders the .hex file unusable in most cases.