I am trying to build a simple C example with SDCC, and I have a problem with the inc2h.pl. I am learning SDCC, so my knowledge may be deficient there as to bad user error.
I run inc2h.pl, and it produces for me .h/.c files which appear correct according to the datasheet of my part. (By correct I see the bit def'ns are good). In the header, pic16f877.h, It also makes these #pragma memmap SFR_SFRREGISTER 0x000 // SFR_REG_NAME (for each SFR).
When I run sdcc, it gives me warnings on compiling my main.c to main.asm, but the inc2h.pl output file pic16f877.c to pic16f877.asm will compile correctly.
> sdcc -S -mpic14 -p16f877a main.c
OUTPUT: appears valid, but with warnings like
.
.
pic16f877A.h:146: warning 116: unknown or unsopported #pragma directive 'memmap EECON2_ADDR EECON2_ADDR SFR 0x000'
-------------------------------------------
I can then use mpasmwin and mplink successfully to build the project to a .hex. I also checked the ASM file produced by the C file main.c, and it is exactly the ASM for what should be done (I make a temp var and move a literal into it).
SDCC Version: 2.6.3 #4543 (Dec 31 2006) (MINGW32)
I searched the documentation for sdcc, and found no mention of #pragma memmap anywhere. The perl script itself doesn't go into depth in its comments, and the #pragma memmap's all give values of 0x000, which just seems incorrect.
----
Is this a big deal? Or... What does #pragma memmap do?
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You probably used an outdated inc2h.pl script. Since r4514, the script does not emit #pragma memmap directives any longer (SDCC grabs them from pic14devices.txt instead). The directive is used to tell the compiler, which memory address ranges map to the same physical RAM cells.
Anyway, support for the 16f877(a) devices is already integrated in current SDCC snapshots. Maybe it suffices to go and get one (http://sdcc.sf.net/snap.php) and try again.
Good luck,
Raphael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I am trying to build a simple C example with SDCC, and I have a problem with the inc2h.pl. I am learning SDCC, so my knowledge may be deficient there as to bad user error.
I run inc2h.pl, and it produces for me .h/.c files which appear correct according to the datasheet of my part. (By correct I see the bit def'ns are good). In the header, pic16f877.h, It also makes these #pragma memmap SFR_SFRREGISTER 0x000 // SFR_REG_NAME (for each SFR).
.. like these ..
..
#pragma memmap EEADRH_ADDR EEADRH_ADDR SFR 0x000 // EEADRH
#pragma memmap EECON1_ADDR EECON1_ADDR SFR 0x000 // EECON1
#pragma memmap EECON2_ADDR EECON2_ADDR SFR 0x000 // EECON2
When I run sdcc, it gives me warnings on compiling my main.c to main.asm, but the inc2h.pl output file pic16f877.c to pic16f877.asm will compile correctly.
-------------------------------------------
> sdcc -S -mpic14 -p16f877a pic16f877a.c
OUTPUT: appears valid, no warnings
> sdcc -S -mpic14 -p16f877a main.c
OUTPUT: appears valid, but with warnings like
.
.
pic16f877A.h:146: warning 116: unknown or unsopported #pragma directive 'memmap EECON2_ADDR EECON2_ADDR SFR 0x000'
-------------------------------------------
I can then use mpasmwin and mplink successfully to build the project to a .hex. I also checked the ASM file produced by the C file main.c, and it is exactly the ASM for what should be done (I make a temp var and move a literal into it).
SDCC Version: 2.6.3 #4543 (Dec 31 2006) (MINGW32)
I searched the documentation for sdcc, and found no mention of #pragma memmap anywhere. The perl script itself doesn't go into depth in its comments, and the #pragma memmap's all give values of 0x000, which just seems incorrect.
----
Is this a big deal? Or... What does #pragma memmap do?
Thanks!
You probably used an outdated inc2h.pl script. Since r4514, the script does not emit #pragma memmap directives any longer (SDCC grabs them from pic14devices.txt instead). The directive is used to tell the compiler, which memory address ranges map to the same physical RAM cells.
Anyway, support for the 16f877(a) devices is already integrated in current SDCC snapshots. Maybe it suffices to go and get one (http://sdcc.sf.net/snap.php) and try again.
Good luck,
Raphael