Hi Matteo and Matheusz, What I mean was the original driver doesn't have a direct read() as in the old style sensors, and if you look usensor_read() is just return success (the amount of bytes to be read).
I think uORB approach is really good for making the sensors more standardized. The only real benefit from the old approach is when you want to use a little bit less memory. BR, Alan On Thu, Feb 13, 2025 at 4:17 PM Matteo Golin <matteo.go...@gmail.com> wrote: > Hello, > > The MCP9600 was a new driver, I moved it to uORB very shortly after it was > suggested by reviewers. I don't see any value in keeping it in the legacy > format. I believe the user can still read data from uORB sensors with > `read()` (unless I'm misunderstanding the driver structure), just the > buffer must be of the same type as the data returned by the driver (i.e. > `struct sensor_temp`). I believe this is the same approach taken by the ADC > character drivers. > > I am now of the opinion that uORB should definitely be pushed/encouraged > over the legacy implementation for new sensors. I think it could be > restricted a little further as well to prescribe some ioctl commands for > certain sensor classes (i.e. all accelerometers should implement > SNIOC_SETFULLSCALE and accept the argument as the FSR in units of g), but > that is another topic. I just find the interface to be more powerful and > also provide a little more guidance when writing the driver. > > I could add a `fetch` interface if that is a desired feature. It will just > take me some time since I have more pressing things to finish for our > rocket launch to be successful. > > Matteo > > On Thu, Feb 13, 2025 at 1:42 PM Tim Hardisty <timhardist...@gmail.com> > wrote: > > > Thank you for clarifying this. It doesn't impact me right now, but I do > > use sensors in my current project - one, perhaps 2, with drivers I > > contributed in a "legacy" style and I recall at the time it being > > suggested I did them in the uorb-way...but I didn't, and haven't looked > > in detail. > > > > The hijack of this thread (by me!) has at least clarified this. > > Hopefully the NuttX uorb requirement is documented somewhere...<ducks>... > > > > On 13/02/2025 17:05, raiden00pl wrote: > > > What is missing in mcp9600_uorb.c is the `mcp9600_fetch()` interface. > > With > > > it supported, > > > this driver can behave the same like the legacy implementation, so all > > > sampling is controlled > > > by user-space logic, not kernel thread. > > > > > > czw., 13 lut 2025 o 18:02 raiden00pl <raiden0...@gmail.com> > napisał(a): > > > > > >> Yes, mcp9600_uorb.c not support legacy implementation, but `uorb` > > >> implementation > > >> is also a character driver. The new sensor implementation also > supports > > >> simple `read()`. > > >> You can look at `apps/system/sensorscope` - there are no single > ioctl() > > >> call in the code. > > >> It works with `open()` and `read()` only. > > >> > > >> > > >> czw., 13 lut 2025 o 17:38 Alan C. Assis <acas...@gmail.com> > napisał(a): > > >> > > >>> I mean it is not used in the same way as other sensors that have two > > >>> files. > > >>> > > >>> I.e. bmp180 has bmp180.c and bmp180_uorb.c > > >>> > > >>> Using the bmp180.c the application can read data from it using the > > read() > > >>> function. > > >>> > > >>> Using mcp9600_uorb.c on the other hand (since we don't have mcp9600.c > > >>> anymore), even if the user is not using the uORB app, it needs to > > follow > > >>> other approach, i.e. using ioctls for it. > > >>> > > >>> BR, > > >>> > > >>> Alan > > >>> > > >>> > > >>> > > >>> On Thu, Feb 13, 2025 at 1:26 PM raiden00pl <raiden0...@gmail.com> > > wrote: > > >>> > > >>>>> I think this is not the case with the MCP9600. > > >>>> What is not the case? I don't understand what you mean :) > > >>>> `mcp9600_uorb.c` is just a character driver but with standardized > > >>>> interface, so other similar chips can be used with the same > user-space > > >>>> code. > > >>>> You don't need `apps/system/uorb` to use it. > > >>>> > > >>>> > > >>>> > > >>>> czw., 13 lut 2025 o 17:11 Alan C. Assis <acas...@gmail.com> > > napisał(a): > > >>>> > > >>>>> Hi Mateusz, > > >>>>> > > >>>>> I think this is not the case with the MCP9600. > > >>>>> > > >>>>> Matteo, is it possible to keep the original driver and the new one? > > >>>>> > > >>>>> BR, > > >>>>> > > >>>>> Alan > > >>>>> > > >>>>> On Thu, Feb 13, 2025 at 1:02 PM raiden00pl <raiden0...@gmail.com> > > >>> wrote: > > >>>>>> `uORB sensors` is a misleading term. All new sensors are character > > >>>>> drivers, > > >>>>>> but with > > >>>>>> a standardized and portable interface. `uORB` is an optional > > >>> feature. > > >>>>>> Legacy sensors in NuttX are the perfect example of a broken > > >>> solution in > > >>>>>> NuttX. > > >>>>>> With old sensors it's not possible to create portable > applications. > > >>> The > > >>>>> new > > >>>>>> sensor > > >>>>>> framework solves this problem. Its main disadvantage currently is > > >>>>> operating > > >>>>>> on float data, > > >>>>>> in the future fixed-point math should be also supported for MCU > > >>> without > > >>>>>> FPU. > > >>>>>> > > >>>>>> czw., 13 lut 2025 o 16:46 Tim Hardisty <timhardist...@gmail.com> > > >>>>>> napisał(a): > > >>>>>> > > >>>>>>> Maybe it is covered by the “inviolable”? uORB is optional and no > > >>> one > > >>>>>>> should be forced to use it? > > >>>>>>> > > >>>>>>> Surely any NuttX sensor driver MUST have a character driver, but > > >>>> could > > >>>>>>> OPTIONALLY have a uORB variant? Or am I missing something? > > >>>>>>> > > >>>>>>> > > >>>>>>>> On 13 Feb 2025, at 14:02, Alan C. Assis <acas...@gmail.com> > > >>> wrote: > > >>>>>>>> Good question Tim, > > >>>>>>>> > > >>>>>>>> Ideally all sensors should have char device and uorb support, > > >>> but I > > >>>>>> don't > > >>>>>>>> think we have this rule. > > >>>>>>>> > > >>>>>>>> Recently a driver was converted from char device to uorb, so for > > >>>>> driver > > >>>>>>>> that are uorb only, you have to use uORB sensortest application. > > >>>>>>>> > > >>>>>>>> BR, > > >>>>>>>> > > >>>>>>>> Alan > > >>>>>>>> > > >>>>>>>>> On Thu, Feb 13, 2025 at 7:48 AM Tim Hardisty < > > >>>>> timhardist...@gmail.com > > >>>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> Bu all sensors should have character drivers though, not just > > >>>> uORB? > > >>>>> I > > >>>>>>>>> have only briefly searched about uORB but it's a messaging > > >>> system > > >>>>> not > > >>>>>> a > > >>>>>>>>> driver as such I think and it lives in nuttx/apps. Perhaps what > > >>>>>> confused > > >>>>>>>>> me is you saying "BMI270 uses uORB" but perhaps you meant that > > >>> was > > >>>>>> just > > >>>>>>>>> an easy/easier way to test it if there's no BMI270 example app? > > >>>>>>>>> > > >>>>>>>>> Just looking for clarity for my interest but also to make sure > > >>> the > > >>>>> OP > > >>>>>> is > > >>>>>>>>> given full information :-) > > >>>>>>>>> > > >>>>>>>>>> On 12/02/2025 20:30, Alan C. Assis wrote: > > >>>>>>>>>> Yes, we still have char driver sensors and uorb sensors > > >>>>>>>>>> > > >>>>>>>>>> On Wed, Feb 12, 2025 at 5:05 PM Tim Hardisty < > > >>>>>> timhardist...@gmail.com> > > >>>>>>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>>> Ah - so something you choose to use or not? But still we'll > > >>> have > > >>>>>>>>>>> "traditional" drivers for new sensors as they're added? > > >>>>>>>>>>> > > >>>>>>>>>>> On 12/02/2025 19:29, Alan C. Assis wrote: > > >>>>>>>>>>>> Hi Tim, > > >>>>>>>>>>>> > > >>>>>>>>>>>> It came from PX4 and how it is used for our sensors. > > >>>>>>>>>>>> > > >>>>>>>>>>>> BR, > > >>>>>>>>>>>> > > >>>>>>>>>>>> Alan > > >>>>>>>>>>>> > > >>>>>>>>>>>> On Wed, Feb 12, 2025 at 4:21 PM Tim Hardisty < > > >>>>>>> timhardist...@gmail.com> > > >>>>>>>>>>>> wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>>> Is uORB really just a PX4 thing? Not NuttX? Or did NuttX > > >>> adopt > > >>>>>> uORB > > >>>>>>>>> too > > >>>>>>>>>>>>> and I missed it? > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Just curious :-) > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> On 12/02/2025 18:51, Alan C. Assis wrote: > > >>>>>>>>>>>>>> Hi Yashvi, > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> BMI270 uses uORB, you need to use sensortest > > >>>>>>>>> (CONFIG_SYSTEM_SENSORTEST) > > >>>>>>>>>>>>>> Just verify if the sensor was created correctly at > > >>> /dev/uorb/ > > >>>>>>>>>>>>>> BR, > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Alan > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> On Wed, Feb 12, 2025 at 3:23 PM 175 yashvi shah < > > >>>>>>>>> yashvee...@gmail.com> > > >>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Yes, I successfully completed the I2C scanner. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> After achieving success with I2C, I need to retrieve data > > >>>> from > > >>>>>> the > > >>>>>>>>>>>>> BMI270. > > >>>>>>>>>>>>>>> For that, I have done all the necessary configurations, > > >>> and > > >>>>>>>>> everything > > >>>>>>>>>>>>>>> seems perfect. However, when I try to enable the BMI270 > > >>> in > > >>>> the > > >>>>>>>>>>>>> application > > >>>>>>>>>>>>>>> configuration -> "Examples," there is no option for the > > >>>> BMI270 > > >>>>>>>>> sensor. > > >>>>>>>>>>>>>>> On Wed, Feb 12, 2025, 11:43 PM Alan C. Assis < > > >>>>> acas...@gmail.com > > >>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>> Hi Yashvi, > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Please describe the issue you are facing. BTW, did the > > >>> i2c > > >>>>> scan > > >>>>>>>>> find > > >>>>>>>>>>>>> your > > >>>>>>>>>>>>>>>> BMI270? > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> BR, > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Alan > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> On Wed, Feb 12, 2025 at 2:41 PM 175 yashvi shah < > > >>>>>>>>>>> yashvee...@gmail.com> > > >>>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> But.... > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> I’m having a little trouble finding the BMI270 option > > >>> in > > >>>> the > > >>>>>>>>>>>>>>> application > > >>>>>>>>>>>>>>>>> configuration examples. > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> Thank you! > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> On Wed, Feb 12, 2025, 11:05 PM 175 yashvi shah < > > >>>>>>>>>>> yashvee...@gmail.com> > > >>>>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> Hello, > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> By applying this, I was able to successfully execute > > >>> the > > >>>>> I2C > > >>>>>>>>>>> scanner. > > >>>>>>>>>>>>>>>>>> Thank you! > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> On Wed, Feb 12, 2025, 9:16 PM Alan C. Assis < > > >>>>>> acas...@gmail.com > > >>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>>>> Hi Yashvi, > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> You can enable the debug symbols to inspect where > > >>> your > > >>>>> code > > >>>>>> is > > >>>>>>>>>>>>>>>> crashing > > >>>>>>>>>>>>>>>>>>> (the positions at LR: 0800d3b7 PC: 0800dcbe) > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> Enable it in your menuconfig: > > >>>>>>>>>>>>>>>>>>> Build Setup ---> Debug Options ---> [*] Generate > > >>> Debug > > >>>>>>> Symbols > > >>>>>>>>>>>>>>>>>>> Then flash the new image and run: > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> arm-none-eabi-addr2line -e nuttx 0800d3b7 > > >>>>>>>>>>>>>>>>>>> arm-none-eabi-addr2line -e nuttx 0800dcbe > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> Probably these LR and PC values will change for your > > >>> new > > >>>>>>> image, > > >>>>>>>>>>> then > > >>>>>>>>>>>>>>>>>>> modify > > >>>>>>>>>>>>>>>>>>> the commands above to use the new values. > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> BR, > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> Alan > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah < > > >>>>>>>>>>>>>>>> yashvee...@gmail.com> > > >>>>>>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> Yes > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> Details of error > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> dump_assert_info: Current Version: NuttX 12.8.0 > > >>>>>>>>> 1828d09b2a-dirty > > >>>>>>>>>>>>>>>> Feb > > >>>>>>>>>>>>>>>>> 12 > > >>>>>>>>>>>>>>>>>>>> 2025 0m > > >>>>>>>>>>>>>>>>>>>> dump_assert_info: Assertion failed panic: at file: > > >>> :0 > > >>>>> task: > > >>>>>>>>>>>>>>> <noname> > > >>>>>>>>>>>>>>>>>>>> process: K5 > > >>>>>>>>>>>>>>>>>>>> up_dump_register: R0: 4000541c R1: 00000000 R2: > > >>>> 00000048 > > >>>>>> R3: > > >>>>>>>>>>>>>>>>>>>> 00000001 > > >>>>>>>>>>>>>>>>>>>> up_dump_register: R4: 00000000 R5: 00000000 R6: > > >>>> 00000000 > > >>>>>> FP: > > >>>>>>>>>>>>>>>>>>>> 00000000 > > >>>>>>>>>>>>>>>>>>>> up_dump_register: R8: 00000000 SB: 00000000 SL: > > >>>> 00000000 > > >>>>>> R11: > > >>>>>>>>>>>>>>>>>>>> 00000000 > > >>>>>>>>>>>>>>>>>>>> up_dump_register: IP: 00000000 SP: 380008b0 LR: > > >>>> 0800d3b7 > > >>>>>> PC: > > >>>>>>>>>>>>>>>>>>>> 0800dcbe > > >>>>>>>>>>>>>>>>>>>> up_dump_register: xPSR: 21000000 BASEPRI: 00000000 > > >>>>> CONTROL: > > >>>>>>>>>>>>>>>>>>>> 00000000 > > >>>>>>>>>>>>>>>>>>>> up_dump_register: EXC_RETURN: > > >>>>>>>>>>>>>>>>>>>> ffffffe9 > > >>>>>>>>>>>>>>>>>>>> dump_stackinfo: User > > >>>>>>>>>>>>>>>>>>>> Stack: > > >>>>>>>>>>>>>>>>>>>> dump_stackinfo: base: > > >>>>>>>>>>>>>>>>>>>> 0x38000208 > > >>>>>>>>>>>>>>>>>>>> dump_stackinfo: size: > > >>>>>>>>>>>>>>>>>>>> 00002008 > > >>>>>>>>>>>>>>>>>>>> dump_stackinfo: sp: > > >>>>>>>>>>>>>>>>>>>> 0x380008b0 > > >>>>>>>>>>>>>>>>>>>> stack_dump: 0x38000890: 00000000 00000000 00000000 > > >>>>> 00000000 > > >>>>>>>>>>>>>>> 00000000 > > >>>>>>>>>>>>>>>>>>>> 00000000 0d > > >>>>>>>>>>>>>>>>>>>> stack_dump: 0x380008b0: 00000000 38000a48 00000001 > > >>>>> 38000a48 > > >>>>>>>>>>>>>>> 24001e3c > > >>>>>>>>>>>>>>>>>>>> 00000000 00 > > >>>>>>>>>>>>>>>>>>>> stack_dump: 0x380008d0: 00000000 00000000 240000f4 > > >>>>> 38000a48 > > >>>>>>>>>>>>>>> 00000000 > > >>>>>>>>>>>>>>>>>>>> 00000000 39 > > >>>>>>>>>>>>>>>>>>>> stack_dump: 0x380008f0: 3800fff8 38000a48 00000001 > > >>>>> 38000a48 > > >>>>>>>>>>>>>>> 240000f4 > > >>>>>>>>>>>>>>>>>>>> 00000000 0f > > >>>>>>>>>>>>>>>>>>>> stack_dump: 0x38000910: 00000009 38000a58 0800bb13 > > >>>>> 38000a58 > > >>>>>>>>>>>>>>> 00000000 > > >>>>>>>>>>>>>>>>>>>> 08009b71 38 > > >>>>>>>>>>>>>>>>>>>> stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 > > >>>>> 08002075 > > >>>>>>>>>>>>>>> 00000001 > > >>>>>>>>>>>>>>>>>>>> 00000000 7f > > >>>>>>>>>>>>>>>>>>>> stack_dump: 0x38000950: 00000030 380009e8 00000000 > > >>>>> 38000a48 > > >>>>>>>>>>>>>>> 00000000 > > >>>>>>>>>>>>>>>>>>>> 08001e9d 00 > > >>>>>>>>>>>>>>>>>>>> stack_dump: 0x38000970: 00000000 08001e25 00000000 > > >>>>> 080023b1 > > >>>>>>>>>>>>>>> 00000000 > > >>>>>>>>>>>>>>>>>>>> 00000000 00 > > >>>>>>>>>>>>>>>>>>>> stack_dump: 0x38000990: 08003ddc 01000000 00000000 > > >>>>> 00000000 > > >>>>>>>>>>>>>>> 00000000 > > >>>>>>>>>>>>>>>>>>>> 00000000 01 > > >>>>>>>>>>>>>>>>>>>> stack_dump: 0x380009b0: 380001f0 00000001 00000000 > > >>>>> 08003e33 > > >>>>>>>>>>>>>>> 00000000 > > >>>>>>>>>>>>>>>>>>>> 380001f0 00 > > >>>>>>>>>>>>>>>>>>>> stack_dump: 0x380009d0: 00000001 00000001 00000000 > > >>>>> 00000000 > > >>>>>>>>>>>>>>> 00000000 > > >>>>>>>>>>>>>>>>>>>> 00000000 00 > > >>>>>>>>>>>>>>>>>>>> dump_tasks: PID GROUP PRI POLICY TYPE NPX > > >>> STATE > > >>>>>>> EVENT > > >>>>>>>>>>>>>>>>>>>> SIGMASK D > > >>>>>>>>>>>>>>>>>>>> dump_task: 0 0 0 FIFO Kthread - > > >>> Ready > > >>>>>>>>>>>>>>>>>>>> 0000000000> > > >>>>>>>>>>>>>>>>>>>> dump_task: 1 0 240 RR Kthread - > > >>>> Running > > >>>>>>>>>>>>>>>>>>>> 0000000000> > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> On Wed, Feb 12, 2025, 7:12 PM Alan C. Assis < > > >>>>>>> acas...@gmail.com > > >>>>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>>>>>> Hi Yashvi, > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> Please send the dump of this crash, using it you > > >>> can > > >>>>> find > > >>>>>>>>> where > > >>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>>>> code > > >>>>>>>>>>>>>>>>>>>> is > > >>>>>>>>>>>>>>>>>>>>> crashing. > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> BR, > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> Alan > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> On Wed, Feb 12, 2025 at 2:51 AM 175 yashvi shah < > > >>>>>>>>>>>>>>>>> yashvee...@gmail.com > > >>>>>>>>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> Hello, > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> I am attempting to retrieve data from a BMI270 > > >>> sensor > > >>>>> on > > >>>>>> an > > >>>>>>>>>>>>>>>>> STM32H7 > > >>>>>>>>>>>>>>>>>>>>> board. > > >>>>>>>>>>>>>>>>>>>>>> However, when using the I2C scanner, a peculiar > > >>> error > > >>>>> is > > >>>>>>>>>>>>>>>> generated > > >>>>>>>>>>>>>>>>>>> in > > >>>>>>>>>>>>>>>>>>>>>> Minicom. > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> The error is dump_assert_info : current version: > > >>>> nuttx > > >>>>>>> 12.8.0 > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> Furthermore, when trying to configure (make > > >>>>> menuconfig-> > > >>>>>>>>>>>>>>>>> application > > >>>>>>>>>>>>>>>>>>>>>> configuration-> example).there no option of bmi270 > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> Could you please assist me in resolving this > > >>> issue? > > >>>>>>>>>>>>>>>>>>>>>> Thank you. > > >>>>>>>>>>>>>>>>>>>>>> > > >
