嵌入式方案设计规范

一、固件是什么?

固件是一种嵌入在硬件设备中的软件,通常通过下载器下载到设备中,固件的功能应该包括系统(如果有的话)、驱动、应用的具体实现。

二、固件方案设计

开发人员在拿到产品说明书和硬件初步原理图后,可以开始推进固件方案设计,方案设计一般分两个模块,第一个是确定方案系统,第二个是确定应用架构,方案设计完成后,输出方案文档、系统框图、技术调研文档等资料,进入方案评审环节。

2.1 确定方案系统

根据产品的功能复杂度和硬件芯片的资源外设,确定方案是否应该上操作系统,常见的设备底层实现方式有:

2.1.1 裸机

此处的裸机指的是不上任何操作系统,如果产品功能简单,需要处理的任务少,直接用状态机轮询的方式实现会是个不错的选择,这种方式的好处是对设备主控要求资源少,代码简单,容易维护。

2.1.2 RTOS

RTOS是实时操作系统的缩写,如果产品功能相对复杂、任务多,而且对业务响应的实时性要求强,就必须考虑移植RTOS了,常用的RTOS有以下几种:
Freertos,RT-Thread,ucos等,应该实用哪种实时操作系统,可以从下面几个维度评估。
  • 团队熟悉程度?
  • 资料丰富程度?
  • 是否付费?
  • 空间占用大小?
  • 功能满足度?
FreeRTOS比uCOS II优胜的地方:
1。内核ROM和耗费RAM都比uCOS 小,特别是RAM。 这在单片机里面是稀缺资源,uCOS至少要5K以上, 而FreeRTOS用2~3K也可以跑的很好。
2。FreeRTOS 可以用协程(Co-routine),减少RAM消耗(共用STACK)。uCOS只能用任务(TASK,每个任务有一个独立的STACK)。
3。FreeRTOS 可以有优先度一样的任务,这些任务是按时间片来轮流处理,uCOSII 每个任务都只有一个独一无二的优先级。因此,理论上讲,FreeRTOS 可以管理超过64个任务,而uCOS只能管理64个。
4。FreeRTOS 是在商业上免费应用。uCOS在商业上的应用是要付钱的。
freeRTOS 不如uCOS的地方:
1。比uSOS简单,任务间通讯FreeRTOS只支持Queque, Semaphores, Mutex。 uCOS除这些外,还支持Flag, MailBox.
2。uCOS的支持比FreeRTOS 多。除操作系统外,FreeRTOS只支持TCPIP, uCOS则有大量外延支持,比如FS, USB, GUI, CAN等的支持
3。uCOS可靠性更高,而且耐优化,FreeRTOS 在我设置成中等优化的时候,就会出问题。

2.1.3 Linux/Android

如果产品资源更上一层楼,希望有更好的交互体验,快速迭代产品,直接上Linux/Android吧,对显示和交互要求强烈的用Android,对处理底层处理和运算要求强烈的用Linux。
剪裁&移植是什么意思?
说白了就是居于现有系统源码(一般芯片厂家会提供源码SDK)做裁剪,举个例子,比如你基于linux开发一款摄像头,但是不需要显示功能,所以裁剪就是就把linux sdk中显示部分的功能代码屏蔽掉,然后把系统固件重新编译重新烧录即可。

2.2 确定通讯协议

基于硬件的方案需求文档,确定确定通讯协议。

2.2.1 设备与设备间通讯

常见的比如Modbus、CANopen(基于CAN)、CANopen(EtherCat),当然了,也可以根据应用情况自定通讯协议。
  • Modbus
Modbus 协议是应用于控制器相互之间、控制器经由网络(例如以太网)和其它设备之间可以通信。它已经成为一通用工业标准。有了它,不同厂商生产的控制设备可以连成工业网络,进行集中监控。
Modbus协议是一项应用层报文传输协议,标准的Modbus协议物理层接口有RS232、RS422、RS485和以太网接口,采用master/slave方式通信。
  • CANopen(基于CAN)
CANOPEN协议是基于CAN总线协议建立的应用层协议。每一个从站点都有一个ID号,一个数据字典和四种工作状态。CANOPEN协议将CAN总线协议的通信帧进行了进一步的封装和分类,以满足更高层次通信的需要。
CAN与CANopen的区别
CAN 提供了所有的网络管理服务和报文传送协议,但并没有定义对象的内容或者正在通讯的对象的类
型(它只定义了 how,没有定义 what),而这正是 CANopen 切入点。CANopen 的核心概念是设备对象字典(OD:Object Dictionary)。CANopen 通讯通过对象字典(OD)能够访问驱动器的所有参数。
  • CANopen(EtherCat)
