给嵌入式代码也来个分层 点击:156 | 回复:1



武汉王工

    
  • 精华:30帖
  • 求助:95帖
  • 帖子:5269帖 | 8770回
  • 年度积分:0
  • 历史总积分:28808
  • 注册:2020年5月25日
发表于:2020-03-23 13:45:11
楼主

给嵌入式代码也来个分层

 

给嵌入式代码也来个分层

 

一、遇到的问题


代码结构也会有缺陷:
1)开发效率低:每次使用片内的某一资源(例如定时器等),笔者都要去查询CC2430中文手册,比较eggache~(2)代码重复较多:每个实验源码中,诸如 xtal_init ,led_init 等初始化函数每次都要编写(3)不易修改:代码中的业务逻辑与SFR的操作混在一起,可读性较差,修改起来也费力
正是由于以上问题,笔者决定暂停了该系列博文的续写,抽出时间来思考一下解决办法。

二、由网站分层引起的思考


笔者在学习嵌入式编程之前,曾有过 ASP.NET 网站开发经验,对其分层理论也有所实践,下面简单提一下:
一般的有一定复杂度的网站可分为以下三层:

1)数据接入层(DAL):负责与数据库的交互,供业务逻辑层调用(2)业务逻辑层(BLL):调用数据接入层以获取数据,并为具体的业务需求提供支持(3)用户界面层(UIL):负责呈现最终的用户界面
总之,分层以后,大大提高了代码的复用性与扩展性。
那么在嵌入式开发中,能否也利用分层的思想,来提高开发效率,增强其可维护性与可扩展性呢?下面,是一些笔者思考后的浅见。

 

三、嵌入式项目也来分个层


当然不能照搬ASP.NET 的具体分层思想,具体问题得具体分析嘛~
首先,嵌入式开发的核心就是芯片,它提供固定的片内资源共开发者使用。而且它具有一个很重要的特点就是,不随项目的需求变动而变动。所以应将其作为最底层,为上层提供基础支持。我们将其命名为 硬件抽象层(Hardware Abstract Layer)。  
芯片有了当然还不够,通常我们会在片外扩展一些功能模块来满足具体的项目需求,例如:传感器、键盘、LCD屏等。这一层的特点是,随项目的变动而以模块为单位动态增减。这一层的运作需要芯片内部资源的支持,所以应处于硬件抽象层之上,并为上层调用。我们将其命名为 功能模块层(Functional Module Layer)。  
OK,现在原材料都准备齐了:芯片+扩展模块,接下来就要开始真正的加工了:我们需要灵活调用之前两层所提供的接口,实现具体的项目需求。我们将其命名为应用程序层(Application Layer)。  
图文:

图片2.png 


1)硬件抽象层(HAL)  
实现对片内资源 (如定时器、ADC、中断、I/O等) 的通用配置,隐藏具体的SFR操作细节,为上层提供简单清晰的调用接口。
嵌入式开发的核心就是芯片,它提供固定的片内资源(常用的有I/O,ISR,TIMER等,稍微好点的还有ADC,SPI等硬件资源,不需要芯片外围ADC采集芯片或模拟SPI)共开发者使用。而且它具有一个很重要的特点就是,不随项目的新增需求变动而变动。所以应将其作为最底层,为上层提供基础支持。

2)硬件驱动层(HDL)     

嵌入式开发基本都会使用片外资源,如AT24C02,W25Q128等常见的外围EEPROM芯片,需要SPI通信(硬件SPI或I/O模拟的SPI)发送相应指令驱动该芯片,实现该芯片能正常工作。因此驱动这部分的API函数实现程序即为硬件驱动层。即使换了MCU,也只需将调用过硬件抽象层的API函数替换即可。

3)功能模块层(FML)  
通过调用 HAL,实现项目中所涉及到的各片外功能模块,隐藏具体的模块操作细节,并为上层提供简单清晰的调用接口。
硬件抽象层和驱动层主要就是为功能模块层提供的,实现该项目需要的功能,比如KEY、LED和EEPROM等功能,其中LEY、LED基本调用硬件抽象层的API函数(更复杂的可能通过片外芯片获取/控制等,因此可能也需要使用硬件驱动层),EEPROM调用硬件驱动层的API函数,即使EEPROM芯片更换(AT24C02或W25Q128等),也不影响EEPROM之前编写含的功能代码程序(前提是AT24C02,W25Q128提供的API函数提供的是统一标准)。

