1321_一份BootLoader xmodem部分的协议分析

全部学习汇总： https://github.com/GreyZhang/g_serial

这两天移植了一个基于xmodem的BootLoader，正好借着这个工程来学习一下xmodem，看看xmodem的实现。

首先，我去网上先看了下xmodem大概的介绍。这可能是一个极其古老的传输协议，最初的设计只是为了在计算机之间传文件而设计的。之前一直没有意识到，我自己使用树莓派等比较多，通常我会使用sz和rz这样的工具。后来看了一下介绍发现，原来这个就是基本的xmodem协议。

李姐姐xmodem协议，流程可能会是有一点可变性的。但是数据报文的格式其实是统一的，简单的两个表格基本上就能够看到这里的一些信息。

这两个表格对于理解这个xmodem还是很有帮助的，第一个是一整包数据的组成，而第二个则是这个协议中涉及到的一些命令，也就是流控命令。一般来说，这种流控命令都是一个单字节的信息。

前面调试BootLoader的时候，在串口监控工具中看到的不断输出的C其实就是这里的一个流控的命令，也就是最后一条。而数据帧的组成也是很简单的，一个固定信息作为头，然后是带有校验功能的数据包编码，再往后是数据，最后是CRC的数值。

接下来，直接分析一下bootloader中的处理逻辑，或许能够更直接理解这里面的一些操作。

这个接收函数其实是BootLoader这个具有文件接收功能的xmodem的关键所在，其实，这就是一个不断查询的函数。上面的初始局部变量的数值可以保证接下来的循环在第一次执行的时候成立，其实也就是相当于做了一个do while的一个结构。

这里我是做了一定的修改的，我的修改点其实是能够通过计数判断等待到一定时间之后跳转到APP。在这部分，首先控制器会尝试去接收一个串口数据，也就是帧头。如果接收不到，并且之前也没有发现第一包数据过来的信息就会发出前面截图中的C。我增加了一个接口调用，这个接口被调用10次，之后会无条件尝试往APP跳转。如果之前的第一包数据到达的标志性信息到了，那么这里出现接收错误或者超时的时候就得进行错误处理。如果一切接收正常，那么会进行到后面的处理过程中。这个时候，帧头已经是确认接收成功了。

错误处理的逻辑很简单，如果错误发生超过了一定的次数，那么就发送取消传送终止传送并报错。否则的话，发送否定响应要求重传。这里有一个信息，那就是计数器的增加。其实，每一次这个接口被调用都代表着出现了一次新的错误。

这里，其实是根据帧头判断流控的命令。如果是数据帧头，那么接下来处理数据包的接收，具体的处理动作后面再看一下。如果是结束传输的流控，那么接下来发送否定响应之后的提示即将跳转到APP。如果是传输取消的命令，那么接下来直接报错，这样下一个while循环就会退出。如果帧头是错误的，不属于任何流控信息，那么这个数据就是一个错误数据，接下来需要进行处理。错误处理的逻辑前面已经看了。

最后，看看收到了数据帧头之后的处理。这个处理其实也简单，只是进行数据包的接收处理，之后根据处理的成功与否进行错误的甄别。如果没错，那么继续传输，如果是刷写错误那么直接就强行借用计数器的机制来停止流程。如果是普通的错误，那么还有可能有修正的机会，这里的处理也就是一个一般的错误处理流程。

这里是前面看到的数据包的接收处理的部分，最初的这部分首先根据SOH还是STX来进行判断，因为这个会涉及到数据包的数据多少。标准是128，扩展则是1K。有了这个数据，就知道接下来的数据帧会有多少个串口数据即将来到。这样，直接使用一个串口的连续接收全都接收过来。接收的时候，按照前面截图中的数据包的组成进行成员的拆分。

如果串口传输有错误，那么标记错误信息。如果成功了，并且发现之前没有第一包传输成功的标记信息，那么意味着这一次是首次传输。这样，接下来需要擦除Flash以准备后面的数据烧写。在这个过程中，看到了前面接触到的Flash的错误，这个错误会导致刷写流程直接中断。

接下来，根据数据包的定义规则进行数据包号、CRC等相关的检查。

如果一切正常，检查通过，那么接下来刷写数据。成功后，请求下一包数据的传输。这样，整个xmodem的传输实现就基本上完成了。的确是很简单，这样让我想到了曾经的计算机行业中的东西是多么纯粹。而现在的技术发展，让我们面对的很多技术内容都已经成为了庞然大物。有时候，静下来看一看之前曾经出现甚至依然在为我们提供便利的这种小而美的设计，还是很有享受的感觉的。