【架构】工程代码结构(附带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
  • 9
    点赞
  • 32
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
### 回答1: NXP RT1176是一款嵌入式处理器,支持UVC(USB Video Class)协议。UVC是一种用于传输视频数据的标准协议,可以在实时应用、监控、远程会议等场景中使用。 NXP RT1176 UVC Demo是基于该处理器开发的演示程序。该演示程序通过连接一个摄像头,实现了将摄像头捕获的视频数据传输到计算机上显示的功能。 演示程序首先利用RT1176处理器的媒体处理能力,实时采集摄像头输出的视频数据。然后,通过USB接口将视频数据传输到计算机上。计算机上安装了合适的UVC驱动程序后,可以自动识别并接收RT1176传输的视频数据。 在计算机上,用户可以使用视频播放软件或者流媒体应用程序来查看和处理RT1176传输的视频数据。用户可以实时观看摄像头捕获的画面,进行录制、拍照等操作。同时,经过RT1176处理器的硬件加速,视频质量和帧率也能得到保证。 NXP RT1176 UVC Demo的开发可为用户提供了一种快速开发基于UVC协议的视频应用的途径。用户可以基于该演示程序进行二次开发,定制自己的视频产品或者应用。 ### 回答2: NXP RT1176是一款高性能的嵌入式处理器芯片,支持多媒体应用和图像处理。UVC(USB Video Class)是一种标准的USB视频设备协议,用于将视频数据传输到计算机上。 NXP RT1176 UVC Demo是基于该芯片的UVC演示项目。这个演示项目通过使用RT1176芯片的视频编解码能力,实现了将图像数据传输到计算机上,并在计算机上显示出来的功能。 在这个演示项目中,RT1176芯片负责从摄像头获取视频数据,并对数据进行编码处理,然后通过USB接口将编码后的数据传输到计算机上。计算机上的UVC驱动程序负责接收并解码这些数据,最后将视频图像显示在计算机的屏幕上。 通过这个演示项目,我们能够看到RT1176芯片强大的处理能力和优秀的图像处理性能。它可以实时采集、编码和传输视频数据,使我们能够方便地在计算机上观看图像。 除了视频传输功能,NXP RT1176还具有丰富的外设接口和强大的计算能力,可以广泛应用于智能摄像头、机器视觉、人工智能等领域。它的高性能和灵活性能够满足不同应用的需求,为用户提供更好的视觉体验。 总之,NXP RT1176 UVC Demo展示了RT1176芯片的视频处理能力和UVC协议的应用。通过这个演示项目,人们可以更好地了解和体验这款芯片的特性,为开发各种视频应用提供参考和灵感。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值