a想要傳送資料給b，那麼用硬體的rts/cts作為硬體流控制機制的話，那麼：
a如果想要傳送資料給b的話，a會使得rts(request to send)引腳有效，表明其想要「請求傳送」資料給作為接收裝置的b，而a接著就會去檢測對應的來自b的cts引腳，直到cts有效（此時意味著b已經做好了相關的準備工作了，然後設定了cts(clear to send) ，表明自己準備好接受資料了)，才會真正開始傳送資料。並且，接下來，在傳送每個字元（data character）之前，都會去檢測對應的cts是否有效，如果有效，才會繼續傳輸對應的資料，如果發現cts無效（此時意味著b那麼發生了啥情況，導致無法繼續正常接受資料了，所以將cts設定為了無效），那麼就不能發生資料了。
對於上述cts一直有效的情況下，a就一直傳送資料給b，到了最後資料傳送完之後，再把rts設定為無效，表示資料已經傳送完了。
這就是整個單個的資料傳送流程。
對此流程，做個簡單的比喻，未必很恰當，但是可以很形象的說明資料傳送的流程：
a和b，相當於馬路的兩邊，a要傳送資料給b，就相當於a要過馬路，具體的流程就是：
1.a說，我要過馬路
就相當於a要將cts設定有效，表示要傳送資料（過馬路到b那裡去）
2.b根據自己情況，決定亮紅燈不允許過，還是亮綠燈允許過（cts有效）
b對於接下來將要接受的資料，要有乙個準備的過程，這要花點時間，在這段時間內，肯定不會讓你傳送資料，也就是，亮紅燈不允許你過馬路，將cts設定無效，表示我還沒準備好，然後a那邊呢就一直檢測cts是否有效，發現是無效，就知道現在b那邊還沒準備好，不允許我傳送資料，然後過了會b準備好了，就把cts設定為有效，表示準備好了，a可以傳送資料給b了，即亮綠燈，讓a過馬路了，而a此時就檢測到cts是有效的了，就可以傳送資料了，即看到綠燈，可以過馬路了。
3.a要傳送給b的每乙個位元組資料之前，都會看看是否是綠燈，如果是，繼續傳送資料，如果不是，就停止傳送
接下來的，a要把乙個個位元組的資料（就相當於乙個個要過馬路的人），傳送給b，在傳送之前都要像前面一樣，去檢測cts是否有效，如果有效，即綠燈，就可以繼續傳送資料，即過馬路，如果cts無效，說明b出啥問題了，比如快取滿了，要處理一下，接著再讓你傳送資料，即亮紅燈，a不能繼續過馬路了。然後a就一直檢測cts直到cts有效，再傳送資料，即a一直看燈，直到紅燈變綠，再繼續過馬路。
4.在cts一直有效的情況下，a傳送資料完成後，把rts設定為無效
所有的a都過完馬路了，就把原先設定的標示rts設定為無效，表示資料傳送完成了。
看著上面解釋的一大堆，其實只看標題，就是很簡單的邏輯：
a要傳送資料，即request to send 「請求傳送」（資料），b看到rts有效了，決定，如果自己要做準備工作，就設定cts無效，如果本身準備好了，就設定cts，clear to send，表示對於你的send傳送（資料）來說，我已經clear（忙清了）。所以a看到cts有效就可以傳送資料了。然後接下來的每乙個從a傳送到b的位元組資料都是這麼個過程。中間有可能遇到說，b的buffer full 快取滿了，所以要設定cts無效，a發現後，就停止傳送資料，繼續檢測cts直到有效，才繼續傳送資料。正常資料傳送完成後，a就把最開始設定為有效的rts這個標示清除掉，即設定rts無效，表示資料傳完了。 由此，整個a傳送資料到b的過程就over了。
串列埠流控 軟體流控與硬體流控
在序列通訊處理中，常常看到rts cts和xon xoff這兩個選項，這就是兩個流控制的選項，目前流控制主要應用於數據機的資料通訊中。那麼，流控制在序列通訊中有何作用，在編制序列通訊程式怎樣應用呢？下面我們就談談這個問題。1.流控制在序列通訊中的作用 這裡講到的 流 當然指的是資料流。資料在兩個串列...
串列埠流控 軟體流控與硬體流控
在序列通訊處理中，常常看到rts cts和xon xoff這兩個選項，這就是兩個流控制的選項，目前流控制主要應用於數據機的資料通訊中。那麼，流控制在序列通訊中有何作用，在編制序列通訊程式怎樣應用呢？下面我們就談談這個問題。1.流控制在序列通訊中的作用 這裡講到的 流 當然指的是資料流。資料在兩個串列...
關於串列埠通訊流控控制
首先，我們需要知道什麼 流 這裡 流 是指資料流。當兩個硬體裝置在通訊時候，通訊的資料就像流體一樣，在兩者之間 流動 流，既分方向，也分快慢。在兩個裝置正常通訊時，由於處理速度不同，就存在這樣乙個問題，有的快，有的慢，在某些情況下，就可能導致丟失資料的情況。如台式電腦與微控制器之間的通訊，接收端資料...