One little nasty assertion in the GNU standard library appeared a few days ago, kind out of nowhere, reporting “REENT malloc succeeded”:
Obviously it was caused by the call to srand() which sets the ‘seed’ for the standard library (pseudo) random number generator. The assertion happens as well later for calling the rand() function.
Continue readingIt is always good to have a close look what ends up in a microcontroller FLASH memory. For example using EHEP Eclipse plugin to inspect the binary file:
Source File Name in Binary Image
Obviously it has path and source file information in it. Why is that? And is this really needed?
What about:
So let’s have a look what is the reason for this and how it could be avoided or at least reduced.
It is great if vendors provide a starting point for my own projects. A working ‘blinky’ is always a great starter. Convenience always has a price, and with a ‘blinky’ it is that the code size for just ‘toggling a GPIO pin’ is exaggerated. For a device with a tiny amount of RAM and FLASH this can be concerning: will my application ever fit to that device if a ‘blinky’ takes that much? Don’t worry: a blinky (or any other project) can be easily trimmed down.
Binky on NXP LPC845-BRK Board
I use a ‘blinky’ project here just as an example: the trimming tips can apply to any other kind of projects too.
MCU on Eclipse 