1.优势
在嵌入式环境中，一旦需要和设备之间通过某种协议传输文件，Ymodem协议因为具备如下特征：
- 基本的流控
- 基本的握手
- 支持多文件传输
- 支持校验
- 协议精简，代码量少
- 用众多既有客户端软件可以供测试，免写上位机程序。
因此，很容易被选作交互协议。
Ymodem协议的交互过程，可以通过安装串口监听工具（比如BusHound之类的），然后使用支持YModem协议的终端软件，彼此通讯，然后了解交互过程。下面为了节省大家开发的时间，把这个过程梳理一下
2.基本通讯流程
其基本的通讯过程如下：
- 发送端设定好要发送的文件列表，进入YModem等待发送状态
- 接收端发送"C"，告知已准备好，提请发送。
- 发送端发送首帧，帧头01 00 ff，01标志这是一个传输起始帧，且长度为128字节。
- 不过注意一个数据帧帧头3个字节，帧尾还有2个字节的CRC，实际是128+5字节。
- 注意帧头非Word对齐，编码时可能要注意。
- 首帧中包含有文件名称，大小，时间戳信息。
- 接收方接收完毕，处理完毕，回送06 - AK.提示可以继续发送，否则回送15 - NAK，表示需要重传。
- 接下来就直接开始传输这个文件了 01帧头不变，第二字节递增，第三字节递减，所以下一个帧头是：01 01 fe，第二字节|第三字节始终等于0xff.
- 数据帧始终是整齐的，128+5或者是1024+5。文件发送的最后一个帧如果不足帧长，会添补后再法。
- 然后发送方会发送04-EOT，单字节结束整个发送。
- 对于04-EOT，据说体面的做法是两次回送，接收方先回NAK，发送方，重复发送EOT，然后接收方发送ACK，结束这个文件的发送。
- 注意，因为YModem是一个多文件传输协议。发送方会在文件列表清空后，发送一个空的01 00 ff帧，内容为空。仍然是128+5字节。这个时候，接收方回送ACK。结束YModem的整个发送过程。
上面仅给出了单个文件的传输过程，多文件的传输过程，可以自行模拟得之。
3.通信过程截屏
注意，下面的截屏中：IN是下位机外设发回的数据，Out是计算机自己。
- 2.1.0时，下位机发出准许发送的信号。
- 随即上位机发出首帧，包含文件信息的128Bytes.（3.1.0~3.1.128)。帧头帧尾会多出5个字节，非常清晰地可以看到。
- 4.1.0 只发06 - ACK即可，多发了一个“C”
- 5.1.0是文件的首帧，帧头01 01 fe 注意 01 fe互补。
下面看文件发送完毕的结束部分：
- 4422.1.0是对文件倒数第二帧的应答，06 - ACK
- 4423.1.0~4423.1.128 是文件传输的最后一帧，它里面有补齐的部分，用1a补齐了。
- 4424.1.0设备回应最后一帧收讫。06 - ACK
- 4425.1.0 上位机回送单字节帧 04 - EOT
- 4426.1.0 设备回应 Parden? 15 - NAK
- 4427.1.0 设备重发04 -EOT
接下来的设备和发送方应有的举止，你是知道的，对吧？还有三帧交互：
- 设备要发ACK
- 然后上位机要发送一个空的文件帧，表示发完了。128+5字节。
- 设备回应ACK。终结掉此次传输过程。
上面的截屏，可以看到这个最终的文件发送完毕后的握手过程。
实际测试，使用SecureCRT与下位机通讯进行YModem文件传输的过程：
Starting ymodem transfer. Press Ctrl+C to cancel.
Transferring main.c...
100% 2 KB 2 KB/sec 00:00:01 0 Errors
Transferring Pic18F45K22.mc3...
100% 276 KB 4 KB/sec 00:01:09 0 Errors
Transferring test.dat...
100% 53 KB 4 KB/sec 00:00:13 0 Errors
First Edition: Jul05,2023
Last Edition: Jul05,2023 11:45