4)应用程序层(APL)  
通过调用 HAL 与 FML,实现最终的应用功能。

负责的就是功能模块的使用和之间的逻辑关系处理等等,比如用户交互界面应用程序可能需要KEY、LED、LCD等。

四、硬件抽象层和硬件驱动层的主要区别

硬件抽象层使用的芯片内本身的资源(芯片手册都有介绍),而硬件驱动层使用的是芯片本身不存在的资源,而且需要编写相应代码才能实现的资源。

比如正点原子STM32中CAN使用的TJA1050芯片,CAN属于STM32的片内资源,TJA1050属于片外资源,但由于TJA1050不需要额外的代码就能通过STM32中CAN本身提供API函数正常 工作;因此可以认为TJA1050不属于硬件驱动层,而若使用TJA1041,则需要编写额外代码才能使正常工作才能使STM32中CAN本身提供API函数正常工作,因此可以将TJA1041归为硬件驱动层。

若不要分这么细,可以将硬件抽象层和硬件驱动层统一归为硬件抽象层。
         
五、功能模块层和硬件抽象层、硬件驱动层的主要区别

功能模块层是按照项目需求提取出来的功能,需要硬件抽象层和硬件驱动层的硬件支持才能实现,功能模块层根据项目的功能需求改变而改变,而硬件抽象层和硬件驱动层则是项目需求书中的功耗等硬件相关的需求变动而改变,当然,若子功能的增加而硬件不支持,则也需更换硬件驱动。

比如项目中的数据储存功能,硬件支持有AT24C02、W25Q128和芯片本身的FLASH,都可以支持数据储存功能,即使后期因为功耗或节约成本等问题,硬件的更换也不影响数据储存功能的实现(前提规划好标准规范的API函数定义)且避免了重写该功能代码所带来的各种问题,保证了该功能的稳定性。

图片1.png分层结构示意图

 


正在下载,请等待……
下载附件需5积分!

1分不嫌少!


楼主最近还看过



武汉王工

  • 精华:30帖
  • 求助:95帖
  • 帖子:5269帖 | 8770回
  • 年度积分:0
  • 历史总积分:28808
  • 注册:2020年5月25日
发表于:2020-03-23 13:47:04
1楼

给嵌入式代码也来个分层

 

一、遇到的问题


代码结构也会有缺陷:
1)开发效率低:每次使用片内的某一资源(例如定时器等),笔者都要去查询CC2430中文手册,比较eggache~(2)代码重复较多:每个实验源码中,诸如 xtal_init ,led_init 等初始化函数每次都要编写(3)不易修改:代码中的业务逻辑与SFR的操作混在一起,可读性较差,修改起来也费力
正是由于以上问题,笔者决定暂停了该系列博文的续写,抽出时间来思考一下解决办法。

二、由网站分层引起的思考


笔者在学习嵌入式编程之前,曾有过 ASP.NET 网站开发经验,对其分层理论也有所实践,下面简单提一下:
一般的有一定复杂度的网站可分为以下三层:

1)数据接入层(DAL):负责与数据库的交互,供业务逻辑层调用(2)业务逻辑层(BLL):调用数据接入层以获取数据,并为具体的业务需求提供支持(3)用户界面层(UIL):负责呈现最终的用户界面
总之,分层以后,大大提高了代码的复用性与扩展性。
那么在嵌入式开发中,能否也利用分层的思想,来提高开发效率,增强其可维护性与可扩展性呢?下面,是一些笔者思考后的浅见。

 

三、嵌入式项目也来分个层


