i.MX 937异构处理器：边缘AI与实时控制的融合设计指南-平芜编程栈

1. 从云端到边缘：为什么我们需要i.MX 937这样的应用处理器？

在过去的十年里，我们见证了计算范式的一次深刻转移。早期的物联网设备，大多扮演着“数据采集器”的角色，将传感器读数、图像信息一股脑地传回云端服务器，等待远方的“大脑”做出决策。这种模式在智能音箱、简单的环境监测上或许可行，但一旦场景切换到工厂流水线、自动驾驶的辅助系统，或者需要实时响应的智能家居安防，问题就暴露无遗：网络延迟、带宽成本、数据隐私，以及最关键的系统可靠性——一旦网络抖动或中断，整个系统就可能陷入瘫痪。

这就是边缘计算崛起的根本原因。它的核心思想非常朴素：让计算发生在数据产生的地方。想象一下，一个工业质检摄像头，如果它能自己判断产品是否有瑕疵，而不是把每秒几十帧的高清图片全部上传到云端分析，那么生产线的速度可以提升几个数量级，网络带宽压力骤减，而且即便外网断了，生产线照样能跑。这个“自己判断”的能力，就需要一个足够强大、但又不能太耗电、体积也不能太大的“大脑”嵌入到摄像头里。这个“大脑”，就是像i.MX 937这样的高性能应用处理器。

i.MX 937的出现，直指当前边缘AI落地的几个核心痛点。首先，是性能与功耗的平衡。传统的通用CPU（比如一些早期的Cortex-A系列）跑复杂的AI模型往往力不从心，功耗却居高不下；而一些纯AI加速芯片，虽然算力强，但通用处理能力弱，难以胜任复杂的系统控制和丰富的交互任务。i.MX 937采用的异构计算架构，就是把不同类型的“专家”集成在一块芯片上：四个Cortex-A55核心负责运行复杂的操作系统（如Linux）和上层应用逻辑，属于“指挥官”；一个专用的神经网络处理单元（NPU，这里指eIQ Neutron）则像“特种兵”，专门高效执行AI推理任务；再加上实时域里的Cortex-M7和M33，它们好比“快速反应部队”，确保对电机控制、传感器中断等实时事件做出微秒级的响应。这种分工协作，让合适的任务跑在合适的核心上，实现了整体效能的最大化。

其次，是系统设计的复杂性与长期维护成本。工业、汽车领域的产品生命周期动辄十年以上，开发者最怕的就是芯片停产、软件生态断裂。i.MX 937明确强调与i.MX 95/952系列的引脚兼容性，并承诺15年的产品供应保障，这不仅仅是商业策略，更是对开发者工程投入的一种保护。这意味着，当你基于i.MX 937设计了一款网关或HMI（人机界面）后，未来如果需要升级性能，很可能只需要更换主芯片而无需重新设计电路板和结构件，大幅降低了硬件迭代的风险和成本。

所以，当我们谈论i.MX 937时，我们谈论的不仅仅是一颗芯片的参数表。我们谈论的是一种面向未来的边缘智能系统设计范式：它需要强大的本地算力来处理AI，需要确定性的实时控制来联动物理世界，需要坚固的安全防线来保护数据和设备，还需要丰富的连接能力来融入更大的网络。接下来，我们就深入这颗芯片的内部，看看它是如何通过精密的架构设计来兑现这些承诺的。

2. 架构深潜：解读i.MX 937的“三域”异构设计

i.MX 937的框图乍一看可能有些复杂，但它的设计逻辑非常清晰，可以概括为“三域分立，协同作战”。理解这个架构，是高效利用这颗芯片的关键。

2.1 应用域：智能系统的“决策大脑”

应用域的核心是四核Arm Cortex-A55集群。A55是Arm的“高效能”核心，在提供相当不错性能的同时，保持了优异的能效比。这四个核心共享一个512KB的L3缓存（带ECC校验），这意味着它们可以高效地协同处理任务，比如一个核心处理网络协议栈，一个核心运行数据库，另外两个核心处理应用程序逻辑。

这个域通常运行像Linux或Android这样的功能丰富的操作系统，负责处理非实时性、计算密集型的任务。例如，在智能家居网关上，应用域负责运行设备管理平台、规则引擎、数据聚合服务，并可能通过容器技术托管多个微服务。在工业HMI上，它负责渲染复杂的图形界面、处理历史数据记录和网络通信。

