Quality RTOS & Embedded Software

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


compiler differences, tuning, linkin together

Posted by Rainer on April 28, 2006
hi all,

Richard pointed out that plain arm-elf-gcc uses more stack than rowley, which in turn uses more than iar. so i'm looking at ways to reduce the stack size used with gcc and optimize it as far as possible.
- do you have any suggestion about what configuration parameters or other ways might tuning arm-elf-gcc? (and how does rowley do it, if it's based on gcc?)
- do i understand it right that the amount of stack size eaten up (i'm not talking about the amount allocated) depends on the compiled code in a way that the optimization is to be searched for in the compiling stage, not at the linking stage?
- last time i used iar was a while ago with msp430 , and it seemed to be 100% gui-bound. is there also a command-line compiler included?
- is it practically feasible to link together stuff compiled separately with iar and gcc?
- as it's openly available for a multitude of host OSes (including linux) and target architectures and since i feel at home with gcc, make etc (and like the way it's all open), i have pretty much standardized all i could on gcc and feel reluctant about changing to a proprietary compiler suite. right now, apart from the bigger stack size (which isn't so problematic), i'm quite happy with gcc. I 'm still a little fresh with arm and FreeRTOS though, so is there any other problem about arm-elf-gcc that i should know about?
- any other ideas or comments related to optimizations of gcc or how to get them to work together?


RE: compiler differences, tuning, linkin together

Posted by Richard on April 29, 2006
GCC is a generic compiler targeted at a whole multitude of processors and systems. The compiler itself is very good at optimising (IMHO) and therefore good for microcontroller use, but the libraries that come with it were no written with small microcontrollers in mind.

From what I have read regarding (non bias) comparisons between ARM compilers the libraries that come with GCC are its major downfall due to the stack they consume. In most embedded applications this is not really an issue, but when you start doing lots of string manipulation for serving html then you are going to start using strcat, strlen, strcpy, etc, etc.

If you can, isolate all the code that uses these libraries into one or two tasks, then just allocate more stack to these tasks.

There may be other libraries around you can use targeted specifically at smaller devices.

In the past, if I have just required a few library functions, I have written them myself rather than include the versions that come with the compiler. For example, I did this in the WIZnet WEB server demo.

As far as IAR goes, you can call the compiler from the command line just like GCC, but I would not attempt to link IAR and GCC code together.


RE: compiler differences, tuning, linkin toge

Posted by Rainer on April 29, 2006
thanks for the information.

there's just one thing i'm not sure about concerning the libraries: most every arm-elf-gcc toolchain out there doesn't use the gnu libc (glibc) as the standard c library, but newlib (which pretends to be programmed specifically for embedded stuff and smaller resources). i thought the c string functions and others of the kind were in there. obviously, newlib (as a general, platform-independent libc) is still not at the highest level of optimization.

for atmel's smaller avr family, there's a specially optimized open source libc (avrlibc). i guess that's missing for the arm family.

thanks for the info

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

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.


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


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