The fixed-point version of the new framework is essentially ready. There's nothing complicated there; the only requirement is the use of macros for mathematical operations. Many uorb sensors must be rewritten to use these macros; I've only ported a few.
In one of the issues, I mentioned the steps needed to further optimize the new framework. Like disable the timestamp in returned data (64 bits int) or use the fetch interface instead of the polling thread. It shouldn't be difficult. On Tue, Dec 2, 2025, 21:07 Matteo Golin <[email protected]> wrote: > Hi KR, > > I won't reject your PR because it is a legacy interface. I don't really > think we should merge those anymore because it creates more work down the > line, but at least in this specific case I think it's pretty much > impossible for you to use the standardized interface because of floating > point. So I won't be opposed to merging it. I think raiden may have > implemented some small subset of the fixed point version but I don't think > it's enough for you to re-write your driver with yet. > > Unfortunately we can't really fix this issue for architectures that have > trouble with floats until we design the fixed point version properly and > that will just take too much time to reasonably delay your PR. So I think > in this case it's acceptable to merge. > > Matteo > > On Tue, Dec 2, 2025, 2:51 PM <[email protected]> wrote: > > > I see that the TWI patch is merged, thanks for everyone involved. > > > > As for the driver - PR #17405 - user jerpelea left a comment with a > > request to resolve conflicts. Did a quick check, seems that another > > sensor driver was merged so it probably won't be that difficult to > > resolve. I can certainly do it but the question is if the driver is not > > getting rejected anyway because of the old interface issue. > > > > On 2025-11-30 16:46, Tomek CEDRO wrote: > > > On Sun, Nov 30, 2025 at 4:38 PM <[email protected]> wrote: > > >> On 2025-11-29 18:19, Tomek CEDRO wrote: > > >> > Some more typos caught: > > >> > ... > > >> > I fixed them already lets see the CI status now :-) > > >> > > >> 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. > > > > > > no worries :-) > > > > > >> > 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. > > >> (..) > > > > > > thank you for valuable feedback, i copy pasted to uorb mailing thread, > > > please join discussion over there :-) > > > > > >> I see that the first (bugfix) branch is already merged - thanks for > > >> the > > >> help. > > > > > > thank you for valuable fixes and contributions! :-) > > > > > > -- > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > >
