On 2025-11-29 18:19, Tomek CEDRO wrote:
Some more typos caught:
...
I fixed them already lets see the CI status now :-)
Hi,
thanks for fixing those typos - I ran the patches through a spellchecker
but there was a lot of false positives (NuttX, AVR, register names etc.)
so unfortunately some things hid among them and got missed.
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.
I see that the first (bugfix) branch is already merged - thanks for the
help.
