Skip to content

Conversation

@Donny9
Copy link
Contributor

@Donny9 Donny9 commented Jul 25, 2022

Summary

  1. support users to write data to sensor device.
  2. simplify buffer operation and some structure update.
  3. support multi users to access sensor device.

Impact

This PR is a part of #6653.

Testing

Vela CI

Donny9 added 7 commits July 25, 2022 12:34
Signed-off-by: Jiuzhu Dong <dongjiuzhu1@xiaomi.com>
1.Simplify buffer opeations to avoid frequent resize for batch and no-batch mode.
2.When sensor event is first generated, the buffer is initialized.
3.Remove and merge batch_number to buffer_number when device support batch mode.

Signed-off-by: Jiuzhu Dong <dongjiuzhu1@xiaomi.com>
1. change unsigned int to unsigned long

Signed-off-by: Jiuzhu Dong <dongjiuzhu1@xiaomi.com>
1.cmd:SNIOC_REGISTER with struct sensor_reginfo_s to register user sensor
2.cmd:SNIOC_UNREGISTER to unregister user sensor

Signed-off-by: Jiuzhu Dong <dongjiuzhu1@xiaomi.com>
1.Allow multi users to access the same sensor device simultaneously.
2.Get real state of sensor device by cmd SNIOC_GET_STATE for users.
3.Get update state since last read by poll without timeout for users.
4.Sensor device will be activated when first user open and will close when
  last user closed.
5.When multi users to access device, driver always set the minimum
  sampling interval and latency to the sensor device and allow
  downsampled for users above the minimum sampling interval.
6.The circbuffer will overwrite old data when buffer is full, so if users
  don't read data soon, data will be lost, and the oldest data in circbuffer
  are returned to the users.
7.Always read the last data in the circbuffer as initial value for new
  users when the sensor device has not yet generated new data.
8.when user uses poll, if subscription interval is satisfied, the POLLIN
  events is returned for each users.
9.When new user generate or the state of sensor device changed, the POLLPRI
  will notify to all users.
10.Support multi advertisers to subscribe their own data as loop test.

Signed-off-by: Jiuzhu Dong <dongjiuzhu1@xiaomi.com>
Signed-off-by: Jiuzhu Dong <dongjiuzhu1@xiaomi.com>
Signed-off-by: Jiuzhu Dong <dongjiuzhu1@xiaomi.com>
@xiaoxiang781216 xiaoxiang781216 requested a review from acassis July 25, 2022 13:53
@xiaoxiang781216
Copy link
Contributor

@acassis this PR depends on sensortest change apache/nuttx-apps#1228.

@xiaoxiang781216 xiaoxiang781216 merged commit 01aa0c2 into apache:master Jul 26, 2022
Comment on lines +163 to +171
static int usensor_open(FAR struct file *filep)
{
return 0;
}

static int usensor_close(FAR struct file *filep)
{
return 0;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think those are not needed

static ssize_t usensor_read(FAR struct file *filep, FAR char *buffer,
size_t buflen)
{
return buflen;
Copy link
Contributor

@pkarashchenko pkarashchenko Jul 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think 0 should be returned instead

@zouboan
Copy link
Contributor

zouboan commented Mar 7, 2023

Hello:
I'm very interested in NuttX's native uORB, but there's some question puzzled me. when uORB register a customer sensor by ioctl of usensor:
https://github.com/apache/nuttx-apps/blob/master/system/uorb/uORB/uORB.c#L85
usensor will call sensor_custom_register to register a new sensor, and the file_operations of new sensor is given by lower->driver.ops = &g_usensor_ops;
https://github.com/apache/nuttx/blob/master/drivers/sensors/usensor.c#L113-L115
what puzzled me is that the g_usensor_ops is actually NULL, and there's no assignment for g_usensor_ops In usensor.c or lower->ops in sensor.c. so, how can the new sensor's file_operations working?

@xiaoxiang781216
Copy link
Contributor

For usensor case, the data is provided by orb publisher and consumed by orb subscriber. The sensor upper half does all required functionality(FIFO, file operation etc), that's why the sensor lower half is empty.

@zouboan
Copy link
Contributor

zouboan commented Mar 9, 2023

@xiaoxiang781216 Thanks so much for your explanation! I think i misread the role of usensor, I thought the usensor is used for sensors(e.g. mpu60x0) that didn't registered under the sensor.c in the nuttx, and when we use uorb on these sensors(e.g. mpu60x0), we register it under sensor.c by usensor.
BTW, it seems that only the sensor registered by int sensor_register(FAR struct sensor_lowerhalf_s *lower, int devno) can be used in uORB, but there's only ds18b20,bmp280,hyt271,l3gd20,lsm303agr,lsm6dsl,ltr308,ms5611,msa301,wtgahrs2 is registered by sensor_register, does it means most of other sensor driver registered in traditional way(e.g. mpu60x0) cannot be used in uORB method at present?

@xiaoxiang781216
Copy link
Contributor

Yes, the old sensor developed before the new sensor driver framework need rewrite to integrate with uORB.

@zouboan
Copy link
Contributor

zouboan commented Mar 10, 2023

got it, Thank you for your reply

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants