Quality RTOS & Embedded Software

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




Loading

Case problems, again

Posted by Jay Maynard on August 19, 2007
The CodeSourcery G++ package for Stellaris, at least (and, I suspect, all of their supported architectures) both supplies and requires using a Unix environment under Windows. I keep tripping over case botches (case is different in the #include statement and the actual filename). Fixing these is getting annoying. The right way to do it is to always name include files in lower case and use lower case in #include statements.

I know that it's not an issue under native Windows, but not all the world is Windows! I would be doing this entirely under Linux (or Mac OS X) if I could; I hate using Windows in general.

Can this please be fixed *and stay fixed*?

RE: Case problems, again

Posted by Richard on August 20, 2007
You are not the first to complain about this. I only run Windoze so don't get to test on Linux. When people point our errors I try and correct them - but there are an awful lot of makefiles and it is tricky to re-test every one to ensure any case changes have not caused any problems.

Regarding CodeSourcery. I can build using the the CodeSourcery tools from just a native command shell (DOS box). I don't need to use a Cygwin bash shell. The demos as in the FreeRTOS.org download all build ok for me. Is this not the case for you?

Regards.

RE: Case problems, again

Posted by Jay Maynard on August 20, 2007
They build in the DOS box, but I can't use their suggestion of a shortcut definition in the .gdbinit file to replace the long (and, in the FreeRTOS doc, incorrect) command to connect to the controller that way.

The CodeSourcery tools include a Unix command environment that isn't Cygwin, and that environment is used under the covers even if you're in a DOS box. You can also invoke that shell (and that's what they tell you to use) by running the command C:\bin\sh .

Here's a test you can run: In a DOS box, run make to build the package. Run make *again*, as though you were rebuilding after changing one file (you don't need to actually change any files for this test). The second make will complain about missing dependencies. That's because the case differences will be picked up by make from the automatically-generated gcc/*.d files. Changing the case in the source, then doing make clean, then make, then make again will show the problem is fixed (and reveal the next one to fix). I spent an hour or so last night doing that.

RE: Case problems, again

Posted by Richard on August 20, 2007
> They build in the DOS box, but I can't use their suggestion
> of a shortcut definition
> in the .gdbinit

I have not tried using an init file, but in the past I have found on a Windoze host that the file has to be called gdb.ini, rather than .gdbinit.

>file to replace the long (and, in the
> FreeRTOS doc, incorrect)
> command to connect to the controller that way.


What is incorrect with it?

> Here's a test you can run: In a DOS box, run make to build
> the package.

Ok, here is my output.

C:\E\Dev\FreeRTOS\Demo\CORTEX_LM3S6965_GCC>make clean

C:\E\Dev\FreeRTOS\Demo\CORTEX_LM3S6965_GCC>make
CC startup.c
CC main.c
CC ../../Source/list.c
CC ../../Source/queue.c
CC ../../Source/tasks.c
CC ../../Source/portable/GCC/ARM_CM3/port.c
CC ../../Source/portable/MemMang/heap_2.c
CC ../Common/Minimal/BlockQ.c
CC ../Common/Minimal/PollQ.c
CC ../Common/Minimal/integer.c
CC ../Common/Minimal/semtest.c
CC LuminaryDrivers/osram128x64x4.c
CC LuminaryDrivers/ustdlib.c
CC ../Common/Minimal/blocktim.c
CC ../Common/Minimal/death.c
CC ParTest/ParTest.c
CC timertest.c
CC webserver/emac.c
CC webserver/http-strings.c
CC webserver/httpd-cgi.c
CC webserver/httpd-fs.c
CC webserver/httpd.c
CC ../Common/ethernet/uIP/uip-1.0/uip/psock.c
CC ../Common/ethernet/uIP/uip-1.0/uip/timer.c
CC ../Common/ethernet/uIP/uip-1.0/uip/uip.c
CC ../Common/ethernet/uIP/uip-1.0/uip/uip_arp.c
CC webserver/uIP_Task.c
LD gcc/RTOSDemo.axf


>Run
> make *again*, as though you were rebuilding after changing
> one file (you don't
> need to actually change any files for this test).


Ok, here is my output this time:

C:\E\Dev\FreeRTOS\Demo\CORTEX_LM3S6965_GCC>make
make: Nothing to be done for `all'.


> The second
> make will complain
> about missing dependencies. That's because the case
> differences will be picked
> up by make from the automatically-generated gcc/*.d files.


Which version of make are you using? I am not using cs-make, but (I think) the one from the Cygwin directory.

Regards.

RE: Case problems, again

Posted by Jay Maynard on August 20, 2007
>>file to replace the long (and, in the
>> FreeRTOS doc, incorrect)
>> command to connect to the controller that way.
>What is incorrect with it?

The doc says it should be "target extended-remote | armswd -s 2 -f lmi.dll stdio", when the correct command is "target extended-remote | arm-stellaris-eabi-sprite –s 2 –f lmi.dll stdio".

>Which version of make are you using?
I'm using the one supplied by CodeSourcery, in the c:\usr\local\wbin directory. This comes from the UnxUtils package.


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




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists