1 Project Overview

This project is based on the NXP FRDM-MCXA156 development board, running the RT-Thread real-time operating system. It implements multi-sensor data acquisition and uploads the data to the Huawei Cloud IoT platform via the ESP01S WiFi module.

1.1 Main Functions

1.2 System Architecture

+------------------+     +------------------+     +------------------+
|   Sensor Layer   |     |   Application    |     |   Communication   |
|                  |     |   Layer          |     |   Layer           |
+------------------+     +------------------+     +------------------+
| drv_mq2.c        | --> | MQ2_app.c        |     |                  |
| drv_dht11.c      | --> | dht11_app.c      | --> | esp_app.c        | --> Huawei Cloud IoT
| drv_max30102.c   | --> | max30102_app.c   |     | (MQTT reporting) |
| (UART receive)   | --> | ATGM336H_app.c   |     |                  |
+------------------+     +------------------+     +------------------+

2 Hardware Platform

2.1 Main Controller Chip

Model: NXP MCXA156

Core: ARM Cortex-M33

Main Frequency: 96 MHz

Flash: 1 MB

RAM: 128 KB

2.2 Pin Assignment

3 Directory Structure

frdm-mcxa156/
├── applications/           # Application layer code
│   ├── main.c             # Main function entry
│   ├── mydefine.h         # Common header definitions
│   │
│   ├── drv_dht11.c/h      # DHT11 driver layer
│   ├── dht11_app.c/h      # DHT11 application layer
│   │
│   ├── drv_mq2.c/h        # MQ2 driver layer
│   ├── MQ2_app.c/h        # MQ2 application layer
│   │
│   ├── drv_max30102.c/h   # MAX30102 driver layer
│   ├── max30102_app.c/h   # MAX30102 application layer
│   │
│   ├── ATGM336H_app.c/h   # GPS module application layer
│   │
│   ├── esp_app.c/h        # ESP01S WiFi/MQTT communication
│   │
│   ├── adc_app.c/h        # ADC acquisition wrapper
│   └── uart_app.c/h       # UART utility functions
│
├── board/                  # Board support package
│   ├── board.c/h          # Board initialization
│   ├── Kconfig            # Hardware configuration menu
│   ├── MCUX_Config/       # NXP MCUXpresso configuration
│   │   └── board/
│   │       ├── clock_config.c/h   # Clock configuration
│   │       └── pin_mux.c/h        # Pin multiplexing configuration
│   └── linker_scripts/    # Linker scripts
│
├── packages/               # RT-Thread packages
│   ├── nxp-mcx-cmsis-latest/     # NXP CMSIS support
│   └── nxp-mcx-series-latest/    # NXP MCX series drivers
│
├── .config                # RT-Thread configuration file
├── rtconfig.h             # RT-Thread configuration header
├── Kconfig                # Top-level configuration menu
├── SConstruct             # SCons build file
├── project.uvprojx        # Keil MDK project file
└── rtthread.elf/bin       # Build output files

4 Sensor Module Details

4.1 MQ2 Gas Sensor

Files: drv_mq2.c/h, MQ2_app.c/h

Function: Detects methane (CH4) and other combustible gases

Data Structure:

typedef struct {
    rt_base_t dopin;    // Digital output pin
    float adc_val;      // ADC raw value
    float ch4ppm;       // Methane concentration (ppm)
} mq2_device_t;

API Interfaces:

// Initialize MQ2 device
rt_err_t mq2_init(mq2_device_t *dev, rt_base_t dopin);

// Read gas concentration
mq2_result_t MQ2_GetPmm(mq2_device_t *dev);

// Get current methane concentration (application layer)
float mq2_get_ch4ppm(void);

Global Variable:
g_mq2_dev — MQ2 device object

4.2 DHT11 Temperature and Humidity Sensor

Files: drv_dht11.c/h, dht11_app.c/h

Function: Measures ambient temperature and humidity

Data Structure:

typedef struct {
    rt_base_t pin;          // Data pin
    rt_uint8_t humidity;    // Integer part of humidity
    rt_uint8_t temperature; // Integer part of temperature
} dht11_device_t;

API Interfaces:

// Initialize DHT11 device
rt_err_t dht11_init(dht11_device_t *dev, rt_base_t pin);

// Read temperature and humidity
dht11_result_t dht11_read(dht11_device_t *dev, rt_uint8_t *temp, rt_uint8_t *humi);

// Get current temperature (application layer)
rt_uint8_t dht11_get_temperature(void);

// Get current humidity (application layer)
rt_uint8_t dht11_get_humidity(void);

Global Variables:

• g_dht11_dev — DHT11 device object
• g_dht11_temperature — Latest temperature value
• g_dht11_humidity — Latest humidity value

4.3 MAX30102 Heart Rate and Blood Oxygen Sensor

Files: drv_max30102.c/h, max30102_app.c/h

Function: Detects heart rate and blood oxygen using red and infrared light

Communication Interface: I2C (address: 0x57)

Data Structure:

typedef struct {
    struct rt_i2c_bus_device *i2c_bus;  // I2C bus handle
    rt_mutex_t lock;                   // Mutex
    rt_uint8_t addr;                   // I2C address
    rt_bool_t initialized;             // Initialization flag
} max30102_device_t;

API Interfaces:

// Initialize MAX30102 device
max30102_device_t *max30102_init(const char *i2c_bus_name);

// Read LED data from FIFO
rt_err_t max30102_read_fifo(max30102_device_t *dev,
                            rt_uint32_t *red_led,
                            rt_uint32_t *ir_led);

// Get heart rate (application layer)
rt_uint32_t max30102_get_heart_rate(void);

Global Variables:

• g_max30102_red_led — Red LED raw value
• g_max30102_ir_led — Infrared LED raw value
• g_max30102_heart_rate — Estimated heart rate

Operating Modes:
Supports interrupt mode and polling mode (switch via USE_INTERRUPT_MODE macro)

4.4 ATGM336H GPS Module

Files: ATGM336H_app.c/h

Function: Obtains GPS positioning information (longitude, latitude)

Communication Interface: UART2 (baud rate: 9600)

Data Structures:

typedef struct {
    char GPS_Buffer[80];    // Raw GPS data buffer
    char isGetData;         // Data received flag
    char isParseData;       // Data parsed flag
    char UTCTime[11];       // UTC time
    char latitude[11];      // Latitude string
    char N_S[2];            // North/South
    char longitude[12];     // Longitude string
    char E_W[2];            // East/West
    char isUsefull;         // Valid positioning flag
} _SaveData;

typedef struct {
    float latitude;         // Latitude (decimal degrees)
    float longitude;        // Longitude (decimal degrees)
    char N_S;               // North/South indicator
    char E_W;               // East/West indicator
} LatitudeAndLongitude_s;

Global Variables:

• Save_Data — Raw GPS data structure
• g_LatAndLongData — Parsed latitude and longitude
• latitude, longitude — Global coordinate variables

4.5 ESP01S WiFi Module

Files: esp_app.c/h

Function: Uploads sensor data to Huawei Cloud IoT platform via MQTT protocol

Communication Interface: UART1

Cloud Configuration (defined in esp_app.h):

#define WIFI_NAME               "LP11"
#define WIFI_PWD                "123456aa"
#define HUAWEI_MQTT_ADDRESS     "e8b7ac5772.st1.iotda-device.cn-east-3.myhuaweicloud.com"
#define HUAWEI_MQTT_PORT        1883

API Interfaces:

// Send AT command
void esp_send(const char *data);

// Report sensor data to cloud
int esp_report(float density, int hr, int temp, int humi);

Data Reporting Format (MQTT JSON):

{
  "services": [{
    "service_id": "BasedData",
    "properties": {
      "density": 100.5,
      "heart_rate": 75,
      "temperature": 25,
      "humidity": 60
    }
  }]
}

5 Thread Architecture

The system adopts a multi-threaded architecture, where each sensor is collected independently:

6 Build and Flash

6.1 Using Keil MDK

Open the project.uvprojx project file

Build: Project -> Build Target or F7

Flash: Flash -> Download or F8

6.2 Using SCons (Command Line)

# Configure
scons --menuconfig

# Build
scons

# Clean
scons -c

7 Configuration

7.1 RT-Thread Configuration

Configure via menuconfig or by directly editing the .config file:

# UART configuration
CONFIG_BSP_USING_UART0=y    # Debug UART
CONFIG_BSP_USING_UART1=y    # ESP01S
CONFIG_BSP_USING_UART2=y    # GPS module

# I2C configuration
CONFIG_BSP_USING_I2C0=y     # MAX30102

# ADC configuration
CONFIG_BSP_USING_ADC0_CH0=y # MQ2 analog output

7.2 Sensor Pin Configuration

Modify pin definitions in each application file:

// MQ2_app.c
#define MQ2_DATA_PIN     ((3*32)+7)    // P3_7

// dht11_app.c
#define DHT11_DATA_PIN   ((3*32)+6)    // P3_6

// max30102_app.c
#define MAX30102_INT_PIN ((1*32)+13)   // P1_13

8 Data Flow Description

[Sensor Acquisition] --> [Global Variable Update] --> [esp_thread_entry Read] --> [esp_report Upload] --> [Huawei Cloud]

Sequence:

1. Each sensor thread periodically collects data and updates global variables
2. The ESP thread reads global variables in the main loop
3. Calls esp_report() to construct and send MQTT messages
4. Huawei Cloud IoT platform receives and stores the data

9 Notes

• DHT11: At least 2 seconds interval between reads
• MQ2: Requires a warm-up stabilization period after power-on
• MAX30102: I2C communication requires larger stack space
• GPS: Initial positioning may take a long time; may not work indoors
• ESP01S: WiFi connection requires ~5 seconds; MQTT connection requires ~3 seconds

10 File Dependency Relationships

mydefine.h (basic definitions)
    ├── drv_dht11.h
    ├── drv_mq2.h
    ├── drv_max30102.h
    │
    ├── dht11_app.h      --> dht11_app.c
    ├── MQ2_app.h        --> MQ2_app.c
    ├── max30102_app.h   --> max30102_app.c
    ├── ATGM336H_app.h   --> ATGM336H_app.c
    │
    └── esp_app.h        --> esp_app.c (references all sensor data)

