一、遇到的问题 代码结构也会有缺陷: (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)共开发者使用。而且它具有一个很重要的特点就是,不随项目的新增需求变动而变动。所以应将其作为最底层,为上层提供基础支持。
|