[Sdcc-user] trying to add pic12f683 support to sdcc

[Ernst B. <e.b...@xe...>]

Hi all,

I just upgraded my SDCC snapshot from 6th April to 12th April, and noticed 
that support for p12f683 is still missing.

I noticed that the way for adding new pic devices has changed quite a bit 
between those versions, here's what I did trying add that device:

> Append to sdcc/device/include/pic/pic14devices.txt:
------------------
processor 12f683
        program         2K
        data            128
        eeprom          256
        io              6
        maxram          0xff
        bankmsk         0x80
        confsiz         1
        regmap          0x80 0x00 0x02 0x03 0x04 0x0a 0x0b
        memmap          0x0020 0x006f 0x000
        memmap          0x0070 0x007f 0x080
        memmap          0x00a0 0x00bf 0x000
-------------------

Generate the header file:
> support/scripts/inc2h.pl 12f683 > pic12f683.h

Fix a typo (?) in the generated header/source:
> perl -pi -e 's/COMCON/CMCON/g' pic12f683.[ch]

put the header into sdcc/device/include/pic/
and the source into sdcc/device/lib/pic/libdev/

Edit the sdcc/device/lib/pic/libdev/Makefile.in to make it recognize the 
device sourcefile:
> replace "wildcard pic16*.c" with "wildcard pic1*.c"

> patch sdcc/src/pic/device.c (More or less only a cosmetical issue)
------------------------
--- device.c~   2006-04-12 23:35:00.652850794 +0200
+++ device.c    2006-04-12 23:35:00.652850794 +0200
@@ -122,6 +122,15 @@
        else if (STRNCASECMP(proc_pos, "16", 2) == 0)
                proc_pos += 2;

+       else if (STRNCASECMP(proc_pos, "pic12", 5) == 0)
+               proc_pos += 5;
+
+       else if (STRNCASECMP(proc_pos, "p12", 3) == 0)
+               proc_pos += 3;
+
+       else if (STRNCASECMP(proc_pos, "12", 2) == 0)
+               proc_pos += 2;
+
        return proc_pos;
 }
-------------------------

Some more issues remain, e.g. in the 
static PIC_device *create_pic(char *pic_name, int maxram, int bankmsk, int 
confsiz, int program, int data, int eeprom, int io)
method (also device.c), the "pic16" prefix is hardcoded, which I didn't fix.

Unfortunately, it didn't work as expected, when compiling sdcc now instructs 
gputils to use p16f683.inc instead of p12f683.inc, which fails:
> sdcc -V -mpic14 -p12f683 test.c
> + "/usr/bin/sdcpp" -nostdinc -Wall -std=c99 -obj-ext=.o -DSDCC_MODEL_SMALL 
-DSDCC=256 -DSDCC_pic14 -D__pic14 -DSDCC_PROCESSOR="12f683" 
-I"/usr/bin/../share/sdcc/include/pic14" -I"/usr/share/sdcc/include/pic14" 
-I"/usr/bin/../share/sdcc/include" -I"/usr/share/sdcc/include" 
-I"/usr/bin/../share/sdcc/include/pic" -I"/usr/share/sdcc/include/pic"  
"test.c"
> + "/usr/bin/gpasm" -c "test.asm"
> test.asm:12:Error [157] Unable to open file "p16f683.inc" - No such file or 
directory

(its also listed as "16f683" in sdccs output of supported pic devices)

But if I patch the intermediate asm file, changing the device referenced in it 
back to 12f683, gpasm eats that file without complaining.

So the problem basically is that sdcc assumes all 14bit pic devices have a 
name starting with "16", unfortunately microchip didn't stick to their naming 
scheme for the 12f683, that one definitly has an 14bit instruction set, 
too...

Any ideas on how to patch that without breaking support for the majority 
"16..." named devices?

/Ernst