Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Compiling Cortex-M3 LM3S6965 Demo Under Linux

Posted by JC on February 21, 2008
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.

--jc

RE: Compiling Cortex-M3 LM3S6965 Demo Under Linux

Posted by Richard on February 21, 2008
> 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'


Oops, sorry about that. I can only test on a Windoze machine so this is a common complaint. I need a case sensitive search and replace in files utility (ironically that would probably be easy to do under Linux).

I am releasing V4.7.2 today or tomorrow so will try to catch these case issues in that (the new release has some new ports in it only, so won't affect what you are doing).


> 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/l
> ibdriver.a that
> are not defined
> in
> FreeRTOS/Demo/Common/drivers/LuminaryMicro/arm-stellaris-eabi-
> gcc/libdriver.a
> .


The demos switched between using the *stellaris* version to the *none* version some time back, and this pre-dates the Ethernet enabled Luminary parts. The driver build is therefore not up to date. The *none* version is a free download and therefore what most users use, and the version that the FreeRTOS.org project is setup to use.


> 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...


One other thing to be careful of. The Luminary eval kits had to switch display suppliers. If you have a Rev C board then the display driver in the library will be incorrect - the WEB server will run but you will not see anything on the display. If you have a Rev B board then the display driver will be correct.


> 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.


Well I agree with most of what you are saying here. I'm sorry you have had problems, one of the goals of FreeRTOS.org is 'out of the box' compile and build with no errors - although you are attempting to use an 'unsupported' build environment. Unsupported in the sense that I cannot test it, although I would be much happier if it worked.

Keep letting me know through this forum what you find. I can then make any necessary changes in the FreeRTOS.org distribution even without access to a Linux machine. It is important that Linux users have a good experience too.

I will try and sort out the case issues for V4.7.2 in a few days. Within a month there should then also be V4.7.3 being released with some new features and yet another new port!

There are also some other new developments on the horizon that may well make your project easier. Watch this space!

Regards.

RE: Compiling Cortex-M3 LM3S6965 Demo Under L

Posted by JC on February 22, 2008
>Well I agree with most of what you are saying here. I'm sorry you have had
>problems, one of the goals of FreeRTOS.org is 'out of the box'
compile and build
>with no errors - although you are attempting to use an 'unsupported' build
>environment. Unsupported in the sense that I cannot test it, although I would
>be much happier if it worked.

Richard, please don't apologize. You've done some wonderful work
here. The issues I'm seeing are basically third-party caused
problems, particularly those related to defective operating systems :)
And it seems to me that CodeSourcery is also making this
unnecessarily complicated.

Looks like the GNU group is supposed to release GCC with ARMv7/THUMB-2
support in 4.3, hopefully in mid-March. This means generic GCC builds
will be able to build Cortex-M3 code, and we can get away from a
custom tool chain build.

Thanks!

--jc

RE: Compiling Cortex-M3 LM3S6965 Demo Under L

Posted by JC on February 22, 2008
Richard, I imagine you already know this, but since I got the Rev C board OLED going, I thought I'd pass it along.

In Makefile, delete the osram128x64x4.c references
Copy the rit128x96x4.c and rit128x96x4.h from the LuminaryMicros DriverLib source
In main.c, in the vOLEDTask() function, delete the case statement, but keep the lines from the default case.

Recompiled, came right up.

--jc

RE: Compiling Cortex-M3 LM3S6965 Demo Under L

Posted by David Gesswein on February 22, 2008
4.7.2 missed the
webserver/emac.c: line 35, change 'Semphr.h' to 'semphr.h'

I also have the rev_c board and was going to pull in the new rit128x96x4.c from DriverLib but noticed a problem with its license. This new file seems to be incompatible with the FreeRTOS license. Do FreeRTOS people understand Luminary new license or have contact with them to figure out what it means?

// The software is owned by LMI and/or its suppliers, and is protected under
// applicable copyright laws. All rights are reserved. You may not combine
// this software with "viral" open-source software in order to form a larger
// program.


RE: Compiling Cortex-M3 LM3S6965 Demo Under L

Posted by Richard on February 22, 2008
> 4.7.2 missed the
> webserver/emac.c: line 35, change 'Semphr.h' to 'semphr.h'

Aaargh!


> // The software is owned by LMI and/or its suppliers, and is
> protected under
> // applicable copyright laws. All rights are reserved. You
> may not combine
> // this software with "viral" open-source software in order
> to form a larger
> // program.


I wonder what they mean by 'viral'?

The driver lib is included in the FreeRTOS.org download with the agreement of LMI, but if the license has changed then I need to re-confirm this. I'm sure it will be fine but will double check all the same.

Regards.

RE: Compiling Cortex-M3 LM3S6965 Demo Under L

Posted by David Gesswein on February 22, 2008
For the purposes of this Agreement, "viral open
source" software means open source software made available on license terms,
such as the GNU General Public License (GPL), that would alter the foregoing
license grant restrictions if combined with the Software.

This patch makes the old version of the code work on the rev c board. I didn't see any reasonable way to make it detect a rev c board so I used a #define.

Still trying to get eclipse/openocd working under Linux or Windows.

I was trying to use gdb to on the startup code. When using openocd gdb monitor reset run_and_halt seems to always execute the startup code before halting. Do you know how to use gdb on the startup code?

diff -rcw FreeRTOSV4.7.2/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/main.c FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/main.c
*** FreeRTOSV4.7.2/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/main.c2008-02-21 19:05:50.000000000 -0500
--- FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/main.c2008-02-22 16:00:17.000000000 -0500
***************
*** 107,112 ****
--- 107,115 ----
#include "rit128x96x4.h"
#include "osram128x64x4.h"

