you might be right, or not, I cant tell.
To be honest, I find this specific rule to be very complex. it's not
easy to understand its effect (I did not apparently)
so it should be reworded at least.
I suggest still not to integrate it as-is.
Sebastien
On 12/02/2025 19:21, Tiago Medicci Serr
Hello
the hardware and driver are cool.
However, if this driver is accepted, I will be very mad, as several
years ago, I built a complete radio transceiver driver framework based
on character devices (for the si4463, using a lower/higher half
approach, and it was fully working), and this was
My votes:
18. Pull Requests should be as small as possible and focused on only
> one functional change. Different functional changes should be provided
> in separate Pull Requests. Remember that breaking changes are not
> welcome. Pull Requests must not break overall build, runtime, and
> compatib
Hi all, here's my update on items 18 and 19 recently added.
18: +1
Following suggestions from my colleagues, please also add documentation to this.
19: +1
Makes sense to me. I strongly support this as we don't have that many people to
review and approve.
We can't stop going forward, but this ite
Lwazi - today was a school day and you are now my favourite teacher :-)
You could not have explained this more clearly or thoroughly and I
TOTALLY get it now!!!
THANK YOU
What you propose as the way to do it - just use the load address as
provided in the MCUboot header and running from t
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
I figured it out. The poll() implementation already supports this (see
poll_cleanup()), but it was (implicit) disabled in my configuration:
CONFIG_TLS_NCLEANUP=0
Increasing it, solved the issue. The driver's poll "teardown" is then called
before the driver's close function.
Thank you for your i
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
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
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
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
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
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
`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
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
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
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
> 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.
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
20 matches
Mail list logo
