I am attempting to compile the FreeRTOS/uIP demo under GCC built for the LM3S6965 on a Linux machine. I’m using the ‘FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo’ source files. Here’s what I’ve got so far:
main.c: line 83, change ‘Task.h’ to ‘task.h’
main.c: line 95, change ‘pollq.h’, to ‘PollQ.h’
webserver/emac.c: line 35, change ‘Semphr.h’ to ‘semphr.h’
webserver/emac.c: line 39, change ‘EMAC.h’ to ‘emac.h’
Makefile: line 80, change ‘Portable’ to ‘portable’
Makefile: line 81, change ‘Portable’ to ‘portable’
Makefile: line 102, change ‘cs-rm’ to ‘rm’
I attempted to compile the project with CodeSourcery’s G++ Eclipse IDE. It’s whining something about it can’t build a managed project because a ‘Managed Make project file’ is missing. I have no idea what this means, except that F7 doesn’t build a project. And, personally, I’m finding that IDE to be incredibly obtuse.
When I edited the demo Makefile to use arm-stellaris-eabi tools instead of the arm-none-eabi tools to build it from the command line, I found that there are functions defined in FreeRTOS/Demo/Common/drivers/LuminaryMicro/arm-none-eabi-gcc/libdriver.a that are not defined in FreeRTOS/Demo/Common/drivers/LuminaryMicro/arm-stellaris-eabi-gcc/libdriver.a.
Examples are EthernetInitExpClk vs EthernetInit, HibernateEnableExpClk vs HibernateEnable, etc. You can use ‘arm-stellaris-eabi-nm -a’ to get a list of symbols from each library and diff them out.
When I pulled down Luminarys DriverLib source, built it, and replaced the FreeRTOS/Demo/Common/drivers/LuminaryMicro/arm-stellaris-eabi-gcc/libdriver.a with the one from the compiled DriverLib source, it all links correctly. Of course, now I have to find out if it runs…
This would lead me to believe that if you could get as far as actually compiling the project under Eclipse, it likely wouldn’t link. The link errors below indicate what happened when I tried to link against the arm-stellaris-eabi/libdriver.a in the FreeRTOS sources:
rit128x96x4.o: In function `RIT128x96x4Enable’:
/home/jcw/FR/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/rit128x96x4.c:752: undefined reference to `SSIConfigSetExpClk’
/home/jcw/FR/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/rit128x96x4.c:769: undefined reference to `SSIDataGetNonBlocking’
rit128x96x4.o: In function `RIT128x96x4Disable’:
/home/jcw/FR/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/rit128x96x4.c:805: undefined reference to `SSIDataGetNonBlocking’
osram128x64x4.o: In function `OSRAM128x64x4Enable’:
/home/jcw/FR/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/osram128x64x4.c:718: undefined reference to `SSIConfigSetExpClk’
/home/jcw/FR/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/osram128x64x4.c:735: undefined reference to `SSIDataGetNonBlocking’
osram128x64x4.o: In function `OSRAM128x64x4Disable’:
/home/jcw/FR/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/osram128x64x4.c:773: undefined reference to `SSIDataGetNonBlocking’
./webserver/emac.o: In function `vInitEMAC’:
/home/jcw/FR/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/webserver/emac.c:101: undefined reference to `EthernetInitExpClk’
collect2: ld returned 1 exit status
make: *** [RTOSDemo.axf] Error 1
Possibly I’m just over-analyzing an issue with an old arm-stellaris-eabi/libdriver.a file being in the FreeRTOS distribution. However, the initial compilation errors seems to indicate no one has reported building this in a Linux environment since 2008-02-03.
I have no idea why CodeSourcery builds its Eclipse binaries as arm-stellaris-eabi-*, but the ‘lite’ tools as arm-none-eabi-*. This is foolish, as regardless if you build from the lite tools or the Eclipse tools, your results should be the same. I can come up with no valid reason why the naming conventions should be different, since either set would be usable from a command line or IDE.
And I *really* hate Microsoft for non-case sensitive names… Well, and a lot of other reasons, too.