固件方案设计经验

固件方案设计经验

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

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

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中，主站发送数据，整个网络可能只有一个数据帧依次将通过每个节点（像火车一样）。
主站是唯一允许发送帧的节点，子站只能转发帧。数据帧就像火车一样，从主站开出，途经各个子站，把对于子站的数据放下或者带上，最后回到主站，这种方法有助于确保实时操作并避免延迟。

2.2.2 物联网设备与服务器端通讯
常见智能硬件设备通讯协议模型：

发布/订阅服务更适合物联网环境下通信，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等

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

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

输入：
-产品需求文档
-原理图、PCB文件
-测试用例文档

输出：
-软件设计框图
-技术框架说明

参考链接
物联网协议差异：https://blog.csdn.net/wangguchao/article/details/101756484
流媒体协议：https://www.cnblogs.com/balabalala/p/8044057.html
开源框架：https://www.cnblogs.com/lizhensheng/p/11117380.html