信盈达分享嵌入式应用程序设计的一些思路

做嵌入式应用开发，如果没有好的应用架构会是一个很大的烦恼，信盈达小编带大家分享嵌入式程序设计的一些思路

如果没有好的架构，移植将会是一件很痛苦的事情。

如果没有好的架构，复用是最大的难题，没法更大限度的复用原有的代码。

如果没有好的架构，一旦驱动改了，所有的地方都要改，费时费力且很容易出错。

如果没有好的架构，应用层中穿插着硬件驱动层的代码，看着会是一片混乱，逻辑不清，代码维护起来会很困难。

 

现在的小朋友都爱玩搭积木的游戏，一个模块一个模块的拼装起来，快速组成各种不同的模型。现在的产品设计也很少从零开始。大都复用现有成熟的模块，专注于某个擅长领域。

要做到嵌入式应用的代码逻辑清晰，且避免重复的造轮子，没有好的应用架构怎么行！

把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 )

 

按照以上模块化设计思想，很容易实现一模拟pos机：

以开发一个智能pos应用为例：

一个智能pos涉及到的功能模块有：

读写卡功能，保存与读取消费记录，查找保存黑名单，界面显示，菜单显示，通信下载参数上传记录等。

在电脑上实现一模拟pos用到的功能模块有 文件存储模块，卡处理模块，算法模块，银联库模块。我把这些模块移植到电脑上。

 

只是功能上的实现,完成刷卡消费，记录存储，记录上传，黑名单，票价下载等功能。界面为Dos窗口。后续如果用QT把界面也做出来，就是一功能齐全的模拟POS机，不过得把荒废多年的C++重新拾起来了。可以继续完善做一个上位机模拟pos，改变编译器在上位机仿真调试并交叉编译后运行在真实POS上。

 

关于卡处理模块的实现，由于电脑上没读卡头，于是用外接读卡器。把读卡器串口接电脑上。电脑上做一读写卡服务，提供TCP接口的读写卡接口。

 

移植文件库，嵌入式程序中是操作的flash,在电脑上把文件库中用到的接口用读写文件的形式替换。

 

移植算法库，算法库都是c写的，直接用gcc在windows平台重新编译即可。

 

各个功能模块，又可以进一步细分为子模块。

 

拿通信库举例：

嵌入式设备都需要支持各种不同的通讯模块。比如硬件设备有A701、A801、B502等，通讯模块有GL868、MG323、MC8630、N710、ZIGBEE等，这些设备分别支持全部或部分通讯模块。

 

整体架构分为如下：

 

 

 

驱动大致分为三层：

1、接口层：为用户提供统一的接口，比如：Connect、TxData、RxData、Disconnect等。

2、驱动层：向接口层暴露统一的接口，这些接口用于完成实际的连接断开和数据收发等，比如：DevConnect、DevTxData、RxData、Disconnect等。该层只会和支持的通讯模块相关，不会直接访问任何硬件功能，包括串口通讯、GPIO控制全部通过底层的设备层实现。

3、设备层：向驱动层提供统一的接口，这些接口通过访问物理硬件来实现和模块的通讯，比如：XXXPowerOn、SerialSend、SerialReceive等，并定义该设备支持哪些模块。

 

对于部分编写通讯模块驱动常用的功能，模块中提供了一系列的辅助函数，避免重复劳动。

信盈达2008年在深圳特区南山高新科技园成立。自成立至今近九年来专注为企业和个人提供高端方案设计、高端嵌入式/Android培训等服务。公司下设信盈达实训学院、信盈达研发中心、信盈达教学仪器三大业务板块。九年来公司坚持"技术领先、服务领先"，以雄厚的实力和专业的品质成为国内唯一有实力从产品最底层研发到系统层开发的嵌入式实训、产品解决方案提供商。为中国IT行业提供最具价值的职业教育服务。专业培训嵌入式、物联网、人工智能、Java、单片机等课程，想了解更多信息点击立马咨询