嵌入式软件的设计方法.pdfVIP

嵌入式软件设计方法 从硬件驱动层到应用层，嵌入式应用 软件这样设计 要做到嵌入式应用的代码逻辑清晰，且避免重复的造轮子，没有好的应用架构怎 么行。 如果没有好的架构，移植将会是一件很痛苦的事情。 如果没有好的架构，复用是最大的难题，没法更大限度的复用原有的代码。 如果没有好的架构，一旦驱动改了，所有的地方都要改，费时费力且很容易出错。 如果没有好的架构，应用层中穿插着硬件驱动层的代码，看着会是一片混乱，逻 辑不清，代码维护起来会很困难。 这里总结下我的嵌入式程序设计思路，分享出来与大家共同探讨，同时也欢迎提 出不同意见。 现在的小朋友都爱玩搭积木的游戏，一个模块一个模块的拼装起来，快速组成各 种不同的模型。 现在的产品设计也很少从零开始。大都复用现有成熟的模块，专注于某个擅长领 域。 我的嵌入式应用架构思路来源与此，即功能模块设计与分层。 把 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 架构，虽然很复杂，但从框图上看，也像是