【架构】工程代码结构(附带NXP、ST官方demo)

文章目录

1. 起因

最近在做我们应用层内部代码从2.0到3.0版本的迁移，除了删减增加模块，规范写法，最主要的就是重新规划了代码的结构。我们代码的特点就是并行了很多项目，这些项目有共同的地方，又有区别。把哪些部分抽出来做共有库，哪些做自己的项目内部，makefile怎么构思(关于makefile我也会写一篇快速入门）。
有时候回头看看自己的代码，怎么可以写的这么乱，模块化一点都不好，接口乱七八糟。最近重构代码的冲动越来越强烈。
这么想想，小工程就算了，大一点的项目，还是应该提前把结构和接口设计好，代码怎么分层，功能怎么划分，再开始写。
不过很多工程，前期设计好了，也经不住需求的一再变更，改改改改，就变成了一坨忍不住想重写的翔……
算了不抱怨了，还是看看别人是怎么分层的。

2. Demo结构解析

这里列的几个例子不是linux应用层的，是单片机的demo。

2.1 ST公司的STM32Cube

Cube版本：
在这里插入图片描述

简单来说，布局如下：
工程名

  • Document：文档
  • Driver：硬件驱动
    • Bsp：板级的接口，比如串口、IO、定时器……
    • CMSIS：内核接口，这个一般是内核厂家提供，代码不用改，
    • STM32F7xx_HAL_Driver：ST厂家提供的HAL库，与以前提供的3.5的标准外设库属于同级，都是对寄存器配置的封装。HAL库是一个硬件抽象层，便于不同芯片之间的移植。（大家底层不一样，但是HAL库的接口都一样）
  • Middleware：中间件包含的是一些位于系统代码和应用代码之间的，这里感觉就是在HAL库和用户调用之间又封装了一层，把一些协议栈封装进来了。
    • ST：ST自己的一些协议栈
      • STemWin：ST自己的界面
      • STM32_Audio：音频驱动
      • STM32_USB_Device_Library：封装了USB协议
      • STM32_USB_Host_Library
    • Third_Party：第三方库（协议栈）
      • Fatfs：文件系统
      • FreeRTOS：操作系统
      • LwIP：IP协议栈
      • ……
  • Project：不同的项目，我理解应用层的代码都写在这里面，就是流程，对BSP的调用，对middleware的调用
  • Utilities ：这一块不太懂，是公共库？公共资源？字库图库这些？
  • xxxx.ioc ： 图形化配置文件，可以用CubeMx打开

2.2 NXP公司的S32DS

S32DS版本：S32 Design Studio for Power Architecture Version: 2.1
在这里插入图片描述

NXP家的S32DS架构如下：
工程

  • Include：我理解是 应用层的头文件
  • Generated Code：这个是根据图形化配置，系统自动生成的代码（配置数组），实际使用的使用，把这些配置数组加载到系统接口上就能实现对外设的配置。
  • Project_Settings：
    • Debugger：调试器配置
    • Linker_File：链接.ld文件
    • startup_code：启动代码，这个应该是厂家提供，不用改的
  • SDK
    • plantform
      • devices：设备
      • driver：类似bsp，对寄存器操作的封装
      • pal：NXP基于driver层上又封装了一层PAL层，把不同芯片的接口统一了。类似ST的HAL库，都是便于移植用的。
    • rtos
      • FreeRTOS_PA:没啥说的，就是移植的freetos
      • osif： NXP自己的一个裸核的系统。bareMetal。
  • Source：我理解是应用层的代码
  • Document
  • xxx.pe：图形化配置界面。
  • xxx.ld：链接文件

2.3 自己写的应用层

这是我目前在整理的结构，个人感觉还挺好的，毕竟已经是做的第2次重构了，比较贴合我们的真实需求。
因为保密考虑，只列了一部分简单结构，能体现出来结构优势即可。

  • api：一些公有库的头文件
    • BaseApi
  • lib
    • BaseLib：包含一些硬件模块的驱动
      • Can：Can的驱动接口
      • Gpio：Gpio的驱动接口
      • NetSend：网络驱动接口
      • I2C：I2C的驱动接口
      • Uart：串口的驱动接口
      • …
    • Isp：摄像头芯片的图像调整
    • Common：读写文件、读写DDR、时间获取
    • Xcore：cache映射
    • ……
  • project：以上都属于共有库的部分，适合于一些项目来做开发，在project目录下，做不同项目的区别，流程、交互、协议等。
    • zu3_foresight
      • main
        • main.c
        • Buf_Manage：buf管理，不同项目的buf分的数据大小管理方式都不一样的。
        • Buf_Send：buf发送，涉及到和上位机（显示界面）的交互协议，不同项目定的不同
        • Weight_Load：权重加载，前视环视的的weight结构是不同的，也是跟着项目走的
        • Fpga_Cfg：Fpga配置，不同项目FPGA的bit不同，寄存器列表也不同。
        • ……
    • zu5_fisheye
    • 7020_foresight
    • ……

这样的好处就是，能多个项目做在一起，最大限度的共用一些库。
某些东西在一个项目中优化了，不用所有的分支全部合一遍。
比较典型的就是ISP模块，ISP工程师更新了ISP模块，只要更新到共同依赖库的Isp模块中，保持接口不变，其他的项目就都可以同步使用到这个改进，而不像一起，N个分支要全部合一遍。
对于我们这种需求多变，分支超级超级多的版本，就比较好用。不同的项目，在project文件夹下建立自己的项目工程，写自己的makefile就好。
外面的库都编成公共库，最后链接进来就好。

3. 实践

参考了两家的代码，感觉做非应用层项目，和底层关系会比较近，还是ST的架构会好一些，模块化分层会好做一些。
以一台PH滴定仪的设计为例，实操一下。

  • Document
  • Driver
    • Core：内核接口，CMSIS
    • HAL：HAL库接口，STM32F7xx_HAL_Driver
    • BSP：基于HAL又封装一层，应用层可以直接调用
  • Middleware
    • Third_Party：一些第三方库的移植
      • FreeRTOS
      • FATFS
      • EasyFlash
      • FreeModbus
    • Module：一些功能模块，基于BSP层，封装了一些功能模块的接口，供流程调用
      • FuncCommon 版本控制，硬件版本，软件版本 IO口
      • FuncRelay 继电器模块 依赖 IO口
      • FuncPumpT600 泵T600模块 依赖串口
      • FuncValueSv01 六通阀模块 依赖串口
      • FuncPumpKzq1 柱塞泵模块
      • FuncTemperaturePT 测温模块 Max31865 依赖IIC
      • FuncDebug 调试模块 依赖 flash
      • FuncAuthentication 加密模块 依赖 IIC 随机数
      • FuncStriier 搅拌器模块 依赖 IO
      • FuncLiquidLevel 液位模块 依赖IO
      • FuncMcgs屏幕MCGS交互模块 依赖串口
        • 接口：更新结果，更新步骤，更新温度，更新状态…
      • FuncWarn：
        • 接口：报警事件更新，报警触发，报警消除
  • Project：放置不同项目，以F离子滴定仪为例展开子文件夹
    • PH_AutoTitration：PH滴定仪
    • ORP_AutoTitration：ORP滴定仪
    • Spectrophotometer：分光光度计
    • F_Spectrophotometer：F离子滴定仪
      • Workspace
        • KeilMdk521：基于keil MDK 5.21建立的工程文件
        • sourceInsight4：基于SourceInsight4.0 建立的工程文件
        • CubeIde：基于cube建立的工程文件
      • UsrApp：放一些业务代码(server)
        • SvcWarn ：报警流程
        • SvcMcgs：屏幕(MCGS组态屏)交互，modbus主机
        • SvcProcess：流程控制
        • SvcComm：外部通信交互，modbus从机，维护通信协议
        • main.c