Im trying to wrap my head around os devices and sensors and am finding the
current implementations odd.

>From what I can gather, os_dev_create creates an os device which mainly
provides the benefit of being able to open,suspend, resume,close a
resource. It does this by calling a callback (device init) function after
it finishes whom it expects to register the handler functions

But oddly NOTHING in mynewt utilizes suspend or resume functionality, and
only adc, uart and pwm even register open/close handlers.

Even more odd is that none of the slew of sensors registers ANY handlers
with os_device, and are therefore completely wasting the memory associated.

Proof of this lies in the fact that only one out of the six upstream sensor
implementations (the shell implementations) even bothers to find and open
its existing device
https://github.com/apache/mynewt-core/blob/master/hw/drivers/sensors/bma253/src/bma253_shell.c

The other five leave the os device closed and they make a fresh interface.
https://github.com/apache/mynewt-core/blob/master/hw/drivers/sensors/bmp280/src/bmp280_shell.c#L39
https://github.com/apache/mynewt-core/blob/master/hw/drivers/sensors/bno055/src/bno055_shell.c#L45
https://github.com/apache/mynewt-core/blob/master/hw/drivers/sensors/bno055/src/bno055_shell.c#L45
https://github.com/apache/mynewt-core/blob/master/hw/drivers/sensors/tcs34725/src/tcs34725_shell.c#L38
https://github.com/apache/mynewt-core/blob/master/hw/drivers/sensors/tsl2561/src/tsl2561_shell.c#L55

Which as I said, actually makes sense since opening doesnt do anything

Which isnt to tear down any work by anyone involved, Its not like I offered
any input when this was all being merged originally :)

Thoughts on what the usefulness of os_dev is and should be and thus how
sensors should or shouldn't be built on top of them?

Reply via email to