nRF Connect SDK Hands-on Part 2: File Structure and Sensor Integration

Nordic Semiconductor

Summary:

This video, the second part of a hands-on series, details the nRF Connect SDK application development process, focusing on file structure and sensor integration.

• The video first explains the nRF Connect SDK's file structure, emphasizing the separation of source code, software configurations (Kconfig files), and hardware configurations (Devicetree files) for scalability and portability.
• It then demonstrates how to integrate both simulated and real sensors into an application using the unified Sensor API.
• The process involves creating new source files for a sensor data collection thread, updating the CMakeLists.txt for the new files, and configuring Kconfig and Devicetree overlay files.
• The simulated sensor provides temperature, humidity, pressure, and accelerometer data.
• The video shows connecting physical BME688 environmental and BMI270 IMU sensors via I2C.
• It highlights the ease of switching between simulated and physical sensors with minimal code changes due to the standardized Sensor API.

Understanding nRF Connect SDK Application File Structure [00:00:21]

• The nRF Connect SDK architecture ensures clear separation between application source code and configuration files, promoting scalability and portability.
  • Source Code Files (C/C++): Typically located in the src directory, containing the application's core logic (e.g., main.c). [00:01:27]
• Configuration Files: Essential for defining application behavior and hardware interfaces.
  • Kconfig Files (Software Configuration): Used to specify software functionalities, modules, libraries, and settings from the nRF Connect SDK. [00:00:53]
    • prj.conf: The main application configuration file, enabling modules like Bluetooth LE (e.g., CONFIG_BT=y), defining device names (CONFIG_BT_DEVICE_NAME), and enabling services (e.g., CONFIG_LBS=y). [00:01:57]
      • A default logging configuration is often included via NCS_SAMPLES_DEFAULT. [00:02:12]
    • prj_minimal.conf: An alternative configuration file, often used for optimized "release" builds, disabling features like extensive logging to save memory. [00:03:35]

      

    • Kconfig.sysbuild: Used for multi-image builds, such as supporting MCUboot or dual-core devices like the nRF5340. [00:04:39]
    • Kconfig: Defines the application's own custom software options and configurations, which are optional. [00:05:02]
  • Devicetree Files (Hardware Configuration): Capture hardware-specific settings and peripherals. [00:00:56]
    • boards directory: Contains board-specific configuration fragments (ending in .conf) and Devicetree overlays (ending in .overlay). [00:06:33]
      • Devicetree overlays (.overlay files) are used to modify or extend the base Devicetree provided by the build target (e.g., nrf52840dk_nrf52840) to add custom hardware components or change pin assignments. [00:07:02]
• CMakeLists.txt (Build System): A mandatory file for every nRF Connect SDK application, as all applications are CMake projects. [00:05:33]
  • It controls the application's configuration and build process, including referencing SDK libraries and adding source files. [00:05:41]

Sensors in nRF Connect SDK and Zephyr [00:08:00]

• The SDK provides a rich set of sensor drivers, abstracting hardware interactions (e.g., SPI, I2C). [00:08:07]
• Unified Sensor API: A key feature that offers high-level portability and ease of use. [00:08:42]
  • Applications can easily support new sensors or swap existing ones with minimal code changes. [00:08:51]
  • Data is exposed as sensor_value through channels. [00:08:58]
• Sensor Data Acquisition Steps:
  1. Get Node Identifier: Obtain a device identifier for the sensor in the C code using DT_LABEL. [00:14:39]
  2. Fetch Sample (sensor_sample_fetch): Instructs the sensor driver to read data from all its channels, storing it internally in the driver's buffer. [00:14:56]
  3. Get Channel Data (sensor_channel_get): Retrieves individual channel values from the driver's buffer. [00:15:02]

     

• The video demonstrates this principle by first using a simulated sensor and then seamlessly transitioning to physical sensors. [00:09:01]

Implementing a Simulated Sensor [00:09:33]

• Modular Application Structure: Create a dedicated thread and files for sensor data collection.
  • sensor_data_collector.c: Contains the sensor data collection logic, including a thread that continuously fetches and processes sensor data. [00:10:04]
  • sensor_data_collector.h: Defines the interface and data structures (e.g., sensor_data_t struct for temperature, humidity, pressure, accelerometer) to expose sensor readings to other modules. [00:11:15]

    

• Updating Build Configuration:
  • CMakeLists.txt: Add the new source and header files (sensor_data_collector.c, sensor_data_collector.h) to the application's build system. [00:10:24]
  • prj.conf: Enable the generic sensor drivers using CONFIG_SENSOR=y. [00:12:07]
  • Devicetree Overlay (nrf52840dk_nrf52840.overlay): Configure the simulated sensor by defining it as a node with specific properties (e.g., compatible = "zephyr,sim-temp-hum-press-accel"). [00:13:26]

    

    • This triggers the inclusion and initialization of the simulated sensor driver. [00:13:44]
• Adding Application Options (Kconfig):
  • Define a custom Kconfig option, CONFIG_APP_SENSOR_SAMPLING_INTERVAL, to control the data sampling rate in milliseconds. [00:16:01]

    

• Building and Testing:
  • Perform a pristine build and flash the firmware to the nRF52840 DK. [00:16:29]
  • Verify the output in the terminal, observing the simulated temperature, humidity, pressure, and accelerometer data. [00:17:23]

Integrating Real Sensors (BME688 & BMI270) [00:17:39]

• Hardware Connection:
  • Connect the BME688 environmental sensor and BMI270 6-DoF IMU to the nRF52840 DK via the I2C bus. [00:17:43]
  • Specific pins used are P0.27 for SCL (clock) and P0.26 for SDA (data) on the nRF52840 DK. [00:19:10]

    

• Devicetree Overlay Configuration:
  • Update the nrf52840dk_nrf52840.overlay file to define the physical sensors as child nodes of the I2C0 controller. [00:18:54]
  • Specify their compatible properties (e.g., bosch,bme688 for the environmental sensor and bosch,bmi270 for the IMU) and I2C addresses. [00:18:59]
• Code Modification for Switching Sensors:
  • Add a Kconfig option, CONFIG_SIMULATED_SENSOR, to the application's Kconfig file, allowing developers to choose between using the simulated or physical sensors. [00:20:17]
  • Implement conditional compilation (#if CONFIG_SIMULATED_SENSOR) in sensor_data_collector.c to call the appropriate sensor initialization and data fetching functions based on the selected option. [00:21:02]

    

• Building and Testing with Real Sensors:
  • Build the application with CONFIG_SIMULATED_SENSOR disabled (set to n).
  • Flash the firmware to the development kit.
  • Observe real-time sensor data from the BME688 and BMI270 in the terminal, demonstrating the ease of switching between sensor types due to the unified Sensor API. [00:22:03]

Summary of Benefits [00:22:18]

• Scalability and Portability: Achieved by separating source code from software (Kconfig) and hardware (Devicetree) configurations. [00:22:20]
• Kconfig Flexibility: Allows dynamic inclusion of SDK modules, libraries, and stacks, and definition of custom application options. [00:22:34]
• Devicetree for Hardware Abstraction: Manages hardware configurations and enables changes via overlay files without modifying core application code. [00:22:52]