Here is some info on AVR from KeroGit from another mailing thread: On Sun, Nov 30, 2025 at 4:38 PM <[email protected]> wrote: > On 2025-11-29 18:19, Tomek CEDRO wrote: > > Raiden already reaised an issue on GH about floats in uORG and there > > is a proposition to use fixed point built time alternative, please > > take a look here: > > https://github.com/apache/nuttx/issues/10644 > > I will start a mailing list discussion in a moment this seems important > > :-) > > I did two quick tests with a code that reads data from I/O port (to > force data to be unknown at a build time so the compiler cannot > optimize) and does sprintf with it. Second test added division by 10 to > the first one. > > Without the division, the code size was 1716, 1722 and 1844 bytes for > uint8_t, uint32_t and float respectively. Not a huge difference. With > the division, the sizes were 1730, 1804 and 2246 bytes. That's a not > insignificant difference and the computational cost probably isn't > negligible either, but at the same time it's not that huge. Overall, > being able to use fixed point calculations would certainly improve > things somewhat. > > I also did another test - tried to compile the bmp180 driver with both > old and new interface and there seems to be a 8kB difference in code > size. (Not completely sure - for some reason, I cannot compile code that > has floats in it with NuttX, something from the standard library is > probably not loaded correctly. Despite that, the build process printed > code size table but I have no idea if it can be trusted.) I think it was > mentioned either in the neighbouring discussion or in some GitHub > discussion already - the framework builds with multiple modes of > operation (both periodic fetch and on-demand read) and the first one > needs work queues. Guess that's where the code size increase comes from > and on a device with 128kB program memory, 8kB is a lot. > > So in my opinion, the interface - while being better in many regards - > feels too heavy for small systems at the moment.
-- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
