Great! Maybe this driver can build on your work then. On Tue, Dec 2, 2025, 3:38 PM raiden00pl <[email protected]> wrote:
> 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 > > > > > >