This article is based on the existing DM (Device Model) framework of RT-Thread. Taking the Rock2F development board as an example, it systematically outlines the rapid porting process for the RK3528 SoC, covering the adaptation methods of key drivers such as CLK, Pinctrl, ADC, NVMEM, Thermal, and RNG.

1. Prerequisites

In bsp/rockchip, it can be seen that support has already been implemented using the DM framework for SoCs such as RK3566, RK3568, RK3576, and RK3588. Next, we will take the Rockchip RK3528-based Rock2F as an example to briefly explain the porting process for a new Rockchip BSP.

2. Product Introduction

Official website: https://docs.radxa.com/rock2/rock2f

3. Preparation

In addition, I prepared an FPC Connector with PCIe 2.0 for the Raspberry Pi 5 to verify PCIe functionality.

First, follow the official Radxa guide to flash RadxaOS onto the board:
https://docs.radxa.com/rock2/rock2f/getting-started/install-os

Connect the serial port and boot up the board:
https://docs.radxa.com/rock2/rock2f/radxa-os/serial

Debian GNU/Linux 12 rock-2f ttyFIQ0

rock-2f login: radxa
Password:
Linux rock-2f 6.1.43-26-rk2312 #26 SMP Tue Dec 30 13:28:44 UTC 2025 aarch64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Jun 26 14:59:52 UTC 2025 on ttyFIQ0
radxa@rock-2f:~$

Swipe up/down or left/right to view more.

Then, use the dtc tool to extract the device tree from the SBC:

radxa@rock-2f:~$ sudo dtc -I dtb -O dts /sys/firmware/fdt -o Rock2F.dts

4. Start Porting

In bsp/rockchip/dm, a set of DM drivers has already been implemented. This means you only need to port the drivers that are not yet supported for RK3528 but are required for your use case.

In the device tree, we can see a large number of device nodes with compatible strings starting with rockchip,rk3528-. Since the device tree supports driver backward compatibility, we need to identify which nodes correspond to new IP blocks or device configurations introduced by Rockchip for the RK3528.

Therefore, the next step is to clone the Rockchip Linux kernel source code:
https://github.com/rockchip-linux/kernel/tree/develop-6.6

Under the drivers directory, search for drivers related to RK3528:

[gui@gui-pc drivers]$ grep -riE rk3528
clk/rockchip/Makefile
clk/rockchip/clk-rk3528.c
cpufreq/cpufreq-dt-platdev.c
devfreq/event/rockchip-dfi.c
devfreq/rockchip_bus.c
devfreq/rockchip_dmc.c
gpu/arm/mali400/mali/platform/rk/rk.c
gpu/drm/rockchip/dw_hdmi-rockchip.c
gpu/drm/rockchip/rockchip_drm_tve.c
gpu/drm/rockchip/rockchip_drm_vkms.c
gpu/drm/rockchip/rockchip_drm_vop2.c
gpu/drm/rockchip/rockchip_vop2_reg.c
iio/adc/rockchip_saradc.c
mmc/host/sdhci-of-dwcmshc.c
net/ethernet/stmicro/stmmac/dwmac-rk.c
nvmem/rockchip-otp.c
pci/controller/dwc/pcie-dw-rockchip.c
phy/rockchip/phy-rockchip-inno-hdmi-phy.c
phy/rockchip/phy-rockchip-inno-usb2.c
phy/rockchip/phy-rockchip-naneng-combphy.c
pinctrl/pinctrl-rockchip.c
pmdomain/rockchip/pm-domains.c
soc/rockchip/rockchip-cpuinfo.c
soc/rockchip/rockchip_pm_config.c
thermal/rockchip_thermal.c
video/rockchip/mpp/mpp_rkvdec2.c
video/rockchip/mpp/mpp_rkvenc2.c

Next, we focus on several key modules:

Here is a precise and faithful English translation of your content:

In addition, some drivers may not be named with “RK3528”, so we still need to rely primarily on the device tree. For example, this RNG device:

rng: rng@ffc50000 {
    compatible = "rockchip,rkrng";
    reg = <0x00 0xffc50000 0x0 0x200>;
    interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&scmi_clk SCMI_HCLK_TRNG>;
    clock-names = "hclk_trng";
    resets = <&cru SRST_HRESETN_TRNG_NS>;
    reset-names = "reset";
};

Swipe up/down or left/right to view more.

We also need to complete support in dm/hwcrypto/hw-rng-rockchip.c.

7. Start Porting Drivers

In other words, once clk and pinctrl are supported, the Rock2F should be able to boot. Then, adding support for ADC, NVMEM, Thermal, and RNG will complete the porting process.

Note: RK3528 uses GICv2:

gic: interrupt-controller@fed01000 {
    compatible = "arm,gic-400";
    #interrupt-cells = <3>;
    #address-cells = <0>;
    interrupt-controller;
    reg = <0x00 0xfed01000 0x0 0x1000>,
          <0x00 0xfed02000 0x0 0x2000>,
          <0x00 0xfed04000 0x0 0x2000>,
          <0x00 0xfed06000 0x0 0x2000>;
    interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
};

This has already been ported in DM. Simply enable RT_PIC_ARM_GIC to use it directly.

CLK Porting

Refer to RK3568.

Taking RK3568 as an example, we can see that DM already integrates many CLK modules (newer Rockchip SoCs may require additional modules):

#include "clk-rk-composite.h"
#include "clk-rk-cpu.h"
#include "clk-rk-divider.h"
#include "clk-rk-factor.h"
#include "clk-rk-fraction-divider.h"
#include "clk-rk-gate.h"
#include "clk-rk.h"
#include "clk-rk-half-divider.h"
#include "clk-rk-mmc-phase.h"
#include "clk-rk-muxgrf.h"
#include "clk-rk-mux.h"
#include "clk-rk-pll.h"
#define DBG_TAG "clk.rk3568"
#define DBG_LVL DBG_INFO
#include <rtdbg.h>
#include <dt-bindings/clock/rk3568-cru.h>

Each new driver requires filling in the CLK Cells table. Every device has its own CLK description, which can be referenced from the TRM and Linux implementation.

Then, during the platform bus probe phase, register the CLK into the system and also register the reset controller.

RK3528 Implementation

From the device tree, RK3528 has a syscon-based CRU and a main CRU:

grf: syscon@ff300000 {
    compatible = "rockchip,rk3528-grf", "syscon", "simple-mfd";
    reg = <0x00 0xff300000 0x0 0x90000>;
    grf_cru: grf-clock-controller {
        compatible = "rockchip,rk3528-grf-cru";
        #clock-cells = <1>;
    };
};

cru: clock-controller@ff4a0000 {
    compatible = "rockchip,rk3528-cru";
    reg = <0x00 0xff4a0000 0x0 0x30000>;
    rockchip,grf = <&grf>;
    #clock-cells = <1>;
    #reset-cells = <1>;
    ...
};

Follow the same approach as RK3568. Key parts to port include:

• Import clock IDs
• Define PLL rate tables
• Define CPU clock tables
• Define parent clock sources
• Define PLL and mux cells
• Populate RT-Thread CLK cell tables
• Register CRU and GRF clock cells

RK3528 CLK is a new driver file and must be registered in:

• bsp/rockchip/dm/clk/Kconfig
• bsp/rockchip/dm/clk/SConscript

Pinctrl Porting

Similar to other SoCs. Rockchip pinctrl mainly includes four aspects:

• MUX (function multiplexing)
• Pull-up/down
• Drive strength
• Schmitt trigger

Add implementations in pinctrl-rockchip.c, including:

• set_mux
• set_pull
• set_drive
• set_schmitt

Then:

• Define GPIO banks
• Define SoC pinctrl descriptor
• Add device tree matching IDs

ADC Porting

ADC porting is straightforward. Only channel descriptions need to be added:

static const struct saradc_channel rockchip_rk3528_channels[] =
{
    SARADC_CHANNEL(0, "adc0", 10),
    SARADC_CHANNEL(1, "adc1", 10),
    SARADC_CHANNEL(2, "adc2", 10),
    SARADC_CHANNEL(3, "adc3", 10),
};

Also define SoC-specific access methods and register device tree matching.

NVMEM Porting

Even simpler. Just define:

• OTP memory size
• Read interface version

Thermal Porting

Thermal requires:

• Temperature lookup tables
• Sensor configuration
• Implementation of new interface functions (based on hardware manual)

RNG Porting

For RNG:

• Implement initialization and random read interfaces
• Add device tree matching (rockchip,rkrng)

8. Boot Address

Since we are replacing Linux directly, we need to know where U-Boot loads the kernel:

radxa@rock-2f:~$ sudo cat /proc/iomem | grep -iE Kernel
  00410000-019affff : Kernel code
  02050000-024cffff : Kernel data

So the load address is approximately 0x410000.

For RT-Smart:

• ARCH_TEXT_OFFSET = 0x410000
• ARCH_RAM_OFFSET = 0x0

9. Toolchain Configuration

The Rock2F uses Cortex-A53, while RK3500 defaults to Cortex-A55 (ARMv8.2+), which may cause instruction incompatibility.

Use minimal compatibility settings:

# For Cortex-A53/A72
DEVICE = ' -g -mcpu=cortex-a53 -fdiagnostics-color=always'

10. Earlycon

If the system crashes before showing any boot logo, enable early serial debugging:

chosen {
    bootargs = "console=ttyFIQ0,1500000n8";
};

aliases {
    serial0 = "/serial@ff9f0000";
};

serial@ff9f0000 {
    compatible = "rockchip,rk3528-uart","snps,dw-apb-uart";
    reg = <0x000 0xff9f0000 0x000 0x100>;
};

fiq-debugger {
    compatible = "rockchip,fiq-debugger";
    rockchip,serial-id = <0>;
};

The early UART address is 0xff9f0000, using a DWC 8250 UART.

11. Boot Configuration

Check the SBC boot method via /boot:

ls /boot
lsblk

It uses the familiar extlinux boot script:

cat /boot/extlinux/extlinux.conf

Add a new entry before label l0 to boot RT-Thread:

label rt-thread
        menu RT-Thread
        linux /boot/rtthread.bin
        fdtdir /usr/lib/linux-image-6.1.43-26-rk2312/
        append earlycon=uart8250,mmio32,0xff9f0000 console=ttyFIQ0,1500000n8 root=sd1p0 rootfstype=elm rootwait rw

12. Start Booting

Copy rtthread.bin into /boot (on the third MMC partition), reboot the board, and enter 1 in the boot menu to launch RT-Thread.

Then we can see that we have entered the MSH:

We directly reused a large number of device drivers from DM, so we can check how many devices are currently supported by the system:

Except for SDMMC and NVMe, which we can mount and test directly, testing for other interfaces can refer to the official documentation:
https://docs.radxa.com/rock2/rock2f/getting-started/interface-usage/pin-40-test

Next, we can check the status of other system subsystems:

Interrupt Domain

In the interrupt domain, we can observe the number of interrupts triggered by devices, as well as their cascading relationships and affinity. For example, NVMe uses the DWC PCI INTx interrupt, which is cascaded to the GICv2 of rk-pcie.

Thermal Domain

In the thermal domain, we can view the temperature of devices equipped with thermal sensors, along with their cooling methods, mechanisms, and trigger thresholds. Currently, only the CPU is present in this domain, using CPU DVFS for thermal management. Since DVFS has not yet been merged into the mainline, it is shown as unsupported here.

Clock Domain (Partial)

In the clock domain, we can see the names and frequencies of system clocks, their enable counts, associated devices, and parent-child relationships.

LED

We can observe that the LED operates in a heartbeat pattern, which matches the configuration specified in the device tree:

gpio-leds {
    compatible = "gpio-leds";
    state-led {
        gpios = <&gpio3 RK_PC1 GPIO_ACTIVE_LOW>;
        linux,default-trigger = "heartbeat";
    };
};

Code Repository

We can also review all the modifications:

[gui@gui-pc rockchip]$ git status .
On branch rockchip_rk3528
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:     dm/adc/adc-rockchip_saradc.c
        modified:     dm/clk/Kconfig
        modified:     dm/clk/SConscript
        modified:     dm/hwcrypto/hw-rng-rockchip.c
        modified:     dm/include/pinctrl-rockchip.h
        modified:     dm/nvmem/nvmem-rockchip-otp.c
        modified:     dm/pinctrl/pinctrl-rockchip.c
        modified:     dm/thermal/thermal-rockchip_tsadc.c
        modified:     rk3500/README.md
        modified:     rk3500/README_ZH.md
        modified:     rk3500/rtconfig.h
        modified:     rk3500/rtconfig.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        dm/clk/clk-rk3528.c
        dm/include/dt-bindings/clock/rk3528-cru.h

Changes not staged for commit (use git add and/or git commit -a).

Pull Request:
https://github.com/RT-Thread/rt-thread/pull/11300

Slack: https://rtthreadhq.slack.com/archives/C0AHNBQLW5P
Discord: https://discord.com/channels/1444976234378428520/1444976235435524180

Edge Impulse is a leading edge AI development platform designed to help developers, engineers, and enterprises rapidly deploy intelligent AI to any edge device, such as microcontrollers, sensors, and IoT hardware.

With Edge Impulse, you can easily collect sensor data, build datasets, train and optimize machine learning models, and deploy them to thousands of hardware platforms worldwide with just one click — enabling fast prototyping and real-world deployment without requiring deep AI expertise.

Today, we’ll walk you step by step through how to train a wake word model and deploy it to embedded hardware using the Edgi-Talk platform integrated with Edge Impulse. The same principles also apply to other ARM-based embedded platforms. Let’s explore how to get started with edge machine learning on Edgi-Talk!

Create an Account

Steps:

1. Go to Edge Impulse: https://edgeimpulse.com/
2. Sign up for an account;
3. Create a project by clicking “Create New Project”.

Record Dataset

1. Flash the UAC firmware onto the Edgi-Talk development board to collect audio data: uac-firmware.hex;
2. Download the audio recording tool: Audio-recording.exe;
3. Connect the development board to your computer via USB — an audio input device will appear;
4. Select the audio input device: Audio Control (MME);

5. Click Start Recording to record for 10 seconds. During recording, ensure clear speech, and leave a 1–2 second pause between wake words;

6. After each recording, click “Save Recording” on the right to save the file;

7. The file index will increment automatically — repeat the above steps to record 20–50 keyword audio samples;

8. Finally, prepare two types of audio data: one for the wake word and one for background noise.

Upload Data

Steps:

1. Click Add Existing Data;
2. Select Upload Data;

3. Choose the folder on your computer containing the audio files and upload them. The platform will automatically categorize the files based on their names (e.g., noise, wake word).

Data Segmentation

Steps:

1. First, select the data in the Training list. Click Filter and enter the file prefix of your wake word recordings to filter the files you want to work on.

2. On the right, click an audio file and select Split Sample. The platform will split the audio into roughly 1-second segments.

3. In the split audio interface, you can adjust each segment to fully cover the wake word. Play back the segments to check and fine-tune them.

Each rectangle represents a segment extracted from the audio. You can move the rectangles to fully cover the wake word, or add/delete segments as needed.

4. The split segments will become independent audio files, and the platform will automatically append a suffix to each file (e.g., xxxx_Sn).

5. Repeat the above steps to segment all wake word training files.

6. Select the data in the Test list and similarly split the wake word files. Noise-labeled files do not need to be split.

7. Classify the data: as shown in the diagram, divide the dataset into two main categories: Wake Word + Others.

Model Training
Create an Impulse (Preprocessing / Model Definition)
An impulse here is Edge Impulse’s term for a data processing and training pipeline.

Create an impulse and set the window size to 1000 ms, window increase to 500 ms (overlapping windows to augment data), and frequency to 16 kHz.
These settings mean that each inference collects sensor data over 1000 ms, with the number of samples determined by the sampling frequency.
In short, your device collects N data samples within a 1000 ms window, then preprocesses them and feeds them into the neural network for inference.

Steps:

1. Click Create Impulse on the left;
2. Click Add a Processing Block and add Audio (MFCC);

3. A dialog will pop up — use the default settings;

4. MFCC extracts features from audio signals using Mel-Frequency Cepstral Coefficients, which is very useful for human voice;

5. Click Add a Learning Block and add a Classification module, which builds our model from scratch using a convolutional neural network;

6. Finally, click Save Impulse to save the configuration.

Preprocessing (MFCC)
MFCC is a widely used method to convert audio signals into 2D features representing speech frequency patterns, which are ideal for speech-based recognition models.
We create spectrogram images from the recorded audio.

Steps:

1. Click MFCC and keep the default parameter values;
2. Click Save Parameters;

3. Click Generate Features to generate features for the three labeled datasets.

Model Design and Training (Classifier)
Next, we design the model structure and start training.

Steps:

1. Click Classifier on the left — the model structure is already configured;
2. Click Save & Train to start training the model.

Through multiple iterations, the model’s generalization can be improved. Methods include optimizing the test dataset and adjusting the model structure (e.g., adding more convolutional layers).
The platform has a limit on training time: free users can train for up to 20 minutes per session. Unlimited training requires a paid plan.

Model Evaluation

Steps:

1. Click Model Testing on the left;
2. Click Classify All;
3. Classify all test dataset data;

4. After testing, view the results on the right under Result.

Model Integration
Generate Library File
After training, generate a library file that can run on the Edgi-Talk platform.

Steps:

1. Click Deployment on the left;
2. Search for Arduino Library and TensorFlow Lite;
3. Click Build. After building, save and download the library files.

Deploy to Embedded Hardware

1. Unzip the downloaded package to get the file directory;

2. Obtain the latest Edgi-Talk SDK and enter Edgi_Talk_M55_XiaoZhi/edge-impulse directory. Delete the two folders shown, then replace them with the two folders from the previous step to update the model files;

3. Compile the Edgi_Talk_M55_XiaoZhi project and flash it to the development board;

4. On the Edgi-Talk serial terminal, enter the following commands to start the wake word test:

5. Say the wake word to the board. In this demo, the wake word is “xiaorui, xiaorui”. When spoken, the serial terminal will print logs.

Join our global community on Slack or Discord to connect directly with official experts and developers.

Slack: https://rtthreadhq.slack.com/archives/C0AHNBQLW5P
Discord: https://discord.com/channels/1444976234378428520/1444976235435524180

Open the XiaoZhi AI project: Edgi_Talk_M55_XiaoZhi

Firmware Compilation

Open Env and run the following command to compile the project:

scons

After compilation, the firmware file rtthread.hex will be generated in the current directory.

Firmware Flashing

The flashing method is the same as described in the environment setup section.

Use the OpenOCD tool to flash the firmware through the command line.

./openocd.exe -s ../scripts -s ../flm/cypress/cat1d -f interface/kitprog3.cfg -f target/infineon/pse84xgxs2.cfg -c "set QSPI_FLASHLOADER ../flm/cypress/cat1d/PSE84_SMIF.FLM" -c "transport select swd" -c "set ENABLE_ACQUIRE 0" -c "init; reset init; flash write_image erase ./rtthread.hex; reset run; exit"

How to Configure the XiaoZhi App Network Connection

Note:

If you have an SD card, insert it into the development board’s SD card slot.

The device will automatically reconnect to the network on the next boot.

First-Time Network Setup

When the development board is powered on for the first time, it will enter AP mode by default.

1. Find and connect to the corresponding Wi-Fi AP broadcast by the board.

2. The Wi-Fi password is displayed on the screen.

After successfully connecting to the AP, open a browser on your device and enter:

192.168.169.1

This will open the configuration interface for network setup.

Steps to Connect to Wi-Fi

1. Click Scan to search for nearby Wi-Fi networks.

2. Select the Wi-Fi you want to connect to and enter the password.

3. After a successful connection, the interface will display the connection status.

XiaoZhi AI — Meaning of the Status Emojis

Connecting to the network

The device is connecting to the network. Please wait until the process is completed.Listening for conversation

The device is waiting for interaction.

At this moment, press the user button or say the wake word “Xiao Rui, Xiao Rui”, then start speaking.

Listening state

XiaoZhi enters the listening mode and begins capturing the conversation.

After you finish speaking and pause, the system will process the input.In conversation

XiaoZhi is generating and replying to your request.Sleep mode

The device enters low-power mode.

Press the user button once to wake it up, wait until the screen shows Standby, and then you can continue the conversation.

MCP Control of Development Board Peripherals

