如何做好嵌入式项目？
1 固件
固件：嵌入在硬件设备中的软件，通常通过下载器下载到设备中。
固件功能可包括系统、驱动、应用的具体实现。
2 固件方案设计
固件方案设计：一般在阅读产品说明书及硬件初步原理图后开始。
分两个模块：①确定方案系统②确定应用架构
完成后输出方案文档、系统框图、技术调研文档后评估方案。
2.1 确定系统方案
依据：产品功能复杂程度、硬件芯片外设资源→决定：有无操作系统
底层实现方案
2.1.1 裸机：不上任何操作系统。
适用：产品功能简单、需要处理的任务少
实现：用状态机轮询
好处：对设备主控要求资源少，代码简单，易维护
2.1.2 RTOS：实时操作系统
适用：产品功能相对复杂、任务多，对业务响应的实时性要求强
分类：FreeRTOS, RT-Thread, uCOSii 等等
选用RTOS的评估方法：团队成员对该RTOS的熟悉程度、该RTOS的资料丰富程度、费用、空间占用、功能满足度。
比较FreeRTOS
| 优点 | 缺点 | |
| FreeRTOS相比uCOSii |
1.内核ROM和耗费RAM（尤其）小 前者2~3k, 后者5k以上 2.可用协程共用STACK减少RAM；uCOS只可用任务 3.可有优先度一样的任务，按时间片轮流处理（可处理>64个）；uCOS每个任务只能有一个优先级（只能管64个） 4.商业上免费；uCOSii商业上付费 |
1.更简单，任务间通讯只支持Queque, Semaphores, Mutex；uCOS还支持Flag, MailBox 2.支持更少，除操作系统仅支持TCPIP；uCOS有大量外延支持FS、USB、GUI、CAN等等 3.中等优化就会出问题；uCOS可靠性更高，耐优化； |
2.1.3 Linux或Android
适用：有更好的交互体验、快速迭代产品（显示与交互：Android，底层处理和运算要求：Linux）
裁剪和移植：基于现有系统源码（由芯片厂家提供）做修改应用到你自己的产品中
eg.基于Linux开发摄像头，不需要显示→裁剪意味着把Linux的SDK中显示部分功能去掉或注释掉，再把系统固件重新编译、烧录
2.2 通讯协议
根据硬件方案需求文档确定
2.2.1 设备间通讯
可选用下方的，也可根据实际情况自定通讯协议
①Modbus：应用层报文传输协议，标准物理层接口有RS232,RS422,RS485和以太网接口，用master/slave方式通讯
控制器相互之间或经由网络与其他设备间通讯
工业标准！！！使不同厂商生产的控制设备可连成工业网络集中监控
②CANopen（基于CAN）：应用层。
一个从站点一个ID号、一个数据字典、四种工作状态。
将CAN总线协议的通讯帧进一步封装、分类以满足高层次通信需要。
【注】CAN提供了所有网络管理服务和报文传送协议却没有定义对象的内容或正通讯的对象的类型，即定义了方法，没有定义对象。
故CANopen弥补了这里的空缺，其核心概念是设备对象字典（Object Dictionary），通过对象字典访问驱动器所有参数。
③ CANopen(EtherCat)
主站发送数据，整个网络或只有一个数据帧依次通过每个节点。
主站是唯一运行发送帧的节点，子站只可以转发帧。
类比~~~数据帧像火车，从主站开出，途径子站，把对子站的数据放下或带上回主站
优点：有利于确保实时操作、避免延迟。
|
|
物理接口支持
|
价格
|
通讯方式
|
抗干扰能力
|
实时性高
|
网络层级
|
|
Modbus
|
不指定RS232、422、485和以太网接口均可
|
低
|
一主多从
|
中
|
中
|
应用层
|
|
CANopen
|
指定，CAN
|
中
|
多主多从
|
高
|
高
|
应用层
|
|
EtherCat
|
指定，Ethernet
|
高
|
多主多从
|
高
|
超高
|
数据链路层
|
2.2.2 物联网设备与服务器端通讯
智能硬件设备通讯协议模型
|
应用层协议
|
MQTT
CoAP
DDS
XMPP
AMQP
HTTP
|
|||
|
网络层、传输协议
|
IPv4
IPv6
TCP
6LoWPAN
RPL
|
|||
|
物理层、数据链路层协议
|
近距离通信
Dash7
NFC
Bluetooth
RFID
IRdA
……
|
远距离蜂窝通信
GSM(2G)
WCDMA(3G)
LTE(3.9G)
TD-LTE(4G)
NB-IOT
……
|
远距离非蜂窝通信
ZigBee
Wi-Fi
Z-Wave
wHART
LoRa
……
|
有线通信
MBus
USB
RS232
RS485
Ethemnet
……
|
|
设备层
|
RFID读写器
传感器
可穿戴设备
红外设备
RFID标签
Beacon
摄像机
|
|||
|
|
模式
|
服务质量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发起或终结流媒体
对流媒体数据封包、实现媒体流实时传输
组成
头部(Header)：前12个字节含义固定
负载(Payload)：音频或视频数据
②RTP传输媒体数据
③RTCP对RTP控制同步
2.3 应用模块划分
固件设计中常见的模块，在对技术方案进行评审时，产品/项目经理可根据方案的模块进行评估，是否能满足当前业务需求，是否存在待完善的缺陷。
2.3.1 主业务
产品业务强关联，根据不同产品功能需求进行设计，主要为了具体业务细节进行实现。
一般分为入口事件管理、回调事件管理、主业务处理。
例如智能音箱的主业务可以细分为：前端算法模块、识别引擎模块、播放器管理模块，用到相关库为ALSA、ffmpeg、libspexx等
2.3.2 监控
监控模块主要用于设备软硬件健康度监听，包括软硬件看门狗、监控进程系统RAM、ROM、CPU、温度等监控模块，具体实现时根据应用需要，定时监听设备当前运行情况。
2.3.3 工具
工具模块包含应用开发过程中常用的插件工具，包括字节处理、jso解析器、压缩、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
如果设备中使用到第三方的$DK或接口的，例如语音识别、人脸识别等相关的，需提前确定好接口功能是否能满足业务需求以及商务相关事宜。
2.4.2 第三方库
需要使用第三方库的，提前确定开源许可，是否有版权方面问题。
2.5 其他设计
2.5.1 低功耗设计
软件层面，为了配合进行低功耗设计，有以下几种方法。
- 确定主控是否有低功耗模式，一般对功耗有要求的场景，在选择芯片时，都会考虑选择带有低功耗模式的芯片。例如在M3中，提供三种模式，sleep, stop, standby模式。stop模式，也就是深度休眠，需要将功耗降低到1mA以下。通过按键和串口可以将设备唤醒，并继续工作。
- 进入到stop模式或者其它的省电模式的时候需要手动关闭自己外设的时钟，有的cpu在汇编中会做好，但是更多的cpu没有做这一步所以这些动作都要我们来完成。
- 原理图仔细分析判断，哪些元件会损耗电流(尤其关注电阻，还有芯片)，如果相应芯片在so模式中不需要工作，那么在设计上可以考虑用多余的管脚来控制这个芯片的VCC来达到stop模式下不工作。
- 未使用的管脚按理来说，应该要配置成浮空输入，这样就不会产生压降差，也就不会有电流的损耗（有的cpu管脚默认就是浮空输入的状态）。
2.5.2 雾计算引擎
为了适应智能硬件设备在出货后，能动态对设备进行某部分功能的修改或在设备端进行相关数据计算，除了直接进行OTA的功能外，雾计算的方式会更加灵活，雾计算引擎的实现说白了就是把脚本解析器移植到设备端，建立字典，然后动态对服务端来的脚本进行解析。常用有lua、micropython、jsengine等。
2.5.3 内存泄漏监测
内存泄漏监测算是单元测试的一部分，但是由于单元测试是偏功能的，所以这里把内存泄漏检测单独开来，一般可
以通过重写动态内存分配函数实现，当然了，也有一些地方工具可以协助进行内存泄漏检测，例如valgrind等。
2.5.4 交互UI
在选择非Android或Liux操作系统时，如果需要做交互UI,处理自己手写界面和交互，是否还有什么高效的方式
呢？答案是肯定有的。常用有littlevGL、freetype、CEGUI、MyGUI等。
2.5.5 深度学习
人工智能和深度学习这么火的趋势下，为不同处理能力的智能硬件设备移植一套深度学习框架，无论是从产品宣传还是技术研发方向，都将给我们带来一些新的机遇。常用有tensorflowlite、caffe、Keras等。
3 方案评审
在硬件部门输出方案后，将联合总监、产品、项目、技术负责人进行方案评审。
评审阶段主要确定方案功能、性能能否满足产品设计要求，确定方案设计无异常后，评估开发周期、技术风险是否可控，最终输出评审意见，评审通过的方案推进研发。
4 注意事项
1.支持总线或联网的设备，能上OTA功能尽可能上OTA功能。Over-The-Air technology (空中下载技术)
2.无总线或联网功能的大型设备，可以购买无线仿真下载器进行调试，不用天天拆机。
3.产品功能验收标准，测试用例尽可能提前输出给研发，这里指的不是功能描述，需要有可量化或能衡量的指标，没有设计标准后期只能一次又一次补坑。
4.让测试进行跟踪，不仅要保证整机功能能达到要求，也要提前对模块功能，性能，可靠性等等进行验证，减少后续过认证时整改时间，有条件的在初版出来后就找摸底实验室进行摸底，提前整改。
来源：如何做好 一个企业级嵌入式单片机项目？方法-流程-技巧介绍 【软件篇】_哔哩哔哩_bilibili
