嵌入式应用一例--借助卫星广播信号实现程序升级

一.前言：

    忘了是哪几部科幻电影，里面有个情节，就是大反派操控了卫星，发射邪恶的信号，然后地面的所有机器人的智能程式都变了，成了杀人机器。现在，我就准备当那个“大反派”：只是我没有机器人，只有卫星通信接收机；我能做的也只是把接收机的程序刷掉。其实，这种做法在无线通信领域不是什么新鲜事。不过，有条件利用现有的设备实现这一功能，还是很令人兴奋的，功能完成的一霎我觉得我就成了那“大反派”，非常过瘾，极有快感……闲话少说，进入正题

二.准备：

    之前突然有了这个想法，便先调研一下可行性。首先，我们的设备之前已经实现了串口升级程序功能，理论上有数据传输的通路就可以用作程序的传输；这样，无论是串口、并口、网口还是蓝牙、WIFI甚至是卫星通信，都可以升级设备的程序。其次，目前我们可用的链路传输率非常低，几秒甚至几分钟才能传输一个数据包，并且数据包只有几十个字节，一个小时最多能传20k左右。我们的程序大小大概是100k~700k，经过压缩可以减少到20k~200k，还好，理想状态下1个工作日之内可以完成传输-_-！再者，目前我们可用的链路传输成功率很高，虽然还是会有失败、误码等情况出现，但对整体性能影响不会很大。

    简单地说，我们把程序分割成成千上万个小包，经过几个小时发送到设备，里面的程序进行拼包；当中可能出现丢包或者包出错，要求重传的情况；在收到完整的程序后进行升级操作，最终完成升级。

    这里的开发涉及两个工程，一个是设备里面目标板的程序，另一个是上位机的控制终端软件。估计开发工作量不会很大，基于现有的状态，一个人一个星期之内能拿出“演示效果”。

    示意图：
[控制终端]<====>(卫星通信设备)<- - - - >{卫星}<- - - - >(卫星通信设备)

    目标板相关功能的程序代码大致可以划分为下面几个层次：
--------------
升级程序功能
--------------
分包拼接功能
--------------
传输控制功能
--------------
通信链路驱动
--------------


三.实现：

    在现有的设备程序里，升级程序功能和通信链路驱动已经存在，因此只需要实现分包拼接功能和传输控制功能。类似这样的功能模块网上搜搜应该不少，估计实现会比较复杂，为了简单我决定自己实现具有最简功能的，凑合着先用。

    首先是实现一个靠谱的分包拼接功能模块：沿用"目标板程序的压缩"的套路，我也先在vc里开发测试好，然后移到嵌入式的开发环境(例如ADS、CCS等) 用simulator测试，最后再添加到目标工程里面。一直以来，类似敏捷开发、XP、TDD这样的词汇都没少听过，但就不知道到底是什么东东。这回，我决定“实践”一把，模仿一下“测试驱动开发”，把这个模块弄出来(其实是我为偷懒找个冠冕堂皇的理由，我不打算写什么需求设计文档，除了在记事本里简单列几条)。

    在下手敲代码之前，我大概比划过模块的实现细节。不过，这一回我准备“忘记”实现，先把测试代码写好。在搭建测试“框架”的过程中，我修改了几次模块的对外接口，感觉对模块功能到底要干什么和怎么干有了更清晰的认识。至于测试用例，我除了想到穷举一些参数的边界值的组合，其余全部随机生成……实在是没经验测试用例要怎么写。测试代码写好之后，便具体实现这个模块。

    我把模块分成了发送端和接收端两个部分，这样实际上相当于指定了一个分包的协议。按照我的设想，作为接收数据的一方(例如目标板程序)需要接收端的功能，作为发送数据的一方(通常是上位机控制软件)需要相应发送端的功能，这两方遵循相同的分包协议。

    经过多次测试，清查了不少bug，我放心地把这个模块添加进工程里。

    接着是实现传输控制功能。我只简单地定了4条协议，发送数据方到接收数据方3条，反过来1条：分别是数据信息及分包参数、分包数据、询问丢包和丢包重传请求。由于设计比较简单，而且这部分和嵌入式系统耦合较大，我直接添加到工程里。

    然后是在已有的终端控制软件里面增加文件拆包发送和处理丢包重传请求的功能。

    最后来做“系统测试”，按照前面那个示意图的方式连起来，先传了一个小文件，测试正常；然后故意弄些丢包的情况，观察效果并调整传输控制参数；在觉得一切就绪后，开始传输目标板的新程序，在经过若干小时之后，接受一方的设备成功升级。


四.后记：

    感觉这个应用的开发过程中我没学到多少新知识新技术，但其实编程是一个实践性很强的活，多动动手还是能积累不少经验。

    基本功能是可以演示出来了，不过可以改进的地方还很多，例如：

        1.分包拼接和传输控制实现得比较山寨，需要吸收现行工业应用里比较成熟的案例。TCP/IP协议本身就是个好参考。当然如果能参考例如迅雷、FlashGet等应用层协议就更好了。

        2.现在我只是用了一台设备作为发送端，如果用多台设备，传输时间就可以大大减少；当然串口要够多，或者来个串口服务器，配合修改控制端软件。之所以要借助卫星广播信号，就是让所有“留有后门”的设备都能同时接收升级，而不仅仅是点对点的通信。至于安全性，这已经是超出我的考虑范围了……(不然“大反派” 怎么能有机可乘)

        3.这次整个开发过程都算比较顺利，得益于已有的“技术储备”，还有“按部就班”的测试。可惜是没有同事一并参与。编程开发“方法论”的东西就如同哲学，看了似乎明白了，但没实践过就是不会理解深刻的。

    最后还有一个值得思考的问题：这个应用并非相关项目的需求任务，我是在项目经理和部门经理不知道的情况下，打着维护代码测试设备的幌子捣鼓出来的。实话说目前这个应用是完全没有市场需求的，在我看来至少5年内，现在完全是玩票性质的。项目经理人挺好，最近项目不忙，只要我日常的工作做好，没搞出什么岔子，他也不会有意见。但部门经理挺严，他要是知道员工花一个礼拜搞些没有需求的feature，难免心中不舒服，然后就有新的任务安排，运气“好”的话那些炙手可热的项目能找到苦主了。对于老板来说，当然恨不得员工每一分力都花在能赚钱的地方。不过我倒是挺乐意干这种事，例如上回串口升级功能也没有在需求计划里面，现在串口升级成了必不可少的功能了，对于我来说这肯定是有锻炼意义的，对于产品来说也不见得完全是在做无用功，当然不要耽误正常的工作就是了。


五.总结：

其实，这就是串口升级的无线传输版本