“As one of the most important devices in various fields, sensors have many types of products and wide application fields. With the advent of the “smart era”, the use of sensors will play a more critical role. So, how to use these various and complex sensors in the simplest and most efficient way?
“
As one of the most important devices in various fields, sensors have many types of products and wide application fields. With the advent of the “smart era”, the use of sensors will play a more critical role. So, how to use these various and complex sensors in the simplest and most efficient way?
As a detection device, the application of sensor has already penetrated into a wide range of fields such as industrial production, space exploration, ocean exploration, environmental protection, resource survey, medical diagnosis, biological engineering, and even cultural relics protection. It is no exaggeration to say that from the vast space, to the vast ocean, and various complex engineering systems, almost every modern project is inseparable from sensors.
At present, there are a large number of various types, models, and various sensors produced by different manufacturers on the market, such as temperature, humidity, voltage, current, pressure, light, acceleration, angular velocity, and so on. Their application scenarios, product parameters, and usage methods are different, which often makes it difficult for many project developers to use sensors: to add a sensor, it is necessary to write a corresponding driver to provide a set of interfaces to access this sensor. Usually, in a complex system, there are often more than one sensor, and there may be several or dozens or even more different types of sensors. If these sensors use different interfaces, it is conceivable that the software aspect What will be the workload and complexity? Invisibly, it increases the difficulty of development. Not only that, if applications developed based on multiple sensors want to be reused across platforms, but the interfaces of the underlying sensors are all kinds of strange, then how much will such workload and complexity increase?
In order to solve these problems, AWorks defines a common sensor interface, which is suitable for all kinds of sensors. As long as the sensors are mounted in the AWorks system, they can be accessed through the same operation interface. At the same time, as long as the applications developed based on these general interfaces will not be bound to specific hardware devices, in other words, the underlying replacement of sensors with different types will not affect the application, and the application can do nothing. change.
From a functional point of view, the sensor realizes the acquisition of certain physical signals (temperature, humidity, air pressure, etc.) in the real world. When using the sensor, the most important operation is to obtain the corresponding data from the sensor. Next, we will further introduce how to obtain sensor data through the interface.
1. Sensor Channel ID
Before introducing how to use the interface, you need to understand a concept briefly. The reason why AWorks can use a set of the same interface to access all types of sensors is that AWorks has unified management of the sensors in the system. In order to achieve unified management of various sensors, the abstract concept of “sensor channel” is defined in AWorks. One sensor channel is used to complete the acquisition of one physical signal. The system assigns a unique sensor channel to each sensor channel. ID. For example, if there are three sensors in the system at this time, they are the temperature and humidity sensor HTS221 (which can provide one temperature and one humidity channel for the system), and the three-axis magnetic sensor LIS3MDL (the energy level system provides X, Y, Z-axis three-way magnetic data channel and one temperature channel) and illumination sensor BH1730 (which can provide one illumination acquisition channel for the system), the corresponding ID assignment example is shown in Table 1.
Table 1 Sensor channel id assignment
According to the above sensor channel ID allocation method, theoretically, an infinite number of sensors of various types can be mounted in the system, and the newly added sensor channels only need to be assigned IDs in sequence according to the above method. Usually, the allocation of the ID number has been completed by the system, and we do not need to allocate it by ourselves. We only need to simply know the sensor channel type corresponding to the valid ID number in the current system. For example, the current sensors in the AWorks system are shown in Table 1. There are three sensors with ID numbers from 0 to 6. The function interface ID will be used as an example below.
2. Get sensor data
Based on the above description of the sensor ID, if you want to obtain sensor data at this time, you only need to call the function interface for obtaining sensor data in the application program. The function interface for obtaining sensor data is as follows:
aw_err_t aw_sensor_data_get (int id, aw_sensor_val_t *p_val);
Among them, id is the sensor channel ID number, and p_val is the sensor data that stores the corresponding ID. Here the aw_sensor_val_t type is a structure, just know that it is a variable that holds sensor data.
Based on this, you only need to call this interface to obtain data from any sensor channel in the system. For example, the program example to obtain temperature sampling data every 500ms is as follows:
1 aw_sensor_val_t tem_val;
2 while (1) {
3 aw_sensor_data_get(0, &tem_val); // The channel ID is 0, corresponding to the temperature acquisition channel in Table 1
4 aw_mdelay(500);
5 }
Similarly, if you want to obtain the sampling data of the illuminance sensor, the program example is as follows:
1 aw_sensor_val_tals_val;
2 while (1) {
3 aw_sensor_data_get(6, &als_val); // The channel ID is 6, corresponding to the illumination acquisition channel in Table 1
4 aw_mdelay(500);
5 }
By analogy, the data of all sensors in the system can be obtained in turn by calling the same interface. At this point, some people may question whether it will be cumbersome to call the interface one by one with so many sensors in the system? For this question, the AWorks system certainly gave the answer, that is, it provides an interface to acquire sensor data of multiple channels or all channels at the same time. The prototype of the interface is as follows:
aw_err_t aw_sensor_group_data_get (const int *p_ids,
int num,
aw_sensor_val_t *p_buf);
Among them, p_ids is a pointer to the sensor channel id list; num represents the number of channels, that is, the size of the id list; p_buf points to the buffer used to store the data of each channel, and the buffer size is the same as num. Based on this interface, the sampling data of multiple or all sensors in the system can be obtained at the same time. For example, the program example of obtaining the sampling data of all the sensor channels in the current table 1 every 500ms is as follows:
1 const int id_s[7] = {0, 1, 2, 3, 4, 5, 6}; // application uses 7 channels
2 aw_sensor_val_t val_buf[7]; // buffer for storing 7 channels of data
3
4 while (1) {
5 aw_sensor_group_data_get(id_s, 7, val_buf); // Get the sampling data of all sensor channels in the current system
6 aw_mdelay(500);
7 }
Based on this, the sensor interface of the AWorks system has perfectly realized the function of obtaining all sensor sampling data using the same interface. At this point, some people may ask questions. It seems that these two interfaces use polling methods to obtain sensor data. If the efficiency requirements are high, is it not good to call this interface? Furthermore, many sensors today can acquire data in an interrupt-triggered way, which can greatly improve the efficiency of the application, so can this function be implemented? certainly! AWorks also provides this interface, and the calling of the interface is very convenient and concise. The following will reveal the secrets for you.
3. Trigger to obtain sensor data
Nowadays, most sensors internally support the function of notifying the application to obtain sensor data through interrupt triggering. The application only needs to detect the trigger type and do the corresponding processing, which greatly improves the execution efficiency of the application and avoids the need for querying This time-consuming operation of actively acquiring sensor data.
The triggering method that a sensor has is generally determined by the sensor itself. For example, the configurable trigger mode of temperature and humidity sensor HTS221 is only data ready trigger; the configurable trigger mode of three-axis magnetic sensor LIS3MDL is data ready trigger and upper and lower threshold value trigger. Next, we will only use the data ready trigger method to explain how to efficiently acquire sensor data.
In AWorks, to obtain sensor channel data by triggering, only two steps are required. The first step is to configure the trigger callback function of the sensor channel, and the second step is to enable the trigger of the channel.
First, the function prototype to configure the trigger mode of the sensor channel is as follows:
aw_err_t aw_sensor_trigger_cfg (int id,
uint32_t flags,
aw_sensor_trigger_cb_t pfn_cb,
void *p_arg);
Among them, id is the number of the sensor channel, and the flags parameter is the macro corresponding to the configured trigger mode (here, only the data-ready trigger is used as an example, and the corresponding macro is defined in AWorks as AW_SENSOR_TRIGGER_DATA_READY, which can be directly passed in), pfn_cb To trigger the callback function, p_arg is the parameter of the user-triggered callback function. The type of trigger callback function is aw_sensor_trigger_cb_t, which is defined as follows:
typedef void (*aw_sensor_trigger_cb_t) (void *p_arg, uint32_t trigger_src);
Among them, p_arg is the parameter of the user-triggered callback function, and trigger_src is the stored trigger type. For example, to configure the data ready trigger of the X-axis acquisition channel of the three-axis magnetic sensor LIS3MDL (Table 1, channel 2), the program example is as follows:
1 /* Define a callback function to be called when the trigger event occurs */
2 static void __pfn_trigger_callback (void *p_arg, uint32_t trigger_src)
3 {
4 /* Data ready trigger */
5 if (trigger_src & AW_SENSOR_TRIGGER_DATA_READY) {
6 aw_sensor_data_get(2, &data_val); // Trigger to get the sampling data of this channel
7 }
8 }
9 aw_sensor_trigger_cfg( 2,
10 AW_SENSOR_TRIGGER_DATA_READY,
11 __pfn_trigger_callback,
12 NULL); // Configure the data ready trigger of channel 2
After the above program completes the configuration of the trigger mode of the channel, next, you only need to open the trigger of the channel. The definition of the function interface is as follows:
aw_err_t aw_sensor_trigger_on (int id);
This function interface only needs to pass in the id. Note that the aw_sensor_trigger_on function interface must be called after the aw_sensor_trigger_cfg interface, and the order cannot be reversed. At this time, the complete program example to obtain the X-axis acquisition data of the three-axis magnetic sensor LIS3MDL by triggering is as follows:
1 aw_sensor_val_t data_val; // define sensor data buffer
2
3 /* Define a callback function to be called when the trigger event occurs */
4 static void __pfn_trigger_callback (void *p_arg, uint32_t trigger_src)
5 {
6 /* Data ready trigger */
7 if (trigger_src & AW_SENSOR_TRIGGER_DATA_READY) {
8 aw_sensor_data_get(2, &data_val); // Trigger to get the sampling data of this channel
9 }
10 }
11
12 int mian()
13 {
14 aw_sensor_trigger_cfg(2,
15 AW_SENSOR_TRIGGER_DATA_READY,
16 __pfn_trigger_callback,
17 NULL);
18 aw_sensor_trigger_on(2);
19 while (1) {
20 aw_mdelay(1000);
twenty one }
twenty two }
Through the above interfaces, the function of accessing all sensor data through an interface is perfectly realized, and these interfaces can be used on any platform running the AWorks operating system, and no matter how the type and number of sensors in the platform change, you only need to know the The ID information of the platform sensor channel can be accessed using these common interfaces. As long as it is an application program developed based on this common interface, as long as it is in the AWorks system, the application program can realize the transplantation of “zero” modification. In the sense of software, the historical problem of “one-time programming, lifetime use, and cross-platform” is truly realized.
4. Summary
AWorks is the next-generation open-source embedded development platform developed by ZLG for 12 years. It abstracts the commonality of MCU and OS into a unified interface, supports “pluggable, replaceable, and configurable” platform components, independent of hardware and operating system. Type-independent design, users only need to modify the corresponding header files to achieve “one-time programming, lifetime use, cross-platform”.
And ZLG has launched a series of core boards with common cores such as Cortex-M0/3/4/7, Coterx-A7/8/9, ARM7/9, and DSP equipped with AWorks operating system. Using these core boards, you can quickly complete product development on the AWorks platform.
The Links: LJ512U32 CM600DY-24A