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.
