Oh, sorry, in fact that other file has a proper read() function!
BR,
Alan
On Thu, Feb 13, 2025 at 4:36 PM raiden00pl wrote:
> That is not true Alan ;) you are looking at the wrong driver. Look at
> drivers/sensors/sensor.c not drivers/sensors/usensor.c. usensor has
> different purpose.
>
> On
That is not true Alan ;) you are looking at the wrong driver. Look at
drivers/sensors/sensor.c not drivers/sensors/usensor.c. usensor has
different purpose.
On Thu, Feb 13, 2025, 20:26 Alan C. Assis wrote:
> Hi Matteo and Matheusz,
>
> What I mean was the original driver doesn't have a direct re
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 rea
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
bu
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 h
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 napisał(a):
> Yes, mcp9600_uorb.c no
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()` onl
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 u
> 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.
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 wrote:
> `uORB sensors` is a misleading term. All new sensors are character drivers,
> but with
> a standardized
Hi Tim,
I think it depends on the contributor's needs.
In the case of the MCP9600, Matteo realized that uORB was better suited to
his needs than char device driver and converted it from char device to uORB.
But anyone willing to use this sensor as a char device can rewind the git
repo and recover
`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 application
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 wrote:
>
> Good quest
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 A
Yes, we still have char driver sensors and uorb sensors
On Wed, Feb 12, 2025 at 5:05 PM Tim Hardisty
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,
> >
>
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
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 Yash
I am not able to understand can you describe it briefly?
Thank you!
On Thu, Feb 13, 2025, 1:35 AM Tim Hardisty 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
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
wrote:
Is
Hello
I enabled the sensortest in sensor drive <- testing<- application
configuration..
But in ls/dev
Uorb is not available+ imu0 is visible
On Thu, Feb 13, 2025, 1:00 AM Alan C. Assis wrote:
> Hi Tim,
>
> It came from PX4 and how it is used for our sensors.
>
> BR,
>
> Alan
>
> On Wed, F
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/
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
wrote:
> Yes, I successfully completed the I2C scanner.
>
> After achieving success with I
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," t
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
wrote:
> But
>
> I’m having a little trouble finding the BMI270 option in the application
> configuration examples.
>
> Thank you!
>
> On W
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 wrote:
>
>
> Hello,
>
> By applying this, I was able to successfully execute the I2C scanner.
>
> Thank you!
>
> On Wed, Feb 12, 20
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 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 y
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 0800
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:
process: K5
up_dump_register: R0: 4000541c R1: R2: 0048 R3:
0001
up_dump_register: R4: R5: R6: 000
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
wrote:
> Hello,
>
> I am attempting to retrieve data from a BMI270 sensor on an STM32H7 board.
>
> However, when using the I2C scanner, a p
28 matches
Mail list logo
