i.MX6ULZ无头嵌入式计算方案：DART模块开发实践

这块板子最近在嵌入式圈子里讨论度不低Variscite 把 DART 系列模块从 i.MX6UL/ULL 往 i.MX6ULZ 上引方向其实很明确给无头场景做一个更低成本、更省电、更适合量产的方案。如果你是做工业网关、边缘采集、简易控制盒这类产品i.MX6ULZ 这颗芯片值得你认真看一遍DART 模块的封装方式也决定了它比直接画核心板要省事得多。我最近基于这个方案做了一个远程数据采集网关的原型下面把这颗芯片、这个模块、以及整个开发落地过程中真正有用的东西整理出来。1. 这个模块到底在解决什么问题1.1 Variscite 和 DART 系列是什么定位Variscite 不是芯片原厂它是做系统级模块System on ModuleSoM的。你可以把 SoM 理解成一块提前帮你画好、调好、验证过的半成品电脑CPU、内存、存储、电源管理、网络接口这些都集成在一小块板子上做成邮票孔或者金手指连接器。你只需要根据自己的产品需求设计一块底板Carrier Board把模块插上去再引出你需要的接口就行。DART 系列是 Variscite 的主力产品线之一过去几年里 DART-MX6、DART-6UL 这些型号在工业领域出货量不算小。它的特点是比较克制不追求旗舰性能而是围绕稳定、低功耗、长生命周期、可定制这几个工业客户最在意的点来做。这次把 DART 平台迁移到 i.MX6ULZ本质上是一次产品定位的收束——既然很多客户根本不需要显示接口为什么还要为 GPU、LCD 控制器这些用不到的功能买单1.2 i.MX6ULZ 是什么它和 i.MX6UL/ULL 有什么区别i.MX6ULZ 是 NXP i.MX6 家族里非常特殊的一个成员。它基于 Cortex-A7 内核主频最高 528MHz从算力上说和 i.MX6UL、i.MX6ULL 处于同一水平线都属于轻量级应用处理器。但它最核心的变化是砍掉了显示相关的外设。我之前画 i.MX6ULL 底板的时候LCD 接口、GPU、图形加速这些引脚和电源域占了不小的设计面积PCB Layout 时还要特别注意显示信号线的等长、阻抗匹配。但对一个纯数据采集设备来说这些引脚从产品定义的第一天就不会被用到。i.MX6ULZ 等于把这一坨直接拿掉芯片封装更小、引脚更少、BOM 成本更低软件上也不需要为图形栈做任何配置。另外一个容易被忽略的点是i.MX6ULZ 保留了和 i.MX6ULL 高度兼容的外设接口比如 10/100M 以太网 MAC、USB 2.0 OTG、多个 UART、CAN、I2C、SPI、ADC、PWM 等。也就是说你砍掉的是给人看的部分保留的是给设备交互的部分。对于物联网网关、工业控制器、传感器 Hub 这类产品来说需求刚好被精准覆盖。1.3 DART 模块把芯片价值放大了如果只是用一颗 i.MX6ULZ 做核心板其实很多公司都能做。但自己做核心板和买 Variscite 这类成熟模块差别非常大尤其是在量产阶段。做核心板不是光把 CPU 周围电路画出来就行。DDR 走线、电源时序、晶振配置、EMC 处理、复位逻辑任何一个环节处理不好都会导致系统不稳定。更麻烦的是这些问题往往要到整机测试阶段才暴露到时候改板成本极高。Variscite 的 DART 模块把这些东西全部封装好了你拿到的是一块经过大批量验证的硬件BSP 也是配套维护好的Yocto、Buildroot、Debian 都有现成镜像。我自己第一次用 DART 模块做项目的时候最大的感受是硬件设计周期被压缩了至少一半。底板只需要关注连接器的位置、接口电路、电源输入、结构尺寸不需要去抠 DDR 布线这种高风险的事。2. 无头不是砍配置而是产品定义的重新思考2.1 无头系统在嵌入式领域的真实含义Headless这个词这几年被前端领域用得多Headless UI 指的是组件逻辑和界面展示分离你拿到的是 API 和状态管理渲染层自己决定。嵌入式里的无头思路非常相似系统逻辑、业务功能与显示界面解耦。以往很多产品的思路是先放一个屏幕上去再做功能于是 CPU 选型时优先考虑带 GPU 的型号内存也往大了配。但实际上大量设备装屏幕只是为了显示几个状态参数或者本地调试信息真正的人机交互全在远端。屏幕带来的成本、功耗、结构设计难度、软件复杂度全是隐性负担。无头化之后产品的逻辑变成了设备只负责采集数据、执行控制、联网通信人机交互交给云端平台或手机 App。这就带来几个直接好处设备体积可以做小功耗可以降下来开机时间可以缩短现场维护时不需要面对一个半死不活的触摸屏。2.2 i.MX6ULZ 的取舍逻辑正好卡在甜点上i.MX6ULZ 的取舍不是阉割而是精准。它去掉的东西是为显示场景服务的留下来的东西全部是为设备互联场景服务的。528MHz 的 Cortex-A7 跑 Linux 5.x 内核完全没有压力跑一个 Mosquitto MQTT Broker、Node-RED、或者 Python 写的数据采集脚本也够用。如果业务逻辑不复杂甚至可以跑 .NET 或者 Go 编译的二进制。内存方面DART 模块一般可以选配不同容量的 DDR从 256MB 到 1GB 都有。对于无头场景256MB 能跑一个裁剪过的 Yocto 系统加几个应用512MB 就比较从容1GB 基本上可以塞很多东西了。我在网关上装了 Docker 的轻量容器方案512MB 下跑两个容器还是稳的。存储同样很灵活。NAND Flash 成本低适合只读为主的系统eMMC 寿命和稳定性更好适合要频繁写日志或做本地缓存的场景。DART 模块在存储颗粒选择上给了比较多的 SKU你不需要自己贴片。2.3 和竞品对比这个方案强在哪儿如果拿 i.MX6ULZ 和同价位的国产方案比性能上确实没什么优势很多国产 Cortex-A7/A53 芯片的主频更高、核心数更多。但 i.MX6ULZ 的护城河不在算力而在长期供货承诺和生态成熟度。工业产品最怕的是芯片停产。很多客户的产品生命周期是五到十年芯片用了一年就断供整个产品线都要重新设计。NXP 在工业级芯片的长供货策略上一直比较稳i.MX6 系列的生命周期规划覆盖到 2028 年之后。Variscite 作为方案商也会在模块层面保持兼容性换料、替代、版本升级都更可控。另一个优势是软件生态。Yocto 的 BSP 更新及时主线内核支持完善设备树配置公开社区资料多。团队里随便一个嵌入式工程师都能在一天内把环境搭好开始写应用。这个隐性成本在项目排期里非常重要。3. 硬件平台的几个关键设计细节3.1 模块形态与连接器DART 模块的体积控制得很紧凑。具体尺寸不同型号略有差异大体上是 30mm 级别见方的小板通过高密度板对板连接器与底板连接。这种连接器的好处是拆卸方便研发阶段可以快速换模块验证量产时也可以用机器自动贴装返修比邮票孔方案要友好一些。底板设计时需要注意连接器的引脚间距和推荐焊盘尺寸Variscite 的硬件手册里都有明确标注。我踩过一个坑第一次画底板时没有仔细看连接器的封装推荐导致模块插上去后几个信号脚虚焊整机偶发性死机。后来重新按官方封装画了一版问题立刻消失。3.2 底板电源设计虽然模块上已经做了大部分电源转换但底板仍然需要为模块提供合适的主供电轨。DART 模块一般支持宽压输入常见的是 3.3V 到 5.5V 或者更高范围具体看型号。我在设计中直接采用 5V 输入通过底板上的 DC-DC 将外部 12V 或 24V 工业电源转换成 5V再供模块使用。这里要说一个重要细节i.MX6ULZ 本身的功耗很低不代表底板电源可以随便做。它的瞬态电流变化是存在的尤其在网络吞吐高的时候和写入 eMMC 的同时发生电流尖峰如果不处理好会导致模块复位。我在底板输入端加了足够的去耦电容并选用了一颗瞬态响应好的降压芯片实测电压波动控制在 3% 以内。3.3 关键外设电路无头网关最常用的几个外设是以太网、USB、UART、CAN、GPIO。DART 模块一般把 PHY 芯片也集成进去了所以底板上只需要加网络变压器和 RJ45 座。这点非常省心之前用裸芯片设计的时候PHY 芯片的 Layout 是非常头疼的现在模块全部搞定。USB 方面模块引出的是 USB 2.0 信号底板上加 TVS 管和 ESD 保护即可。如果需要做 OTG还要注意 ID 引脚的上拉/下拉处理。UART 直接引出 TTL 电平如果需要 RS232 或 RS485在底板上加对应的收发器芯片。CAN 接口类似需要加 CAN 收发器和终端电阻。GPIO 数量对于无头设备来说非常充裕。我在项目里用 GPIO 控制了一个三色指示灯、一个蜂鸣器、几个拨码开关检测输入还留了一路 GPIO 做远程硬件复位控制完全够用。3.4 存储选型的建议DART 模块在存储配置上给的选择很多我简单从实际效果说一下。NAND Flash 的成本确实低但坏块管理和擦写均衡依赖软件层面的 UBI/UBIFS 文件系统。如果只是放只读的根文件系统几个月不写一次NAND 完全够用。但如果系统需要频繁写日志或者做本地 SQLite 缓存建议直接上 eMMC。eMMC 内部有控制器擦写均衡、坏块管理都是硬件完成的软件层面对它就是一个普通块设备出问题的概率低得多。如果预算允许我甚至会建议选稍大一点的 eMMC不要卡着系统需求来。Linux 系统、应用、缓存、日志这些加起来很快会把存储占满后期清理远端数据的成本远高于硬件选型的差价。4. 软件栈怎么搭BSP 怎么用4.1 用 Yocto 还是 DebianVariscite 对 DART 模块的软件支持做得比较到位官方维护 Yocto 和 Debian 两套 BSP。Yocto 适合产品形态固定、对系统体积和启动速度有要求的场景Debian 适合研发原型阶段或者是应用层依赖比较多、不想折腾交叉编译的场景。我个人的习惯是原型阶段直接用官方 Debian 镜像跑通业务逻辑之后再裁剪成 Yocto。原因很简单Debian 上可以用 apt 装各种东西Python、Node.js、Mosquitto、InfluxDB一条命令装好开发效率高。等原型验证完之后再用 Yocto 做一个精简小系统把启动时间从十几秒压到三五秒。4.2 设备树的几个重点不管用哪套 BSP设备树都是绕不开的。i.MX6ULZ 的设备树整体结构和 i.MX6ULL 非常接近NXP 官方内核里已经有对这颗芯片的基础支持Variscite 又在板级设备树里做了定制。你自己写应用时经常会动设备树以下几个节点是重点UART每个串口对应节点里要确认 pinctrl 引脚是否和底板一致否则会出现引脚复用冲突。GPIO需要确认 active-high 还是 active-low建议在设备树里直接定义好不要到应用层去反转。以太网确认 PHY 地址和 phy-mode。如果用模块自带的 PHY一般不用改。I2C如果要接外部传感器确认总线上没有地址冲突。我踩过的坑是设备树里引用了多个 UART但实际上底板没有引出那几个引脚。系统启动时 UART 驱动会尝试请求引脚导致其他复用功能异常。后来我把没用的 UART 节点全部 disable 掉问题就消失了。4.3 U-Boot 和启动流程U-Boot 在 i.MX6ULZ 平台上已经非常成熟。Variscite 的 BSP 里默认配置好了启动参数你可以通过 U-Boot 环境变量定制启动流程比如从哪里加载内核、根文件系统用什么参数挂载。无头系统最好把串口控制台保留出来调试的时候太方便了。我发现有些工程师为了省东西量产板上不引出串口系统出问题只能干瞪眼。哪怕只在 PCB 上预留两个测试点也比什么都没有强。4.4 无头应用架构怎么做前面说了嵌入式无头思路和前端 Headless UI 很像。在具体实现上我建议把应用拆成三层数据采集层、业务逻辑层、通信协议层。每一层之间通过接口解耦这样后面换通信协议或者改采集方案时不需要推倒重来。我最近这套采集网关的架构是这样的底层用 C 写了一个高效的数据采集程序通过设备树和 Modbus 协议读取现场传感器数据中间用 Node-RED 做业务逻辑编排负责数据过滤、报警判断、本地缓存上层用 MQTT 协议把数据发到云端。Node-RED 跑在 528MHz 的 i.MX6ULZ 上完全流畅内存占用在 512MB 配置下还有富余。5. 从一个真实项目看完整落地流程5.1 项目需求我最近做的这个项目是一个厂区环境监测网关需要采集温湿度、粉尘浓度、有害气体浓度还要控制现场几个排风扇。网关本身没有屏幕所有配置和数据显示都在远端 Web 平台和手机小程序上。现场采用 24V 工业电源供电对外提供以太网和 4G 两种联网方式。5.2 底板设计步骤第一步是确定接口清单。根据需求底板需要引出以下接口1 路 10/100M 以太网RJ45带状态指示灯1 路 USB 2.0 Host用于 4G 模块或现场调试 U 盘2 路 RS485接传感器和控制设备1 路 CAN预留后续扩展2 路模拟量输入用于接 4-20mA 变送器8 路 GPIO接指示灯、拨码开关、继电器第二步是根据接口清单找模块引脚。DART 模块的连接器引脚图非常规整把外设信号、电源轨、地线都分区块排列。你在底板上布局时按区块走线能显著减少信号交叉。第三步是电源设计。我从 24V 输入开始先用一颗宽压 DC-DC 降到 5V然后分三路一路给模块供电一路给 RS485 和传感器供电一路给 4G 模块供电。分别在模块电源入口和传感器电源入口加了 π 型滤波器实测现场强电设备启停时网关纹波控制在可接受范围。第四步是 PCB Layout。底板层数不用太多四层板就够。关键信号线尽量走内层晶振附近不要走高频线防护器件靠近连接器放置ESD 路径要短。我把 DART 模块放在板子中央连接器分布在四周结构件通过四个角的定位孔固定。5.3 软件配置与镜像烧录底板焊接完成后的第一件事不是马上跑业务应用而是先验证基础系统。我用官方 Debian 镜像烧录了一张 TF 卡插入模块的 SD 卡槽然后通过串口连接 U-Boot设置从 SD 卡启动。启动后确认以下几项正常以太网检测到 PHY能获取 IP 地址USB Host 能识别 U 盘每个 UART 口都能收发数据GPIO 能正常拉高拉低温度传感器读取数据正常这些基础项验证通过后再把系统安装到 eMMC后续开发就在 eMMC 系统上进行。5.4 产品化过程中的注意事项产品化和原型验证完全是两码事有几个点我建议提前想清楚标识与丝印底板上的丝印要标清楚调试口、电源输入正负极、拨码开关定义现场维护工程师看到丝印就能动手。软件看门狗无头设备一定要在软件层面加看门狗机制。如果应用进程崩溃要能自动重启。我用的是 systemd 的 watchdog配合硬件看门狗芯片做双重保障。日志策略日志必须做轮转和定期清理不然 eMMC 会被写满。我配置了 logrotate 按天轮转保留 7 天。远程 OTA无头设备不在现场的话每次升级都要跑现场会非常痛苦。建议在项目初期就规划 OTA 方案哪怕先用最简单的方案SSH 脚本也比没有强。5.5 网络与通信协议选型无头网关的通信可靠性直接决定产品口碑。我在项目里做了双链路冗余以太网为主4G 为备。主链路断开时系统通过脚本检测到后自动把默认路由切到 4G 模块。业务层用 MQTT QoS 1保证消息至少送达一次配合心跳机制检测连接状态。如果你对实时性要求比较高可以考虑 Modbus TCP 或者 OPC UA。i.MX6ULZ 的算力跑这几个协议栈都没问题关键看你的现场传感器支持什么。6. 我踩过的坑与问题排查6.1 偶发性复位问题出在电源瞬态项目测试时遇到一个很头疼的问题系统运行一两天后会偶发复位没有任何规律。看内核日志只能看到启动记录完全找不到复位前的线索。后来排查到是供电问题。现场设备的排风扇启停时电源线上会有很大的电压跌落。DART 模块虽然允许输入电压在一个范围内波动但如果输入端没有足够的储能电容电压跌落时间稍微长一点就会触发模块的欠压复位。解决方法是在底板电源输入端增加一个 470uF 的电解电容和 0.1uF、10uF 的陶瓷电容并联形成多级去耦网络。同时把 DC-DC 的反馈补偿调快一点让它在瞬态条件下能更快响应。改完这个问题之后连续跑了两个星期没有再复现。这是我反复强调的无头设备死机是最难排查的问题之一因为它没有屏幕给你报错。所以电源设计宁可保守不要极限。6.2 串口数据偶发乱码引脚复用冲突第二个坑是 RS485 通信偶尔出现乱码。一开始以为是收发器芯片问题换了三四种收发器都没解决。后来用示波器看波形发现 TX 信号线上叠加了一个不干净的脉冲。最终定位到是 GPIO 引脚复用冲突。我在设备树里把某个 UART 的 RTS 引脚同时配成了 GPIO 功能用来控制 RS485 收发切换。结果两个功能在底层打架导致串口数据发送异常。正确做法是在设备树里单独创建一个 RS485 控制节点把收发切换引脚定义成标准 GPIO然后在应用层通过 ioctl 控制切换方向或者干脆用内核的 RS485 驱动接口。6.3 写入 eMMC 时系统卡顿IO 调度问题用 eMMC 版本时发现一个现象系统在写入大量日志的时候网络 ping 延迟会飙到很高甚至有时候 SSH 都会卡住。刚开始以为是 CPU 忙不过来后来查了 IO 调度器才发现eMMC 的写放大和 Linux 默认的 I/O 调度策略不太匹配。解决方法是把 mmcblk 的 IO 调度器从默认的 mq-deadline 改成 none并在文件系统挂载参数里加上 noatime减少不必要的元数据写回。改完之后写日志期间网络延迟恢复正常系统操作也流畅了。6.4 快速排查技巧清单排查无头系统问题我的建议是按这个顺序来串口控制台永远是最快的眼睛先看内核日志确认电源正常用示波器看关键节点的瞬态检查设备树引脚是否有冲突外设是否 enable检查 logs 目录看有没有 OOM、IO 错误、驱动报错用 iostat、top 看系统负载排除资源耗尽这些基本功在无头系统上比在带屏系统上重要得多因为没有任何图形界面可以救命。7. 一些个人经验算给我自己做个小结7.1 什么样的人适合买 DART 模块而不是自己画核心板如果你的团队有很强的硬件设计能力产品量又大自己设计核心板摊薄成本是合理的。但如果你的团队更偏软件和应用或者产品开发周期紧张DART 这类模块几乎是唯一解。我见过太多项目死在自己画核心板上。不是画不出来而是画完之后调不稳。DDR 不稳定、电源时序不对、电磁兼容过不了任何一个问题都能拖掉一两个月。买模块看起来单价贵了几十块算上研发成本和上市时间其实是省钱。7.2 i.MX6ULZ 的上限在哪里很多人在选型时会问这颗芯片到底能不能跑我的应用我的判断标准很简单如果应用主要是网络 I/O、串口通信、数据处理而不是大量本地计算或复杂 GUI那 i.MX6ULZ 完全够用。跑 Node.js 服务、Python 脚本、Go 二进制、Java 轻量服务都没问题。但如果要做 AI 推理或者视频流处理就别为难它了那不是它的定位。7.3 后续能往哪升如果产品定义已经在这条路上未来想升级性能Variscite 的产品线里还有更高阶的 i.MX8M 系列模块封装和底板设计上可以考虑兼容策略。提前在底板设计时留出扩展接口和电源余量后续硬件升级就不用推倒重来。另外一个小技巧如果你不确定未来要用哪种模块可以先选接口最丰富的一款做底板通过飞线或者扩展板的方式兼容参考设计的余量留足后面会感谢自己当时的决定。整体用下来我对 DART i.MX6ULZ 这套组合的评价是它不炫技但很稳。它做的每件事——砍显示、保守的功耗、成熟的 BSP、靠谱的模块供应链——都是冲着把产品稳定量产出来这个目标去的。如果你正好在做类似的设备可以认真考虑一下。