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. > >>>>>>>>>>>>>>>>>>>>>> >