EtherCAT中,主站发送数据,整个网络可能只有一个数据帧依次将通过每个节点(像火车一样)。
主站是唯一允许发送帧的节点,子站只能转发帧。数据帧就像火车一样,从主站开出,途经各个子站,把对于子站的数据放下或者带上,最后回到主站,这种方法有助于确保实时操作并避免延迟。
物理接口支持
价格
通讯方式
抗干扰能力
实时性高
网络层级
Modbus
不指定RS232、422、485和以太网接口均可
一主多从
应用层
CANopen
指定,CAN
多主多从
应用层
EtherCat
指定,Ethernet
多主多从
超高
数据链路层

2.2.2 物联网设备与服务器端通讯

常见智能硬件设备通讯协议模型:
模式
服务质量QoS
通讯场景
应用领域
MQTT
发布订阅
3种
多对多
物联网
CoAP
请求应答
TCP保证
一对一
物联网
AMQP
发布订阅
3种
多对多
金融/物联网
DDS
发布订阅
22种
多对多
工业
REST/HTTP
请求应答
TCP保证
一对一
物联网
发布/订阅服务更适合物联网环境下通信,DDS、MQTT、AMQP和JMS都是基于发布/订阅模式,发布/订阅框架具有服务自发现、动态扩展、事件过滤的特点,它解决了物联网系统在应用层的数据源快速获取、物的加入和退出、兴趣订阅、降低带宽流量等问题,实现物的联接在空间上松耦合(双方无需知道通信地址)、时间上松耦合和同步松耦合。
智能家居的电力供给,发电厂的发动机组的监控可以使用DDS协议;当电力输送到千家万户时,电力线的巡查和维护,可以使用MQTT协议;家里的所有电器的电量消耗,可以使用AMQP协议,传输到云端或家庭网关中进行分析;最后用户想把自家的能耗查询服务公布到互联网上,那么可以使用REST/HTTP来开放API服务。
总结一句话来说:
我们可以用可以一套协议完整实现整个链路,当然也可以根据协议特点进行具体业务模块划分。

2.2.3 音视频流通讯

用一句简单的话总结:RTSP发起/终结流媒体、RTP传输流媒体数据 、RTCP对RTP进行控制,同步。
RTP:
RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输,每一个RTP数据报都由头部(Header)和负载(Payload)两个部分组成,其中头部前12个字节的含义是固定的,而负载则可以是音频或者视频数据。
RTCP:
RTCP包括Sender Report和Receiver Report,用来进行音频/视频的同步以及其他用途,是一种控制协议 ,总的来说:RTCP为RTP+控制部分协议。
RTSP:
RTSP实时流协议 作为一个应用层协议,RTSP提供了一个可供扩展的框架,它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来,RTSP是一个流媒体表示协议,主要用来控制具有实时特性的数据发送,但它本身并不传输数据,而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂停、快进等操作,它负责定义具体的控制消息、操作方法、状态码等。

2.3 确定应用模块划分

以下模块为固件设计中常见的模块,在对技术方案进行评审时,产品/项目经理可根据方案的模块进行评估,是否能满足当前业务需求,是否存在待完善的缺陷。
如下图为智能音箱应用架构简化版本:

2.3.1 主业务模块

主业务模块和产品业务强关联,根据不同产品功能需求进行设计,主要为了具体业务细节进行实现。一般分为入口事件管理、回调事件管理、主业务处理。
例如智能音箱的主业务可以细分为:前端算法模块、识别引擎模块、播放器管理模块,用到相关库为ALSA、ffmpeg、libspexx等

2.3.2 监控模块

监控模块主要用于设备软硬件健康度监听,包括软硬件看门狗、监控进程、系统RAM、ROM、CPU、温度等监控模块,具体实现时根据应用需要,定时监听设备当前运行情况。

2.3.3 工具模块

工具模块包含应用开发过程中常用的插件工具,包括字节处理、json解析器、压缩、AT指令集、校验等接口。
常用用cjson、at、bzip2、crclib等

2.3.4 网络模块

网络模块主要围绕着设备网络管理进行,包括网络配置、重连、状态、信号强度等功能管理。
常用有LwIP、curl等

2.3.5 协议模块

协议模块主要根据设备通讯需求制定,包括自定协议,常用的设备间协议Modbus、CANopen、EtherCat,网络间协议MQTT、 DDS、 AMQP、XMPP、 JMS、 REST、 CoAP,和其他业务专用协议等等。

2.3.6 配置模块

配置模块主要用于设备常用配置功能实现,通过配置管理正式环境、测试环境的切换,管理生产版本和测试版本的切换,对设备token,appid,productkey相关信息进行管理。

2.3.7 日志模块

日志模块主要用于管理设备运行过程日志、保存的数据、文件、音视频信息,可通过配置模块接口进行打开或关闭。
常用有sqlite、mongoose、fatfs、zlog等。

2.3.8 加密模块

