固件/软件方案设计通识

一、固件是什么？

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

二、固件方案设计

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

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

2.1.1 裸机

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

2.1.2 RTOS

RTOS是实时操作系统的缩写，如果产品功能相对复杂、任务多，而且对业务响应的实时性要求强，就必须考虑移植RTOS了，常用的RTOS有以下几种：

Freertos，RT-Thread，ucos等，应该用哪种实时操作系统，可以从下面几个维度评估。

FreeRTOS比uCOS II优胜的地方：

freeRTOS 不如uCOS的地方：

2.1.3 Linux/Android

如果产品资源更上一层楼，希望有更好的交互体验，快速迭代产品，直接上Linux/Android吧，对显示和交互要求强烈的用Android，对处理底层处理和运算要求强烈的用Linux。

剪裁&移植是什么意思？

说白了就是居于现有系统源码（一般芯片厂家会提供源码SDK）做裁剪，举个例子，比如你基于linux开发一款摄像头，但是不需要显示功能，所以裁剪就是就把linux sdk中显示部分的功能代码屏蔽掉，然后把系统固件重新编译重新烧录即可。

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

2.2.1 设备与设备间通讯

常见的比如Modbus、CANopen（基于CAN）、CANopen（EtherCat），当然了，也可以根据应用情况自定通讯协议。

Modbus 协议是应用于控制器相互之间、控制器经由网络（例如以太网）和其它设备之间可以通信。它已经成为一通用工业标准。有了它，不同厂商生产的控制设备可以连成工业网络，进行集中监控。

Modbus协议是一项应用层报文传输协议，标准的Modbus协议物理层接口有RS232、RS422、RS485和以太网接口，采用master/slave方式通信。

CANOPEN协议是基于CAN总线协议建立的应用层协议。每一个从站点都有一个ID号，一个数据字典和四种工作状态。CANOPEN协议将CAN总线协议的通信帧进行了进一步的封装和分类，以满足更高层次通信的需要。

CAN与CANopen的区别

CAN 提供了所有的网络管理服务和报文传送协议，但并没有定义对象的内容或者正在通讯的对象的类

型（它只定义了 how，没有定义 what），而这正是 CANopen 切入点。CANopen 的核心概念是设备对象字典（OD：Object Dictionary）。CANopen 通讯通过对象字典（OD）能够访问驱动器的所有参数。

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.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 数据埋点

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

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

2.4.2 确定第三方库

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

软件层面，为了配合进行低功耗设计，有以下几种方法。

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等

三、方案评审

在硬件部门输出方案后，将联合总监、产品、项目、技术负责人进行方案评审。

评审阶段主要确定方案功能、性能能否满足产品设计要求，确定方案设计无异常后，评估开发周期、技术风险是否可控，最终输出评审意见，评审通过的方案推进研发。

四、踩坑经历

参考链接：

物联网协议差异：https://blog.csdn.net/wangguchao/article/details/101756484

流媒体协议：https://www.cnblogs.com/balabalala/p/8044057.html

开源框架：https://www.cnblogs.com/lizhensheng/p/11117380.html

往期推荐

     

欢迎更多的同学加入我们 “ 智能硬件产品汪 ”  社群

在这里你可以和千百位硬件产品大佬交流

也可以获得丰富的干货资料

请关注公众号“ 贾明华 ”

点击“入群”加入我们。期待与大家一块交流学习
一个人可以走的很快，一群人可以走的更远

本篇文章来源于微信公众号: 贾明华