注意：虽然A55性能足够，但它并非为极致的实时性设计。如果你的应用中有严格时限（比如必须在100微秒内响应）的控制任务，千万不要放在这个域。把它留给实时域。

2.2 实时域：精准控制的“快速反应部队”

实时域是i.MX 937区别于许多通用应用处理器的精髓所在。它进一步细分为两个子域，体现了精细化的功耗和性能管理。

高性能实时域：以Arm Cortex-M7为核心。M7是MCU领域的性能王者，主频高，带有双精度浮点单元（FPU），并且拥有512KB的紧耦合内存（TCM）。TCM的特点是CPU可以直接访问，延迟极低且确定。这个域适合处理中等复杂度的实时任务，例如电机的高频PID控制、复杂的传感器融合算法（如IMU数据滤波），或者音频流的实时编解码。它像是一个“高级技工”，能处理需要一定计算量的实时作业。

低功耗系统管理域：以Arm Cortex-M33为核心。M33同样具备MPU（内存保护单元）和FPU，但更侧重于能效和安全。它通常负责系统的“打更”工作：管理低功耗模式（如休眠、唤醒）、监控系统健康状态（温度、电压）、处理简单的传感器轮询，以及作为安全启动和加密服务的信任根。在设备深度休眠时，可能只有M33和少数外设还在活动，将整体功耗降至极低水平。

实操心得：在实际项目规划中，我通常会这样分配任务：将关键的安全功能（如安全启动、密钥管理）和基础的设备监控放在M33域；将运动控制、实时通信协议栈（如带时间敏感网络TSN的以太网处理）放在M7域；而用户界面、AI模型加载、云同步等任务放在A55域。这种隔离确保了高优先级任务不被低优先级任务阻塞。

2.3 灵活域与专用加速器：释放特定负载的“特种装备”

除了通用计算核心，i.MX 937集成了多个专用硬件加速单元，它们被组织在灵活域或直接挂载在高速总线上，用于卸载特定类型的计算负载，从而大幅提升能效和性能。

eIQ Neutron NPU：这是边缘AI的算力核心。它提供高达2 eTOPS（每秒万亿次操作）的整数算力，专门为执行神经网络推理优化。与在CPU上运行模型相比，NPU的能效比通常有数量级的提升。这意味着你可以在一两瓦的功耗预算内，实时运行一个像YOLOv5这样的目标检测模型，这在电池供电或散热受限的设备中至关重要。

Arm Mali GPU：支持OpenGL ES 3.2和Vulkan 1.2，它不仅能驱动绚丽的用户界面（如1080p分辨率的工业仪表盘），还能通过OpenCL 3.0进行通用计算加速。例如，你可以将一些图像预处理（如色彩空间转换、缩放）或者非神经网络的并行计算任务卸载到GPU上，减轻CPU负担。

视频处理单元（VPU）与显示子系统：独立的VPU支持1080p60的视频编解码，这对于视频门铃、会议系统等应用非常有用。显示控制器则功能强大，支持旋转、缩放、叠加、色彩转换等操作，这些都可以由硬件完成，无需消耗宝贵的CPU周期。特别是2D GPU被放在实时域，这个设计非常巧妙——它可以在实时系统（如汽车仪表盘）中，确保速度��、警告灯等关键图形信息能够以确定性的延迟覆盖在主界面上，不受应用域复杂图形渲染可能带来的卡顿影响。

丰富的连接矩阵：2个带TSN的千兆以太网、PCIe 3.0、多个USB、CAN-FD、多路高速串行接口，构成了设备与外界连接的“高速公路”。特别是TSN的引入，使得i.MX 937能够成为工业现场中确定性网络的关键节点，确保关键控制指令和数据能在精确的时间窗口内送达。

3. 面向场景的实战解析：如何为你的项目选型与设计？

了解了架构，我们来看看i.MX 937如何落地到具体的应用场景。不同的场景对处理器的需求侧重点不同，配置和使用策略也应有差异。

3.1 工业4.0与工厂自动化

在这个场景下，可靠性、实时性和多接口连接能力是首要考量。

典型应用：工业人机界面（HMI）、机器视觉质检站、可编程逻辑控制器（PLC）的智能网关、产线设备控制器。

设计要点：

实时控制回路：将产线设备的运动控制逻辑、高速IO中断处理放在Cortex-M7实时域中。利用其TCM内存和可预测的中断延迟，确保控制循环的周期时间稳定在微秒级。CAN-FD接口可用于连接现场的电机驱动器、传感器网络。
TSN网络集成：利用芯片内置的两个TSN以太网口，将设备接入时间敏感网络。一个口可以连接上层监控网络（SCADA系统），另一个口可以组成菊花链连接下游设备。你需要配置TSN交换机（或使用芯片的桥接功能）和相应的协议栈（如IEEE 802.1AS时间同步、802.1Qbv流量整形），来保证关键的控制指令帧不会被其他数据流量阻塞。
多屏与高可靠性图形：对于复杂的HMI，可以利用Mali GPU渲染主操作界面。同时，将报警信息、紧急停止按钮状态等关键指示图形的渲染，交给实时域中的2D GPU。这样即使主应用（运行在A55上）因故卡死或重启，关键安全信息依然能稳定显示。显示控制器的多图层叠加和硬件旋转功能，可以轻松实现仪表数据的“画中画”显示。
安全与维护：利用EdgeLock安全 enclave实现安全启动，确保产线设备不会被恶意固件篡改。结合ECC内存和宽温级支持（-40°C 到 105°C/125°C），保障设备在恶劣的工厂环境中长期稳定运行。通过安全OTA功能，可以在不停机的情况下，远程为大批量部署的设备更新算法模型或修复漏洞。

3.2 汽车电子：数字座舱与两轮车仪表

汽车应用对功能安全、图形性能和温度范围有极致要求。

典型应用：中低端车型的独立信息娱乐系统（Head Unit）、副驾或后排娱乐显示屏、智能两轮车/电动摩托车的数字仪表盘。

设计要点：

图形性能与多显示：i.MX 937的GPU支持OpenGL ES 3.2和Vulkan，足以驱动流畅的2D/3D仪表盘动画和地图渲染。其显示接口（4-lane MIPI-DSI + 8-lane LVDS）可以灵活地驱动一个高清主屏和一个辅助屏，或者一个宽屏。在数字仪表盘中，车速、转速等关键信息的渲染应优先考虑使用实时域的2D GPU，确保极高的刷新率和确定性。
功能安全考虑：虽然i.MX 937本身可能不是按照ASIL-D这样的最高功能安全等级设计，但其内部的多域隔离架构为实现安全概念提供了基础。你可以将车辆的关键状态显示和报警功能放在实时域（M7/M33）中，与运行娱乐应用的应用域（A55）进行物理隔离。即使娱乐系统崩溃，仪表核心信息依然完好。芯片内丰富的看门狗定时器和内存ECC保护，也增强了系统的鲁棒性。
连接与扩展：通过PCIe接口连接4G/5G或C-V2X通信模组，实现网联功能。USB接口可用于连接CarPlay/Android Auto的智能手机投屏。CAN-FD接口则是与车内其他ECU（如车身控制器、动力系统）通信的标准通道。
热管理：汽车前装环境对温度要求严苛（-40°C 到 125°C结温）。设计散热方案时，需要充分考虑芯片在满负荷运行AI推理（NPU+CPU）和图形渲染（GPU）时的发热情况。合理的PCB布局、散热片甚至小型风扇可能是必要的。

3.3 高端智能家居与物联网网关

这个场景追求高集成度、AI能力、多协议融合和低待机功耗。

典型应用：智能家居中控屏、带视觉识别的安防网关、视频会议终端、高端打印机/扫描仪控制器。

设计要点：

本地AI推理：这是i.MX 937的核心价值所在。例如，在智能门禁中，你可以将人脸识别模型部署在eIQ Neutron NPU上。摄像头通过MIPI-CSI接口输入视频流，经过VPU或CPU进行预处理（缩放、归一化），然后送入NPU进行推理，整个过程完全在本地完成，响应速度快（毫秒级），且无需上传隐私数据到云端。NXP的eIQ机器学习开发环境提供了从模型训练、量化、优化到部署的全套工具链，能帮助你将TensorFlow或PyTorch模型高效地部署到NPU上。
丰富的无线连接：芯片的PCIe 3.0接口可以用来连接Wi-Fi 6/6E和蓝牙5.2模组（如NXP自家的88W9098）。两个千兆以太网口则一个用于连接家庭宽带，另一个可以用于连接本地有线设备或组成Mesh回程。这种设计让网关能够同时管理Zigbee、Thread（通过另接的协处理器）、Wi-Fi、蓝牙和有线设备，成为真正的家庭网络中枢。
低功耗设计：智能家居设备很多需要7x24小时待机。利用i.MX 937的能量弹性架构，在无事件发生时，可以让A55域和大部分外设进入深度休眠，仅由Cortex-M33域维持最低限度的监听（比如通过低功耗的SPI接口轮询门磁传感器，或通过PDM接口监听唤醒词）。当M33检测到唤醒事件后，再按需唤醒其他域，从而极大降低整体平均功耗。
多媒体与交互：对于带屏的智能中控，GPU能提供流畅的触控交互体验。VPU可以处理视频通话的编解码。高保真音频接口（I2S TDM）则能连接多麦克风阵列，用于远场语音交互和降噪。

