add new feature about sensor driver model

[Donny9]

Summary

driver/sensor: add new feature about sensor driver

1.support for multi-user access
2.support special cmd to control sensor
3.support userspace to set size of intermediate buffer by ioctl: SNOIC_SET_BUFFER_SIZE
4.add fetch api to use userspace buffer rather than intermediate buffer of upperhalf driver
5.fetch api support block and non-block ways.
It will directly access sensor register by i2c/spi when open mode is non-block,
It will wait until sensor data ready and call fetch api.

Impact

disable intermediate buffer by lowerhalf driver use fetch api.

Testing

daily test

[xiaoxiang781216]

@v01d and @btashton this patch series address your suggestion here: #2039.
Please take a look.

[Donny9]

@v01d @btashton hello, I submitted some patches about sensor model features and optimization. Please review, thank you.

[gustavonihei]

Just pointing out some typos and improvement opportunities in the documentation.

[Donny9]

Just pointing out some typos and improvement opportunities in the documentation.

Thank you very much, I'll study this documentation guide and modify them.

[protobits]

I'm looking at the changes. I wanted to ask, any reason why you are defining your own queue structure instead of using definitions in queue.h?

[protobits]

Also, shouldn't the buffer be released on close() on the last reference? Right now it requires the unregistration of the sensor

[protobits]

And if I understand correctly, the internal buffer is always allocated to the sensor structure size, even when only fetch() will be used, right? It would be better to only do so if fetch() will not be used, otherwise it is just wasted memory.

Also, would it be possible (and would it make sense) to let the driver define its own structure? I'm thinking about custom sensors types which may not map exactly to any of the structs defined. Maybe this could be done by letting the lower part define the struct size and dev prefix string.

That is all the comments I have. I feel I would have to try to use this interface to really understand it and see if there's any limitation, but it looks good so far.

[Donny9]

I'm looking at the changes. I wanted to ask, any reason why you are defining your own queue structure instead of using definitions in queue.h?

The circualr buffer and queue are different for their behavior. We need to overwrite old data when buffer is full, and it's better to operate buffer directly rather than queue node.

[Donny9]

I'm looking at the changes. I wanted to ask, any reason why you are defining your own queue structure instead of using definitions in queue.h?

The circualr buffer and queue are different for their behavior. We need to overwrite old data when buffer is full, and it's better to operate buffer directly rather than queue node.

I will add mm/circ_buf for circular buffer management on other patch later, and driver/sensor and driver/rc will call these api about circ_buf_xxx to use circular buffer.

[Donny9]

And if I understand correctly, the internal buffer is always allocated to the sensor structure size, even when only fetch() will be used, right? It would be better to only do so if fetch() will not be used, otherwise it is just wasted memory.

Also, would it be possible (and would it make sense) to let the driver define its own structure? I'm thinking about custom sensors types which may not map exactly to any of the structs defined. Maybe this could be done by letting the lower part define the struct size and dev prefix string.

That is all the comments I have. I feel I would have to try to use this interface to really understand it and see if there's any limitation, but it looks good so far.

1. When fetch isn't NULL, the intermediate buffer is disabled on sensor_register to save ram. Done on this patch.
2. I think we should move towards unification. If there is no conforming type or structure, we should add them and make them as versatile as possible. It's especially good for application developers.

Thank you.

[protobits]

1. When fetch isn't NULL, the intermediate buffer is disabled on sensor_register to save ram. Done on this patch.

I see. But the call to the buffer creation function is still done and if I understand correctly, due to the rounding up, one struct will be allocated in the buffer still.

2. I think we should move towards unification. If there is no conforming type or structure, we should add them and make them as versatile as possible. It's especially good for application developers.

I agree, but I'm thinking in the lines of something that wouldn't necessarily be ported upstream, leaving downstream user the possibility of defining a particular driver with specific needs. But we can go back to this later on.

Thank you.

[protobits]

I'm looking at the changes. I wanted to ask, any reason why you are defining your own queue structure instead of using definitions in queue.h?

The circualr buffer and queue are different for their behavior. We need to overwrite old data when buffer is full, and it's better to operate buffer directly rather than queue node.

I will add mm/circ_buf for circular buffer management on other patch later, and driver/sensor and driver/rc will call these api about circ_buf_xxx to use circular buffer.

Are you sure there's no circular buffer structure defined anywhere else in NuttX?

[protobits]

Also, shouldn't the buffer be released on close() on the last reference? Right now it requires the unregistration of the sensor

What about this?

[xiaoxiang781216]

1. When fetch isn't NULL, the intermediate buffer is disabled on sensor_register to save ram. Done on this patch.

I see. But the call to the buffer creation function is still done and if I understand correctly, due to the rounding up, one struct will be allocated in the buffer still.

It isn't an issue more with new mm/circ_buf, so we can temporarily ignore it here.

2. I think we should move towards unification. If there is no conforming type or structure, we should add them and make them as versatile as possible. It's especially good for application developers.

I agree, but I'm thinking in the lines of something that wouldn't necessarily be ported upstream, leaving downstream user the possibility of defining a particular driver with specific needs. But we can go back to this later on.

Ok, we can add a special register api later.

Thank you.

I'm looking at the changes. I wanted to ask, any reason why you are defining your own queue structure instead of using definitions in queue.h?

The circualr buffer and queue are different for their behavior. We need to overwrite old data when buffer is full, and it's better to operate buffer directly rather than queue node.

I will add mm/circ_buf for circular buffer management on other patch later, and driver/sensor and driver/rc will call these api about circ_buf_xxx to use circular buffer.

Are you sure there's no circular buffer structure defined anywhere else in NuttX?

We can't find one, could you point to a general and standalone implementation?

Also, shouldn't the buffer be released on close() on the last reference? Right now it requires the unregistration of the sensor

What about this?

Since the upcomming patch will replace the buffer implemenation to a common one, how about move this change to that PR?

[protobits]

I grepped the sources and found various mentions to circular buffers being used, but they all appear to be ad-hoc implementations, so a separate ring buffer structure could be useful to have.

I agree to making the memory related changes later.