加密模块主要针对对数据安全有要求的场景,通过自定混淆或第三方加密协议对设备通讯数据进行加解密处理,对敏感数据进行保护。
常用有openssl、mbedtls等

2.3.9 升级模块

升级模块主要为三大块内容,一是系统升级、二是应用升级、三是系统重置,对于能够联网的智能硬件来说,升级的功能应该为必备的功能,无论是在进行BUG修复还是功能体验更新,远程升级的功能都能大大减少资源消耗。
常用有乒乓升级,压缩升级,差分升级,安全升级等

2.3.10 自测模块

软件开发过程中,要求软件开发人员能够自己编写单元自测用例,对自己写的代码进行单元测试,一方面让输出更有保障,也减少后续功能修改导致的BUG。
常用有CMockery、Cunit、CuTest等。

2.3.11 产测模块

智能硬件设备应该设计好量产测试模式,在推进设备生产时,通过量产测试模式来验证设备功能是否完整,性能是否达标。

2.3.12 数据埋点

根据业务情况,进行必要数据采集埋点,后期可根据埋点数据做需求闭环分析。

2.4 确定外部业务接口

2.4.1 确定外部接口/SDK

如果设备中使用到第三方的SDK或接口的,例如语音识别、人脸识别等相关的,需提前确定好接口功能是否能满足业务需求以及商务相关事宜。

2.4.2 确定第三方库

如果设备中需要使用第三方库的,需要提前确定开源许可,是否有版权方面问题。

2.5 其它模块设计

2.5.1 低功耗设计

软件层面,为了配合进行低功耗设计,有以下几种方法。
  • 确定主控是否有低功耗模式,一般对功耗有要求的场景,在选择芯片时,都会考虑选择带有低功耗模式的芯片,例如在M3中,提供三种模式,sleep stop standby模式。stop模式,也就是深度休眠,需要将功耗降低到1mA以下。通过按键和串口可以将设备唤醒,并继续工作。
  • 2在进入到stop模式或者其它的省电模式的时候需要手动关闭自己外设的时钟,有的cpu在汇编中会做好,但是更多的cpu没有做这一步所以这些动作都要我们来完成。
  • 原理图仔细分析判断,哪些元件会损耗电流(尤其关注电阻,还有芯片),如果相应芯片在stop模式中不需要工作,那么在设计上可以考虑用多余的管脚来控制这个芯片的VCC来达到stop模式下不工作。
  • 未使用的管脚按理来说,应该要配置成浮空输入,这样就不会产生压降差,也就不会有电流的损耗(有的cpu管脚默认就是浮空输入的状态)。

2.5.2 雾计算引擎

为了适应智能硬件设备在出货后,能动态对设备进行某部分功能的修改或在设备端进行相关数据计算,除了直接进行OTA的功能外,雾计算的方式会更加灵活,雾计算引擎的实现说白了就是把脚本解析器移植到设备端,建立字典,然后动态对服务端来的脚本进行解析。
常用有lua、micropython、jsengine等

2.5.3 内存泄漏监测

内存泄漏监测算是单元测试的一部分,但是由于单元测试是偏功能的,所以这里把内存泄漏检测单独开来,一般可以通过重写动态内存分配函数实现,当然了,也有一些地方工具可以协助进行内存泄漏检测,例如valgrind等。

2.5.4 UI相关

在选择非Android或Linux操作系统时,如果需要做交互UI,处理自己手写界面和交互,是否还有什么高效的方式呢?答案是肯定有的。
常用有littlevGL、freetype、CEGUI、MyGUI等

2.5.5 深度学习相关

人工智能和深度学习这么火的趋势下,为不同处理能力的智能硬件设备移植一套深度学习框架,无论是从产品宣传还是技术研发方向,都将给我们带来一些新的机遇。
常用有tensorflowlite、caffe、Keras等

三、方案评审

在硬件部门输出方案后,将联合总监、产品、项目、技术负责人进行方案评审。
评审阶段主要确定方案功能、性能能否满足产品设计要求,确定方案设计无异常后,评估开发周期、技术风险是否可控,最终输出评审意见,评审通过的方案推进研发。

四、踩坑经历

  1. 支持总线或联网的设备,能上OTA功能尽可能上OTA功能。
  2. 无总线或联网功能的大型设备,可以购买无线仿真下载器进行调试,不用天天拆机。
  3. 产品功能验收标准,测试用例尽可能提前输出给研发,这里指的不是功能描述,需要有可量化或能衡量的指标,没有设计标准后期只能一次又一次补坑。
  4. 让测试进行跟踪,不仅要保证整机功能能达到要求,也要提前对模块功能,性能,可靠性等等进行验证,减少后续过认证时整改时间,有条件的在初版出来后就找摸底实验室进行摸底,提前整改。

发表回复

登录... 后才能评论