Get an mbed!
Subscribe to the mailing list
Please note, changing the compiler toolchain introduces many degrees of freedom in the system; these differences include the translation of C/C++ code to assembly code, the link time optimizations, differences because of the implementations of the C standard libraries, and differences based on compile and link options. It also makes it a lot harder to share code and questions with other developers, as the context needs to be shared too!
Whilst we support exporting your project and the libraries to an alternate toolchain, we cannot guarantee the same consistency as using the mbed Online Compiler. We will do our best to maintain the exported libraries, project file and makefiles, but please understand we can not cover all cases, combinations or provide support for use of these alternate tools themselves!
Code Red is one of the external offline toolchains supported by the mbed platform.
For a complete overview of the "export" feature, please refer to our general: Exporting to offline toolchains.
To export your mbed program for use in Code Red, right-click the program in your program workspace. From the dialog, you can select the "Export To" as "code_red Red Suite 4", and the target microcontroller you wish to export for.
When you choose export, a zip file containing all the files you need for Code Red will be generated.
The zip file is ready to be imported in Red Suite. In the "Quickstart Panel" click on the "Import project(s)" and select the project archive (.zip) path.
After the build, your binary will be generated in the "Release", or "Debug" directory, depending on the selected configuration.
These are the toolchain options we are using:
-std=gnu++98 -Os -fno-common -fmessage-length=0 -fno-exceptions -fno-builtin -ffunction-sections -fdata-sections -mcpu=cortex-m3 -mthumb -D__NEWLIB__ -D__CODE_RED -D__USE_CMSIS -DCPP_USE_HEAP
-Wl,--gc-sections -mcpu=cortex-m3 -mthumb -nostdlib
Emilio Monti wrote: The key issue was that the exception handling name demangling code was pulled in even if we were not using exceptions.
Emilio,
Is this related to the verbose_terminate_handler() function implemented in your stdio.cpp? The reason I ask is that I was doing some size optimizations on binaries using your new libs and noticed this function. After some investigation I determined that the terminate handler was getting pulled into some of my mbed based binaries because of pure virtual stubs. I found that if I added a basic implementation of __cxa_pure_virtual() which just called abort() then the terminate handler path would be removed all together (so that verbose_terminate_handler() wasn't needed at all). The only C++ runtime code that was then pulled in related to some RTTI functionality used by the mbed library.
It appears that the mbed library's verbose_terminate_handler() was calling fprintf() which pulls in >30k of code on GCC. Most of this bloat is from the fact that it appears to pull in the bulk of the floating point math operations. Similar inclusion of floating point routines with the ARM RealView compiler only adds about 4k. Way to go ARM! It would be best if calls to fprintf() could be avoided or we figure out a way to make its use have a smaller impact on the resulting code size.
I noticed this while playing with your GCC libraries on the mbed-m0 beta device. I get errors from the beta compiler indicating that GCC_CS isn't supported as an export option for the LPC11U24. What is the plan here? I will say that the code size difference with GCC is much more noticeable on a device that only has 32k of FLASH :)
On a final note, I am really impressed with your work on pulling these libraries together. You have done a great job!
-Adam
Adam Green wrote: Is this related to the verbose_terminate_handler() function implemented in your stdio.cpp?
Yes, exactly. At the moment we are keeping the largest part of the specific C standard library retargeting in this file.
Adam Green wrote: the terminate handler was getting pulled into some of my mbed based binaries because of pure virtual stubs. I found that if I added a basic implementation of __cxa_pure_virtual() which just called abort() then the terminate handler path would be removed all together (so that verbose_terminate_handler() wasn't needed at all).
Thanks, we can break this “pull chain” a link earlier. I will update the next version of the libraries.
Adam Green wrote: The only C++ runtime code that was then pulled in related to some RTTI functionality used by the mbed library.
Yes, we could probably manage to remove the RTTI requirement. It is already in the list of things I will investigate.
Adam Green wrote: It appears that the mbed library's verbose_terminate_handler() was calling fprintf() which pulls in >30k of code on GCC. Most of this bloat is from the fact that it appears to pull in the bulk of the floating point math operations. Similar inclusion of floating point routines with the ARM RealView compiler only adds about 4k. Way to go ARM! It would be best if calls to fprintf() could be avoided or we figure out a way to make its use have a smaller impact on the resulting code size.
Yes, unfortunately in the industry there is the tradition of not supporting C++ with the space optimized libraries (redlib, microlib, etc).
It is quite a shame because it is not that hard to add C++ support to a C library. I did that for the microlib version we use in the online compiler for the M0.
In a similar way, the Code Red team could update its Redlib library adding C++ support.
Alternatively, the open source community could improve Newlib!
Adam Green wrote: I noticed this while playing with your GCC libraries on the mbed-m0 beta device. I get errors from the beta compiler indicating that GCC_CS isn't supported as an export option for the LPC11U24. What is the plan here? I will say that the code size difference with GCC is much more noticeable on a device that only has 32k of FLASH :)
We are still trying to improve the code space before releasing it. At the moment, I cannot even run the whole set of tests because of memory size constraints.
Adam Green wrote: On a final note, I am really impressed with your work on pulling these libraries together. You have done a great job!
Thanks, Emilio
Emilio Monti wrote: It is quite a shame because it is not that hard to add C++ support to a C library. I did that for the microlib version we use in the online compiler for the M0.
The online compiler is using microlib for the LPC11U24 part and the full ARM C library for the LPC1768 part? Is that correct?
Adam Green wrote: The online compiler is using microlib for the LPC11U24 part and the full ARM C library for the LPC1768 part? Is that correct?
Yes, a custom version of microlib with C++ support for the LPC11U24 and the ARM C library for the LPC1768 part.
Eli Hughes wrote: "fatal error cstlib: No such file or directory" in Base.h
The problem is given by the file extension of your source files: for C++ files you should use ".cpp", instead of ".c".
Note: the mbed libraries are written in C++, therefore each source file including the mbed headers should be considered C++.
For simplicity, the online compiler is treating both ".c" and ".cpp" files as C++ files, this is not the case for "Red Suite" projects.
HTH, Emilio
Please login to post comments.
Wiki home
Recent changes
All Pages
New Page
Exporting to offline toolchains 
Page history
Test with my
http://mbed.org/users/dreschpe/notebook/micro-paint/
demo. uVision has worked, but with GCC it compile but does not run. I get some warnings :
DigitalIn.h:35:31: warning: 'mbed::DigitalIn' has a field 'mbed::DigitalIn::_gpio' whose type uses the anonymous namespace
but i think the code is ok at this position. The display is initialised, but not cleared. I will try to debug with a LPCXpresso board, but I have to shrink the code fist. Can only debug to 128K with the LPC-Link. The code is realy big compared with the Keil compiler. 137K / 33K.
Peter