You may need to install sdcc-nonfree as well (if that exists) or build sdcc from source to get access to the pic libraries. IIRC, Debian did not like the unclear license / terms of use of the headers and libraries generated for these targets.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
More info:
You can also do #include <pic16f877.h> but pic16regs.h includes the header file of the PIC you have defined with -p. This way, if you change to another PIC model, you won't need to change that include line.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
adding the include line made no difference. According to the sdcc user manual, the code I have in test.c should compile successfully with the string.h include line. It's like sdcc doesn't know where to find the pic microcontroller lib files. And that's the funny thing, I don't see any p*.lib files in the /usr/share/sdcc folder. Is that why i need the non-free files?
Last edit: scsi050 2014-02-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that is indeed the reason. If Debian does not have the non-free parts (they might be hidden in universe or multiverse repositories, or non-free, if that exists as a repository), then you need to either build from source or use a snapshot build provided by the sdcc project. You can find the pre-built snapshots at http://sdcc.sourceforge.net/snap.php .
Best regards,
Raphael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks! i downloaded the most recent snap version and ran the install. I now am no longer getting that missing .lib file error, so that's great, but it still doesn't compile successfully:
root@server:/home/xxxx/xxxpic# sdcc --use-non-free -mpic14 -p16f877 test.c
message: using default linker script "/usr/share/gputils/lkr/16f877.lkr"
error: missing definition for symbol "_strcpy", required by "test.o"
Again, this test.c is the example from the sdcc user manual, so i don't see how there can be an inspector/syntax error now, but this is the farthest i've gotten after a week of this...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
strangely, I am sure that I had posted another comment on this one, but for some reason, my post did not make it...
The PIC14 library (esp. the C standard library, which you are trying to use) is practically non-existing. The linker cannot find strcpy because there is no implementation available in any of the (few) libraries shipped with sdcc for PIC14.
You need to include all library routines you want to use in your project and link them together with your application.
You can find source code for many C library routines in the SDCC sources, mostly written in C, occasionally supplemented with assembly routines for specific targets. The Internet also provides source code for virtually every standard library routine.
Last edit: Raphael Neider 2014-03-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Support for PIC16 targets (18fxxx, 18fxxxx) is in much better shape both regarding correctness of the generated code and libraries (libc, I/O peripheral access libraries).
The site you linked does not seem to use libc features (at least not in the code sample printed on the Web page). Also, 4 years ago, the "non-free" may not yet have been removed from the Debian packages (so they did not need to specify - - use-non-free).
Beware:the configuration bit setup in SDCC had changed since then. The
unsigned int at _CONFIG1 configWord1 = 0x2FF4;
lines probably should be (maybe: must be) replaced with
#pragma config NAME=value
lines, the proper content of which is always somewhat unclear to me. Basically, SDCC follows the lead of Microchip's compiler here.
Good luck,
Raphael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to get a very simple C code compiled with sdcc, but I can't get past this missing lib file error:
root@server:/home/xxxx/testpic# sdcc -mpic14 -p16f877 test.c
pic16f877.lib: No such file or directory
SDCC version on Debian:
SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.1.0 #7066 (Jun 5 2012) (Linux)
test.c :
include <string.h>
char strl[10];
void main(void) {
strcpy(strl, "testing");
}
Any suggestions? thanks
It looks like you're missing the
--use-non-free
needed for PIC libraries due to Microchip restrictions.no luck:
root@server:/home/xxx/xxxpic# sdcc --use-non-free -mpic14 -p16f877 test.c
pic16f877.lib: No such file or directory
root@server:/home/xxxx/xxxspic#
You may need to install sdcc-nonfree as well (if that exists) or build sdcc from source to get access to the pic libraries. IIRC, Debian did not like the unclear license / terms of use of the headers and libraries generated for these targets.
where/how would i get the sdcc-nonfree install?
Can you attach test.c? Due to sourceforge formatting the include part can't be read.
see attachment. It's very simple, straight from the sdcc user manual.
Try adding this line:
#include <pic16regs.h>
More info:
You can also do
#include <pic16f877.h>
but pic16regs.h includes the header file of the PIC you have defined with-p
. This way, if you change to another PIC model, you won't need to change that include line.adding the include line made no difference. According to the sdcc user manual, the code I have in test.c should compile successfully with the string.h include line. It's like sdcc doesn't know where to find the pic microcontroller lib files. And that's the funny thing, I don't see any p*.lib files in the /usr/share/sdcc folder. Is that why i need the non-free files?
Last edit: scsi050 2014-02-28
Yes, that is indeed the reason. If Debian does not have the non-free parts (they might be hidden in universe or multiverse repositories, or non-free, if that exists as a repository), then you need to either build from source or use a snapshot build provided by the sdcc project. You can find the pre-built snapshots at http://sdcc.sourceforge.net/snap.php .
Best regards,
Raphael
thanks! i downloaded the most recent snap version and ran the install. I now am no longer getting that missing .lib file error, so that's great, but it still doesn't compile successfully:
root@server:/home/xxxx/xxxpic# sdcc --use-non-free -mpic14 -p16f877 test.c
message: using default linker script "/usr/share/gputils/lkr/16f877.lkr"
error: missing definition for symbol "_strcpy", required by "test.o"
Again, this test.c is the example from the sdcc user manual, so i don't see how there can be an inspector/syntax error now, but this is the farthest i've gotten after a week of this...
can anyone help? Why do I get this error message if sdcc can find the .lib files? thanks
error: missing definition for symbol "_strcpy", required by "test.o"
Hi,
strangely, I am sure that I had posted another comment on this one, but for some reason, my post did not make it...
The PIC14 library (esp. the C standard library, which you are trying to use) is practically non-existing. The linker cannot find strcpy because there is no implementation available in any of the (few) libraries shipped with sdcc for PIC14.
You need to include all library routines you want to use in your project and link them together with your application.
You can find source code for many C library routines in the SDCC sources, mostly written in C, occasionally supplemented with assembly routines for specific targets. The Internet also provides source code for virtually every standard library routine.
Last edit: Raphael Neider 2014-03-05
if I was to use something like a pic 18f452 instead, and used the pic16 libraries, are those libraries more populated?
I guess I'm confused because I read a how-to article like this: http://hackaday.com/2010/11/03/how-to-program-pics-using-linux/ and they were obviously able to use sdcc (all be it 4 years ago), but still, why does it work for them and not me?
Last edit: scsi050 2014-03-05
Support for PIC16 targets (18fxxx, 18fxxxx) is in much better shape both regarding correctness of the generated code and libraries (libc, I/O peripheral access libraries).
The site you linked does not seem to use libc features (at least not in the code sample printed on the Web page). Also, 4 years ago, the "non-free" may not yet have been removed from the Debian packages (so they did not need to specify - - use-non-free).
Beware:the configuration bit setup in SDCC had changed since then. The
lines probably should be (maybe: must be) replaced with
lines, the proper content of which is always somewhat unclear to me. Basically, SDCC follows the lead of Microchip's compiler here.
Good luck,
Raphael