中文字幕理论片,69视频免费在线观看,亚洲成人app,国产1级毛片,刘涛最大尺度戏视频,欧美亚洲美女视频,2021韩国美女仙女屋vip视频

Kermit協(xié)議

報(bào)文格式：

1.MARK，起始標(biāo)記START_CHAR，為0x01（CTRIL-A）；

2.LEN，報(bào)文剩余部分的長度，取值范圍0~94，報(bào)文最大長度96，長度不包含換行符或者制表符；

3.SEQ，數(shù)據(jù)包編號(hào)，取模64,；

4.TYPE，k_state數(shù)據(jù)包類型

        NAK包用來說明等待的包沒有正常接收，它不提供別的信息，例如不提供請(qǐng)求的服務(wù)之類。它的數(shù)據(jù)域總是空的。T報(bào)文用于內(nèi)部kermit程序說明超時(shí)。

5．DATA，0~31,127這33個(gè)控制字符需要進(jìn)行轉(zhuǎn)換，前面加’#’，0~31之間加上64,127減去64處理。加過前綴的序列不要分散在不同的包。前綴字符也包含在計(jì)數(shù)之內(nèi)。除S,I,A報(bào)文及其響應(yīng)，都不能進(jìn)行編碼。

6．CHECK，假如S是整個(gè)報(bào)文字符的算術(shù)和，只是校驗(yàn)0~5位的和。

這是基本的默認(rèn)塊校驗(yàn)，所有的kermit都必須可以實(shí)施。

kermit報(bào)文發(fā)送過程

1.發(fā)送方首先發(fā)送一個(gè)初始化報(bào)文S（以0x01起始），確定報(bào)文長度，超時(shí)時(shí)間等；-->

<--接收方返回一個(gè)確認(rèn)報(bào)文Y，在報(bào)文數(shù)據(jù)段存放自己的參數(shù)

2.發(fā)送方發(fā)送文件頭報(bào)文F，在數(shù)據(jù)段包含文件名-->（如果發(fā)送多個(gè)文件，重復(fù)此步驟即可）

<--返回ACK，數(shù)據(jù)段可以不包含數(shù)據(jù)

3.開始發(fā)送文件內(nèi)容，數(shù)據(jù)報(bào)文D，不在可打印ascii碼范圍內(nèi)的，需要被提前替換成等價(jià)的可打印字符，每個(gè)數(shù)據(jù)報(bào)文都會(huì)收到ACK。

4.文件數(shù)據(jù)發(fā)送結(jié)束后，發(fā)送方發(fā)送文件尾報(bào)文Z，收方接收后確認(rèn)。

5.沒有文件需要發(fā)送時(shí)，發(fā)送傳輸結(jié)束報(bào)文B，并接收ACK，然后關(guān)閉連接，物理連接依然保留

每個(gè)報(bào)文都有編號(hào)，0~63之間。

XMODEM

簡(jiǎn)單通用，傳輸信息單位是“包=128B”,傳輸速度慢，適合電話線路質(zhì)量差的情況下使用。

Xmodem是最廣泛使用的文件傳輸協(xié)議之一。原始的Xmodem協(xié)議使用128字節(jié)的數(shù)據(jù)包和一個(gè)簡(jiǎn)單的“校驗(yàn)和”的錯(cuò)誤檢測(cè)方法。隨后的版本XMODEM-CRC，使用了更安全的循環(huán)冗余校驗(yàn)（CRC）錯(cuò)誤檢測(cè)方法。Xmodem協(xié)議始終首先嘗試使用CRC。如果發(fā)送者不響應(yīng)CRC的請(qǐng)求，接收器轉(zhuǎn)移到校驗(yàn)和模式，并繼續(xù)其請(qǐng)求傳輸。
1．Xmodem協(xié)議是什么？
　　XMODEM協(xié)議是一種串口通信中 廣泛用到的異步文件傳輸協(xié)議。分為標(biāo)準(zhǔn)Xmodem和1k-Xmodem兩種，前者以128字節(jié)塊的形式傳輸數(shù)據(jù)，后者字節(jié)塊為1k即1024字節(jié)，并且每個(gè)塊都使用一個(gè)校驗(yàn)和過程來進(jìn)行錯(cuò)誤檢測(cè)。在校驗(yàn)過程中如果接收方關(guān)于一個(gè)塊的校驗(yàn)和與它在發(fā)送方的校驗(yàn)和相同時(shí)，接收方就向發(fā)送方發(fā)送一個(gè)確認(rèn)字節(jié)(ACK)。由于Xmodem需要對(duì)每個(gè)塊都進(jìn)行認(rèn)可，這將導(dǎo)致性能有所下降，特別是延時(shí)比較長的場(chǎng)合，這種協(xié)議顯得效率更低。
    除了Xmodem，還有Ymodem，Zmodem協(xié)議。他們的協(xié)議內(nèi)容和Xmodem類似，不同的是Ymodem允許批處理文件傳輸，效率更高；Zmodem則是改進(jìn)的了Xmodem，它只需要對(duì)損壞的塊進(jìn)行重發(fā)，其它正確的塊不需要發(fā)送確認(rèn)字節(jié)。減少了通信量。