4. 开发实战：从硬件评估到软件部署的完整路径

纸上谈兵终觉浅，我们来看看拿到一颗i.MX 937芯片后，一个典型的开发流程是怎样的，以及其中有哪些需要注意的“坑”。

4.1 硬件设计与评估起步

第一步：选择合适的评估套件。NXP通常会提供i.MX 937 FRDM开发板。这块板子是快速原型验证的利器，它会把芯片的所有主要接口都通过连接器引出来，并集成基础的外设（如DDR内存、eMMC存储、以太网PHY、USB接口等）。在项目初期，强烈建议先基于这块开发板进行软硬件可行性验证。

第二步：核心电路设计。这是硬件工程师的主战场，有几个关键点：

电源树设计：i.MX 937作为一款高性能异构处理器，需要多路、不同电压、不同时序要求的电源。仔细阅读数据手册的电源章节，使用推荐的电源管理芯片（PMIC），如NXP配套的PF系列PMIC，可以省去大量调试时间。要特别注意核心电源（如A55、GPU、NPU的VDD_SOC）的电流需求和大动态负载响应能力。
DDR内存布线：LPDDR4X/LPDDR5接口的布线是高速信号设计的关键。必须严格遵循参考设计和Layout指南，控制好阻抗、长度匹配��时序。建议使用至少6层板，并为DDR信号提供完整的地平面参考。一个稳定的内存系统是整个系统稳定的基石。
时钟与复位：确保为芯片提供稳定、低抖动的系统时钟。复位电路要保证上电时序和复位脉冲宽度符合要求，特别是要处理好硬件复位和软件看门狗复位的关系。
散热考虑：根据你的应用场景估算芯片的峰值功耗。19x19mm或15x15mm的封装，热阻是明确的。如果计算结温会超过规格，就需要在PCB上设计散热焊盘、过孔，甚至考虑附加散热片。

4.2 软件环境搭建与系统构建

NXP为i.MX系列提供了成熟的软件支持，主要围绕Yocto Project构建。

第一步：搭建Yocto开发环境。这通常是在一台Ubuntu Linux的开发主机上进行的。你需要从NXP的官方GitHub仓库获取meta-imx层（BSP层）。这个过程会下载大量的源码和工具链，对网络和磁盘空间有一定要求。一个常见的“坑”是主机Ubuntu的版本和依赖库版本必须严格匹配文档要求，否则编译过程中可能会出现各种诡异的错误。

# 示例：初始化Yocto环境（具体命令请以最新官方文档为准） repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-kirkstone -m imx-5.15.71-2.2.0.xml repo sync DISTRO=fsl-imx-xwayland MACHINE=imx93evk source imx-setup-release.sh -b build-xwayland

第二步：配置与定制镜像。Yocto的核心是bitbake命令和.conf、.bb文件。你可以通过修改local.conf文件来添加需要的软件包（如OpenCV、TensorFlow Lite、MQTT客户端等）。对于i.MX 937，关键是要正确配置机器类型（MACHINE）和选择所需的特性：

图形支持：选择X11或Wayland图形后端，以及是否包含GPU驱动（imx-gpu-viv）。
AI/ML支持：包含imx-ai或eIQ相关的包，这会集成NPU的驱动和运行时库。
实时性支持：如果你要使用Cortex-M7/M33实时域，需要额外配置和编译FreeRTOS或其它RTOS的固件。这部分通常与Linux镜像分开构建，并通过 remoteproc 或 RPMsg 框架与A55域的Linux进行通信。

第三步：驱动与外设调试。镜像构建完成后，烧录到开发板启动。接下来就是外设驱动的调试：