当然不能照搬ASP.NET 的具体分层思想,具体问题得具体分析嘛~
首先,嵌入式开发的核心就是芯片,它提供固定的片内资源共开发者使用。而且它具有一个很重要的特点就是,不随项目的需求变动而变动。所以应将其作为最底层,为上层提供基础支持。我们将其命名为 硬件抽象层(Hardware Abstract Layer)。  
芯片有了当然还不够,通常我们会在片外扩展一些功能模块来满足具体的项目需求,例如:传感器、键盘、LCD屏等。这一层的特点是,随项目的变动而以模块为单位动态增减。这一层的运作需要芯片内部资源的支持,所以应处于硬件抽象层之上,并为上层调用。我们将其命名为 功能模块层(Functional Module Layer)。  
OK,现在原材料都准备齐了:芯片+扩展模块,接下来就要开始真正的加工了:我们需要灵活调用之前两层所提供的接口,实现具体的项目需求。我们将其命名为应用程序层(Application Layer)。  
图文:

 


1)硬件抽象层(HAL)  
实现对片内资源 (如定时器、ADC、中断、I/O等) 的通用配置,隐藏具体的SFR操作细节,为上层提供简单清晰的调用接口。
嵌入式开发的核心就是芯片,它提供固定的片内资源(常用的有I/O,ISR,TIMER等,稍微好点的还有ADC,SPI等硬件资源,不需要芯片外围ADC采集芯片或模拟SPI)共开发者使用。而且它具有一个很重要的特点就是,不随项目的新增需求变动而变动。所以应将其作为最底层,为上层提供基础支持。

2)硬件驱动层(HDL)     

嵌入式开发基本都会使用片外资源,如AT24C02,W25Q128等常见的外围EEPROM芯片,需要SPI通信(硬件SPI或I/O模拟的SPI)发送相应指令驱动该芯片,实现该芯片能正常工作。因此驱动这部分的API函数实现程序即为硬件驱动层。即使换了MCU,也只需将调用过硬件抽象层的API函数替换即可。

3)功能模块层(FML)  
通过调用 HAL,实现项目中所涉及到的各片外功能模块,隐藏具体的模块操作细节,并为上层提供简单清晰的调用接口。
硬件抽象层和驱动层主要就是为功能模块层提供的,实现该项目需要的功能,比如KEY、LED和EEPROM等功能,其中LEY、LED基本调用硬件抽象层的API函数(更复杂的可能通过片外芯片获取/控制等,因此可能也需要使用硬件驱动层),EEPROM调用硬件驱动层的API函数,即使EEPROM芯片更换(AT24C02或W25Q128等),也不影响EEPROM之前编写含的功能代码程序(前提是AT24C02,W25Q128提供的API函数提供的是统一标准)。

4)应用程序层(APL)  
通过调用 HAL 与 FML,实现最终的应用功能。

负责的就是功能模块的使用和之间的逻辑关系处理等等,比如用户交互界面应用程序可能需要KEY、LED、LCD等。

四、硬件抽象层和硬件驱动层的主要区别

硬件抽象层使用的芯片内本身的资源(芯片手册都有介绍),而硬件驱动层使用的是芯片本身不存在的资源,而且需要编写相应代码才能实现的资源。

比如正点原子STM32中CAN使用的TJA1050芯片,CAN属于STM32的片内资源,TJA1050属于片外资源,但由于TJA1050不需要额外的代码就能通过STM32中CAN本身提供API函数正常 工作;因此可以认为TJA1050不属于硬件驱动层,而若使用TJA1041,则需要编写额外代码才能使正常工作才能使STM32中CAN本身提供API函数正常工作,因此可以将TJA1041归为硬件驱动层。

若不要分这么细,可以将硬件抽象层和硬件驱动层统一归为硬件抽象层。
         
五、功能模块层和硬件抽象层、硬件驱动层的主要区别

功能模块层是按照项目需求提取出来的功能,需要硬件抽象层和硬件驱动层的硬件支持才能实现,功能模块层根据项目的功能需求改变而改变,而硬件抽象层和硬件驱动层则是项目需求书中的功耗等硬件相关的需求变动而改变,当然,若子功能的增加而硬件不支持,则也需更换硬件驱动。

比如项目中的数据储存功能,硬件支持有AT24C02、W25Q128和芯片本身的FLASH,都可以支持数据储存功能,即使后期因为功耗或节约成本等问题,硬件的更换也不影响数据储存功能的实现(前提规划好标准规范的API函数定义)且避免了重写该功能代码所带来的各种问题,保证了该功能的稳定性。

分层结构示意图



热门招聘
相关主题

官方公众号

智造工程师