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

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

全部学习汇总： ​​while的一个结构。

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

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

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

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

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

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

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

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。