I checked the settings for my (non-ARM) Eclipse GCC toolchain and it looks like you inserted the path correctly. Try clicking on the root of the C/C++ Project and press F5 (refresh). Then click on your C source file and do a clean (Project | Clean).
riden:
I checked the settings for my (non-ARM) Eclipse GCC toolchain and it looks like you inserted the path correctly. Try clicking on the root of the C/C++ Project and press F5 (refresh). Then click on your C source file and do a clean (Project | Clean).
Thanks Riden, but I've done those things many times before and it does nothing. I'm starting to think there's something wrong with XP. I added the path to the path environment variable manually and rebooted. Still can't find the files in that dir without a full path. That seems very strange to me.
futz:
I’m starting to think there’s something wrong with XP. I added the path to the path environment variable manually and rebooted. Still can’t find the files in that dir without a full path. That seems very strange to me.
I’m pretty sure that XP isn’t the problem, or at least this problem.
When you added the include paths, did you leave “Is a workspace path” unchecked? The other thing I would check is the setting of the auto-discover paths, it should be checked. I’m sorry, but I’m on the way out the door and can’t give you the exact path.
Yes, the environment path is important when the project is built. It is the way that the tools know where the required files are located. The problem that you are seeing is that the Eclipse IDE can’t resolve the location of one of the system include files, which makes it an issue with the project settings. The project may or may not build when make is run. When I ran into a similar situation with a different toolset, the IDE was off, but when I executed make, it was able to build the project.
If “Is a workspace path” is checked, it tells Eclipse to reference the path relative to the project’s workspace path (I believe) rather than an absolute path. A similar setting in the Java perspective would give me fits from time to time when I wanted to reference files outside of the workspace.
Yes, the “Automate discovery of paths…” was the setting I was thinking about.
Did you install the Zylin plug-in for Eclipse? I was going to play around with it tonight, but my current working Eclipse is configured for generating x86 code and uses Cygwin. I’m hesitant to tinker with my installation and I would have to clone my VM.
riden:
2) If “Is a workspace path” is checked, it tells Eclipse to reference the path relative to the project’s workspace path (I believe) rather than an absolute path.
Ah! OK! That makes sense. Why the hell didn't they say so? :mrgreen: Everybody wants to make up their own names for things (microsoft) instead of calling them what they are. It's annoying.
Yes, the “Automate discovery of paths…” was the setting I was thinking about.
That was enabled all along. I've tried every option in there and nothing helps. It doesn't help that I'm completely lost about what they all mean. :mrgreen:
Did you install the Zylin plug-in for Eclipse? I was going to play around with it tonight, but my current working Eclipse is configured for generating x86 code and uses Cygwin. I’m hesitant to tinker with my installation and I would have to clone my VM.
I installed this whole thing from the Olimex disk that came with my [[LPC-P2148](http://www.optimal-microsystems.com/store/product_info.php?cPath=24&products_id=114&osCsid=32e20479eb85656ea0232f3025b7e3dc) board. Zylin was part of it. The entire thing was broken and unuseable when installed (thanks a lot Olimex :roll: ). I've fiddled with it for days and have it almost working now.
I now have it compiling properly and the debugger almost working. It still won’t flash the chip, and I don’t know how to compile in debug mode yet (this is a major part of why the debugger doesn’t work :mrgreen:). I’m using Flash Magic to flash for now, and have no debugger.
futz:
I installed this whole thing from the Olimex disk that came with my [LPC-P2148 board. Zylin was part of it. The entire thing was broken and unuseable when installed (thanks a lot Olimex :roll: ). I’ve fiddled with it for days and have it almost working now.[/quote]I can totally relate to your situation. When I went to modify the Olimex’s PIC-WEB code to add some features, the project wouldn’t build because of files that weren’t included in the project. When I did get it to build, the image file it created was larger than 64k and the PIC-WEB firmware couldn’t handle the image file. I found and fixed the bug in the code and was good to go until a new round of problems showed up in the 4.x stack. Got those fixed and now everything is fine. Clearly the firmware that was shipped with the PIC-WEB wasn’t built from the source provided. Our QA group always installs and tests applications on clean machines (or VM’s) to avoid problems like the ones that you and I have encountered.
I have to admit that I wouldn’t have had the opportunity to learn so much about the PIC-WEB firmware if the code actually built out of the box, but it took a lot of my limited time, time that I would have preferred to invest in my projects. I was able to leverage my development experience to fix the issues, but pity the person just starting out. Their frustration would be much greater than mine.
futz:
and I don’t know how to compile in debug mode yet
Ok, I just checked and found that I've been compiling with the -g debug info option all along, so that aint it. :)
and have no debugger.
Debugger looks like it might work if I could figure out how to get it to flash the chip. It appears that and the include path problem are all I need to get fixed now. I'm Google-exhausted from looking at tons of searches and trying things. Nothing works...
I’m using Eclipse/yagarto/zylin with Olimex ARM-USB-TINY and an Olimex LPC-P2148 target board.
futz:
I’m having a major headache with adding an include directory path in
Eclipse. I use Project/Properties/C/C++ General/Paths and Symbols to add
the path. It shows up in the project’s Includes section, but when I
build it still reports “No such file or directory”! What? Why?
OK, after days of confusion and Googling, 99.999% of which was useless, I finally figured that out.
Manually putting paths in Eclipse’s Project/Properties/C/C++ General/Paths and Symbols is futile. It doesn’t work that way. The proper way to do it is to put the path in the -I compiler flag in your makefile as follows:
Then it shows up in the project view (and in the Project/Properties/C/C++ General/Paths and Symbols dialog box too) and actually gets found. I assume this is where automated discovery comes in, but I don’t know how it all works.
Now that I got that cured, I immediately have another problem. I build and get this error
make all
arm-elf-gcc -Ic:/gccfd/yagarto/arm-elf/include -c -fno-common -O0 -g lcd4bit_busy.c
arm-elf-ld -v -Map lcd4bit_busy.map -T2138_demo.cmd -o lcd4bit_busy.out crt.o lcd4bit_busy.o
GNU ld version 2.17
lcd4bit_busy.o: In function `main':
C:\gccfd\projects\lcd4bit/lcd4bit_busy.c:22: undefined reference to `sprintf'
make: *** [lcd4bit_busy.out] Error 1
Should I be looking for another option that tells it where something else is?
inventore123:
add -L"your path to the lib folder" -lc
-Lpath = sets the path for libraries
-lxxx = link with library xxx. The C library (where sprintf is) is just called c, so that’s why -lc
Ah, then I was on the right track. I had been playing with those two (and getting nowhere), but I see nothing in any of the lib dirs called "c", or "c.a". There is a "libc.a",
rtc_clock.o: In function `main':
C:\gccfd\projects\rtc_clock/rtc_clock.c:21: undefined reference to `sprintf'
make: *** [rtc_clock.out] Error 1
Tried every other variation I could think of, including -llibc and -llibc.a and many others, and nothing seems to work. There’s another lib dir there too. It looks like the screen grab below. Tried that one as well. No go.
It still doesn’t work. I get this output when I make:
**** Build of configuration Default for project rtc_clock ****
make all
arm-elf-ld -v -Map rtc_clock.map -T2138_demo.cmd -Lc:/gccfd/yagarto/lib/gcc/arm-elf/4.2.1/interwork -Lc:/gccfd/yagarto/arm-elf/lib/interwork -nostdlibs --start-group -o rtc_clock.out crt.o rtc_clock.o
GNU ld version 2.17
rtc_clock.o: In function `main':
C:\gccfd\projects\rtc_clock/rtc_clock.c:21: undefined reference to `sprintf'
make: *** [rtc_clock.out] Error 1
All library files do begin with “lib” and end with “.a”. When you specify “-lc” gcc will add “lib” and “.a” to the name forming the correct filename “libc.a”
If the include path worked with “-Ic:/gccfd/yagarto/arm-elf/include”
your linker path should be “-Lc:/gccfd/yagarto/arm-elf/lib -lc”
anyway, yes, you should call the linker through gcc
inventore123:
All library files do begin with “lib” and end with “.a”. When you specify “-lc” gcc will add “lib” and “.a” to the name forming the correct filename “libc.a”
Ya, I had surmised that by the end of last evening's entertainment. Thank you.
If the include path worked with “-Ic:/gccfd/yagarto/arm-elf/include”
your linker path should be “-Lc:/gccfd/yagarto/arm-elf/lib -lc”
anyway, yes, you should call the linker through gcc
I'll try all that out tonight. I can't believe I couldn't find a working makefile on the web. Will let you know how it goes. Thanks again for the assistance. :D
Note that is designed to work under Linux, not Windows so you’ll have to tweak the include paths as you were doing before. It is designed to compile two files “main.c” and “system.c” with a linker scrpt named “LPC2138_rom.ld” and an assembler startup file named “crt.s”. Hope this helps, I’ve been using this makefile for over a year with no problems.
Inventore123 my friend! Thank you very much! I got it working finally.
I think I was pretty close, cause I didn’t change much. Just made a few changes with your makefile as a reference and tried it. It failed with a sbrk undefined reference to end. I googled for that and found that I had to add a “PROVIDE(end = .);” statement in the linker file. And that was it. Cured!
For anyone else grinding through this stuff, here’s my present makefile. No guarantees. It might still not be totally right, but it works good for now.