MCP (Model Context Protocol) is a lightweight implementation adapted for resource-constrained embedded devices, created by simplifying the Model Context Protocol to its essential components.

Core Objective

Enable edge microcontrollers or small SoCs to act directly as an MCP Server, exposing hardware capabilities such as:

● GPIO control

● Sensor reading

● Motor driving

● LED control

● IoT data reporting

These capabilities can then be remotely invoked by an LLM through a standardized protocol, enabling natural language control of the physical world.

Currently Supported Peripheral Controls

● LED indicator

● Screen brightness

● Volume level

How to Use

1. Press the first user button on the development board to start a conversation.

2. XiaoZhi enters listening mode.

3. Speak commands such as:

● “Turn on the light”

● “Turn off the light”

● “Increase the screen brightness”

● “Increase the volume”

These commands will trigger MCP-based control of the board’s peripherals.

XiaoZhi MCP LED Control Principle

1. MCP Initialization

Send the IoT descriptor during MCP initialization.

2. Register IoT device

3. LED control tool

Expose the LED control function as a tool that can be called through MCP.4. Driver mapping

Each control method corresponds to a specific hardware driver implementation.

1. Introduction

This project focuses on developing a multifunctional motor driver based on the Renesas VisionBoard MCU. The core functionality enables communication between external devices and the driver through the RS-485 serial protocol, allowing control commands such as motor start and stop.

During the development process, several additional hardware circuits were temporarily added to enrich the functionality, including general-purpose isolated input/output circuits and stepper motor drivers. At present, the power module, brushless motor driver module, and RS-485 communication module have completed functional verification.

This project was mainly a hands-on learning process. During development, I explored a new PCB design tool to complete circuit layout and routing (although the layout still needs further optimization). I also learned the basics of the RT-Thread operating system and gained initial experience working with the Renesas VisionBoard chip and its development tools.

Since this is my first time participating in such a project and the whole process was mainly for personal learning and experimentation, the current design may appear somewhat messy. I appreciate your understanding.

Additionally, some modules were added simply to try out different ideas. In the future, I plan to redesign the PCB and reorganize the hardware modules. In this version, the functions were implemented module by module without full system integration.

Later in the project, I also designed an additional BTB expansion board. Initially, I expected that the Raspberry Pi PWM interface could provide three PWM outputs to achieve complementary PWM signals for six-step commutation of the BLDC motor. However, due to limited familiarity with the tools and insufficient available IO resources, I created a temporary expansion board that includes LED digital displays and an OLED module while exposing the BTB IO pins via headers.

2. Design Architecture

2.1 Motor Module

2.1.1 Motor Selection

Two types of motors were selected to cover different application scenarios:

● Brushless DC motor (BLDC): suitable for continuous rotation applications

● Stepper motor: suitable for high-precision position control

2.1.2 Brushless Motor Control

The BLDC motor drive is implemented using dedicated hardware circuits.

Core driver

The EG2123A BLDC driver IC (U29) is used to generate phase drive signals for the motor.

Current monitoring

INA240 bidirectional current sensing amplifiers (U25, U26) are used to monitor the phase current of the brushless motor in real time.

Power stage

A power MOSFET stage (Q4, Q5, etc.) amplifies the drive signals before they are connected to the motor through connector J8.

The waveform of the driver signal was measured during testing. The motor can rotate, but there may still be some issues requiring further debugging and testing.

2.1.3 Stepper Motor Control

Stepper motor control is implemented using the A4988 microstepping driver.

Driver IC

Two A4988 stepper motor driver chips (U1, U2) are used, supporting DIR (direction) and STEP (pulse) control signals.

Current monitoring

INA219 current sensors (U3, U4) are used to monitor the working current of the stepper motors.

Interface

The motors are connected through connectors J10 and J13 to transmit control signals.

2.2 Main Control Board and Button Module

2.2.1 Main Controller Selection

The Renesas VisionBoard MCU is used as the main controller, responsible for:

● Parsing RS-485 communication commands

● Generating motor control signals

● Managing the logical scheduling of different functional modules

2.2.2 Communication Module (RS-485 Serial Communication)

The design adopts an isolated and independently powered RS-485 communication architecture.

Signal isolation

The TJA121M31 chip (U13) is used to isolate the control signals between the MCU and the RS-485 bus.

Bus transceiver

The GM485E transceiver (U16) converts MCU UART signals to differential RS-485 signals.

Power isolation

A B0505S-1WR3 isolated power module (U14) provides an independent power supply for the RS-485 circuit to prevent ground interference.

External interface

External RS-485 devices are connected via connector J15.

During testing, the communication waveform was captured successfully, indicating functional operation. However, the waveform amplitude did not reach the expected 3.3V peak and may require further adjustment.

2.2.3 General-Purpose Isolated Input/Output Module

Signal isolation is implemented using EL357N optocouplers.

Isolated input

External signals pass through a 2.2k current-limiting resistor and a 1N4148W protection diode before entering optocouplers (U18, U19). The signals are then transmitted to the MCU input pins (MCU_IN1–IN4 via interface U40).

Isolated output

MCU output signals (MCU_OUT1–OUT2) are transmitted through optocouplers (U20, U21) before reaching external interfaces (U42, U7). Pull-up resistors (4.7kΩ) are used to enhance driving capability.

2.3 Power Module

A multi-stage voltage regulation architecture was designed to power different modules.

+12V input

The +12V input is regulated through chip U54 to supply high-power circuits such as the BLDC motor driver.

12V to 5V conversion

The U35 converter steps down 12V to 5V, which powers the RS-485 communication module and BLDC driver circuits.

5V to 3.3V conversion

An RT90L3–33GB LDO (U36) converts 5V to 3.3V to power the MCU, optocouplers, and current sensing chips.

Filtering

Each power branch uses 10 µF and 0.1 µF capacitors to provide voltage stabilization and filtering.

Power ripple measurements indicate relatively stable performance, although further optimization of resistor and capacitor values may improve the design.

Additional oscilloscope captures show the voltage waveforms after step-down conversion.

3. Code Implementation

3.1 Source Code

The project shares the RT-Thread adaptation code for the Renesas VisionBoard.

The code includes modules such as:

● RS-485 driver

● BLDC motor driver

● Power monitoring

● System initialization and command parsing logic

Configuration is implemented using Renesas FSP (rasc) configuration tools, along with application code.

PWM parameters such as dead time, waveform mode, and switching frequency should be adjusted according to actual hardware requirements.

For reference, developers can consult the RT-Thread guide:

● RA8D1 Vision Board Development Practice Guide

● IIC Practice on RA8D1 Vision Board

● ADC Practice on Vision Board

● PWM Module Practice on Vision Board

RT-Thread community resources are available at:

https://club.rt-thread.org

motor_ctrl.c

#include "FOC.h" #include "rtdevice.h"

#define MOTOR_THREAD_STACK_SIZE    2048

#define MOTOR_THREAD_PRIORITY      8

#define MOTOR_THREAD_TIMESLICE     10

#define MAX_TARGET_SPEED_RPM       2400.0f

#define SPEED_RAMP_RATE            100.0f

static float current_target_speed = 0.0f;

static rt_bool_t motor_enabled = RT_FALSE;

static rt_uint16_t motor_pole_pairs = 7;

static float rpm_to_radps(float rpm) {

      return rpm  2.0f  PI / 60.0f;

}

static float radps_to_rpm(float radps) {

     return radps  60.0f / (2.0f  PI); 

}

static float speed_ramp(float target_speed, float current_speed, float dt) {

      float max_delta = SPEED_RAMP_RATE * dt;

       if (target_speed > current_speed) {

                 current_speed += max_delta; 

                    if (current_speed > target_speed) current_speed = target_speed; 

        } else {  

                  current_speed -= max_delta; 

                  if (current_speed < target_speed) current_speed = target_speed; 

        } return current_speed; 

}

static void motor_thread_entry(void *parameter) {

   static rt_tick_t last_time = 0; 

   static float current_speed_rpm = 0.0f;

foc_init(); foc_start(); motor_enabled = RT_TRUE;

while (1) { rt_tick_t current_time = rt_tick_get(); float dt = (current_time - last_time) * 0.001f; if (dt <= 0) dt = 0.001f;

if (motor_enabled) {
    float target_velocity = get_target_velocity();
    float target_speed_rpm = radps_to_rpm(target_velocity);
    
    target_speed_rpm = target_speed_rpm > MAX_TARGET_SPEED_RPM ? MAX_TARGET_SPEED_RPM : target_speed_rpm;
    target_speed_rpm = target_speed_rpm < -MAX_TARGET_SPEED_RPM ? -MAX_TARGET_SPEED_RPM : target_speed_rpm;
    
    current_speed_rpm = speed_ramp(target_speed_rpm, current_speed_rpm, dt);
    
    float target_mech_radps = rpm_to_radps(current_speed_rpm);
    FOC_M0_SET_VEL(target_mech_radps);
    
    foc_loop();
    
    if (current_time - last_time > RT_TICK_PER_SECOND) {
        float actual_vel = getVelocity();
        float actual_rpm = radps_to_rpm(actual_vel);
        rt_kprintf("Motor: Target=%.1fRPM, Actual=%.1fRPM\n", current_speed_rpm, actual_rpm);
        last_time = current_time;
    }
} else {
    current_speed_rpm = 0;
    FOC_M0_SET_VEL(0);
}

rt_thread_mdelay(1);
last_time = current_time;

}

}

void motor_start(void) {

     rt_thread_t tid = rt_thread_create("motor", motor_thread_entry, RT_NULL,                                                                                                          MOTOR_THREAD_STACK_SIZE, MOTOR_THREAD_PRIORITY,                                                                          MOTOR_THREAD_TIMESLICE); 

     if (tid) { rt_thread_startup(tid); 

    }

}

void motor_enable(rt_bool_t enable) {

    motor_enabled = enable; 

    if (!enable) {

          set_target_velocity(0); 

     } 

}

rs485.c

#include "bsp_rs485.h"
#include "hal_data.h"

#define RS485_RX_BUF_SIZE 100
#define RS485_SWITCH_DELAY 10

static uint8_t rs485_rx_data[RS485_RX_BUF_SIZE];
static volatile uint16_t rs485_rx_datalen;
static volatile bool rs485_rx_complete;
static volatile bool rs485_tx_complete;

fsp_err_t RS485_Init(void)
{
    fsp_err_t err = FSP_SUCCESS;
    err = R_SCI_B_UART_Open(&g_uart2_rs485_ctrl, &g_uart2_rs485_cfg);
    if(FSP_SUCCESS != err) return err;
    err = R_SCI_B_UART_Read(&g_uart2_rs485_ctrl, rs485_rx_data, RS485_RX_BUF_SIZE);
    return err;
}

void RS485_Print(uint8_t *str, uint32_t strlen)
{
    RS485_TX_EN;
    R_BSP_SoftwareDelay(RS485_SWITCH_DELAY, BSP_DELAY_UNITS_MILLISECONDS);
    rs485_tx_complete = false;
    R_SCI_B_UART_Write(&g_uart2_rs485_ctrl, str, strlen);
    while(false == rs485_tx_complete);
    R_BSP_SoftwareDelay(RS485_SWITCH_DELAY, BSP_DELAY_UNITS_MILLISECONDS);
    RS485_RX_EN;
}

uint16_t RS485_GetRxData(uint8_t *buf, uint16_t len)
{
    uint16_t copy_len = (rs485_rx_datalen < len) ? rs485_rx_datalen : len;
    R_BSP_InterruptsDisable();
    memcpy(buf, rs485_rx_data, copy_len);
    rs485_rx_datalen = 0;
    rs485_rx_complete = false;
    R_BSP_InterruptsEnable();
    R_SCI_B_UART_Read(&g_uart2_rs485_ctrl, rs485_rx_data, RS485_RX_BUF_SIZE);
    return copy_len;
}

bool RS485_GetRxComplete(void)
{
    return rs485_rx_complete;
}

void rs485_uart2_callback(uart_callback_args_t *p_args)
{
    switch(p_args->event)
    {
        case UART_EVENT_RX_COMPLETE:
            rs485_rx_complete = true;
            break;
        case UART_EVENT_RX_CHAR:
            R_BSP_InterruptsDisable();
            if(rs485_rx_datalen < RS485_RX_BUF_SIZE)
            {
                rs485_rx_data[rs485_rx_datalen] = (uint8_t)p_args->data;
                rs485_rx_datalen++;
            }
            R_BSP_InterruptsEnable();
            break;
        case UART_EVENT_TX_COMPLETE:
            rs485_tx_complete = true;
            break;
        default:
            break;
    }
}

Have questions while using the RT-Thread RTOS? Join our global community on Slack or Discord to connect directly with official experts and developers.

Slack: https://rtthreadhq.slack.com/archives/C0AHNBQLW5P

Discord: https://discord.com/channels/1444976234378428520/1444976235435524180

This project is an award-winning work from the RT-Thread Embedded Competition. It builds a multifunctional smart door lock control system based on NXP’s MCXA156 series microcontroller.

Currently, multiple products from NXP Semiconductors have completed adaptation with RT-Thread. Recently, an important member of the MCX A series, FRDM-MCXA346, has also completed adaptation. With the collaboration of community developers, the eBook FRDM-MCX A346 Development Practice Guide has been published (see the contributor list and development board details at the end of this article ↓).

1. Project Overview

This project builds a multifunctional smart door lock control system based on the MCXA156 series microcontroller. It integrates three unlocking methods: password, fingerprint, and RFID card. The system features a local OLED display and audio-visual feedback mechanisms. EEPROM is used to achieve persistent key storage, forming an embedded solution that balances security and convenience.

The system supports local key modification, real-time unlocking status feedback, and error alarms. It can be widely applied to access control scenarios in homes, offices, and other environments.

Design Concept Proposal

System operation flowchart

Core Features

Multi-mode unlocking:

● Supports three unlocking methods: 6-digit numeric password, FPM383C fingerprint recognition, and RC522 RFID card, meeting the needs of different usage scenarios.

Key management:

● Uses 24CXX series EEPROM for persistent storage of unlocking keys. Supports local key modification via buttons, with automatic synchronization to storage after changes.

Status visualization:

● With the SSD1306 OLED display, the system shows the current interface status, number of entered password digits, unlocking results, and other real-time information.

Audio-visual feedback:

● When unlocking succeeds, the LED lights up with an icon prompt. When the password is incorrect, the buzzer alarms and the icon flashes, enhancing user interaction experience.

Concurrent task handling:

● Based on bare-metal programming, the system enables concurrent execution of sensor scanning, button processing, display updates, and alarm control, ensuring real-time responsiveness.This article will further break down the system’s hardware selection, software architecture, core logic implementation, and key development details, providing practical reference for embedded access control system development.

2. Hardware Selection and Connections

Core Controller: FRDM-MCXA156

The FRDM-MCXA156 microcontroller is selected as the core control unit. Its advantages are as follows:

Performance:

Equipped with an ARM Cortex-M series core, it provides efficient instruction execution capability to meet the requirements of multi-peripheral concurrent control and algorithm processing. It also features rich interfaces such as I2C, SPI, UART, PWM, and GPIO, allowing direct connection of all functional modules without the need for additional expansion boards.

Module Functions

Communication Protocol Flowchart

Hardware Connection Details

3. Software Architecture Design

The software of this project is developed based on the official demo of RT-Thread 5.2.1. The system functions are divided into multiple independent modules, and global variables are used to enable data interaction between modules, ensuring code maintainability and scalability.

Overall Architecture

The system software consists of five core modules. Each module works independently while collaborating with others:

Peripheral Driver Module:

Responsible for initialization and low-level operations of hardware peripherals (such as UART, I2C, SPI, PWM, GPIO, etc.).Core Control Module:

Implements unlocking logic, key verification, and status management.Input Processing Module:

Handles button input, fingerprint recognition results, and RFID card data reading.Display Control Module:

Manages OLED screen interface refresh and information display.Feedback Module:

Controls LED and buzzer to provide status feedback for successful unlocking or error alarms.

Workflow Details

System Initialization Phase

After startup, the system sequentially completes:

● Interrupt priority configuration

● Serial port initialization

● Initialization of all peripherals (fingerprint module, RC522, OLED, buttons, EEPROM, PWM)

It then checks whether the EEPROM is functioning properly. If an abnormal condition is detected, the LED flashes as an indication. The pre-stored 6-digit unlocking key is read from EEPROM and stored in the global variable open_lock_key.

Main Loop Tasks (Executed Infinitely)

Sensor scanning:

Continuously calls fpm383c_Scan() (fingerprint scanning) and RC522_Scan() (RFID scanning) to wait for recognition results.

Uses key_Scan() to detect button input and process number input, password confirmation, deletion, interface switching, and other operations.

After entering a 6-digit password, it is compared with the stored unlocking key:

● If matched, unlocking is triggered.

● If not matched, the alarm is activated.

Based on the unlocking result or error status, the system controls the LED and buzzer accordingly and updates the OLED display simultaneously.

Inter-thread communication:

Global variables such as open_door_type (unlock status), open_door_alert (alarm status), and interface_num (interface identifier) are used to enable data interaction between modules. This simplifies communication logic while ensuring real-time system responsiveness.

4. Core Module Implementation

EEPROM Key Storage and Reading

A 24CXX EEPROM is used to achieve persistent key storage, ensuring that the key is not lost after power-off.

Initialization:

Call AT24CXX_Init() to initialize the I2C bus and EEPROM device.

Use AT24CXX_Check() to verify whether the device is functioning properly.

Key Reading:

When the system starts, it reads EEPROM addresses 0–5 in a loop and stores the data into the open_lock_key array.

Key Modification:

In the modification interface (interface_num = 2), after confirmation, the temporary key open_lock_key_temp is written to the corresponding EEPROM addresses and then re-read to synchronize with open_lock_key.

// 初始化EEPROM并读取密钥
AT24CXX_Init();
while(AT24CXX_Check()){
    // EEPROM异常，LED闪烁提示
    LED_ON = !LED_ON;
    Delay1_ms(100);
}
for(i=0;i<6;i++){
    open_lock_key[i] = AT24CXX_ReadOneByte(i); // 读取密钥
}
// 修改密钥并写入EEPROM
for(i=0;i<6;i++){
    AT24CXX_WriteOneByte(i, open_lock_key_temp[i]); // 写入新密钥
}

Unlocking and Alarm Feedback

Unlock Logic:

When key verification succeeds (or fingerprint/RFID recognition is successful), open_door_type is set to 1. The LED lights up, and the OLED displays the unlock success icon (BMP4). After 2 seconds, the system automatically locks again (LED turns off and the icon returns to default).

Alarm Logic:

When the key does not match or an operation error occurs, open_door_alert is set to 1. The buzzer emits an alarm sound (time2_Pwm_Alert), and the OLED error icon (BMP2) flashes four times before returning to the default state.

// 开锁反馈
if(open_door_type){
    LED_ON;
    OLED_DrawBMP(12,5,28,7,BMP4); // 显示开锁成功图标
    Delay1_ms(2000);
    LED_OFF;
    OLED_DrawBMP(12,5,28,7,BMP3); // 恢复默认图标
    open_door_type = 0;
}
// 错误报警反馈
if(open_door_alert){
    for(i=0;i<4;i++){
        OLED_DrawBMP(12,5,28,7,BMP2); // 显示错误图标
        time2_Pwm_Alert(150,1000); // 蜂鸣器报警
        OLED_DrawBMP(12,5,28,7,BMP3); // 恢复默认图标
        rt_thread_mdelay(100);
    }
    open_door_alert = 0;
}

OLED Interface Display

The OLED screen is used to display the system status in real time, including the following:

Interface indicator:

Displays the current interface (default interface / modification interface), refreshed via interface_Oled_Flushed().

Password input length:

Indicates the number of entered password digits using the BMP2 bitmap.Status icons:

Default state (BMP3), error state (BMP2), and unlock success state (BMP4).Key value display:

Shows the numeric value of the currently pressed button in real time.

// 刷新界面标识
voidinterface_Oled_Flushed(){
    OLED_DrawBMP(72,5,86,7,BMP6);
    OLED_ShowNum(72,5,interface_num,1,16); // 显示当前界面编号
}
// 显示按键值
OLED_ShowNum(100,5,key_vel,a,16);

5. Multi-Mode Unlocking Extension

The system reserves expansion interfaces for fingerprint recognition (FPM383C) and RFID card recognition (RC522). The core implementation approach is as follows:

Fingerprint recognition:

Continuously scans fingerprints via fpm383c_Scan(). Once recognition succeeds and a match result is returned, open_door_type is set directly to trigger unlocking.

RFID recognition:

Reads the RFID card ID through RC522_Scan(), compares it with the pre-stored valid ID, and triggers unlocking if matched.

At present, module initialization and scanning function calls have been completed in the code. Only the storage and comparison logic for valid fingerprint/RFID data needs to be expanded to fully enable multi-mode unlocking.

A small 3D-printed casing was also made to dress it up.

6. Project Optimization and Improvement Directions

Sensor stability:

The RC522 RFID module may experience read failures in strong interference environments. Adding data validation and multiple scanning mechanisms can improve stability.Password security:

Currently, the key is stored in plaintext in the EEPROM. An AES encryption algorithm can be added to encrypt the key before storage to enhance security.Feature expansion:

Add remote unlocking (via a SIM900A GSM module), unlock log storage, and low-power mode functionality.User interaction:

Optimize the OLED interface by adding hidden password input (e.g., displaying asterisks) and Chinese prompts to improve user experience.Exception handling:

Add dedicated feedback mechanisms for fingerprint recognition failures and RFID reading failures to distinguish different error types.

7. Project Source Code

Baidu Netdisk address: Shared file — frdm-mcxa156.zip

Link: https://pan.baidu.com/s/1SDYqULii2I0b2lkJM9ecrg?pwd=8888

Extraction code: 8888Code repository: https://gitee.com/yang-xianyi/exclusive

Developers are welcome to provide valuable feedback and optimization suggestions to jointly improve the system.

Contributor List of FRDM-MCX A346 Development Practice Guide

The RT-Thread community, together with NXP Semiconductors, jointly launched the FRDM-MCXA346 development board evaluation activity. The FRDM-MCX A346 Development Practice Guide provides detailed listings of each content section and its contributors. Sincere thanks to all contributors for their support and contributions!

Introduction to the FRDM-MCXA346 Development Board

The FRDM-MCXA346 is a compact and scalable development board that enables rapid prototyping based on the FRDM-MCXA346 microcontroller unit (MCU).

It provides industry-standard interfaces for easy access to the MCU’s I/O, and is equipped with an integrated open-standard serial interface, external flash memory, and an onboard MCU-Link debugger.

1.1 Implemented Functions

This project is based on the NXP FRDM-MCXA156 development board and implements a standard USB HID gamepad device. The main functions include:

● 16 digital buttons: Implemented using a 4×4 matrix keypad, consisting of 14 buttons plus 2 joystick buttons

● Dual joystick input: Left and right analog joysticks, each providing X/Y axis data

● USB HID protocol: Standard HID Gamepad device, plug-and-play without driver installation

● Real-time response: 10 ms scanning interval with low-latency input

1.2 Technical Features

2 RT-Thread Usage Overview

2.1 Kernel Configuration

#define RT_THREAD_PRIORITY_MAX  32      // 32 priority levels
#define RT_TICK_PER_SECOND      1000    // 1 ms system tick
#define RT_USING_TIMER_SOFT             // Software timer
#define RT_USING_SEMAPHORE              // Semaphore
#define RT_USING_MUTEX                  // Mutex
#define RT_USING_MAILBOX                // Mailbox

2.2 Used Components

2.3 Thread Design

2.4 Automatic Initialization

The project uses the RT-Thread automatic initialization mechanism:

INIT_BOARD_EXPORT(rt_hw_adc_init);      // ADC driver initialization
INIT_DEVICE_EXPORT(key_init);           // Matrix keypad initialization
INIT_DEVICE_EXPORT(joystick_init);      // Joystick initialization
INIT_COMPONENT_EXPORT(cherryusb_init);  // USB initialization
INIT_APP_EXPORT(gamepad_app_start);     // Application startup

3 Hardware Architecture

3.1 System Block Diagram

┌─────────────────────────────────────────────────────────────┐
│                      FRDM-MCXA156                           │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐ │
│  │  4x4 Matrix │  │ Dual Joystick│  │     USB Device      │ │
│  │   Keypad    │  │  (with BTN)  │  │    (Full Speed)     │ │
│  └──────┬──────┘  └──────┬──────┘  └──────────┬──────────┘ │
│         │                │                     │            │
│    GPIO P2/P3       ADC0 CH0/1/8/13           USB0         │
│         │                │                     │            │
│  ┌──────┴────────────────┴─────────────────────┴──────────┐│
│  │                    MCXA156 MCU                          ││
│  │              (Cortex-M33 @ 96MHz)                       ││
│  └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘

3.2 Pin Assignment

3.2.1 Matrix Keypad (4×4)

3.2.2 Joystick ADC

3.2.3 Joystick Buttons

4 Software Architecture Description

4.1 Software Architecture

┌─────────────────────────────────────────────────────────────┐
│                  Application Layer                          │
│  ┌─────────────────────────────────────────────────────────┐│
│  │                   gamepad_app.c                         ││
│  │   (Integrates input devices and maps to USB HID reports) ││
│  └─────────────────────────────────────────────────────────┘│
├─────────────────────────────────────────────────────────────┤
│                  Function Layer                             │
│  ┌───────────────┐  ┌───────────────┐  ┌─────────────────┐ │
│  │  key_app.c    │  │ joystick_app.c│  │   usb_app.c     │ │
│  │ (Keypad)      │  │ (Dual Joystick)│ │  (USB HID)      │ │
│  └───────────────┘  └───────────────┘  └─────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│                  Driver Layer                               │
│  ┌───────────────┐  ┌───────────────┐  ┌─────────────────┐ │
│  │   drv_pin.c   │  │   drv_adc.c   │  │   CherryUSB     │ │
│  │   (GPIO)      │  │   (ADC)       │  │   (USB Stack)   │ │
│  └───────────────┘  └───────────────┘  └─────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│                  RT-Thread Kernel                           │
│     (Thread scheduling, IPC, device framework, auto init)   │
├─────────────────────────────────────────────────────────────┤
│                  Hardware Abstraction Layer                 │
│                NXP MCX SDK / CMSIS                           │
└─────────────────────────────────────────────────────────────┘

4.2 Data Flow

Matrix Keypad ──► key_read() ───────────────────────────────┐
                                                            │
Left Joystick ADC ──► joystick_left_read() ─► apply_deadzone() ─┤
                                                            ├──► gamepad_thread
Right Joystick ADC ─► joystick_right_read() ─► apply_deadzone() ─┤     │
                                                            │     ▼
Joystick Buttons ──► rt_pin_read() ─────────────────────────┘  scale_axis()
                                                                   │
                                                                   ▼
                                                           USB HID Report
                                                                   │
                                                                   ▼
                                                     hid_gamepad_send_report()
                                                                   │
                                                                   ▼
                                                               USB Host (PC)

This strictly follows the Perception → Cognition → Control system design pattern.

5 Software Module Description

5.1 key_app Module (Matrix Keypad)

Files: applications/key_app.c, applications/key_app.h

Function: 4×4 matrix keypad scanning

Core function:

rt_uint8_t key_read(void);  // Returns 0–15 for key index, 0xFF if no key is pressed

Scanning principle:

● Drive one column low at a time

● Read all row pin states

● A detected low level indicates the key at that intersection is pressed

5.2 joystick_app Module (Joystick)

Files: applications/joystick_app.c, applications/joystick_app.h

Function: Dual joystick ADC reading and button detection

Data structure:

typedef struct {
    int16_t x;      // X axis: -32768 ~ 32767
    int16_t y;      // Y axis: -32768 ~ 32767
    bool btn;       // Button: true = pressed
} joystick_data_t;

Core functions:

rt_err_t joystick_left_read(joystick_data_t *data);
rt_err_t joystick_right_read(joystick_data_t *data);

5.3 usb_app Module (USB HID)

Files: applications/usb_app.c, applications/usb_app.h

Function: USB HID gamepad device implementation

HID report structure (9 bytes):

typedef struct __attribute__((packed)) {
    uint16_t buttons;      // 16 buttons
    int8_t left_x;         // Left joystick X (-127 ~ 127)
    int8_t left_y;         // Left joystick Y
    int8_t right_x;        // Right joystick X
    int8_t right_y;        // Right joystick Y
    uint8_t left_trigger;  // Left trigger (0–255)
    uint8_t right_trigger; // Right trigger (0–255)
    uint8_t hat;           // D-pad (0–8)
} usb_gamepad_report_t;

USB descriptor configuration:

● VID: 0x045E (Microsoft)

● PID: 0x02FF (Generic Gamepad)

● Endpoint: 0x81 (IN), interrupt transfer

● Polling interval: 1 ms

5.4 gamepad_app Module (Application Layer)

Files: applications/gamepad_app.c, applications/gamepad_app.h

Function: Integrates all input devices and maps them to USB HID reports

Core features:

● Dead zone processing: Eliminates joystick center jitter

● Change detection: Reports are sent only when state changes

● Retry mechanism: Reports are cached and resent when USB is busy

● Button mapping

5.5 drv_adc Module (ADC Driver)

File: Libraries/drivers/drv_adc.c

Function: LPADC driver supporting multi-channel ADC reading

Key modifications:

● Fixed multi-channel initialization overwrite issue

● Added timeout protection to prevent system deadlock

● Optimized command slot allocation (4 channels use 4 independent command slots)

6 Demonstration Results

6.1 Startup Log

KEY OK
joystick: init OK
[USB] Initializing HID Gamepad...
[USB] HID Gamepad initialized successfully
[USB] VID:0x045E PID:0x02FF
[GAMEPAD] Started (interval: 10ms)
System Start
[GAMEPAD] Thread started
[USB] Device Configured - Gamepad Ready!

6.2 Windows Testing

1. After connecting the device, it appears as “USB Gamepad HID” in Device Manager

2. Use joy.cpl (Game Controllers) to test all buttons and joysticks

3. Use the online platform https://gamepad-tester.com/ to test all buttons and joysticks

6.3 Function Demonstration

● All 16 buttons respond correctly

● Left and right joystick X/Y axes function correctly

● Joystick buttons function correctly

● Low-latency response

7 Code Repository

Git repository:

https://github.com/Rolmoland/Project_GamepadMi

Main files:

applications/
├── main.c              # Entry point
├── gamepad_app.c/h     # Gamepad application layer
├── key_app.c/h         # Matrix keypad module
├── joystick_app.c/h    # Joystick module
└── usb_app.c/h         # USB HID module
 
board/
├── MCUX_Config/board/pin_mux.c  # Pin configuration
└── ports/cherryusb/             # CherryUSB adaptation
 
Libraries/drivers/
└── drv_adc.c           # ADC driver (modified)

8 Summary

This project successfully implements a USB HID gamepad based on RT-Thread, with the following characteristics:

● Modular design: Clear separation of hardware, function, and application layers for easy maintenance

● Good real-time performance: Based on the RT-Thread real-time kernel with a 10 ms scan cycle

● Strong compatibility: Standard HID protocol, driver-free on Windows, Linux, and macOS

● Extensible: Easy to add features such as vibration feedback and LED indicators

Package URL:

https://packages.rt-thread.org/detail.html?package=vector

Original Article:

https://club.rt-thread.org/ask/article/165b038347c75637.html

1. A New Tool for Embedded Development: RT-Thread Vector Package

In embedded system development, the choice of data structures directly affects application performance, memory utilization, and code maintainability.

Traditional static arrays are simple and intuitive, but they reveal many limitations when dealing with dynamically changing data sizes:Fixed-size limitation

Static arrays require their size to be defined at compile time, making them inflexible when data volume changes.

If the data exceeds expectations, buffer overflow may occur; if the actual data is far less than the allocated size, precious memory is wasted.Inefficient resizing

If developers implement dynamic arrays manually, they must handle memory allocation, data copying, and deallocation themselves, which increases code complexity and introduces risks such as memory leaks.

Poor reusability

Implementing separate dynamic arrays for different data types leads to code duplication and reduced maintainability.

To solve these problems, we designed the Vector package for RT-Thread — a general-purpose dynamic array container tailored for embedded systems.

It combines the fast access of static arrays with the flexibility of dynamic arrays, providing a complete API for storing and managing any data type.As a third-party module designed for RT-Thread, Vector features efficient memory management (automatic expansion and shrinkage), rich operations (insert, delete, update, search, sort, iterate), and a lightweight design suitable for resource-constrained embedded environments.

2. What Is the Vector Package?

2.1 Definition

The RT-Thread Vector package is a general-purpose dynamic array container designed specifically for embedded systems.

It provides a flexible and efficient way to store and manage different types of data elements.By using a void* pointer combined with an element-size parameter, Vector achieves type-independent container functionality, allowing a single container to store integers, floats, structures, or custom data types seamlessly.

Essentially, Vector is a contiguous memory block that automatically resizes, combining:

● O(1) random access of arrays

● Dynamic sizing of linked lists

When the number of elements approaches the capacity limit, the container automatically expands.

When elements are removed significantly, it shrinks to free unused memory — avoiding both waste and overflow risks.2.2 Design Goals

The Vector package follows four core design principles:

2.2.1 Generality

● Type-agnostic design using void* and item size

● Unified API

● Customizable initial capacity

2.2.2 Efficiency

● O(1) random access

● Smart memory resizing (double/half)

● O(n log n) merge sort implementation

● Batch operations for reduced overhead

2.2.3 Lightweight

● Minimal code size and runtime footprint

● Zero external dependencies

● Easy portability to other embedded systems

2.2.4 Ease of Use

● Intuitive API naming

● Clear return values for error handling

● Complete documentation and examples

2.3 Comparison with Traditional Arrays

Compared to static arrays, Vector offers significant advantages in flexibility, memory efficiency, and maintainability (omitted table in original text).

2.4 Position in the RT-Thread Ecosystem

As a third-party module for RT-Thread, Vector plays an important role:

● Memory integration: Built on rt_malloc/rt_free for full kernel compatibility

● Design philosophy alignment: Lightweight, efficient, embedded-friendly

● Seamless integration: No kernel modification required

● Ecosystem enhancement: Fills the gap of general-purpose dynamic containers

● Extensible architecture: Handle-based design hides implementation details

2.5 API Design and Naming Convention

● All APIs use the vector_ prefix

● Handle-based design: vector_handle_t (void*)

● Consistent parameter ordering

● Clear return values

Example:

vector_handle_t vector_create(const vector_config_t *config);
int vector_push_back(vector_handle_t handle, const void *data);
void *vector_get(vector_handle_t handle, size_t index);
int vector_destroy(vector_handle_t handle);

This design makes Vector easy to use even for beginners.

2.6 Typical Use Cases

2.6.1 Dynamic Data Management

Sensor data, packet processing, task queues, etc.

Nested Vectors can be used to build dynamic 2D data structures without wasting memory.

2.6.2 Generic Data Storage

Configuration systems, device management, logging systems.

2.6.3 High-performance Access

Real-time monitoring, caches, indexes.

2.6.4 Resource-constrained Systems

Cortex-M and low-power MCU applications.

2.6.5 Rapid Development

Reduce manual memory management and data movement code.

3. Core Features

3.1 Smart Memory Management

● Automatic expansion (double capacity)

● Automatic shrink (half capacity, min = 4)

● Manual shrink function

3.2 Flexible Element Operations

● Insert: push_back, push_front, insert

● Remove: pop_back, pop_front, remove

● Access: get, front, back, modify

● Management: clear, destroy, size, capacity

3.3 Batch Operations

Efficient bulk insert/remove using memcpy to reduce overhead.

3.4 Stable Sorting

O(n log n) merge sort with user-defined comparator.

3.5 Easy Iteration

Callback-based iteration with context support.

3.6 Thread Safety

● Safe in single-threaded environments

● Multi-threaded use requires mutex protection

3.7 Lightweight Design

● Small code size

● No external dependencies

● Ideal for embedded systems

4. Implementation Details

4.1 Core Data Structure

typedef struct {
    size_t capacity;
    size_t size;
    size_t item_size;
    void *data;
} vector_ctrl_block_t;

4.2 Handle-based Design

● Improves encapsulation

● Prevents direct manipulation

● Allows future extension

4.3 Memory Management

Expansion

● Double capacity

● Allocate new memory

● Copy old data

● Free old memory

Shrinking

● Halve capacity (min 4)

● Copy and free old buffer

4.4 Algorithms

● Merge sort (stable, O(n log n))

● O(1) random access

● Efficient memory movement

4.5 Callback Mechanism

vector_for_each supports context-aware iteration.

5. Usage and Examples

5.1 Basic Workflow

5.1.1 Create and Initialize

vector_config_t config = {
    .item_size = sizeof(int),
    .capacity = 10
};
vector_handle_t v = vector_create(&config);

5.1.2 Core Operations

vector_push_back(v, &num);
vector_pop_back(v);
vector_sort(v, int_cmp);
vector_for_each(v, print_int, RT_NULL);

5.1.3 Batch Operations

vector_push_back_block(v, nums, count);
vector_remove_block(v, start, length);

5.1.4 Management

vector_shrink(v);
vector_clear(v);
vector_destroy(v);

5.2 Complete Example

(Example code unchanged, omitted here for brevity — same as original)

5.3 Common Issues

Memory allocation failure

● Reduce initial capacity

● Check system memory

Type casting errors

Always cast returned pointers correctly.

Index out of bounds

Always check index before access.

6. Performance and Advantages

6.1 Memory Efficiency

● Automatic resizing reduces waste

● Amortized O(1) insert/delete

6.2 Execution Performance

● O(1) access

● O(n log n) sort

● Optimized bulk operations

6.3 Resource Usage

● Control block: ~24 bytes (32-bit)

● Default capacity: 4

● No extra dependencies

6.4 Thread Safety

● Safe in single-thread

● Use mutex in multi-thread

6.5 Best Practices

● Estimate capacity in advance

● Use batch APIs for large data

● Avoid frequent front insert/remove

7. Summary

The RT-Thread Vector package is a general-purpose dynamic array container designed for embedded systems, featuring:

● Smart memory management

● Rich and efficient APIs

● High-performance algorithms

● Type-independent design

● Lightweight implementation

● Easy-to-use interface

It fills an important gap in the RT-Thread ecosystem, providing a reliable and efficient solution for sensor data processing, packet handling, task management, and more.

The Vector package has already been validated in industrial-grade, 24/7 long-running systems, proving its stability and reliability.

This project is a simple, high-precision, and easily extensible desktop-level temperature control system. It achieves accurate temperature control inside an enclosed chamber and connects to the network via Wi-Fi. A fully featured web-based visualization and parameter-tuning dashboard is provided, forming a complete IoT closed loop.

The entire project makes full use of RT-Thread’s multithreading capabilities, device driver framework, and networking components to deliver a complete hardware–software integrated solution.

Hardware Platform: NXP FRDM-MCXA156

RT-Thread Version: 5.2.1

Core Features:

● Maximum system power consumption: 24 W

● Temperature control range: ambient to 70 °C (the range can be extended by adding a thermoelectric cooler or higher-temperature PTC heaters)

● High-precision temperature regulation

○ Maximum fluctuation: 3 °C

○ Steady-state fluctuation: 1 °C

● Multi-sensor data fusion

● Local OLED display

● Web-based remote monitoring and online parameter tuning

Project Highlights:

Cascade PID with feedforward composite control algorithm, a three-state control state machine, and a TCP–WebSocket–bridged web visualization solution.

2. RT-Thread Usage Overview

RT-Thread serves as the core operating system of the project and provides a solid foundation for all functionalities. Its stable and reliable kernel, rich component ecosystem, and concise APIs significantly improve development efficiency.

Kernel and Scheduler:

Multiple threads are created to handle different tasks, including the main control thread, PID control thread, OLED refresh thread, network service thread, and LED indicator thread. RT-Thread’s preemptive scheduler ensures real-time performance for high-priority tasks such as temperature control.Device Driver Framework:

● Using RT-Thread’s unified device model, multiple hardware peripherals are easily managed:Pin device: Controls LED indicators and relays for heating/cooling mode switching

● ADC device: Reads voltage values from the NTC thermistor to calculate the real-time temperature of the PTC heater

● PWM device: Precisely controls the power output of the PTC heater and cooling fan

● I2C device: Drives the OLED display (based on the u8g2 package) and reads data from the onboard P3T1755 ambient temperature sensor

● Sensor framework: Reads data from the DHT11 and P3T1755 sensors

Network Stack:

The built-in lwIP protocol stack and SAL socket abstraction layer are used to quickly implement a stable TCP server for remote monitoring.WLAN Framework:

Wi-Fi connectivity is implemented conveniently via the rt_wlan_connect interface.

FinSH/MSH Command Line:

Custom get_status and tune commands allow all key parameters to be adjusted dynamically at runtime through the serial console.

Software Packages Used:

● u8g2: Local UI graphics library

● dhtxx: DHT11 temperature and humidity sensor package

● p3t1755: Onboard I2C temperature sensor package

3. Hardware Architecture

The system hardware consists of four main parts: core control, sensors, actuators, and human–machine interface.

Core Controller:

● NXP FRDM-MCXA156 development board

Sensor Modules:

● Internal temperature and humidity: DHT11 sensor, read via the RT-Thread Sensor framework

● PTC surface temperature: NTC thermistor sampled via ADC and calculated using the Steinhart–Hart model, used for inner-loop control and over-temperature protection

● Ambient temperature: Onboard P3T1755 I2C temperature sensor on the development board

Actuator Modules:

● Heating: PTC ceramic heater driven by an LR7843 MOSFET, with power regulated via PWM

● Cooling: 12 V DC fan, also driven by PWM

● Mode switching: A relay switches the PWM output between the MOSFET and the fan, enabling automatic heating/cooling mode selection

Human–Machine Interface:

● Local: SSD1306 OLED display showing system status, current temperature, target temperature, and other key information in real time

● Remote: A visual dashboard accessed via a web browser on a PC or mobile device through Wi-Fi

Hardware Wiring Diagram

4. Software Architecture Description

The core software is built around a three-state state machine in main.c and a cascade PID control algorithm implemented in the pid_entry thread.

Software Module Description

Main Control and State Machine (main.c)

The main function initializes all devices (sensors, PWM, ADC, Wi-Fi) and creates the application threads.

The while (1) loop in main acts as the system’s primary state machine. It periodically reads the internal temperature and compares it with the target temperature and hysteresis band, automatically switching among three states: HEATING, WARMING, and COOLING.

During state transitions, the relay is controlled via STATE_PIN to route the PWM signal to the appropriate actuator (PTC heater or fan), and the PID integral term is reset to prevent abrupt changes.

Core Control Algorithm (pid_entry thread)

This independent thread runs at a higher frequency (CONTROL_PERIOD_MS) and is responsible for the core temperature control algorithm.

Cascade PID + Feedforward Control (Heating/Warming Modes):

● Outer-loop PID (pid_box):

Calculates the desired PTC target temperature (ptc_target_temp) based on the difference between the internal temperature and the target temperature. This allows the heating rate to adapt dynamically according to how far the system is from the target.

● Inner-loop PID (pid_ptc):

Computes the PWM adjustment based on the difference between the actual PTC temperature and the ptc_target_temp from the outer loop, enabling fast response to PTC temperature fluctuations and more stable heat output.

● Feedforward Control:

A mapping table (ff_table) is established between ptc_target_temp and a base PWM value. The PID output is applied as a fine adjustment on top of this base value, significantly accelerating convergence and reducing the risk of PID integral windup.

PI Control (Cooling Mode):

When switched to cooling mode, the algorithm uses a simple PI controller (pid_cool) to directly control the fan speed based on the difference between the internal temperature and the target temperature.

Over-Temperature Protection:

The algorithm continuously monitors the PTC temperature. Once it exceeds the safety threshold (PTC_MAX_SAFE_TEMP), the PWM output is immediately set to zero to ensure system safety.

Remote Control Service (remote.c)

The remote_server_thread_entry thread creates a TCP server listening on port 5000.

The server supports two types of text commands:

● get_status:

● Packages all key real-time system variables (temperatures, humidity, PID parameters, control state, PWM duty cycle, etc.) into a JSON string and returns it.tune …:

Passes the received parameters directly to the tune() function in main.c, enabling runtime modification of all key parameters, including target temperature, PID gains, and feedforward tables.

OLED Display (screen.c)

The screen_on thread drives the OLED display.

The UI clearly shows the current operating mode (HEATING / COOLING / WARMING), four temperature values (current, target, ambient, and PTC temperature), and an intuitive temperature difference indicator bar.

5. Demonstration

Local OLED Display

The OLED displays key system data in real time.

Remote Web Dashboard

A real-time monitoring dashboard accessed via a browser, including gauges, status indicators, and an online parameter tuning section.

Temperature History Curve

Historical temperature plots allow intuitive analysis of system response speed, overshoot, and steady-state error (candlestick charts can provide even more information and are visually interesting).

MSH Command-Line Debugging

By connecting via the serial port, system status can be queried using get_status, and parameters can be modified using the tune command.

6. Future Improvements

Hardware

Replace the DHT11 with a better sensor (such as the DHT22). The DHT11 has limited accuracy and response speed. Due to the lack of alternative sensors on hand, it is used temporarily.

Functionality

Allow users to configure a time-based temperature profile via the web interface (e.g., maintain 60 °C for 30 minutes, then increase to 70 °C for 1 hour), enabling the temperature chamber to support more complex use cases.

Parameter Optimization

The current parameters still have significant room for improvement. Since temperature changes slowly, experimentally determining optimal parameters is time-consuming. Model-based simulation is currently being explored to find optimal parameters more efficiently.

With the rapid development of high-performance embedded chips, artificial intelligence, and visual neural networks, intelligent detection technologies have been widely applied in fields such as smart security, intelligent healthcare, autonomous driving, and industrial inspection.

This project mainly relies on the FH8626V300L NNA module, using the humanoid detection model provided by the SDK to implement human detection. Combined with a 2-axis pan-tilt gimbal, the system further realizes humanoid tracking functionality.

2. Hardware Usage

● Dual-camera CV2005 used as binocular visual input

● PWM6 and PWM7 used to drive the pan-tilt servo motors

● Ethernet connection used for network access and RTSP video streaming

3. Hardware Design

The FH8626V300L demo board exposes PWM interfaces, which are selected via jumper caps. The schematic is shown below.

In this design, the jumper caps are removed, and the servo PWM control pins are directly connected to pin 2 of JP18 and JP20, which are connected to the chip.

The 2-axis pan-tilt gimbal used in this project adopts LD-1501MG PWM servos.

Since the servos require 6–7.4V power supply, an additional independent power module is added to power the servos separately.

4. Development Environment

The FH8626V300 SDK must be developed under a Linux environment.

For convenience, a virtual machine is installed on Windows, combined with Samba and SSH, enabling development operations directly from Windows.

Installation of the cross-compilation toolchain, SDK compilation, and usage can be completed quickly by following the official Fullhan SDK documentation.

This project is developed based on the media_demo example provided in the SDK. Configuration follows the manual, with one difference: firmware is loaded via SD card. The commands are as follows:

fatload mmc 0 10000000 media_demo.bin
go 10000000

Apart from the loading method, all other steps are consistent with the official documentation.

5. Software Design

1) PWM Multiplexing

Ensure that the kernel PWM device driver is enabled.

In the sdk/rt-thread directory, run make menuconfig and enable the corresponding PWM configuration, as shown below.

2) IO Multiplexing Configuration

Modify the following file:

sdk/rt-thread/platform/fh8626v300/app_board/appboard_iopad.h

When configuring pin multiplexing, ensure that there are no conflicts, otherwise the multiplexing configuration will not take effect.

Pin functions can be checked via the pin_mux table, or directly referenced from:

fh8626v300_iopad.h

3) Device Verification

After the configuration takes effect, corresponding device files will appear under /dev on the board.

You can use the following command to view pin multiplexing information:

pinctrl -l

4) CV2005 Dual-Camera Output

The dual-camera output of CV2005 can be configured by following the CV2005 always-on mode test firmware documentation provided in the SDK.

The FH video stream channel data format is shown below.

The NNA module requires RGB888 input format, so when enabling humanoid detection, Channel 2 must be enabled.

In this design:

● Sensor 0 is used for humanoid detection

● The resolution of Channel 2 maintains the same aspect ratio as Channel 0

● Channel 2 data is scaled from Channel 0

● Detection results can be directly mapped back to Channel 0 for OSD bounding box rendering

The resolution configuration is shown below.

The mapping relationship between NNA detection results and Channel 0 is illustrated below.

6. Humanoid Tracking Logic

Objective:

Ensure that the detected humanoid target’s center point falls near the center of the frame (1920/2, 1080/2).

To prevent camera jitter, the center area is expanded into a tolerance zone.

As long as the target’s center remains within this zone, the gimbal will not rotate.The relationship between pixel displacement and rotation angle is illustrated below.

Using a simple mapping relationship, the angular difference corresponding to pixel offsets can be calculated.

The gimbal rotation angle is then derived from the pixel distance between the target center and the image center.

7. Video Demonstration

Humanoid detection bounding boxes can be viewed by pulling the RTSP stream using VLC.

Due to the lack of a proper mounting bracket and concerns about short circuits when mounting the gimbal directly onto the development board, the current demo only shows the directional response of the gimbal when a humanoid appears in different regions of the frame.

A full demo with the gimbal mounted on the board will be provided in future updates.

8. Issues Encountered During Debugging

Yellowish Image Color

IR-CUT issue:

● Connect the camera IR-CUT interface to J20

● Short JP27 pins 1 and 2

● After multiplexing to GPIO4, power on the board to switch IR-CUT

● GPIO4 default level is high

Hardware inspection revealed that R69, located between the IR-CUT chip and another control pin GPIO29, is not populated.

Therefore, the IR-CUT module can be removed directly, restoring normal image color.For indoor testing, the IR-CUT state must still be evaluated based on actual lighting conditions.

If IR-CUT needs to be enabled:

● Short R69

● Pull GPIO29 high

● Pull GPIO4 low

9. Future Outlook

This project currently adopts a dual-camera solution:

● The primary camera performs tripwire detection

● The secondary camera performs humanoid tracking

This enables a linkage mechanism where:

● The primary camera monitors a fixed region

● When a person enters a predefined area, an alarm is triggered

● The secondary camera automatically tracks the target

This approach achieves functionality similar to gun-ball linkage systems used in modern surveillance cameras.