嵌入式工控平台升级实战：从EM9161到EM9171的平滑迁移指南
1. 项目概述：从EM9161到EM9171的平滑升级之路
在嵌入式工控领域，硬件平台的迭代往往牵一发而动全身。几年前，我们基于英创公司的EM9161和EM9161G工控板开发了一套数据采集与控制系统，其稳定的WinCE 5.0平台和成熟的性能，在多个现场项目中表现可靠。然而，随着应用场景对数据处理速度、响应时间和存储容量提出了更高要求，原有的200MHz/266MHz主频和64MB Flash逐渐显得捉襟见肘。当得知英创推出了引脚与功能100%兼容的升级型号EM9171时，我们团队第一时间进行了评估与迁移。这次升级的核心目标非常明确：在不改动原有硬件电路板设计的前提下，通过更换核心主板，获得CPU性能翻倍、启动速度提升近一倍、并拥有更大存储空间和更先进USB接口的新平台，同时要确保我们积累的大量应用软件能够平稳过渡。
这不仅仅是一次简单的芯片替换，更是一次涉及操作系统内核（从WinCE 5.0到WinCE 6.0）、开发环境（从EVC到VS2005/2008）以及底层驱动接口适配的系统性工程。幸运的是，英创官方对驱动层进行了重新封装，最大程度保持了接口一致性，这为我们节省了大量底层适配工作。但即便如此，在实际迁移过程中，我们依然遇到了不少从开发环境配置、库文件链接到具体API调用的“坑”。本文将基于我们完整的迁移实践，详细拆解从EM9161升级到EM9171的全过程，重点分享在软件移植环节的关键步骤、常见问题及解决方案，旨在为面临同样升级需求的工程师提供一份可直接参考的“避坑指南”。
2. 升级核心优势与硬件兼容性解析
2.1 性能参数对比与升级价值评估
决定升级前，必须清晰量化新平台带来的收益。EM9171相对于EM9161系列的提升是全方位的，下表直观展示了关键参数的对比：
| 参数项目 | EM9161 | EM9161G | EM9171 | 升级收益分析 |
|---|---|---|---|---|
| CPU | SAM9261 (ARM9) | SAM9G10 (ARM9) | iMX257 (ARM9) | 架构同属ARM9，但iMX257系列在工艺和内核优化上更先进，为性能提升奠定基础。 |
| 主频 | 200MHz | 266MHz | 400MHz | 核心算力显著提升，对于复杂算法、实时数据处理等场景，性能提升感知明显。 |
| FLASH | 64MB | 64MB | 128MB (2GB可选) | 默认容量翻倍，可存储更大的应用程序、更多历史数据或更复杂的配置文件。2GB选项为海量数据本地存储需求打开了可能。 |
| RAM | 64MB | 64MB | 64MB | 内存容量保持不变，在迁移时需注意应用程序的内存使用峰值，避免因性能提升后处理数据量增大而导致内存不足。 |
| 操作系统 | WinCE 5.0 | WinCE 5.0 | WinCE 6.0 | 系统内核升级，带来了更好的实时性、内存管理以及内核服务。这是软件移植中需要应对的主要变化点。 |
| USB | 1.1 | 1.1 | 2.0 | 从全速（12Mbps）到高速（480Mbps）的飞跃，极大提升了与外置U盘、摄像头、扫描枪等设备的数据交换效率。 |
| 启动时间 | 约15秒 | 约15秒 | 约8秒 | 启动速度提升近一倍，对于需要快速上电恢复运行的设备（如户外终端、应急设备）意义重大。这得益于iMX257更快的初始化速度以及WinCE 6.0的BinFS文件系统优化。 |
从表格分析可以看出，升级的核心价值在于性能、存储与I/O速度的全面提升。对于原有系统已接近性能瓶颈的项目，例如图像预处理速度慢、大数据包网络传输卡顿、或需要缓存大量采样数据的情况，升级到EM9171能带来立竿见影的效果。而100%的硬件引脚兼容性，意味着升级成本几乎仅为核心板的差价，无需重新设计、制版和焊接底板，这是本次升级最具吸引力的地方。
2.2 硬件替换实操与注意事项
硬件替换本身是升级过程中最简单的一步，但细节决定成败。
操作步骤：
- 断电与防静电：确保整个设备完全断电。操作人员佩戴防静电手环，或触摸接地的金属物体释放静电，避免高压静电击穿CMOS器件。
- 拆卸旧板：使用合适的螺丝刀卸下固定EM9161核心板的螺丝。注意核心板与底板之间通常通过高密度的板对板连接器（Board-to-Board Connector）或邮票孔焊接。如果是插接式连接器，需轻轻垂直向上用力拔起；若是焊接式，则需要使用热风枪等工具进行解焊，此操作建议由熟练的焊接工程师完成。
- 安装新板：将EM9171核心板对准底板的连接器或焊盘。对于插接式，确保方向正确（通常有防呆设计，如缺口、色标）后，垂直均匀用力按压直至完全就位。对于焊接式，则需要精准对位后回流焊接。
- 固定与复查：用螺丝固定好核心板。仔细检查所有连接器是否插紧，有无引脚弯曲或错位。特别检查电源、复位等关键信号的连接。
注意：尽管引脚100%兼容，但在首次上电前，务必核对底板原理图与EM9171的最新数据手册。重点检查电源轨的电流需求。iMX257在400MHz全速运行时的功耗可能高于之前的SAM9261/9G10，需确认底板电源电路能否提供充足、稳定的电流，特别是核心电压（如1.2V）。我们曾遇到因底板电源芯片带载能力不足，导致EM9171在满载运行时偶发重启的情况。建议使用示波器监测上电瞬间和满载运行时的电源纹波。
3. 软件开发环境迁移与工程改造
这是升级过程中最具挑战性的部分，核心是从Windows CE 5.0的旧生态迁移到Windows CE 6.0的新生态。
3.1 开发工具升级：从EVC到Visual Studio
EM9161时代的主流开发工具是Embedded Visual C++ 4.0 (EVC)，而WinCE 6.0的开发需使用Visual Studio 2005或2008，并安装对应的Windows Embedded CE 6.0 Platform Builder或SDK。
迁移第一步：工程转换
- 在Visual Studio 2005/2008中，直接打开EVC的
.vcp或.vbg工程文件，VS会启动转换向导。 - 转换后，首先会面临编译环境配置问题。在项目属性中，需要将“平台”从原来的“Pocket PC 2003”或“Windows CE 5.0”更改为对应的“EM9171 SDK”。这个SDK需要向英创公司索取或从其官网下载，它包含了EM9171正确的头文件、库文件以及目标设备的连接配置。
- 在“配置属性” -> “常规”中，将“MFC的使用”从默认的“在共享DLL中使用MFC”改为“在静态库中使用MFC”。这是因为目标设备（EM9171）上的WinCE 6.0系统可能未包含与你开发环境完全匹配的MFC运行时DLL，静态链接能将所需的MFC代码直接打包进你的EXE，避免在设备上因缺少
mfcce500.dll（CE 5.0）或mfcce600.dll（CE 6.0）而无法运行。
3.2 代码层面的关键修改点
工程转换后直接编译，几乎百分之百会报错。需要系统性地处理以下几类问题：
1. 资源文件编译错误这是最常见的问题。EVC工程中的资源文件（.rc）通常包含一行：
#include "wceres.rc" // WCE-specific components在WinCE 6.0的编译环境中，这行代码会导致编译失败。解决方案是将其注释掉：
// #include "wceres.rc" // WCE-specific components这是因为VS2005/2008对于Windows CE资源的管理方式已经改变，不再需要这个特定的包含文件。
2. ATL库的差异Windows CE 5.0和6.0的ATL（Active Template Library）库版本不同，一些函数签名或内部实现可能有变。如果代码中使用了ATL，可能会遇到链接错误或运行时错误。例如，某些CString方法的行为可能微调。我们的经验是：
- 对于编译链接错误，根据错误信息查找对应的函数或类，查阅MSDN中针对Windows CE 6.0的文档，调整用法。
- 对于运行时问题，需要加强对涉及ATL代码段的测试，特别是字符串处理和COM对象生命周期管理部分。
3. 编译器差异与语法严格化VS2005/2008的编译器比EVC的更严格。一些在EVC下只是警告的代码，在新编译器下可能直接报错。常见的有：
- 指针类型转换：更严格的
static_cast、reinterpret_cast要求。 - 函数安全性：如
sprintf会被提示不安全，建议改用sprintf_s（如果运行时库支持）或进行长度检查。 - 变量作用域：在
for循环初始化部分声明的变量，其作用域在旧标准下可能不同。需要仔细检查并修正这类代码。
4. 驱动接口库的替换（最关键的一步）英创官方为了兼容性，为EM9171提供了重新封装的驱动库，其接口与EM9161的完全一致，但库文件名称后增加了“Ex”后缀（例如EM91XX.lib变为EM91XXEx.lib，EM91XX.dll变为EM91XXEx.dll）。
- 在项目属性 -> “链接器” -> “输入” -> “附加依赖项”中，将原有的
EM91XX.lib等库名称替换为EM91XXEx.lib。 - 在代码中，所有显式加载DLL的函数（如
LoadLibrary(_T(“EM91XX.dll”))）也需要将DLL名称改为EM91XXEx.dll。 - 重要机制：
Ex版本的库内部实现了板卡型号的自动检测。这意味着，当你使用EM91XXEx.lib编译程序后，生成的可执行文件既能运行在EM9161上，也能运行在EM9171上。库函数内部会根据读取的硬件ID，自动调用对应平台的底层驱动。这实现了二进制级别的向后兼容，是本次升级中最精妙的设计。
4. 系统构建与部署实战
完成代码修改和编译配置后，下一步就是为EM9171构建运行时映像（NK.bin）和部署应用程序。
4.1 获取并定制WinCE 6.0 BSP与SDK
英创公司会提供针对EM9171的板级支持包（BSP）和软件开发工具包（SDK）。
- 安装BSP：将BSP包导入到你的Platform Builder for CE 6.0开发环境中。这个BSP包含了EM9171所有硬件（如iMX257 CPU、网卡、USB、GPIO等）的驱动源码和配置文件。
- 定制系统映像：使用Platform Builder，基于该BSP创建一个新的操作系统设计（OS Design）。在这里，你可以像搭积木一样选择需要的系统组件：
- 核心功能：必须包含.NET Compact Framework（如果你的应用基于.NET CF）、必要的字体、文件系统支持。
- 驱动与协议：勾选你需要的驱动，如USB Host/Function、以太网、SD卡、显示屏驱动等。
- Shell：选择是否包含图形Shell（如标准Shell）或最小化Shell。
- 我们的选择：为了追求8秒快速启动，我们选择了BinFS文件系统作为启动卷。BinFS将核心系统文件以线性方式存储，显著减少了文件系统初始化的开销。在“File System”配置中，需要明确启用BinFS并正确设置其参数。
- 生成SDK：基于定制的OS Design，生成一个对应的SDK。这个SDK就是你之前在Visual Studio中为应用程序项目选择的那个目标SDK。它确保了应用程序与你的定制系统在API层面完全匹配。
4.2 系统烧录与应用程序部署
- 烧录Bootloader和NK.bin：EM9171通常通过USB或以太网口进行系统烧录。你需要使用英创提供的烧录工具（如DNW或特定工具），先将Eboot（以太网引导程序）烧写到板载Flash的指定位置，然后通过Eboot的TFTP或USB下载功能，将编译好的NK.bin文件烧写到Flash中。
- 部署应用程序：系统启动后，可以通过多种方式部署你的EXE和依赖的DLL：
- ActiveSync / Windows Mobile设备中心：通过USB连接，直接复制文件到设备磁盘。
- 以太网共享：在设备上开启文件共享，通过网络邻居拷贝。
- SD卡/U盘：将文件复制到存储介质，再插入设备运行。
- 定制化集成：最彻底的方式是将你的应用程序作为系统服务（Service）或启动项直接编译进NK.bin。这样应用程序在系统启动后会自动运行，并且与系统融为一体，无法被用户轻易删除。这需要在Platform Builder的OS Design中，将你的应用添加到“Project.bib”和“Project.reg”文件中，并指定其启动方式。
5. 迁移过程中的典型问题与深度排查
即使按照上述步骤操作，在实际迁移中仍会遇到一些棘手问题。以下是我们遇到的几个典型案例及解决思路。
5.1 程序在EM9171上崩溃或无法启动
- 症状：在EM9161上运行正常的程序，在EM9171上点击后无反应，或启动瞬间崩溃。
- 排查思路：
- 检查库链接：首先确认程序是否链接了正确的
Ex版本库，并且部署到设备上的DLL也是Ex版本。可以使用depends工具（或VS的模块加载日志）检查运行时加载的DLL。 - 确认MFC链接方式：这是最常见的原因。务必确保项目属性中MFC为静态链接。动态链接在设备缺少对应版本MFC DLL时会失败。
- 检查系统组件依赖：你的程序可能依赖了某个特定的系统组件（如某个COM对象、图形特效库），而这个组件在你定制的WinCE 6.0系统映像中没有被包含。回顾OS Design的组件选择列表，添加可能缺失的组件。
- 使用远程调试：在VS中配置好与EM9171的ActiveSync/网络连接，进行远程调试。在程序入口点（如
WinMain）设置断点，看能否进入。如果不能，往往是启动阶段的初始化代码（如全局对象构造）出了问题。如果能进入但在某处崩溃，通过调用堆栈可以精确定位问题代码。
- 检查库链接：首先确认程序是否链接了正确的
5.2 硬件相关功能异常（如串口、GPIO不工作）
- 症状：调用与EM9161相同的串口发送/接收API，或GPIO控制API，但硬件无响应。
- 排查思路：
- 确认驱动加载：虽然接口一致，但底层驱动不同。首先检查设备启动日志（可通过超级终端连接调试串口查看），确认相关硬件驱动（如COM3:、GPIO）是否成功加载，有无报错信息。
- 核对物理映射：EM9171的iMX257芯片其外设（如UART、GPIO Bank）的物理地址和中断号可能与EM9161的SAM9261不同。英创的
Ex驱动库应该已经处理了这些差异。但如果你的程序中有直接进行硬件寄存器操作的“野路子”代码（绕过官方API），这部分代码必然失效，需要根据EM9171的芯片手册重写。 - 检查电源与引脚复用：iMX257的引脚通常具有多重功能（复用）。确保在系统BSP的配置中，你所使用的串口或GPIO引脚已经被正确初始化为所需的功能模式（例如，UART模式而非GPIO模式）。这需要在Platform Builder中检查BSP的
platform.reg或相关配置文件。
5.3 性能提升未达预期
- 症状：更换EM9171后，感觉程序运行速度没有达到CPU主频翻倍应有的提升。
- 排查思路：
- 瓶颈分析：使用性能分析工具（如远程性能探查器）或添加高精度计时器，定位程序的热点代码。瓶颈可能不在CPU，而在I/O（如低速SD卡读写、网络延迟）或算法复杂度上。
- 编译器优化：检查VS项目属性中的“优化”选项。在Release版本中，可以尝试开启更激进的优化（如
/O2最大化速度）。注意，优化可能会影响调试。 - 内存访问：ARM9架构没有缓存一致性问题的困扰，但内存带宽是共享的。如果程序频繁进行大规模内存拷贝，可能会成为瓶颈。考虑优化数据结构，减少不必要的拷贝。
- 系统负载：检查定制的WinCE 6.0系统是否运行了不必要的后台服务或进程，占用了CPU资源。精简系统映像，只保留必需组件。
从EM9161迁移到EM9171，是一次典型的嵌入式硬件平台纵向升级案例。其“硬件兼容、软件适配”的模式，最大程度保护了用户的硬件投资和软件资产。整个迁移工作的重心，完全落在了软件开发环境的升级和代码的适配改造上。其中，官方提供的兼容性Ex驱动库是平滑过渡的基石，它解决了最复杂的底层硬件差异问题。而开发者需要攻克的主要是WinCE 5.0到6.0的开发工具链变迁、系统组件差异以及编译器带来的代码规范问题。
这次升级给我们的启示是，在进行嵌入式平台选型时，不仅要关注当前的性能参数，更要考察厂商的长期生态支持和技术演进路径。像这种提供引脚兼容升级路径的方案，能显著延长产品线的生命周期，降低长期维护成本。最终，我们成功将多个项目平稳迁移至EM9171平台，系统响应速度和数据处理能力得到了显著提升，而硬件改造成本几乎为零，这无疑是一次非常成功的升级实践。