设备树（Device Tree）：这是Linux内核识别硬件配置的核心。你需要根据自己设计的硬件，修改设备树源文件（.dts），正确配置各个外设的引脚复用（IOMUX）、时钟、中断等。一个引脚复用冲突就可能导致某个外设无法工作。
NPU驱动验证：加载NPU内核模块（如galcore.ko）后，可以通过NXP提供的测试工具（如tensorflow-lite的示例程序，指定--use_npu）来验证NPU是否工作正常。关注推理速度和功耗，与纯CPU推理进行对比。
实时域通信：如果使用了M7/M33，需要建立它们与A55 Linux之间的通信机制。RPMsg是一个常用框架，它基于共享内存和中断，允许两个异构核心之间传递消息。你需要分别编写Linux端的用户空间程序（或内核驱动）和M7/M33端的固件，定义好通信协议。

4.3 应用开发与性能优化

当基础系统跑通后，就进入应用开发阶段。

AI应用开发流程：

模型选择与训练：在PC端使用TensorFlow/PyTorch训练你的模型。
模型转换与量化：使用NXP的eIQ Toolkit将模型转换为TensorFlow Lite格式，并进行INT8量化。量化能大幅减少模型大小、提升NPU推理速度，但可能会带来轻微的精度损失，需要在精度和性能之间做权衡测试。
模型部署：将量化后的.tflite模型文件放入嵌入式设备的文件系统。在应用程序中，链接TFLite库和NPU委托库（Delegate），在代码中指定使用NPU进行推理。
性能剖析：使用工具（如perf、armnn的profiler）分析推理过程的耗时分布。瓶颈可能出现在数据预处理（CPU）、数据搬运（DMA）还是NPU计算本身。针对瓶颈进行优化，例如使用GPU进行图像预处理，或者优化内存访问模式。

系统性能优化：

CPU热配置与调频：通过Linux的CPUfreq子系统，为A55核心配置合适的调频策略（如ondemand,performance,powersave）。在需要低延迟时锁定高频，在空闲时自动降频。
实时性优化：对于运行在A55 Linux上但仍有实时性要求的线程，可以采取以下措施：使用FIFO或RR调度策略（sched_setscheduler）、提高线程优先级、进行CPU亲和性绑定（pthread_setaffinity_np），以及使用内存锁定（mlockall）防止页面交换。但请注意，这仍然无法达到微秒级的确定性，真正的硬实时任务必须放在M7/M33上。
电源管理：合理利用芯片的休眠状态。当没有任务时，主动让系统进入mem或standby低功耗模式。外设不用时及时关闭时钟。

5. 避坑指南与常见问题排查

在实际项目中，总会遇到一些预料之外的问题。以下是一些典型问题的排查思路和经验总结。

5.1 硬件相关

问题1：系统不稳定，频繁死机或重启。

排查方向：
1. 电源完整性：这是最常见的原因。用示波器测量各路核心电源（尤其是VDD_SOC、DDR电源）在芯片高速运行（如跑AI压力测试）时的纹波。纹波过大（超过数据手册要求）会导致逻辑错误。确保电源芯片的负载瞬态响应能力足够，且输入电容、输出电容的容值和ESR符合要求。
2. DDR信号质量：使用高速示波器配合DDR探头，测量DDR时钟和数据线的眼图。检查信号过冲、下冲、振铃是否严重，眼图张开度是否足够。问题往往出在阻抗不连续、串扰或时序不匹配上。
3. 散热：触摸芯片表面是否异常烫手。使用热电偶或红外热像仪测量芯片结温（或壳温）。如果温度超过规格，系统会触发热保护而重启。需要加强散热设计。
4. 复位信号：检查复位信号是否干净，有无毛刺。确保上电时序满足芯片要求。

问题2：某个外设（如以太网、USB）无法识别或工作异常。

排查方向：
1. 设备树配置：首先检查设备树中该外设的节点是否使能，时钟、引脚复用（pinctrl）配置是否正确。一个引脚可能被多个外设复用，配置冲突会导致外设失效。
2. 物理连接与电平：检查连接器、线缆是否完好。用万用表测量PHY芯片的供电电压。对于RMII等接口，测量参考时钟（50MHz）是否正常。
3. 驱动加载：在Linux下使用lsmod查看驱动模块是否加载，使用dmesg | grep过滤该外设的关键词，查看内核启动日志中是否有相关错误信息。

5.2 软件与系统相关

问题3：NPU推理性能远低于预期。

排查方向：
1. 模型兼容性与优化：确认模型是否成功被NPU委托（Delegate）接管。查看日志，确认推理是在NPU上执行而非回退到CPU。使用NXP提供的模型检查工具，确认模型中的所有算子都已被NPU支持。某些特殊算子可能需要拆分或使用其他方式实现。
2. 数据搬运瓶颈：NPU计算很快，但如果输入数据（如图片）从摄像头到内存，再到NPU内部存储器的路径太长或格式不对，就会成为瓶颈。尝试使用零拷贝（zero-copy）技术，或者使用芯片的VDMA、图像处理单元（如ISP）直接将数据搬运到NPU友好的内存格式和地址。
3. 频率与功耗设置：检查NPU的时钟频率是否已经开到最高性能档位。有些BSP默认可能为了省电，将NPU运行在较低频率下。

问题4：实时域（M7）与Linux应用域（A55）通信延迟大或不稳定。

排查方向：
1. RPMsg链路配置：确认Linux内核中已正确配置��RPMsg驱动和对应的virtio设备。检查/sys/class/rpmsg/目录下是否存在对应的设备节点。
2. 共享内存与缓存一致性：确保用于通信的共享内存区域被正确配置为“非缓存”（non-cacheable）或“写回”（write-back）并通过软件维护缓存一致性。如果缓存配置错误，一方写入的数据另一方可能看不到。在Linux端，通常需要使用dma_alloc_coherent或remoteproc框架分配的内存。
3. 中断处理延迟：在M7端发送消息后触发Linux端的中断。测量从M7触发中断到Linux用户空间程序收到消息的总时间。如果延迟过大，检查Linux内核的配置（是否开启了CONFIG_PREEMPT抢占），以及接收线程的优先级和调度策略。

问题5：系统启动失败，卡在U-Boot或内核阶段。

排查方向：
1. 串口日志：这是最重要的调试手段。确保串口线连接正确，波特率设置对（通常是115200）。从头到尾仔细阅读启动日志，错误信息通常会明确指出问题所在，如“DRAM init failed”、“Wrong image format”等。
2. 镜像验证：确认烧录的镜像（U-Boot、设备树、内核）是针对你的具体板卡（MACHINE）编译的。不同板子的DDR配置、外设可能不同，镜像不匹配会导致无法启动。
3. 启动介质：如果是通过SD卡启动，检查SD卡是否完好，镜像是否正确烧录到卡的正确分区（通常U-Boot需要放在未分区的前端，而内核和根文件系统放在FAT或EXT4分区）。

5.3 安全与生产

问题6：如何安全地部署和管理大量设备？

解决方案：充分利用EdgeLock安全 enclave和EdgeLock 2GO服务。
1. 安全启动：在芯片出厂前或生产线上，通过安全 enclave 烧录根密钥。此后，芯片在每次启动时，都会逐级验证引导程序（U-Boot）、内核、根文件系统的数字签名，确保固件未被篡改。
2. 安全供应：通过EdgeLock 2GO云服务，可以为每一颗芯片在产线端注入唯一的设备身份凭证（如私钥、证书）。这个过程是自动化和受保护的。
3. 安全OTA：设备在野外部署后，可以使用基于证书的双向认证（mTLS）与你的升级服务器建立安全连接。下载的升级包经过加密和签名，由安全 enclave 验证通过后，在一个隔离的环境中更新，即使升级中途断电，也有回滚机制防止设备变砖。

问题7：如何保证产品的长期供货和兼容性？

策略：i.MX 937的引脚兼容性和15年供货承诺是两大保障。
- 在设计初期，尽量使用i.MX 95系列参考设计中推荐的、生命周期长的外围器件（如DDR、PMIC）。
- 在PCB布局时，即使当前使用19x19mm封装，也考虑未来可能换用15x15mm封装时的兼容性设计（可能需要一个兼容焊盘）。
- 将硬件依赖的代码（如设备树、引脚配置）与业务逻辑代码分离，便于未来硬件变更时进行适配。

最后，我想分享一点个人体会。像i.MX 937这样高度集成的异构处理器，其强大之处在于它提供了一个“一站式”的边缘智能解决方案。但这也意味着，开发者需要具备更全面的知识栈：从高速电路设计、电源管理，到Linux内核、设备树，再到实时操作系统、AI模型部署，甚至安全协议。我的建议是，不要试图一个人掌握所有细节，而是要组建或融入一个具备跨领域技能的团队，或者善用芯片厂商和社区提供的丰富资源——参考设计、软件SDK、论坛和培训。从评估板开始，快速搭建一个最小可用的原型，然后逐个验证你关心的核心功能（比如AI推理帧率、实时控制延迟、多屏显示），在迭代中加深对芯片的理解，这样才能最终打造出一款稳定、高效、有竞争力的边缘智能产品。