xiaoxiang781216 commented on issue #10644: URL: https://github.com/apache/nuttx/issues/10644#issuecomment-1722230472
> I've spent some time playing with the new sensor framework, and I'm much less skeptical about this approach (previous discussion here #10077). It seems to me that with some changes, it can be a good universal solution. Unfortunately, the lack of documentation causes some misunderstanding. Most information about framework can be found in the discussion under #2039 and #2215. Somehow I missed this before :) @Donny9 has a representation about this new driver framework on NuttX workshop 2022: https://www.youtube.com/watch?v=ESpAE6wqy9o > > Some ideas for improvement from my side: > > 1. We should stop referring to this sensor framework as `uorb`. `uorb` is optional and is part of the apps. Referring to `uorb` on the kernel side gives the false impression that uorb is required. Yes, uorb is a simple and optional wrapper on top of sensor ioctl, but we need find a good name since sensor isn't a good name too: 1. The advanced algorithm(eg. step counter, heart rate) can be built with this framework. 2. Other notification can publish with this framework(eg. BT/WiFi connection state and signal strength) > 2. Make sensor register path configurable. Now it is `/dev/uorb` (changed in [c4bed9e](https://github.com/apache/nuttx/commit/c4bed9eae9037297b3f8de6a3547e8ca6361b933)) but as `uorb` is application-specific property, this should be configurable. > 3. Add options to disable some framework functionality. This can save memory on small systems. For example, disabling polling logic and relying only on the `fetch` interface saves some space and gives the user full control over sensor sampling. Each request is reasonable. > Another thing is `timestamp`; in many cases, timestamp doesn't matter for user. It depends on the sensor type and application. If the timestamp isn't really used, driver could skip fill the timestamp value. > 4. The biggest problem I see now is forcing the user to use `float`. This is not the best solution for applications without FPU (e.g. CM0 which are often used in sensor nodes). What if we made the sensor data type configurable? It would be nice if we had an interface that return data in RAW format, but this may unnecessarily complicate the framework. Since hardwire normally report the measurement with the different unit, raw format makes us can't write the general application. > Support for fixedmath type seems to be a good compromise (`b16_t` ?). > Yes, fixedmath may a good option if the hardware doesn't have FPU. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
