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

Reply via email to