做嵌入式产品的软件开发时，我们会经常遇到因为成本、交期或芯片资源紧张等原因更换MCU平台的情况，加上不同MCU厂商在芯片外设、寄存器和库函数接口等方面的命名规则和名称又不一样，这个时候就肯定会涉及到代码跨平台移植操作。其实，代码移植是一个比较耗费精力和磨性子的过程，可能会让人“发狂”；这个时候，如果你的代码框架在起初设计时就考虑了后续可能会出现的代码跨平台移植这个可能性，那你的代码移植工作量就会大大减少了。
那什么样的软件框架有利于代码移植呢？下面给出一个比较适用于刚出校门入职场的软件同仁们的参考框架，我们一起来看看吧！
代码一定要分层设计，切忌把全部文件放在同一个文件夹下面，最简单的就是区分一下代码层次：
应用层：主要实现业务逻辑，不涉及与MCU平台相关的操作；
MCU驱动层：可以称为BSP（板级支持包）层，主要实现MCU外设驱动代码；
外置芯片驱动层：主要实现与MCU通过总线等方式进行通信的芯片驱动代码；
固件库层：MCU芯片的固件库源文件；
协议层：如果有标准协议，可以单独建个文件夹存放。
根据以上描述，基本上可以按如下拓扑进行设计：
app文件夹下面以模块化的方式实现需要的应用功能，一个功能/模块对应一个源文件+一个头文件，可以用app_功能名称命名源文件和头文件：
main.c文件可以直接放到app文件夹下面。
bsp文件夹下面以区分外设的方式实现需要的芯片驱动，可以用bsp_外设名称命名源文件和头文件：
并且尽量用宏定义方式在头文件里申明GPIO和引脚配置信息，类似下面代码：
MCU芯片处理中断向量表的源文件也可以放到bsp文件夹下面。
driver文件夹下面以区分外置芯片的方式实现需要的芯片驱动，可以用芯片名称来命名源文件和头文件：
并且尽量用宏定义方式在头文件里申明与MCU平台相关的信息，包括GPIO和库函数操作等，后续移植时仅需要修改头文件即可，类似下面操作：
宏定义的越详细越具体，代码移植修改时会越简单越方便。
libraries文件夹下面存放固件库文件：
另外，在设计工程时，可以新建两个文件夹，把固件库文件区分开（外设文件+启动文件）：
ethercat文件夹存放协议文件，直接用协议名称命名该文件夹即可，比如wifi、tcp_ip等：
通过以上的分层和解耦设计，在执行代码移植时，你只需要以下的几个操作步骤即可完成大部分的代码移植：
1、直接把固件库全部替换；
2、修改bsp相关文件，这块的工作量相对来说是最大的；
3、修改driver里面的驱动头文件，其源文件不需要任何修改；
4、修改工程配置里的库文件包含信息。
通过以上的几个移植修改步骤，基本上就完成了代码跨平台移植，编译后可能还会出现个别报错，再修改修改就可以了，毕竟代码移植的第一步就是要让你的代码编译通过，然后再慢慢调试功能即可。
当然软件框架的设计还可以继续深入，比如把MCU底层配置抽象出来并形成一个独立的文件，这样外置芯片驱动的头文件可能都不需要修改了，而只需要修改MCU底层配置文件即可；或者把包括排序算法、滤波算法等通用的算法以API接口的方式封装起来并放到一个源文件里等等。
比如封装GPIO名称：
目前是在驱动代码头文件里按如下方式申明：可以把GPIOB封装到单独的通用头文件（commonHeader.h）里，并按如下方式命名：而驱动头文件里修改如下：如此操作后，代码移植时，只需要修改commonHeader.h文件即可。
其他宏定义的封装操作类似。
复制
#define IS3980S_GPIO GPIOB
复制
#define IS3980S_MCU_GPIO GPIOB
复制
#define IS3980S_GPIO IS3980S_MCU_GPIO
其他宏定义的封装操作类似。
以上是作者针对如何降低代码跨平台移植的工作量的实操经验和拙见，希望对你有用！
。
---------------------
作者：dffzh
链接：https://bbs.21ic.com/icview-3457334-1-1.html
来源：21ic.com
此文章已获得原创/原创奖标签，著作权归21ic所有，任何人未经允许禁止转载。
、膳食营养规划【附源码+文档，调试定制服务】)
