【STM32垂直应用挑战第5周+王小琪学习云连接】

只看该作者 · 2020-12-16 16:38

本帖最后由王小琪于 2020-12-16 16:58 编辑

1.这次学习的垂直应用是：云连接
学习链接为：https://www.stmcu.com.cn/ecosystem/app/cloud
本次的云连接分三部分，分别为基于STM32云连接应用的概览、云平台之间的移植、远程固件升级

2.首先是自我推销阶段，基于STM32的云连接应用，ST提供了丰富的软件例程包，对应的说明文档，配套的评估板。众所周知，ST产品线异常的多，所以软件例程包里，配套的评估板主要集中在L4、F4、F7几个系列。这意味着如果你要做云开发的话，最好选择这几个系列的芯片，当然其它芯片也是可以的，只不过可以在学习指导方面没有这几款芯片的资料多，入门相对难一些。

单单说“连接”这个基本功能的话，它对MCU硬件并没有特殊需求：和外部无线通信模块通信所需要的串口和SPI接口是所有MCU都支持的外设；软件方面，根据不同的应用你需要使用不同的物联网协议，因此只要选择FLASH和RAM的大小能满足的STM32就可以了。
选型方面，如果在意低功耗，ST更推荐以L0、L1、L4、L5为代表的STM32L系列，从名字肯定也知道，如果资金允许，当然L4和L5更好；如果在意高性能的话，H7和F4则是更合适的选择。俗话说鱼和熊掌不可兼得，低功耗和高性能就是如此，选择随难，但成年人就得勇敢的做出选择，这是逃避不了的问题。
关于云平台以及连网方式和应用可以参见下图介绍。

不同的云平台之间的区别主要有：支持的协议，设备认证的方式，和支持的功能。
更换云平台的注意事项：大多数云平台都支持MQTT， HTTP协议，部分平台还支持CoAP等协议，或者有些平台使用的是自定义的协议。所以首先需要确认：换云平台时是否需要换接入协议。
即使是同样的协议，例如都是MQTT协议，不同的平台实现设备认证的方式也不一样，有的就是通过MQTT协议的用户名/密码进行认证，而有的需要通过X.509设备证书，这就涉及到是否要实现TLS协议。就算都是通过MQTT协议的用户名/密码进行认证，用户名和密码的产生规则每个云平台也不一样。这些内容都可以在对应云平台的文档中找到说明。
关于云平台支持的功能，各平台都大同小异，在移植时需要注意的是：是否用到了平台SDK 提供的API的这部分代码，如果是的话这部分代码也要做相应的移植。

FOTA的全称是：Firmware Over-The-Air。就是利用无线技术，利用云服务来实现远程的设备固件更新。
以前产品出厂后，如果需要升级程序，要么是通过预留的调试接口，要么通过串口，USB等普通通信接口利用事先写好的bootloader程序进行更新。总之都需要直接连线到板子上。这样带来的问题就是：不光需要安排人员到现场，升级的时候还需要打开机器外壳，取出主板，连接上位机才能升级。现在物联网产品，已经具备了上网的能力，我们完全可以利用这个功能，实现远程的设备固件更新，不用到现场，不用开盖，设备自动升级。有了这个功能后，可以对已经买出去的产品，修复bug，升级更稳定的软件版本等。

首先，FOTA这个功能一定是由两个部分共同实现：节点端的程序和云端的升级和存储服务。节点端就是需要进行固件升级的设备。运行在节点的程序，除了原有的功能以外，还要包括一部分FOTA功能，这部分程序完成与云端服务器通信，从云端下载固件，并更新MCU固件的工作。云端的服务器能够提供固件升级版本管理，升级文件存储等服务。
其次，选择一种升级方式。从存储器的划分角度可以分为：原位升级，乒乓升级，冗余升级

第一种，固件原位升级。这种方式，程序分为两部分：用户程序只负责接收云端服务器发送过来的固件更新通知，包括新软件版本和下载地址；第二部分程序是bootloader, 这部分程序主要负责从云端服务器下载新固件，并直接更新用户程序。下载完成后，再跳转执行新的用户程序。这种方式对Flash的需求最小，但它的问题是，本地用户程序没有备份，如果下载过程中出错，则用户程序无法运行，直到下载好一个完整的用户程序。最坏的是，如果下载失败，又无法连接网络，程序就没法再运行。并且这种升级方式不支持“后台下载”，即在下载和升级的时候，用户的业务逻辑无法同时运行。

第二种，固件乒乓升级。这种方式，在MCU上同时存在两个用户程序区域，分别存放不同版本的两个程序。MCU运行的时候，就在这两个用户程序区域间切换。在用户程序1的位置运行时，可以将新版本的程序写到用户程序2的位置，然后跳转执行。在用户程序2的位置运行时，可以将新版本的程序写到用户程序1的位置，然后跳转执行。这种方式的好处是支持“后台下载”，下载程序不影响正常程序的运行。比如洗衣机，可以一边洗衣服，一边下载新程序。下载失败也没关系，还可以在原程序区域继续运行。但是它对flash大小的需求就比第一种方式要大，相当于两倍用户程序的大小。
固件乒乓升级的方式中，在两个用户程序区域之间切换执行的操作也可以由一个bootloader来实现，每次都从bootloader启动，然后跳转到用户程序1或用户程序2的位置执行。但这种方式有一个问题，就是用户程序在MCU Flash的这两个执行区域运行时的地址是不一样的，这意味着用户程序编译的时候要设定不一样的ROM地址范围。而因为无法知道设备实际升级的时候，新程序会在哪个区域运行，所以还需要为同一个软件版本准备两套程序，分别是运行在区域1和区域2的，再由设备端的程序选择合适的版本下载。这样一来，整个升级系统的设计就变得复杂，而STM32的双bank启动就可以很完美的解决这个问题。STM32MCU Flash的两个bank可以分别作为两个程序运行区域，切换程序运行区域前，在选项字中设置不同的启动地址来选择不同的bank启动。STM32 MCU复位后，根据选项字的设定，将其对应的bank映射到0x08000000地址，并直接从该bank启动。因为不管是从bank1还是bank2启动执行，都是映射到了地址0x08000000，所以程序运行的地址都是一样的。这样的话就不存在前面所说的问题了。

第三种，固件冗余升级。“固件冗余“，顾名思义就是需要额外的空间来存储固件的备份（不作为可运行区域，这是和第二种方式的区别之一）。所以使用固件冗余升级方式时，节点端包含三部分的程序：BootLoader，用户程序和一个用户程序的备份。和第一种方式相比，这里的Bootloader功能更简单，它不需要实现网络功能，仅执行本地固件更新（将程序从备份的位置，拷贝到片内的执行位置），以及上电跳转到用户程序的功能。用户程序除了其他的产品功能外，还要实现网络通信以及固件下载的功能。从云端下载的程序，放在规划好的片上或片外存储器的相应位置。它可以像第二种方式一样，下载不影响正常的程序运行，同时又不需要MCU的flash双bank。这种方式还有一个好处，Bootloader跟网络下载无关，如果不换MCU，应用层的变化都对bootloader没有影响，不需要频繁更新bootloader。如果MCU的存储空间够大，而应用程序又小，也可以将这三部分都放到片上flash中。
PS：说实话，这次的云连接的知识可能更多的应用在物联网中，所以对于非物联网行业的开发者而言可能难度比较大，所以如果是非物联网行业或者与其不太关联的人员，大可不必过于纠结这次的课程，有个大概了解即可，三百六十行，行行出状元，在自身的行业里面磨砺自己，依旧可以成为厉害的人物，看一行爱一行反而容易捡了芝麻丢了西瓜，没有自己的看家本领。但是“连网”这个话题又是一个趋势，所以有个大概的了解还是有必要的，总结下来一句话，可以了解，但不强求，找准自己的方向即可~
我觉得通过这次的学习可以借鉴的一点就是“远程升级”，现阶段我们的产品都是通过J-LINK下载代码，或者是量产之后通过ISP的方式下载，这两种方式都需要工程师去到现场直接操作产品，如果可以像手机一样通过远程更新程序，这样将会更加的方便和高效。

附件为：利用MQTT及云存储实现STM32远程无线升级和利用MQTT及云存储实现STM32远程无线升级例程的开发文档

只看该作者 · 2020-12-16 23:16

远程升级还是很有必要学学的

只看该作者 · 2020-12-17 22:50

可以可以，牛。。。