外设对于系统迁移至关重要。
许多设计首先会明确系统将提供的功能以及用户访问这些功能的方式。
这将决定所需的电路以及需要集成到微控制器中的外设，以便控制这些功能。例如，如果设计人员想要集成一个工业人机界面 (HMI)，则微控制器需要支持 LCD 显示屏和一些按钮或触摸屏；机器通信接口；LED 指示灯；以及声音报警器或其他音频组件。因此，微控制器需要集成一个用于通信的 CAN 控制器；一个用于触摸屏的 A/D 转换器；以及一个用于声音报警器的 PWM 定时器。外设的功能越强大，所需的外部电路就越少，这可以减少设计人员需要编写的代码量。因此，对于声音报警器而言，通过调节 PWM 即可轻松实现相同的效果。
通常，设计人员想了解内核的两个基本信息：它的速度是否足够快，能够执行支持最终产品所有功能所需的所有软件任务？以及它能否高效地执行所有这些任务？如果这两个问题的答案都是肯定的，那么大多数设计人员就不会太在意所使用的内核类型。.
更重要的是，有多少现有的软件和固件可以从一个内核迁移到另一个内核以提供外设支持。由于大多数 32 位微控制器代码都是用 C 语言编写的，因此其中很多代码可以重新编译以适配任何内核。然而，无论使用何种内核，每个微控制器制造商都会有其产品独有的外设功能和编程模型。这正是代码可移植性面临的挑战。.
固件可移植性：
每个微控制器制造商都会提供一个固件库，其中包含用于配置和运行其微控制器集成外设的代码。然而，每个制造商对这些外设的实现方式各不相同，而且每个外设的功能也可能不同。这意味着将应用程序从一个微控制器移植到另一个微控制器并非易事。
ARM 通过定义一个名为 Cortex™ 微控制器软件接口标准 (CMSIS) 的标准固件抽象层来解决这个问题。所有使用 Cortex-M 内核的微控制器制造商都采用了该标准，并将其应用于各自的固件库中。然而，该标准并未解决外设可移植性方面的挑战，也没有为变量或函数建立标准的命名约定。因此，它对减少在不同 ARM 微控制器供应商之间移植应用程序所需的工作量几乎没有帮助。.
可移植性项目：
尽管微控制器供应商可能使用相同的 ARM 内核，但他们没有动力简化向其他供应商微控制器的移植过程。因此，实现设计可移植性的挑战落在了设计工程师身上。为了简化移植过程，设计人员可以实现一个抽象层，在微控制器、外围硬件和应用程序代码之间创建标准编程接口。至少有两种方法可以实现这一点：
- 可以开发一个补偿层或覆盖层，用于在微控制器制造商的外设库和应用程序代码之间进行转换。虽然这可能是最省时的解决方案，但会增加命令和数据路径中的代码量。-
定义一个标准的函数和变量命名方法，并将其应用于每个外设库。虽然这可以避免增加代码量，但可能会很耗时，尤其是在处理复杂的外设时。
可移植性必须从开发初期就纳入考量。除了固件/软件之外，引脚兼容性也是一个重要问题，这通常意味着在更换微控制器供应商时需要重新布局印刷电路板。此外，电容器和稳压器等外部元件也可能需要更换。.
实际可移植性：
在不同厂商的32位微控制器之间轻松移植一直是业界的愿望，直到外设和固件库的可移植性问题得到解决。在此之前，设计人员必须负责其设计的可移植性。一种缓解方法是选择一款便于在同一厂商产品线内与其他微控制器迁移的微控制器。
例如，Microchip 近期推出了 MPLAB® XC 软件包，简化了其 C 编译器产品组合。该软件包为其 8 位、16 位和 32 位架构分别提供编译器，并支持所有 PIC® 微控制器和 dsPIC® 数字信号控制器 (DSC)。此外，它还具备跨架构兼容性，可节省代码开发成本；同时支持多封装引脚，可简化印刷电路板布局，方便直接替换，使其成为此类应用的理想之选。.
因此，虽然设计人员仍在等待标准内核与标准外围设备和固件配套完善，但他们至少可以通过在每个项目开始时评估迁移到单一制造商产品目录的成本/收益比，来制定面向未来的设计。.