2．Xmodem協(xié)議相關(guān)控制字符
    SOH                      0x01
    STX           0x02
    EOT                      0x04
    ACK                      0x06
    NAK                      0x15
    CAN                      0x18
    CTRLZ                0x1A
3．標(biāo)準(zhǔn)Xmodem協(xié)議（每個(gè)數(shù)據(jù)包含有128字節(jié)數(shù)據(jù)）幀格式

2-1

4．1k-Xmodem（每個(gè)數(shù)據(jù)包含有1024字節(jié)數(shù)據(jù)）幀格式

2-2

5．?dāng)?shù)據(jù)包說明
    對(duì)于標(biāo)準(zhǔn)Xmodem協(xié)議來說，如果傳送的文件不是128的整數(shù)倍，那么最后一個(gè)數(shù)據(jù)包的有效內(nèi)容肯定小于幀長，不足的部分需要用CTRL-Z(0x1A)來填充。這里可能有人會(huì)問，如果我傳送的是bootloader工程生成的.bin文件，mcu收到后遇到0x1A字符會(huì)怎么處理？其實(shí)如果傳送的是文本文件，那么接收方對(duì)于接收的內(nèi)容是很容易識(shí)別的，因?yàn)?span xml:lang="EN-US" lang="EN-US">CTRL-Z不是前128個(gè)ascii碼，不是通用可見字符，如果是二進(jìn)制文件，mcu其實(shí)也不會(huì)把它當(dāng)作代碼來執(zhí)行。哪怕是excel文件等，由于其內(nèi)部會(huì)有些結(jié)構(gòu)表示各個(gè)字段長度等，所以不會(huì)讀取多余的填充字符。否則 Xmodem太弱了。對(duì)于1k-Xmodem，同上理。
6．如何啟動(dòng)傳輸？
   傳輸由接收方啟動(dòng)，方法是向發(fā)送方發(fā)送"C"或者NAK(注意，這里提到的NAK是用來啟動(dòng)傳輸的。以下我們會(huì)看到NAK還可以用來對(duì)數(shù)據(jù)產(chǎn)生重傳的機(jī)制)。接收方發(fā)送NAK信號(hào)表示接收方打算用累加和校驗(yàn)；發(fā)送字符"C"則表示接收方想打算使用CRC校驗(yàn)（具體校驗(yàn)規(guī)則下文Xmodem源碼，源碼勝于雄辯)。
7．傳輸過程
    當(dāng)接收方發(fā)送的第一個(gè)"C"或者NAK到達(dá)發(fā)送方，發(fā)送方認(rèn)為可以發(fā)送第一個(gè)數(shù)據(jù)包，傳輸已經(jīng)啟動(dòng)。發(fā)送方接著應(yīng)該將數(shù)據(jù)以每次128字節(jié)的數(shù)據(jù)加上包頭，包號(hào)，包號(hào)補(bǔ)碼，末尾加上校驗(yàn)和，打包成幀格式傳送。
發(fā)送方發(fā)了第一包后就等待接收方的確認(rèn)字節(jié)ACK，收到接收方傳來的ACK確認(rèn)，就認(rèn)為數(shù)據(jù)包被接收方正確接收，并且接收方要求發(fā)送方繼續(xù)發(fā)送下一個(gè)包；如果發(fā)送方收到接收方傳來的NAK(這里，NAK用來告訴發(fā)送方重傳，不是用來啟動(dòng)傳輸)字節(jié)，則表示接收方請(qǐng)求重發(fā)剛才的數(shù)據(jù)包；如果發(fā)送方收到接收方傳來的CAN字節(jié)，則表示接收方請(qǐng)求無條件停止傳輸。
8．如何結(jié)束傳輸？
   如果發(fā)送方正常傳輸完全部數(shù)據(jù)，需要結(jié)束傳輸，正常結(jié)束需要發(fā)送方發(fā)送EOT 字節(jié)通知接收方。接收方回以ACK進(jìn)行確認(rèn)。當(dāng)然接收方也可強(qiáng)制停止傳輸，當(dāng)接收方發(fā)送CAN字節(jié)給發(fā)送方，表示接收方想無條件停止傳輸，發(fā)送方收到CAN后，不需要再發(fā)送 EOT確認(rèn)（因?yàn)榻邮辗揭呀?jīng)不想理它了，呵呵）。
