Sensor Driver Development Guide
This document is a development guide document for sensor drivers under the RT-Thread Sensor driver framework, providing development standards and specifications for the development team.
Engineers engaged in sensor-driven development
Note
Note: Before reading this document, please read the sensor driver framework introduction first .
Developing a sensor driver generally requires the following steps: research and preparation, development, testing, and submission.
During the development process, you can refer to the supported sensors. Click here to view the list of supported sensors .
According to the datasheet or other methods, understand the characteristics of the sensor and record them, such as the following:
Sensor Type
Communication interface (i2c/spi/...)
Measuring range
Shortest measurement cycle
Support several working modes and power modes
The main task of development is to connect to the ops interface of the Sensor driver framework, and then register it as a Sensor device, so that the relevant behaviors of the sensor can be controlled through the driver framework.
The sensor framework provides two interfaces ( fetch_data
/ control
), which need to be implemented in the driver.
fetch_data
Function: Get sensor data. Interface prototype:
The Sensor driver framework currently supports three default opening modes: polling (RT_DEVICE_FLAG_RDONLY), interrupt (RT_DEVICE_FLAG_INT_RX), and FIFO (RT_DEVICE_FLAG_FIFO_RX). You need to determine the working mode of the sensor here, and then return the sensor data according to different modes.
As shown below:
When returning data, developers should first identify the data type of the stored data, and then fill in the data field and timestamp, as shown below:
Note
Note: - Please use the timestamp acquisition function provided by the Sensor driver framework to obtain the timestamp rt_sensor_get_ts
. - In FIFO mode, the underlying data may be coupled, and a module needs to be used to update the data of two sensors at the same time. - The data unit must be converted to the data unit specified in the Sensor driver framework.
The data units are as follows:
Sensor Name
type
unit
illustrate
Accelerometer
RT_SENSOR_CLASS_ACCE
mg
1 g = 1000 mg, 1 g = 9.8 m/s2
Gyroscope
RT_SENSOR_CLASS_GYRO
mdps
1 dps = 1000 mdps, dps (degrees per second)
Magnetometer
RT_SENSOR_CLASS_MAG
mGauss
1 G = 1000 mGauss
Ambient Light
RT_SENSOR_CLASS_LIGHT
lux
Lumen value
Approaching light
RT_SENSOR_CLASS_PROXIMITY
centimeters
Represents the distance from the object to the sensor, unit: cm
Barometer
RT_SENSOR_CLASS_BARO
Pa
100 Pa = 1 hPa (hectopascal)
thermometer
RT_SENSOR_CLASS_TEMP
°c/10
0.1 degrees Celsius
Hygrometer
RT_SENSOR_CLASS_HUMI
‰
Relative humidity RH, usually expressed in ‰
Heart rate monitor
RT_SENSOR_CLASS_HR
bpm
Times per minute
noise
RT_SENSOR_CLASS_NOISE
HZ
Frequency Unit
Pedometer
RT_SENSOR_CLASS_STEP
1
Number of steps: dimensionless unit 1
Force Sensors
RT_SENSOR_UNIT_MN
mN
Pressure: 10^-3 N
Note: New sensor data units will be added iteratively later.
control
The control of the sensor is realized by this interface function. Different operations are performed by judging the different command words passed in. Currently, the following command words are supported:
This function needs to be implemented in the driver as follows:
Note
Note: It should be noted that the data type of the parameter passed is specified by the struct rt_sensor_config structure. Therefore, RT_SENSOR_CTRL_SET_RANGE
the parameter passed by this command is rt_int32_t
of type , which needs to be forced once to get the correct parameter.
Then implement a device interface structure ops to store the above interface functions,
After completing the docking of the Sensor's ops, you need to register a sensor device so that the upper layer can find the sensor device and then control it.
Device registration requires the following steps: create a rt_sensor_t
structure pointer, allocate memory for the structure, and complete related initialization.
Note
Note: - rt_hw_sensor_register
A prefix will be automatically added to the name passed in, such as 加速度计
the type of sensor will automatically add acce_
a prefix. Since the system default device name is up to 7 characters, if the name passed in exceeds 3 characters, it will be truncated. - When registering, if the sensor supports FIFO, you need to add the RT_DEVICE_FLAG_FIFO_RX flag. - If two devices are coupled, you need to use a module to decouple them. Initialize a module, assign the device control blocks of the two sensors to it, and assign the module address to the two sensor devices. The framework will automatically create a module lock.
The parameter passed in struct rt_sensor_config *cfg
is used to decouple the hardware communication interface. By passing this parameter in when the underlying driver is initialized, the hardware interface configuration is implemented. It contains struct rt_sensor_intf
this structure,
Among them, type indicates the type of interface, dev_name indicates the name of the device, such as "i2c1". user_data is some private data of this interface type. If it is I2C, this is the i2c address corresponding to the sensor, and the input method is (void*)0x55
.
When initializing the underlying driver, you need to initialize this structure first, and then pass it in as a parameter to complete the decoupling of the communication interface. Similar to this:
Use the list_device command to check whether the corresponding device is successfully registered.
Use the exported test function
sensor_polling/int/fifo <sensor_name>
to determine whether the data can be read successfully.Testing other modes and control interfaces
The Sensor driver needs to 软件包
be submitted in the form of . For the specific structure, please refer to the existing Sensor software package. For the specific submission process, please refer to the Document Center: Software Package Development Guide
Used when dynamically allocating memory
rt_calloc
, this API will initialize the requested memory to 0, and there is no need to manually clear it.Please assign initial values to statically defined variables, and initialize unused variables to 0.
If possible, please support multiple instances. Please pay attention to the following issues:
No global variables
All configuration information is stored in the sensor structure
Configurations not in the sensor structure are stored using the user_data of rt_device
Last updated