要做到嵌入式应用的代码逻辑清晰,且避免重复的造轮子,没有好的应用架构怎么行。
如果没有好的架构,移植将会是一件很痛苦的事情。
如果没有好的架构,复用是最大的难题,没法更大限度的复用原有的代码。
如果没有好的架构,一旦驱动改了,所有的地方都要改,费时费力且很容易出错。
如果没有好的架构,应用层中穿插着硬件驱动层的代码,看着会是一片混乱,逻辑不清,代码维护起来会很困难。
这里总结下我的嵌入式程序设计思路,分享出来与大家共同探讨,同时也欢迎提出不同意见。
现在的小朋友都爱玩搭积木的游戏,一个模块一个模块的拼装起来,快速组成各种不同的模型。
现在的产品设计也很少从零开始。大都复用现有成熟的模块,专注于某个擅长领域。
我的嵌入式应用架构思路来源与此,即功能模块设计与分层。
把API分为驱动层和应用层API,而不是所有程序都调用驱动层API。(整个应用中都调用驱动层API会导致应用中驱动调用随处可见,无法移植和最大限度的复用)
先把一个应用进行功能模块划分,并对整体结构进行分层,然后设计出功能独立的各个模块(如算法模块,文件库模块,通信库模块),在模块之上开放公共接口。
驱动层提供出公共接口供上层调用。各个功能模块可以独立编译(如算法模块纯ANSI C,可在任意平台复用),或者调用驱动层接口(文件库模块调用了驱动读写Flash),总而言之,言而总之,封装出各个功能独立的可复用的功能模块。
总体分 硬件驱动层--》功能模块层--》应用接口层--》业务逻辑层--》应用层
总体结构示意框图:
应用层,为程序的总体的运行框架,组织调用业务逻辑。可以用某种嵌入式操作系统实现几种任务 。如定时任务,卡处理任务,菜单任务,通信任务。
业务逻辑层,如CPU卡处理,交通部卡处理,银联卡处理,M1卡处理,通信记录上传,黑名单下载,票价参数下载等。
应用接口层,提供公共的api接口供应用接口供上层调用。这些接口也可由下层的功能模块开放出来,应用接口层负责汇总。
功能模块层,可以封装不同的功能模块。如算法库,文件库,通信库,银联库,向上提供应用接口层的接口,向下调用驱动接口。
硬件驱动层,由各个驱动模块组成,向上提供统一的接口。
遵循一些约定,
1.每个模块提供出的接口要统一,后续只能增,不能改原来的接口。
2.模块与模块之间相互独立,互不影响,不能相互调用,只能调用它下层的接口。
3.由模块构成层,层与层之间不能跨级调用。如在应用层中不能看到直接调用驱动层的代码。
4.模块中又可以继续分层,如接口层,驱动层,硬件层。
如果驱动变动了,或者换不同平台,只需更改驱动层,应用层不受影响。
如果功能模块变动了,只需升级功能功能模块,其他的模块不受影响,应用层也不受影响。
按照这种逻辑设计好之后,主要的工作就是在业务逻辑层。应用层则为程序的总体流程和框架,主要调用业务逻辑层实现不同的功能。
我们现在的代码结构,基本是按这个思路来的。
硬件驱动层--》功能模块层--》应用接口层--》业务逻辑层--》应用层。
看看以下两种风格的代码,你更喜欢哪个。
另一种风格:
同样是保存参数,非要拆成 AlgCRC16 ,WritePraFlash( (unsigned char *)&NetPra , NETPRA_ADDR , sizeof(_NetPra) )两步吗?
还有AH_Para_Verify这个,在应用层中真是多余啊,检测失败又从Flash读取。关于参数,一开机就应该检测合法性了。
既然都是要保存参数,就应该做个封装,如上图所示,把系统用到的不同参数做个规划。应用层调用APP_Open_UseFile 或者APP_Read_UseFile,
而不是直接的去读写Flash。
来看看赫赫有名的谷歌的android架构,虽然很复杂,但从框图上看,也像是搭积木,各个功能模块独立,层次分明。最低层建立在linux Kernel基础上,然后是各个组件库libraries,再往上是应用框架和应用。
以NC_FileLib,文件库模块为例,如果要用在其他平台,如EH0918手持机设备,只需要移植几个硬件层接口即可。
NC_FileSys文件库,跟硬件相关的接口在Hook文件夹,
void HW_FRAM_Init( void )
unsigned int HW_FRAM_Read( unsigned int addr,unsigned
int size,unsigned char *buffer)
unsigned int HW_FRAM_Write( unsigned int addr,
unsigned int size,unsigned char *buffer )
//擦除FLASH一页 (FLASH擦除的最小单元)
unsigned int HW_Flash_PageErase( unsigned int page )
unsigned int HW_Flash_Read( unsigned int addr,
unsigned int size, unsigned char *buffer )
unsigned int HW_Flash_NotEraseWrite( unsigned
int addr, unsigned int size, unsigned char *buffer )
//擦除FLASH一页 (FLASH擦除的最小单元)
unsigned int HW_Flash_PageErase( unsigned int page )
按照以上模块化设计思想,很容易实现一vwin pos机。
以开发一个智能pos应用为例:
一个智能pos涉及到的功能模块有:
读写卡功能,保存与读取消费记录,查找保存黑名单,界面显示,菜单显示,通信下载参数上传记录等。
以下为移植功能模块到电脑上,自己做的一个模拟Pos工具:
在电脑上实现一模拟pos(只是功能上的实现,完成刷卡消费,记录存储,记录上传,黑名单,票价下载等功能。界面为Dos窗口。后续如果用QT把界面也做出来,就是一功能齐全的模拟POS机,不过得把荒废多年的C++重新拾起来了。可以继续完善做一个上位机模拟pos,改变编译器在上位机仿真调试并交叉编译后运行在真实POS上)。
用到的功能模块有 文件存储模块,卡处理模块,算法模块,银联库模块。我把这些模块移植到电脑上。
关于卡处理模块的实现,由于电脑上没读卡头,于是用外接读卡器。把读卡器串口接电脑上。电脑上做一读写卡服务,提供TCP接口的读写卡接口。
移植文件库,嵌入式程序中是操作的flash,在电脑上把文件库中用到的接口用读写文件的形式替换。
移植算法库,算法库都是c写的,直接用gcc在windows平台重新编译即可。
评论
查看更多