In this exercise, we will create a custom driver for the BME280 sensor using the Zephyr sensor API.
In this exercise, we decided to include our device driver as a Zephyr external module. The external module is the source code that could be integrated with Zephyr, but it is located outside of the Zephyr root directory. The idea of Zephyr modules is presented in Modules Documentation. Every Zephyr module shall include a module.yml file in a zephyr/ folder at the root of its location. Thanks to this, we can inform the Zephyr build system where to look for the module files.
As an environmental sensor will be used in this exercise, the device driver needs to have an API that provides measurement data for temperature, pressure, and humidity. We can always design our own API (what will be covered in Exercise 3 of this lesson), but fortunately, in the Zephyr system, we can find an already existing API that matches our needs – sensor API. The sensor driver API provides functionality to uniformly read, configure, and set up event handling for devices that take real-world measurements in meaningful units.
Exercise steps
Open the code base of the exercise by navigating to Create a new application in the nRF Connect for VS Code extension, select Copy a sample, and search for Lesson 7 – Exercise 1. Make sure to use the version directory that matches the SDK version you are using.
Alternatively, in the GitHub repository for this course, go to the base code for this exercise, found in l7/l7_e1 of whichever version directory you are using.
Notice that the exercise code is divided into 2 directories:
app – The target application. It reads sensor data and prints out measurements.
custom_driver_module – The Zephyr external module containing the driver. We will focus mostly on this in the driver development lesson
Devicetree bindings define the compatible property. It declares requirements on the contents of devicetree nodes, and provides semantic information about the contents of valid nodes.
This time, we are creating a custom driver for the existing API, so there is no need to add any additional field. We can copy the original binding for the bme280 sensor from <nRF Connect SDK Install Path>/zephyr/dts/bindings/sensor/bosch,bme280-spi.yaml and adjust the file name and content to match our custom driver.
Create the file zephyr,custom-bme280.yaml and input the following lines:
In our external Zephyr module, we must keep a directory structure similar to that of the base Zephyr directory. Let’s save the file in our custom driver module, in dts/bindings/sensor like other sensor bindings in the Zephyr base directory, to follow the Zephyr file structure convention.
Now that we have a proper binding file in our Zephyr module, we can work on the driver itself. Most of the content has already been prepared, so we will focus only on the driver configurations and align it with the binding and sensor API.
2.1 Define the driver compatible from the custom binding.
When using instance-based APIs, such as DEVICE_DT_INST_DEFINE(), we first need to define the driver compatible as a C macro. This is done by setting DT_DRV_COMPAT to the lowercase-and-underscore version of the compatible that the device driver supports. Since our compatible is "zephyr,custom-bme280", we will set DT_DRV_COMPAT to zephyr_custom_bme280.
Firstly, we declare the binding compatibility for our driver in the driver source file. (custom_bme280.c).
Copy
#define DT_DRV_COMPAT zephyr_custom_bme280
C
2.2 Check if the devicetree contains any devices with the driver compatible.
We should also inform the user if the proper binding is missing by including
Copy
#if DT_NUM_INST_STATUS_OKAY(DT_DRV_COMPAT) ==0#warning"Custom BME280 driver enabled without any devices"#endif
C
3. Implement the driver-specific structures.
Next, we will define 3 missing driver-specific elements
data structure
configuration structure
driver API
3.1 Define the data structure to store BME280 data.
Create a driver data structure—it is the same structure we used in Lesson 5. The driver will use the structure to store current sensor data on each sampling. Put the data structure into the driver`s code.
3.2 Define the structure to store sensor configuration.
Since our sensor is connected using the SPI bus, we will need to get its configuration to communicate properly with the device. We can define a structure for storing this.
Now it is time to define API for our driver. In this exercise, we decided to use existing API from sensor subsystem. In our case we will use the polling method to get sensor data.
More on this
In this exercise we are using Zephyr sensor subsystem. It is well described in: Sensors.
In our case, we only need the sample_fetchand channel_get functions. Skeletons of these are already prepared in custom_bme280.c (custom_bme280_sample_fetch() and custom_bme280_channel_get()).
We just need to implement the content, define the API structure, and connect them to proper callbacks in the driver source code.
4.1 Populate the custom_bme280_sample_fetch() function.
This function should take in the device structure struct device and sensor_channel, use bme280_reg_read() to read out sensor measurements from the sensor and store them in custom_bme280_data.
4.2 Populate the custom_bme280_channel_get() function.
This function should take in the device structure struct device, the sensor_channel and sensor_value, and depending on the given channel (e.g pressure, humidity or temperature), calculate and store the value in sensor_value.
Copy
struct custom_bme280_data *data = dev->data;switch (chan) {case SENSOR_CHAN_AMBIENT_TEMP: /* * data->comp_temp has a resolution of 0.01 degC. So * 5123 equals 51.23 degC. */val->val1 = data->comp_temp / 100;val->val2 = data->comp_temp % 100 * 10000;break;case SENSOR_CHAN_PRESS: /* * data->comp_press has 24 integer bits and 8 * fractional. Output value of 24674867 represents * 24674867/256 = 96386.2 Pa = 963.862 hPa */val->val1 = (data->comp_press >> 8) / 1000U;val->val2 = (data->comp_press >> 8) % 1000 * 1000U + (((data->comp_press & 0xff) * 1000U) >> 8);break;case SENSOR_CHAN_HUMIDITY: /* * data->comp_humidity has 22 integer bits and 10 * fractional. Output value of 47445 represents * 47445/1024 = 46.333 %RH */val->val1 = (data->comp_humidity >> 10);val->val2 = (((data->comp_humidity & 0x3ff) * 1000U * 1000U) >> 10);break;default:return -ENOTSUP; }return0;
C
5 Create the device driver definition
In this step, we need to design the helper macro (CUSTOM_BME280_DEFINE) responsible for device driver definition for a given device tree node. In the next step, we will use this macro for every enabled device tree node compatible with our driver. Macro contains 3 parts:
Device`s data structure template- It creates a data structure instance for a given device tree node
Devices`s configuration structure template- It creates a configuration structure instance for a given device tree node
Devices`s definition macro (instance-based) -Create a device object from a given device tree node.
5.1 Prepare helper macro and add structures for each device driver instance.
This step defines data and configuration structure instances for a given device tree node. We are using default values for the data structure instance, which will change during driver operation. For the configuration structure instance, we need to get SPI from the given device tree node, using SPI_DT_SPEC_INST_GET, you can learn more about this macro in SPI interface documentation
inst – instance which is used to get device tree node id we are defining driver for, we take it from an input parameter of our CUSTOM_BME280_DEFINE macro helper
init_fn – Pointer to the device’s initialization function, we use already implemented our drivers initialization function (custom_bme280_init).
pm – Pointer to the device’s power management resources. We don’t need it for this exercise.
data– Pointer to the device’s data structure instance. We use the instance created by the template from previous step.
config – Pointer to the device’s configuration structure instance. We use the instance created by the template from previous step.
level – The device’s initialization level. We want to have device initialized after kernel initialization.
prio – The device’s priority within its initialization level. We use default priority level for sensor subsystem.
API -Pointer to the device’s API structure. That is our device API created in step 3, we use custom_bme280_api for this parameter.
5.3. Create the struct device for every status “okay” node in the devicetree.
DT_INST_FOREACH_STATUS_OKAY() expands to code that calls CUSTOM_BME280_DEFINE once for each enabled node with the compatible binding file determined by DT_DRV_COMPAT.
Copy
DT_INST_FOREACH_STATUS_OKAY(CUSTOM_BME280_DEFINE)
C
6. Create the build system for the driver.
Kconfig and CMake are necessary parts of the Zephyr build system. We need to include them at each level of the drivers directory.
6.1. Populate the CMakeLists.txt file for the custom driver.
Create drivers/sensor/custom_bme280/CMakeLists.txt and add the following lines.
Here, we define the Kconfig symbol CUSTOM_BME280_DRIVER , which, when enabled, will add the custom driver to the build (as we will do in the next step). The Kconfig symbol depends on DT_HAS_ZEPHYR_CUSTOM_BME280_ENABLED which just checks if the build devicetree has enabled this compatibility.
6.3. Add the custom_bme280 directory as a subdirectory in the sensor driver.
The custom_bme280 directory must be added as a subdirectory in drivers/sensor.
Create drivers/sensor/CMakeLists.txt and add the following line
6.5 Add the sensor directory to the build system structure.
Create drivers/CMakeLists.txt and add the following code snippet
Copy
add_subdirectory_ifdef(CONFIG_SENSOR sensor)
CMake
6.6 Add the sensor submenu.
Create drivers/Kconfig and replace the code with the following code snippet
Copy
menu"Drivers"rsource"sensor/Kconfig"endmenu
Kconfig
7. Create the Zephyr module definition.
7.1 Create a zephyr/module.yml file in the custom_driver_module folder and input the necessary configuration. Please notice that we put our dts directory into the Zephyr configuration by dts_root: .
Now that our Zephyr module containing a custom driver is ready, it is time to use it in the application.
8.1 Include the Zephyr module in the target application.
First, we need to tell Zephyr where to find our external module. We include it in the Zephyr modules list by modifying the CMakeLists.txt file in the app directory.
EXTRA_ZEPHYR_MODULES – is a CMake list of absolute paths to the directories containing Zephyr modules. We can add our module by using list(APPEND …) command.
8.2 Next, we need to enable our custom driver in prj.conf. We will use configuration parameters created in step 6.
Copy
CONFIG_SENSOR=yCONFIG_CUSTOM_BME280=y
Kconfig
8.3 Create a proper node definition in the overlay file corresponding to the board you are using. This time, our node should be compatible with our zephyr,custom-bme280 binding.
In this exercise, we will create a custom driver for the BME280 sensor using the Zephyr sensor API.
In this exercise, we decided to include our device driver as a Zephyr external module. The external module is the source code that could be integrated with Zephyr, but it is located outside of the Zephyr root directory. The idea of Zephyr modules is presented in Modules Documentation. Every Zephyr module shall include a module.yml file in a zephyr/ folder at the root of its location. Thanks to this, we can inform the Zephyr build system where to look for the module files.
As an environmental sensor will be used in this exercise, the device driver needs to have an API that provides measurement data for temperature, pressure, and humidity. We can always design our own API (what will be covered in Exercise 3 of this lesson), but fortunately, in the Zephyr system, we can find an already existing API that matches our needs – sensor API. The sensor driver API provides functionality to uniformly read, configure, and set up event handling for devices that take real-world measurements in meaningful units.
Exercise steps
Open the code base of the exercise by navigating to Create a new application in the nRF Connect for VS Code extension, select Copy a sample, and search for Lesson 7 – Exercise 1. Make sure to use the version directory that matches the SDK version you are using.
Alternatively, in the GitHub repository for this course, go to the base code for this exercise, found in l7/l7_e1 of whichever version directory you are using.
Notice that the exercise code is divided into 2 directories:
app – The target application. It reads sensor data and prints out measurements.
custom_driver_module – The Zephyr external module containing the driver. We will focus mostly on this in the driver development lesson
Devicetree bindings define the compatible property. It declares requirements on the contents of devicetree nodes, and provides semantic information about the contents of valid nodes.
This time, we are creating a custom driver for the existing API, so there is no need to add any additional field. We can copy the original binding for the bme280 sensor from <nRF Connect SDK Install Path>/zephyr/dts/bindings/sensor/bosch,bme280-spi.yaml and adjust the file name and content to match our custom driver.
Create the file zephyr,custom-bme280.yaml and input the following lines:
In our external Zephyr module, we must keep a directory structure similar to that of the base Zephyr directory. Let’s save the file in our custom driver module, in dts/bindings/sensor like other sensor bindings in the Zephyr base directory, to follow the Zephyr file structure convention.
Now that we have a proper binding file in our Zephyr module, we can work on the driver itself. Most of the content has already been prepared, so we will focus only on the driver configurations and align it with the binding and sensor API.
2.1 Define the driver compatible from the custom binding.
When using instance-based APIs, such as DEVICE_DT_INST_DEFINE(), we first need to define the driver compatible as a C macro. This is done by setting DT_DRV_COMPAT to the lowercase-and-underscore version of the compatible that the device driver supports. Since our compatible is "zephyr,custom-bme280", we will set DT_DRV_COMPAT to zephyr_custom_bme280.
Firstly, we declare the binding compatibility for our driver in the driver source file. (custom_bme280.c).
Copy
#define DT_DRV_COMPAT zephyr_custom_bme280
C
2.2 Check if the devicetree contains any devices with the driver compatible.
We should also inform the user if the proper binding is missing by including
Copy
#if DT_NUM_INST_STATUS_OKAY(DT_DRV_COMPAT) ==0#warning"Custom BME280 driver enabled without any devices"#endif
C
3. Implement the driver-specific structures.
Next, we will define 3 missing driver-specific elements
data structure
configuration structure
driver API
3.1 Define the data structure to store BME280 data.
Create a driver data structure—it is the same structure we used in Lesson 5. The driver will use the structure to store current sensor data on each sampling. Put the data structure into the driver`s code.
3.2 Define the structure to store sensor configuration.
Since our sensor is connected using the SPI bus, we will need to get its configuration to communicate properly with the device. We can define a structure for storing this.
Now it is time to define API for our driver. In this exercise, we decided to use existing API from sensor subsystem. In our case we will use the polling method to get sensor data.
More on this
In this exercise we are using Zephyr sensor subsystem. It is well described in: Sensors.
In our case, we only need the sample_fetchand channel_get functions. Skeletons of these are already prepared in custom_bme280.c (custom_bme280_sample_fetch() and custom_bme280_channel_get()).
We just need to implement the content, define the API structure, and connect them to proper callbacks in the driver source code.
4.1 Populate the custom_bme280_sample_fetch() function.
This function should take in the device structure struct device and sensor_channel, use bme280_reg_read() to read out sensor measurements from the sensor and store them in custom_bme280_data.
4.2 Populate the custom_bme280_channel_get() function.
This function should take in the device structure struct device, the sensor_channel and sensor_value, and depending on the given channel (e.g pressure, humidity or temperature), calculate and store the value in sensor_value.
Copy
struct custom_bme280_data *data = dev->data;switch (chan) {case SENSOR_CHAN_AMBIENT_TEMP: /* * data->comp_temp has a resolution of 0.01 degC. So * 5123 equals 51.23 degC. */val->val1 = data->comp_temp / 100;val->val2 = data->comp_temp % 100 * 10000;break;case SENSOR_CHAN_PRESS: /* * data->comp_press has 24 integer bits and 8 * fractional. Output value of 24674867 represents * 24674867/256 = 96386.2 Pa = 963.862 hPa */val->val1 = (data->comp_press >> 8) / 1000U;val->val2 = (data->comp_press >> 8) % 1000 * 1000U + (((data->comp_press & 0xff) * 1000U) >> 8);break;case SENSOR_CHAN_HUMIDITY: /* * data->comp_humidity has 22 integer bits and 10 * fractional. Output value of 47445 represents * 47445/1024 = 46.333 %RH */val->val1 = (data->comp_humidity >> 10);val->val2 = (((data->comp_humidity & 0x3ff) * 1000U * 1000U) >> 10);break;default:return -ENOTSUP; }return0;
C
5 Create the device driver definition
In this step, we need to design the helper macro (CUSTOM_BME280_DEFINE) responsible for device driver definition for a given device tree node. In the next step, we will use this macro for every enabled device tree node compatible with our driver. Macro contains 3 parts:
Device`s data structure template- It creates a data structure instance for a given device tree node
Devices`s configuration structure template- It creates a configuration structure instance for a given device tree node
Devices`s definition macro (instance-based) -Create a device object from a given device tree node.
5.1 Prepare helper macro and add structures for each device driver instance.
This step defines data and configuration structure instances for a given device tree node. We are using default values for the data structure instance, which will change during driver operation. For the configuration structure instance, we need to get SPI from the given device tree node, using SPI_DT_SPEC_INST_GET, you can learn more about this macro in SPI interface documentation
inst – instance which is used to get device tree node id we are defining driver for, we take it from an input parameter of our CUSTOM_BME280_DEFINE macro helper
init_fn – Pointer to the device’s initialization function, we use already implemented our drivers initialization function (custom_bme280_init).
pm – Pointer to the device’s power management resources. We don’t need it for this exercise.
data– Pointer to the device’s data structure instance. We use the instance created by the template from previous step.
config – Pointer to the device’s configuration structure instance. We use the instance created by the template from previous step.
level – The device’s initialization level. We want to have device initialized after kernel initialization.
prio – The device’s priority within its initialization level. We use default priority level for sensor subsystem.
API -Pointer to the device’s API structure. That is our device API created in step 3, we use custom_bme280_api for this parameter.
5.3. Create the struct device for every status “okay” node in the devicetree.
DT_INST_FOREACH_STATUS_OKAY() expands to code that calls CUSTOM_BME280_DEFINE once for each enabled node with the compatible binding file determined by DT_DRV_COMPAT.
Copy
DT_INST_FOREACH_STATUS_OKAY(CUSTOM_BME280_DEFINE)
C
6. Create the build system for the driver.
Kconfig and CMake are necessary parts of the Zephyr build system. We need to include them at each level of the drivers directory.
6.1. Populate the CMakeLists.txt file for the custom driver.
Create drivers/sensor/custom_bme280/CMakeLists.txt and add the following lines.
Here, we define the Kconfig symbol CUSTOM_BME280_DRIVER , which, when enabled, will add the custom driver to the build (as we will do in the next step). The Kconfig symbol depends on DT_HAS_ZEPHYR_CUSTOM_BME280_ENABLED which just checks if the build devicetree has enabled this compatibility.
6.3. Add the custom_bme280 directory as a subdirectory in the sensor driver.
The custom_bme280 directory must be added as a subdirectory in drivers/sensor.
Create drivers/sensor/CMakeLists.txt and add the following line
6.5 Add the sensor directory to the build system structure.
Create drivers/CMakeLists.txt and add the following code snippet
Copy
add_subdirectory_ifdef(CONFIG_SENSOR sensor)
CMake
6.6 Add the sensor submenu.
Create drivers/Kconfig and replace the code with the following code snippet
Copy
menu"Drivers"rsource"sensor/Kconfig"endmenu
Kconfig
7. Create the Zephyr module definition.
7.1 Create a zephyr/module.yml file in the custom_driver_module folder and input the necessary configuration. Please notice that we put our dts directory into the Zephyr configuration by dts_root: .
Now that our Zephyr module containing a custom driver is ready, it is time to use it in the application.
8.1 Include the Zephyr module in the target application.
First, we need to tell Zephyr where to find our external module. We include it in the Zephyr modules list by modifying the CMakeLists.txt file in the app directory.
EXTRA_ZEPHYR_MODULES – is a CMake list of absolute paths to the directories containing Zephyr modules. We can add our module by using list(APPEND …) command.
8.2 Next, we need to enable our custom driver in prj.conf. We will use configuration parameters created in step 6.
Copy
CONFIG_SENSOR=yCONFIG_CUSTOM_BME280=y
Kconfig
8.3 Create a proper node definition in the overlay file corresponding to the board you are using. This time, our node should be compatible with our zephyr,custom-bme280 binding.
In this exercise, we will create a custom driver for the BME280 sensor using the Zephyr sensor API.
For this exercise, we will not be using the GitHub repository for this course but rather a different GitHub repository that is an example of a production-level nRF Connect SDK-based application: ncs-example-application.
We will be creating a west workspace using this example application.
Exercise steps
1. Set up the application as a west workspace.
1.1 In Visual Studio Code, go to the nRF Connect for VS Code extension window. Select Create a new application then select Browse nRF Connect SDK Add-on Index.
1.2 Select the nRF Connect SDK example application
1.3 Select whichever nRF Connect SDK version you are using
1.4 Select a location for the West workspace
Input the full path of where you want your application to be stored. Then press ‘Enter’
Note that the last operation will take several minutes to complete.
Alternatively, you can issue the following terminal commands which does the same thing as in step 1.
Issue the following commands, <version> should reflect which nRF Connect SDK version you are using
As you can see, we have pulled in nRF Connect SDK <version>, as well as the ncs-example-application repository, which is where we will be adding our code.
2. Create a custom binding for the sensor.
In academy_workspace/ncs-example-application/dts/bindings/sensor, we need to create a custom binding for our sensor.
Note: Since we are working in ncs-example-application, we will be omitting the <academy_workspace/ncs-example-application> of the full path going forward.
Create the file zephyr,custom-bme280.yaml and input the following lines:
In drivers/sensor, create a directory and call it custom_bme280. This is for our custom driver, and will be populated in the following steps.
Create the following three files
CMakeLists.txt
Kconfig
custom_bme280.c
Copy and paste the contents of the file custom_bme280_template.c found in l7/l7_e1 into custom_bme280.c, to serve as a template for the next steps.
4. Define the driver compatible from the custom binding.
custom_bme280.c is where we will reuse most of the code from Lesson 5.
When using instance-based APIs, such as DEVICE_DT_INST_DEFINE(), we first need to define the driver compatible as a C macro. This is done by setting DT_DRV_COMPAT to the lowercase-and-underscores version of the compatible that the device driver supports. Since our compatible is "custom,bme280", we will define DT_DRV_COMPAT to custom_bme280 in our driver C file.
Copy
#define DT_DRV_COMPAT zephyr_custom_bme280
C
5. Check if the devicetree contains any devices with the driver compatible.
Copy
#if DT_NUM_INST_STATUS_OKAY(DT_DRV_COMPAT) ==0#warning"Custom BME280 driver enabled without any devices"#endif
C
6. Define the data structures for data and config.
The sensor API requires the following structures, custom_bme280_config and custom_bme280_data respectively.
7.1 Populate the custom_bme280_sample_fetch() function.
This function should take in the device structure struct device and sensor_channel, use bme280_reg_read() to read out sensor measurements from the sensor and store them in custom_bme280_data.
7.2 Populate the custom_bme280_channel_get() function.
This function should take in the device structure struct device, the sensor_channel and sensor_value, and depending on the given channel (e.g pressure, humidity or temperature), calculate and store the value in sensor_value.
Copy
struct custom_bme280_data *data = dev->data;switch (chan) {case SENSOR_CHAN_AMBIENT_TEMP: /* * data->comp_temp has a resolution of 0.01 degC. So * 5123 equals 51.23 degC. */val->val1 = data->comp_temp / 100;val->val2 = data->comp_temp % 100 * 10000;break;case SENSOR_CHAN_PRESS: /* * data->comp_press has 24 integer bits and 8 * fractional. Output value of 24674867 represents * 24674867/256 = 96386.2 Pa = 963.862 hPa */val->val1 = (data->comp_press >> 8) / 1000U;val->val2 = (data->comp_press >> 8) % 1000 * 1000U + (((data->comp_press & 0xff) * 1000U) >> 8);break;case SENSOR_CHAN_HUMIDITY: /* * data->comp_humidity has 22 integer bits and 10 * fractional. Output value of 47445 represents * 47445/1024 = 46.333 %RH */val->val1 = (data->comp_humidity >> 10);val->val2 = (((data->comp_humidity & 0x3ff) * 1000U * 1000U) >> 10);break;default:return -ENOTSUP;}
C
7.3 Define custom_bme280_api and configure the relevant members.
The most important thing here is to understand in detail the contents and use of DEVICE_DT_INST_DEFINE(), which has the following signature
inst – This is the instance number passed as a parameter to CUSTOM_BME280_DEFINE(inst).
init_fn – This is the initializing function, called before the main() in the application is called. The other arguments level and prio can be used to manage the actual initialization order and priority of calling this init_fn at the time of the Zephyr boot up. In this exercise, we have defined custom_bme280_init()function as the initializing function where we configure the pins and initialize the SPI interface and the BME280 sensor.
pm – This token is used to plug our device driver into the overall Zephyr power management system. You can use PM_DEVICE_DT_DEFINE to define a pm instance and implement the pm action events that are sent to your driver at the time of system power events. In this exercise, we do not implement this, so we set this to NULL.
data – This token is used to pass a pointer to any additional mutable data that you want to pass between the driver and the app. In this exercise, we are passing &custom_bme280_data_##inst.
config – This token is used to pass the device private constant config data, in this exercise &custom_bme280_config_##inst.
level – This is the device’s initialization level, which can be PRE_KERNEL_1, PRE_KERNEL_2 or POST_KERNEL. We are passing POST_KERNEL, which is the same level as the SPIM device driver.
prio – This is the device’s priority within its initialization level, which needs to be of lower priority than the SPIM driver to ensure it is initialized first. We are passing CONFIG_SENSOR_INIT_PRIORITY, which is the predefined sensor initialization priority.
api – Pointer to the device’s API structure, which we defined ascustom_bme280_api.
9. Create the struct device for every status “okay” node in the devicetree.
DT_INST_FOREACH_STATUS_OKAY() expands to code which calls CUSTOM_BME280_DEFINE once for each enabled node with the compatible determined by DT_DRV_COMPAT.
Copy
DT_INST_FOREACH_STATUS_OKAY(CUSTOM_BME280_DEFINE)
C
10. Populate the CMakeLists.txt file for the custom driver.
In drivers/sensor/custom_bme280/CMakeLists.txt, add the following lines.
Here we define the Kconfig symbol CUSTOM_BME280_DRIVER which, when enabled, will add the custom driver to the build. The Kconfig symbol depends on DT_HAS_ZEPHYR_CUSTOM_BME280_ENABLED which just checks if the build devicetree has enabled this compatible.
Now that we have created a custom driver, let’s test it out by adding it to our application. The application is found in the directory called app.
12. Add the custom_bme280 directory as a subdirectory in the sensor driver.
The custom_bme280 directory must be added as a subdirectory in drivers/sensor.
12.1 Add the custom driver as a subdirectory of the sensor driver.
Open drivers/sensor/CMakeLists.txt and replace the code with the following code snippet
13.3 If you are using a board with a dual-core (nRF7002 DK, nRF5340 DK, nRF91 Series DK), add the .conf file corresponding to the board you are using
Copy
#UART1 is used for TF-M logging should be disabledCONFIG_TFM_SECURE_UART=nCONFIG_TFM_LOG_LEVEL_SILENCE=y
Kconfig
14. Enable the sensor API
Notice that in the prj.conf file, the sensor API is enabled through the Kconfig CONFIG_SENSOR
Copy
CONFIG_SENSOR=y
Kconfig
This will automatically bring in the custom_bme280 driver, if CONFIG_CUSTOM_BME280 is enabled, which depends on DT_HAS_CUSTOM_BME280_ENABLED, i.e if the device tree has a node with the custom, bme280 compatible with the status okay.
15. Clear the contents of main.c
In app/src/main.c, clear the contents of the file.
Copy and paste the contents of the file main_template.c found in l7/l7_e1 into main.c, to serve as a template for the next steps.
16. Get the device structure from the node label.
Add the following line to retrieve the device structure from the node label bme280.
Copy
conststruct device * dev = DEVICE_DT_GET(DT_NODELABEL(bme280));
C
17. Continuously read out sensor data using the sensor API calls.
17.1 Define the structures to store the temperature, pressure and humidity.
Copy
struct sensor_value temp_val, press_val, hum_val;
C
17.2 Continuously read out sensor data using the sensor API calls.
In the while-loop, add the following code to continuously read the sensor data, using the sensor APIs sensor_sample_fetch() and sensor_channel_get().
Copy
err = sensor_sample_fetch(dev);if (err < 0) {LOG_ERR("Could not fetch sample (%d)", err);return0;}if (sensor_channel_get(dev, SENSOR_CHAN_AMBIENT_TEMP, &temp_val)) {LOG_ERR("Could not get sample");return0;}if (sensor_channel_get(dev, SENSOR_CHAN_PRESS, &press_val)) {LOG_ERR("Could not get sample");return0;}if (sensor_channel_get(dev, SENSOR_CHAN_HUMIDITY, &hum_val)) {LOG_ERR("Could not get sample");return0;}LOG_INF("Compensated temperature value: %d", temp_val.val1);LOG_INF("Compensated pressure value: %d", press_val.val1);LOG_INF("Compensated humidity value: %d", hum_val.val1);
C
18. Build and flash the application to your board.
Add a build configuration for the board you are using.
In this Privacy Policy you will find information on Nordic Semiconductor ASA (“Nordic Semiconductor”) processes your personal data when you use the Nordic Developer Academy.
References to “we” and “us” in this document refers to Nordic Semiconductor.
2. Our processing of personal data when you use the Nordic Developer Academy
2.1 Nordic Developer Academy
Nordic Semiconductor processes personal data in order to provide you with the features and functionality of the Nordic Developer Academy. Creating a user account is optional, but required if you want to track you progress and view your completed courses and obtained certificates. If you choose to create a user account, we will process the following categories of personal data:
Email
Name
Password (encrypted)
Course progression (e.g. which course you have completely or partly completed)
Certificate information, which consists of name of completed course and the validity of the certificate
Course results
During your use of the Nordic Developer Academy, you may also be asked if you want to provide feedback. If you choose to respond to any such surveys, we will also process the personal data in your responses in that survey.
The legal basis for this processing is GDPR article 6 (1) b. The processing is necessary for Nordic Semiconductor to provide the Nordic Developer Academy under the Terms of Service.
2.2 Analytics
If you consent to analytics, Nordic Semiconductor will use Google Analytics to obtain statistics about how the Nordic Developer Academy is used. This includes collecting information on for example what pages are viewed, the duration of the visit, the way in which the pages are maneuvered, what links are clicked, technical information about your equipment. The information is used to learn how Nordic Developer Academy is used and how the user experience can be further developed.
2.2 Newsletter
You can consent to receive newsletters from Nordic from within the Nordic Developer Academy. How your personal data is processed when you sign up for our newsletters is described in the Nordic Semiconductor Privacy Policy.
3. Retention period
We will store your personal data for as long you use the Nordic Developer Academy. If our systems register that you have not used your account for 36 months, your account will be deleted.
4. Additional information
Additional information on how we process personal data can be found in the Nordic Semiconductor Privacy Policy and Cookie Policy.
Nordic Developer Academy Terms of Service
1. Introduction
These terms and conditions (“Terms of Use”) apply to the use of the Nordic Developer Academy, provided by Nordic Semiconductor ASA, org. nr. 966 011 726, a public limited liability company registered in Norway (“Nordic Semiconductor”).
Nordic Developer Academy allows the user to take technical courses related to Nordic Semiconductor products, software and services, and obtain a certificate certifying completion of these courses. By completing the registration process for the Nordic Developer Academy, you are agreeing to be bound by these Terms of Use.
These Terms of Use are applicable as long as you have a user account giving you access to Nordic Developer Academy.
2. Access to and use of Nordic Developer Academy
Upon acceptance of these Terms of Use you are granted a non-exclusive right of access to, and use of Nordic Developer Academy, as it is provided to you at any time. Nordic Semiconductor provides Nordic Developer Academy to you free of charge, subject to the provisions of these Terms of Use and the Nordic Developer Academy Privacy Policy.
To access select features of Nordic Developer Academy, you need to create a user account. You are solely responsible for the security associated with your user account, including always keeping your login details safe.
You will able to receive an electronic certificate from Nordic Developer Academy upon completion of courses. By issuing you such a certificate, Nordic Semiconductor certifies that you have completed the applicable course, but does not provide any further warrants or endorsements for any particular skills or professional qualifications.
Nordic Semiconductor will continuously develop Nordic Developer Academy with new features and functionality, but reserves the right to remove or alter any existing functions without notice.
3. Acceptable use
You undertake that you will use Nordic Developer Academy in accordance with applicable law and regulations, and in accordance with these Terms of Use. You must not modify, adapt, or hack Nordic Developer Academy or modify another website so as to falsely imply that it is associated with Nordic Developer Academy, Nordic Semiconductor, or any other Nordic Semiconductor product, software or service.
You agree not to reproduce, duplicate, copy, sell, resell or in any other way exploit any portion of Nordic Developer Academy, use of Nordic Developer Academy, or access to Nordic Developer Academy without the express written permission by Nordic Semiconductor. You must not upload, post, host, or transmit unsolicited email, SMS, or \”spam\” messages.
You are responsible for ensuring that the information you post and the content you share does not;
contain false, misleading or otherwise erroneous information
infringe someone else’s copyrights or other intellectual property rights
contain sensitive personal data or
contain information that might be received as offensive or insulting.
Such information may be removed without prior notice.
Nordic Semiconductor reserves the right to at any time determine whether a use of Nordic Developer Academy is in violation of its requirements for acceptable use.
Violation of the at any time applicable requirements for acceptable use may result in termination of your account. We will take reasonable steps to notify you and state the reason for termination in such cases.
4. Routines for planned maintenance
Certain types of maintenance may imply a stop or reduction in availability of Nordic Developer Academy. Nordic Semiconductor does not warrant any level of service availability but will provide its best effort to limit the impact of any planned maintenance on the availability of Nordic Developer Academy.
5. Intellectual property rights
Nordic Semiconductor retains all rights to all elements of Nordic Developer Academy. This includes, but is not limited to, the concept, design, trademarks, know-how, trade secrets, copyrights and all other intellectual property rights.
Nordic Semiconductor receives all rights to all content uploaded or created in Nordic Developer Academy. You do not receive any license or usage rights to Nordic Developer Academy beyond what is explicitly stated in this Agreement.
6. Liability and damages
Nothing within these Terms of Use is intended to limit your statutory data privacy rights as a data subject, as described in the Nordic Developer Academy Privacy Policy. You acknowledge that errors might occur from time to time and waive any right to claim for compensation as a result of errors in Nordic Developer Academy. When an error occurs, you shall notify Nordic Semiconductor of the error and provide a description of the error situation.
You agree to indemnify Nordic Semiconductor for any loss, including indirect loss, arising out of or in connection with your use of Nordic Developer Academy or violations of these Terms of Use. Nordic Semiconductor shall not be held liable for, and does not warrant that (i) Nordic Developer Academy will meet your specific requirements, (ii) Nordic Developer Academy will be uninterrupted, timely, secure, or error-free, (iii) the results that may be obtained from the use of Nordic Developer Academy will be accurate or reliable, (iv) the quality of any products, services, information, or other material purchased or obtained by you through Nordic Developer Academy will meet your expectations, or that (v) any errors in Nordic Developer Academy will be corrected.
You accept that this is a service provided to you without any payment and hence you accept that Nordic Semiconductor will not be held responsible, or liable, for any breaches of these Terms of Use or any loss connected to your use of Nordic Developer Academy. Unless otherwise follows from mandatory law, Nordic Semiconductor will not accept any such responsibility or liability.
7. Change of terms
Nordic Semiconductor may update and change the Terms of Use from time to time. Nordic Semiconductor will seek to notify you about significant changes before such changes come into force and give you a possibility to evaluate the effects of proposed changes. Continued use of Nordic Developer Academy after any such changes shall constitute your acceptance of such changes. You can review the current version of the Terms of Use at any time at https://academy.nordicsemi.com/terms-of-service/
8. Transfer of rights
Nordic Semiconductor is entitled to transfer its rights and obligation pursuant to these Terms of Use to a third party as part of a merger or acquisition process, or as a result of other organizational changes.
9. Third Party Services
To the extent Nordic Developer Academy facilitates access to services provided by a third party, you agree to comply with the terms governing such third party services. Nordic Semiconductor shall not be held liable for any errors, omissions, inaccuracies, etc. related to such third party services.
10. Dispute resolution
The Terms of Use and any other legally binding agreement between yourself and Nordic Semiconductor shall be subject to Norwegian law and Norwegian courts’ exclusive jurisdiction.