9．特殊處理
    雖然數(shù)據(jù)包是以 SOH 來標(biāo)志一個(gè)信息包的起始的，但在 SOH 位置上如果出現(xiàn)EOT則表示數(shù)據(jù)傳輸結(jié)束，再也沒有數(shù)據(jù)傳過來。
接收方首先應(yīng)確認(rèn)數(shù)據(jù)包序號(hào)的完整性，通過對(duì)數(shù)據(jù)包序號(hào)取補(bǔ)，然后和數(shù)據(jù)包序號(hào)的補(bǔ)碼異或，結(jié)果為0表示正確，結(jié)果不為0則發(fā)送NAK請(qǐng)求重傳。
    接收方確認(rèn)數(shù)據(jù)包序號(hào)正確后，然后檢查是否期望的序號(hào)。如果不是期望得到的數(shù)據(jù)包序號(hào)，說明發(fā)生嚴(yán)重錯(cuò)誤，應(yīng)該發(fā)送一個(gè)CAN 來中止傳輸。
   如果接收到的數(shù)據(jù)包的包序號(hào)和前一包相同，那么接收方會(huì)忽略這個(gè)重復(fù)包，向發(fā)送方發(fā)出ACK，準(zhǔn)備接收下一個(gè)包。
   接收方確認(rèn)了信息包序號(hào)的完整性和是正確期望的后，只對(duì) 128字節(jié)的數(shù)據(jù)區(qū)段進(jìn)行算術(shù)和校驗(yàn)，結(jié)果與幀中最后一個(gè)字節(jié)（算術(shù)校驗(yàn)和）比較，相同發(fā)送 ACK，不同發(fā)送 NAK。
10．校驗(yàn)和的說明
    Xmodem協(xié)議支持2種校驗(yàn)和，它們是累加和與CRC校驗(yàn)。
   當(dāng)接收方一開始啟動(dòng)傳輸時(shí)發(fā)送的是NAK，表示它希望以累加和方式校驗(yàn)。
   當(dāng)接收方一開始啟動(dòng)傳輸時(shí)發(fā)送的是字符“C”，表示它希望以CRC方式校驗(yàn)。
   可能有人會(huì)問，接收方想怎么校驗(yàn)發(fā)送方都得配合嗎，難道發(fā)送方必須都支持累加和校驗(yàn)和CRC校驗(yàn)？事實(shí)上Xmodem要求支持CRC的就必須同時(shí)支持累加和，如果發(fā)送方只支持累加和，而接收方用字符“C”來啟動(dòng)，那么發(fā)送方只要不管它，當(dāng)接收方繼續(xù)發(fā)送“C”，三次后都沒收到應(yīng)答，就自動(dòng)會(huì)改為發(fā)送 NAK，因?yàn)樗呀?jīng)明白發(fā)送方可能不支持CRC校驗(yàn)，現(xiàn)在接收方改為累加和校驗(yàn)和發(fā)送方通訊。發(fā)送方收到NAK就趕緊發(fā)送數(shù)據(jù)包響應(yīng)。

YMODEM

由XMODEM演變來，效率可靠性高，包=128*8B；一次傳輸可發(fā)送或接受幾個(gè)文件。

XMODEM1K本質(zhì)上是XMODEM CRC1K（1024字節(jié)）的數(shù)據(jù)包。在某些系統(tǒng)中，它也可以被稱為YMODEM。有些通信軟件程序，著名的Procomm的1.x版本中，也將XMODEM-1K 稱為YMODEM，但在Procomm的2.0版本中不再稱XMODEM-1K為YMODEM。

YMODEM -G：YMODEM-G是一種YMODEM的變種。它被設(shè)計(jì)成用于支持錯(cuò)誤控制的調(diào)制解調(diào)器。該協(xié)議不提供軟件糾錯(cuò)或恢復(fù)，但預(yù)計(jì)調(diào)制解調(diào)器提供的服務(wù)。這是一個(gè)流媒體協(xié)議，在一個(gè)連續(xù)的數(shù)據(jù)流上發(fā)送和接收1K的數(shù)據(jù)包，直顯式停止。每塊被發(fā)送后，它不會(huì)等待肯定的確認(rèn)，而是快速連續(xù)地發(fā)送塊。如果任何塊傳輸失敗，本次傳輸將會(huì)失敗退出。

