Since the beginning of our project I have been monitoring code size, since we had some reservations about the ROM usage of part of mbed-os.
However, we’ve come to a big surprise today. mbed-CLI always reported the total Flash usage (or so we thought) upon each successful build. However, it turns out this does not take into account .rodata, and instead is just .text + .data. This means we’ve been using about 50 K more Flash than we expected.
Is it an oversight that the build size report does not include .rodata?
As I mentioned in the (closed!) Github issue, it is really a shame that this broken tool is still being used by default. As a workaround, you can use arm-none-eabi-size to track the correct code size.
Thanks guys. What a shame how they handled this. Well, we’re probably forced due to code size constraints to migrate away from mbed-os anyway, but this wasn’t the best parting gift.
This adds up to 64739, which is about double what our previous project (FreeRTOS + custom drivers) uses. Part of the reason is that mbed-os makes use of HAL drivers rather than LL, which makes development easier but also increases code size quite a lot.
Then, because mbed-os uses CMSIS RTOS2 API to abstract the OS, this adds another 10906 bytes. These are some examples. Then there are other reasons, such as:
mbed-os cmake has long been in development, but is still not marked as ready, which means we are stuck using mbed build tools and their limitations, such as:
lack of custom firmware versioning
not able to use different mbed_app.json files per release configuration (debug/release)
I see, we have plenty of space in our MCU so this doesn’t really bother us, but I can understand how it’s an issue for you.
Nothing prevents you from using only the RTOS and providing your own drivers using LL instead of mbed’s. We have actually structured our project to be able to do that in the future using DI and interfaces. Of course this comes at a cost of using vtables, but for the moment this doesn’t have a real impact on performance.
We’ve been using USCRPL/mbed-cmake for quite some time now and it works great. We are now moving to mbed’s vanilla cmake.
This is more a CI issue than an mbed’s one, no? What would you need in mbed to be able to do that ?
Using cmake you “can” – you might need to provide the cmake config yourself and not use mbed-tools configure (only twice at the beginning to get the configs) but it’s worth it and you’ll have full control afterwards.
Yup this one’s a bummer, I’ll have to rework our CI because of that… We do code size analysis on every pr/commits.
This article (not sure if someone just shared it or if I googled it) has a very nice solution:
