首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >保姆级教程 | i.MX 93开发板适配Zephyr RTOS全解析

保姆级教程 | i.MX 93开发板适配Zephyr RTOS全解析

原创
作者头像
飞凌嵌入式
修改2026-04-28 16:12:34
修改2026-04-28 16:12:34
210
举报
文章被收录于专栏:国产方案国产方案

前言

Zephyr是Linux基金会旗下开源实时操作系统(RTOS),由Intel、NXP、Google、Qualcomm等头部厂商持续支持,现已迭代至v4.x。它支持700余款开发板与主流处理器架构。

Zephyr 不是传统 RTOS 的替代品,而是将云计算时代的开发理念引入资源受限的嵌入式世界——解决碎片化、安全性和开发效率问题的下一代基础软件,它的设计理念是:模块化、可裁剪、开箱即用

i.MX 9352作为NXP推出的轻量级边缘AI处理器,集成2个Cortex-A55核和1个Cortex-M33实时核,其架构设计充分体现了对实时性与复杂任务处理能力的兼顾。为了帮助开发者充分利用i.MX 9352 M33核的实时能力,结合VSCode+MCUX扩展的完整开发体验,本文将介绍如何在Zephyr中完成M33核PWM驱动的验证,帮助读者快速上手 Zephyr 在工业级 SoC 上的移植与测试实践。

演示平台:飞凌嵌入式OK-MX9352-C开发板

点击添加图片描述(最多60个字) 编辑

为什么选择Zephyr?

1.1 相比传统RTOS,Zephyr的核心优势

从"写代码配置硬件"到"声明硬件关系"

传统痛点:每换一个MCU引脚或外设,就要重写驱动、调寄存器、改编译选项。Zephyr以Devicetree硬件蓝图(.dts)描述整个硬件布局,更换硬件只需修改蓝图,核心业务代码几乎不动;搭配Kconfig图形化配置工具,可像 Linux 内核一样灵活裁剪系统功能。

从"功能实现"到"安全与功耗原生设计"

传统痛点:传统RTOS的安全、低功耗能力多为后期追加功能,漏洞多、优化难度大。Zephyr从底层设计就以安全为核心,覆盖安全启动链、MPU内存保护、加密服务等全链路安全能力;基于事件驱动的电源管理框架,可实现微安级精准功耗控制。

从"单一固件"到"可移植的软件资产"

传统痛点:A公司芯片写的驱动,在B公司芯片上几乎要重写。Zephyr 统一设备模型,驱动一次开发可跨厂商芯片复用;蓝牙、Wi-Fi、Matter等协议栈即插即用,与硬件底层隔离,让核心代码成为可复用、可迭代的软件资产。

1.2 Zephyr vs FreeRTOS

Zephyr和FreeRTOS都属于实时操作系统,且都面向物联网场景深化布局,但二者在软件架构、内核设计上有明显差异。

核心设计哲学

系统架构

协议栈与功能

资源占用Cortex-M4最小核无外设

开发环境与调试

根据上述对比,发现Zephyr也有一下短板:

  • 学习曲线陡峭
  • 资源占用更大
  • 构建系统复杂
  • 上下文切换性能不如 FreeRTOS

从对比能看出,Zephyr的短板主要集中在入门阶段和极致资源受限场景,一旦团队熟悉开发流程、硬件资源满足要求,这些劣势会快速弱化;而它的可移植性、安全能力、生态优势,会随着项目复杂度提升愈发明显。

1.3 Zephyr 应用场景

医疗与可穿戴设备

Zephyr的确定性实时响应和低功耗特性,可支撑连续血糖监测、心脏监护等医疗级应用,满足量产医疗设备的技术要求。

工业自动化

支持10BASE-T1S等工业以太网协议,适配工厂自动化、过程控制场景,OSADL已为Zephyr建立工业领域量化性能基准。

智能家居与消费电子

从Matter协议支持到蓝牙5.4完整协议栈,Zephyr正成为智能家居生态核心支撑。Arduino VENTUNO Q平台已采用 Zephyr确保时间关键型任务的确定性执行。

汽车电子

随着汽车电子架构向集中式演进,Zephyr的模块化设计和内存保护机制满足了汽车功能安全要求,是车载域控制器的理想选择。

开发环境搭建(VSCode+MCUX)

2.1 工具准备

推荐使用NXP MCUXpresso for VS Code扩展,插件已内置核心能力:

1. CMakePresets.json一键构建

2. SEGGER J-Link / LinkServer调试支持

3. 设备树可视化可直接预览 .overlay 文件

安装步骤:

1. 安装VS Code编辑器

2. 在扩展市场搜索并安装MCUXpresso for VS Code

3. 按插件引导安装west、Zephyr SDK、arm-none-eabi-gcc工具链

2.2 工程结构

使用CMakePresets.json管理构建配置,每个应用统一如下结构:

my_app/

├── CMakeLists.txt

├── CMakePresets.json ← 指定 BOARD、构建目录

├── prj.conf ← Kconfig 全局配置

├── boards/

│ ├── imx93_evk_mimx9352_m33.overlay ← 板级 DTS 扩展

│ └── imx93_evk_mimx9352_m33.conf ← 板级 Kconfig 覆盖

└── src/

└── main.c

CMakePresets.json示例:

{

"configurePresets": [

{

"name": "debug",

"cacheVariables": {

"BOARD": "imx93_evk/mimx9352/m33",

"CMAKE_BUILD_TYPE": "debug"

}

}

]

}

在VSCode中,点击底部状态栏的Build按钮即可完成编译,无需手动敲命令。

设备树Overlay:Zephyr的硬件描述核心

Zephyr通过Devicetree描述硬件,板级差异通过 .overlay文件叠加,无需修改官方主DTSI文件,这也是 Zephyr 高可移植性的核心设计。

RTC 外设的 Overlay 描述

RTC(实时时钟)是工业与消费电子产品中必不可少的外设。在Zephyr中,外部RTC芯片通过I2C总线挂载,并在 .overlay文件中完整描述其连接关系,应用层只需调用统一的RTC API,无需关心底层硬件差异。

以i.MX93 EVK接入EPSON RX8010为例,overlay需要做两件事:启用I2C控制器并添加RTC子节点,同时通过 aliases让上层应用找到该设备:

/* boards/imx93_evk_mimx9352_m33.overlay */

&lpi2c3 {

status = "okay";

clock-frequency = <I2C_BITRATE_FAST>; /* 400 kHz */

pinctrl-0 = <&i2c3_default>;

pinctrl-names = "default";

rx8010: rx8010@32 {

compatible = "epson,rx8010"; /* 匹配驱动 binding */

reg = <0x32>; /* I2C 设备地址 */

status = "okay";

};

};

/ {

aliases {

rtc = &rx8010; /* 应用通过 "rtc" 别名访问 */

};

};

应用代码中只需:

const struct device *rtc = DEVICE_DT_GET(DT_ALIAS(rtc));

struct rtc_time tm = { .tm_year = 125, .tm_mon = 3, .tm_mday = 20 };

rtc_set_time(rtc, &tm);

rtc_get_time(rtc, &tm);

可移植性体现:若将RX8010更换为其他Zephyr支持的 RTC芯片(如DS3231、PCF8563),只需修改overlay 中的 compatible和reg,应用代码零改动

驱动验证实践

本节展示在i.MX 93开发板的M33核上已完成验证的PWM驱动样例。

样例:pwm_api—使用TPM2 控制器输出PWM信号

我们通过Import Example from Repository导入pwm_api项目后

overlay只需声明别名:

/* boards/imx93_evk_mimx9352_m33.overlay */

/ {

aliases {

pwm-test = &tpm2;

};

};

Kconfig 配置:

/* boards/imx93_evk_mimx9352_m33.overlay */

CONFIG_PWM=y

测试通过 pwm_set_cycles() / pwm_set()设置占空比,可用示波器验证输出波形。i.MX93的TP(Timer/PWM Module)直接映射到Zephyrnxp,kinetis-tpm驱动,无需任何自定义代码。

Zephyr 开发中的常用调试技巧

5.1 Kconfig配置检查

Vscode中project文件中

debug/zephyr/.config 为项目最终合并后的config内容。

5.2 设备树最终输出检查

Vscode中project文件中

debug/zephyr/zephyr.dts 为项目最终合并后的dts内容。

这是排查overlay合并是否生效的最直接方式。

5.3 日志级别

CONFIG_I2C_LOG_LEVEL_DBG=y # 开启 I2C 驱动调试日志

5.4 ztest 测试框架

所有驱动样例均使用ztest框架,运行后通过串口输出结果。以PWM测试为例,烧录后串口输出如下:

*** Booting Zephyr OS build v4.1.0 ***

Running TESTSUITE pwm_basic

===================================================================

START - test_pwm_nsec

[PWM]: 0, [period]: 2000000, [pulse]: 1000000

[PWM]: 0, [period]: 2000000, [pulse]: 2000000

[PWM]: 0, [period]: 2000000, [pulse]: 0

PASS - test_pwm_nsec in 3005 ms

START - test_pwm_cycle

[PWM]: 0, [period]: 64000, [pulse]: 32000

[PWM]: 0, [period]: 64000, [pulse]: 64000

[PWM]: 0, [period]: 64000, [pulse]: 0

PASS - test_pwm_cycle in 3003 ms

===================================================================

TESTSUITE pwm_basic succeeded

输出说明:

test_pwm_nsec:以纳秒为单位依次设置 50% 占空比(1.65V)、100%占空比(3.3V)、0%占空比(0V),每步保持1秒

test_pwm_cycle:以cycle为单位重复上述三种占空比验证,period=64000cycle,pulse依次为32000/ 64000/0

每条[PWM]行对应一次pwm_set()/pwm_set_cycles()调用,可用示波器或万用表在TPM2输出引脚上验证实际电压。

总结

通过本次i.MX93 M33核的Zephyr移植实践,我们验证了:Zephyr原生的应用pwm_api在i.MX 93 M33核的支持过程。

Zephyr 的核心价值在于:

1. 一套驱动API,覆盖所有平台——更换SoC只改overlay,不改应用代码;

2. 设备树驱动开发——硬件配置与软件逻辑清晰分离;

3. 完整的测试基础设施——ztest+testcase.yaml支持 CI/CD集成;

4. 安全与低功耗原生设计——不是后期补丁,是系统基础设施;

5. 活跃的上游社区 —— 全球超1600名贡献者,每周数百次代码合并。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • 为什么选择Zephyr?
  • 开发环境搭建(VSCode+MCUX)
  • 设备树Overlay:Zephyr的硬件描述核心
  • 驱动验证实践
  • Zephyr 开发中的常用调试技巧
  • 总结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档