文件傳輸過程的開啟：

（1）開啟是由接收方開啟傳輸，它發(fā)一個(gè)大寫字母C開啟傳輸。然后進(jìn)入等待（SOH）狀態(tài)，如果沒有回應(yīng)，就會(huì)超時(shí)退出。

（2）發(fā)送方開始時(shí)處于等待過程中，等待C。收到C以后，發(fā)送（SOH）數(shù)據(jù)包開始信號(hào)，發(fā)送序號(hào)（00），補(bǔ)碼（FF），“文件名”，“空格”“文件大小”“除去序號(hào)外，補(bǔ)滿128字節(jié)”，CRC校驗(yàn)兩個(gè)字節(jié)。進(jìn)入等待（ACK）狀態(tài)。

（3）接收方收到以后，CRC校驗(yàn)滿足，則發(fā)送ACK。發(fā)送方接收到ACK，又進(jìn)入等待“文件傳輸開啟”信號(hào)，即重新進(jìn)入等待“C”的狀態(tài)。

（4）前面接收方只是收到了一個(gè)文件名，限制正式開啟文件傳輸，Ymodem支持128字節(jié)和1024字節(jié)一個(gè)數(shù)據(jù)包。128字節(jié)以（SOH）開始，1024字節(jié)以（STX）開始。

接收方又發(fā)出一個(gè)“C”信號(hào)，開始準(zhǔn)備接收文件。進(jìn)入等待“SOH”或者“STX”狀態(tài)。

（5）發(fā)送接收到“C”以后，發(fā)送數(shù)據(jù)包，（SOH）（01序號(hào)）（FE補(bǔ)碼）（128位數(shù)據(jù)）（CRC校驗(yàn)），等待接收方“ACK”。

（6）文件發(fā)送完以后，發(fā)送方發(fā)出一個(gè)“EOT”信號(hào)，接收方也以“ACK”回應(yīng)。

然后接收方會(huì)再次發(fā)出“C”開啟另一次傳輸，若接著發(fā)送方會(huì)發(fā)出一個(gè)“全0數(shù)據(jù)包”，接收方“ACK”以后，本次通信正式結(jié)束。

（7）當(dāng)然YMODEM相對(duì)于XMODEM改進(jìn)的地方就在于傳輸再次開啟以后，又可以發(fā)送另外一個(gè)文件，即一次傳輸允許發(fā)送多個(gè)文件。

所用到的符號(hào)

#define MODEM_SOH 0x01//數(shù)據(jù)塊起始字符

#define MODEM_STX 0x02//1028字節(jié)開始

#define MODEM_EOT 0x04//文件傳輸結(jié)束

#define MODEM_ACK 0x06//確認(rèn)應(yīng)答

#define MODEM_NAK 0x15//出現(xiàn)錯(cuò)誤

#define MODEM_CAN 0x18//取消傳輸

#define MODEM_C0x43  //大寫字母Ｃ

CRC計(jì)算方法

in_ptr =mblock->buf; //指向要計(jì)算CRC的緩沖區(qū)開頭

cksum = 0; //

for(stat=mblock->len ; stat>0; stat--)//len是所要計(jì)算的長度

{

cksum = cksum^(int)(*in_ptr++)<< 8; //

for (i=8; i!=0; i--)

{

if (cksum &0x8000)

cksum = cksum<< 1 ^ 0x1021;

else

cksum = cksum<< 1;

}

}

ZMODEM

與上兩種不同，可以連續(xù)的數(shù)據(jù)流發(fā)送數(shù)據(jù)，效率更高

在具體的環(huán)境中，通過多次采用的xmodem的傳輸可以發(fā)現(xiàn)，不管是直接傳輸，還是按照網(wǎng)上的說法采用rz sz傳輸，都很難將文件正確傳輸?shù)角度胧皆O(shè)備上。當(dāng)采用zmodem進(jìn)行傳輸?shù)臅r(shí)候卻發(fā)現(xiàn)傳輸?shù)男屎芨?，幾乎沒有失敗。

Zmodem協(xié)議有兩個(gè)顯著的特點(diǎn)：它是非常有效的，它提供了類似于YMODEM-G的崩潰恢復(fù)機(jī)制，Zmodem協(xié)議不會(huì)等待肯定的確認(rèn)后，每個(gè)塊被發(fā)送，而是快速連續(xù)地發(fā)送塊。Zmodem協(xié)議傳輸如果因任何原因被取消或中斷，恢復(fù)后，先前傳送的信息都需要重新發(fā)送。