1、架构设计的意义
1)应用代码逻辑清晰、避免代码冗余、;
2)代码通用,方便软件移植;
3)最大限度做到无需大量修改即可复用;
4)各功能独立,低耦合高内聚;
5)利用架构及其规则进行开发,在开发时间、成本、生产率和产品质量方面具有极大的回报。
应用层 为程序的总体运行框架,组织、整合、调用业务逻辑,完成产品整体功能;提供两种方案,如下:
a)使用 实时操作系统 ( FreeRTOS、μClinux、μC/OS-II) 实现多种任务,如 按键任务、显示任务、通信任务、心跳任务、定时任务 等;
b)由 消息队列搭建而成的多任务调度 方法,适合轻便型、内存小的芯片;准备中……
业务逻辑层 通过调用应用接口层API接口实现产品的各个业务功能,如:
a)按键事件业务;
b)用户GUI业务;
c)通信收发业务;
d)线程守护业务;
e)系统自检业务;
……
功能模块层 封装实现具体功能的子模块,如 :
a)储存读写 模组;
b)按键触发 模组;
c)系统心跳 模组;
d)显示操作 模组;
e)串口收发 模组;
f )数据采集 模组;
……
硬件抽象层 包含了两部分:
a)STM32片内外设驱动( GPIO、RCC、ADC、SPI、I2C、USART、etc );
b)外设底层驱动 ( Screen font library、Sensor I2C / SPI read and write );
a)文件名添加前缀:硬件抽象层( hal_ )、功能模块层( fml_ )、应用接口层( api_ )、业务逻辑层( bll_ )、应用层( app_ );
b)api接口命名规则:api_功能名称,例:lis3dh传感器初始化接口命名 api_lis3dh_init();
a)同一级别的层相互独立,互不影响、互不干扰、互不关联,不能相互调用,只能调用下层接口;
b)各个层之间不能跨层调用,如:在业务逻辑层不能直接调用功能模块层的代码 ,仅能调用应用接口层代码;
a)新增接口要求与整体规则统一,后续只能增加,不允许修改、不允许删除;
b)每次新增接口,需在文件头备注 (作者、版本信息、状态功能) ;
a)底层驱动变动、更换平台,只需更改底层驱动,其他的层次结构不受影响、干扰,无需重新修改;
b)功能模块变动,只需单独升级功能模块,其他模块不受影响,应用层也不受影响;
c)架构设计完成后主要的工作区在业务逻辑层,应用层的作为整体架构的调度者、领导者,通过调用业务逻辑完成产品功能。
a)架构设计一般比较复杂,设计和实现一个好的架构需要相当的时间。所以,一般只有在架构可以被多次反复应用的时候,前期投入的时间成本会得到丰厚的回报;
b)架构设计规定了一系列的接口和规则,这虽然简化了二次开发工作,但同时也要求二次开发者必须记住很多规则,如果违反了这些规则,就不能工作。但是由于架构屏蔽了大量的领域细节,相对而言,其学习成本还是大大降低了;
c)架构的升级对已有产品可能会造成严重的影响,导致需要完整的回归测试。
本例以stm32f030k6t6为主控的小玩具为介绍,内部资源及外部设备 如下:
a)MCU内部资源: 32k flash、4k ram、DMA、ADC、TIM、I2C、SPI、USART……
b)软件运行框架: 由于内存较小,所以采用 消息队列搭建而成的多任务调度 ;
c)外部设备:LED x 4、KEY x 2、DS1302、LIS3DH、OLED、锂电池充电管理、预留ESP32模块接口;
a)树形结构图:
b)文件说明:
kernel: 主架构目录,存放5个层,每个层带 src、inc;
obj: 工程编译输出文件,存放编译过程文件以及hex文件;
project: 工程项目编译及编辑文件,编译器 keil 工程文件、编辑器 source insight 4 工程文件;
readme: 说明文件,软件变更、软件版本、项目状态说明
免责声明:本文系网络转载或改编,未找到原创作者,版权归原作者所有。如涉及版权,请联系删