+ /* 1 if running on Luminary Micro LM3S6965 Rev C Board with RIT OLED else 0 */
+ #define EK_LM3S6965_REVC 1
+
/*-----------------------------------------------------------*/

/* The time between cycles of the 'check' functionality (defined within the
***************
*** 333,339 ****
--- 336,344 ----
for the evaluation kit being used. */
switch( HWREG( SYSCTL_DID1 ) & SYSCTL_DID1_PRTNO_MASK )
{
+ #if !EK_LM3S6965_REVC
case SYSCTL_DID1_PRTNO_6965:
+ #endif
case SYSCTL_DID1_PRTNO_2965:vOLEDInit = OSRAM128x64x4Init;
vOLEDStringDraw = OSRAM128x64x4StringDraw;
vOLEDImageDraw = OSRAM128x64x4ImageDraw;
diff -rcw FreeRTOSV4.7.2/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/rit128x96x4.c FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/rit128x96x4.c
*** FreeRTOSV4.7.2/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/rit128x96x4.c2008-02-17 18:36:14.000000000 -0500
--- FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/rit128x96x4.c2008-02-22 15:51:12.000000000 -0500
***************
*** 56,61 ****
--- 56,66 ----
#define LM3S8962_GPIO_OLEDDC_PIN GPIO_PIN_6
#define LM3S8962_GPIO_OLEDEN_PIN GPIO_PIN_7

+ #define LM3S6965_SYSCTL_PERIPH_GPIO_OLEDDC SYSCTL_PERIPH_GPIOC
+ #define LM3S6965_GPIO_OLEDDC_BASE GPIO_PORTC_BASE
+ #define LM3S6965_GPIO_OLEDDC_PIN GPIO_PIN_7
+ #define LM3S6965_GPIO_OLEDEN_PIN GPIO_PIN_6
+
#define LM3S1968_SYSCTL_PERIPH_GPIO_OLEDDC SYSCTL_PERIPH_GPIOH
#define LM3S1968_GPIO_OLEDDC_BASE GPIO_PORTH_BASE
#define LM3S1968_GPIO_OLEDDC_PIN GPIO_PIN_2
***************
*** 591,597 ****
// If there is room, dump the single data byte column to the
// display. Otherwise, bail out.
//
! if(ulX < 126)
{
RITWriteData(g_pucBuffer, 8);
ulX += 2;
--- 596,602 ----
// If there is room, dump the single data byte column to the
// display. Otherwise, bail out.
//
! if(ulX <= 126)
{
RITWriteData(g_pucBuffer, 8);
ulX += 2;
***************
*** 845,856 ****
/* Determine which board is being used. */
if( SysCtlPeripheralPresent( SYSCTL_PERIPH_ETH ) )
{
! /* Ethernet is present, we must be using the LM3S8962 EK. */
ulGPIOId = LM3S8962_SYSCTL_PERIPH_GPIO_OLEDDC;
ulGPIOBase = LM3S8962_GPIO_OLEDDC_BASE;
ulOLEDDC_PIN = GPIO_PIN_6;
ulOLEDEN_PIN = GPIO_PIN_7;
}
else
{
/* Ethernet is not present, we must be using the LM3S1968 EK. */
--- 850,871 ----
/* Determine which board is being used. */
if( SysCtlPeripheralPresent( SYSCTL_PERIPH_ETH ) )
{
! /* Ethernet is present, check if LM3S6965 or LM3S8962 EK. */
! if ( (HWREG( SYSCTL_DID1 ) & SYSCTL_DID1_PRTNO_MASK) == SYSCTL_DID1_PRTNO_6965) {
! ulGPIOId = LM3S6965_SYSCTL_PERIPH_GPIO_OLEDDC;
! ulGPIOBase = LM3S6965_GPIO_OLEDDC_BASE;
! ulOLEDDC_PIN = LM3S6965_GPIO_OLEDDC_PIN;
! ulOLEDEN_PIN = LM3S6965_GPIO_OLEDEN_PIN;
! }
! else
! {
ulGPIOId = LM3S8962_SYSCTL_PERIPH_GPIO_OLEDDC;
ulGPIOBase = LM3S8962_GPIO_OLEDDC_BASE;
ulOLEDDC_PIN = GPIO_PIN_6;
ulOLEDEN_PIN = GPIO_PIN_7;
}
+
+ }
else
{
/* Ethernet is not present, we must be using the LM3S1968 EK. */

RE: Compiling Cortex-M3 LM3S6965 Demo Under L

Posted by David Gesswein on February 24, 2008
I have put a page at http://www.pdp8.net/other/freertos_linux/install.shtml that documents how to setup the demo project under Linux.

RE: Compiling Cortex-M3 LM3S6965 Demo Under L

Posted by Richard on February 25, 2008
Excellent - thanks. Will this be a permanent link? If so I can link to it from the FreeRTOS.org Stellaris pages.

Regards.

RE: Compiling Cortex-M3 LM3S6965 Demo Under L

Posted by David Gesswein on February 25, 2008
Yes it will be permanent. http://www.pdp8online.com/other/freertos_linux/install.shtml is the better URL t o use.

Anybody know how to set the eclipse memory display to the correct endian when displaying hex?

RE: Compiling Cortex-M3 LM3S6965 Demo Under Linux

Posted by paulk on October 23, 2009
Just to add/confirm this. I was having the same problem with a rev D board. I had to download the updated StelarisWare software and copy the rit128x96x4.c and rit128x96x4.h files into the FreeRTOS project directoy.

I then deleted the osram* and formike* files just in case. I removed the references to osram*.c from the makefile.

I also had to remove the path information from the rit*.c file include statements, and just leave the filenames.

This post saved me LOTS of hair-pulling.

--pk


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS