Quality RTOS & Embedded Software

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


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 ]    [ Privacy ]    [ Sitemap ]    [ ]


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

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

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

Xilinx Microblaze and Zynq partner