mbed

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

Hi Peter, thank you for the feedback. I was aware of the warning, time permitting, I should be able to fix it in the following days.

One of the main reason behind the big code size is that we are using "Newlib" instead of "Redlib", because we need C++ support: http://support.code-red-tech.com/CodeRedWiki/RedlibAndNewlib

Emilio

I have also test it with the tuned libs from Adam Green. This code was 83K.

Peter

I have used a LPCXpresso board to debug. The problem is the freopen command. I use the TextDisplay class from Simon to implement my TFT lib. Inside the claim command a freopen is used. This end in a hardfault. Without the claim command the program is running - but without text.

Hope that help to fix.

Peter

OK, we managed to reduce the size of the library. The key issue was that the exception handling name demangling code was pulled in even if we were not using exceptions.

The beta library has been updated: http://mbed.org/projects/libraries-testing/svn/m0-beta

Good news, it is working with the new library. The new codesize is 94kb / 137Kb.

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

Yes, exactly. At the moment we are keeping the largest part of the specific C standard library retargeting in this file.

Thanks, we can break this “pull chain” a link earlier. I will update the next version of the libraries.

Yes, we could probably manage to remove the RTTI requirement. It is already in the list of things I will investigate.

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!

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.

Thanks, Emilio

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.

Hello:

I am having trouble with one of my MBED projects witht code red tool. I am using the 256k NXP edition. I have a project:

http://mbed.org/users/emh203/programs/COMPACT_FLASH/m30jkp

that gives the error:

"fatal error cstlib: No such file or directory" in Base.h

Other than Mbed, the only other library I am using is MODSERIAL

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

Thought I would give the exported code a try as I am missing some of the features of a desktop IDE (Autocomplete!). Exported to CodeRed (NXP Edition) and compilied ... (Program is available at http://mbed.org/users/roselea/programs/AirCon/m70xdm) Get the following error

Error: AirCon.axf: hidden symbol `ARM_grp_.debug_frame$$$i._ZN4mbed14FileSystemLike6renameEPKcS2_$i._ZN4mbed14FileSystemLike6renameEPKcS2_' isn't defined

and a number warnings about wchar_t being 2 byte in library and 4 byte in output (All from FATFileSystem Library). The latter can probably be fixed by using the source for the library rather than the compiled version. But the I dont know where the hidden(!) symbol is being defined...

The example above shows exporting for the 11U24 for code red. But when I try to do that, I get an error about it not being supported on the code red toolchain. The 1768 works just fine (export, compile, run, all good).

Is this on the list of things to get working? Or can somebody help me out with how to export my M0 program down to code red? Thanks.

SOLVED

Hi guys,

Every time I debug the code which I have exported from the Mbed compiler, I get errors in the Mbed can_helper.h, PeripheralNames.h, PinNames.h and PortNames.h libraries.

May I know if this has to do with the complier and linker settings in the RedCode toolchain? If so, how do I go about making these changes?

Thanks

OS : Windows 7 Pro on Dell Precision T3500 (Xeon Quad - 6GB ram)

I run into trouble when exporting following 2 mbed projects to LPCXpresso v4.3.0 [Build 1023] [2012-09-19]:

Peter Drescher's TFT_Test1

Jonne Valola's SPI18TFT (code based on Peter Drescher's code)

Also note that several warnings occur when compiling these projects in the mbed compiler:

The first problem i encounterd was the typedef enum error - resolved after reading http://mbed.org/forum/mbed/topic/2336/?page=1#comment-12269

The second problem was an array declaration - resolved

I'm stuck at the third problem - Build project on LPCXpresso (Debug or Release): Compilation stops at following message c:/nxp/lpcxpresso_4.3.0_1023/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe: unrecognized option '-T' c:/nxp/lpcxpresso_4.3.0_1023/lpcxpresso/tools/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe: use the help option for usage information

Any ideas on how to resolve this issue?

Is this flow working for others? I exported to code red and the project link command includes -lmbed. However the project file that I downloaded doesn't have an mbed library in it. There are some .a files, but no libmbed.a.

any suggestions? thanks, steve

Hi, I have the exact same problem. how can I fix this?