驅(qū)動中寫串口問題。

closetome123

我在驅(qū)動中打開了串口，用tty的write和file的write往串口發(fā)數(shù)據(jù)，這些工作我都放在tasklet里面處理的，10ms調(diào)度一次，每次發(fā)送32字節(jié)，問題是我慢著點發(fā)就沒有問題，一旦發(fā)快點就丟數(shù)據(jù)或是亂序。
為什么我在應(yīng)用層發(fā)就不丟數(shù)據(jù)或是數(shù)據(jù)亂序呢？
驅(qū)動中的設(shè)置跟應(yīng)用層我都設(shè)成一樣了。115200 8N1，一旦速度上1k/s就亂。再快就panic了。
希望牛人幫忙解答啊，在線等!

dreamice

你這個問題可能跟Modem串口驅(qū)動那位兄弟的問題比較類似。
首先，串口的特性需要明白，它是一個低速設(shè)備，它的發(fā)送能力可能與你的處理器的能力是數(shù)量級上的差異，串口是一個字節(jié)一個字節(jié)的發(fā)送數(shù)據(jù)的。
其次，在應(yīng)用層發(fā)送數(shù)據(jù)時，應(yīng)用層序會有一個緩沖區(qū)，就是說應(yīng)用程序可以等待，串口在發(fā)送完一個字節(jié)后，通過某種狀態(tài)通知應(yīng)用層而繼續(xù)取緩沖區(qū)數(shù)據(jù)發(fā)送。
你如果在tasklet中做發(fā)送，那么很顯然，這是工作在內(nèi)核空間，內(nèi)核沒有提供這個緩沖的機制。于是，它不顧及串口的處理能力，強行的把數(shù)據(jù)塞給串口發(fā)送，而串口本身有自己的硬件緩沖，當(dāng)然這個緩沖相當(dāng)小，在它無法容納別人給它的數(shù)據(jù)的時候，它就被迫丟棄數(shù)據(jù)，只做自己力所能及的事情。

于是，你這個現(xiàn)象也就很好解釋了。

我覺得，串口通常有發(fā)送結(jié)束的中斷，以及相關(guān)狀態(tài)位來檢測其對前一個字節(jié)是否發(fā)送結(jié)束，你可以查看一下，保證在發(fā)送結(jié)束后再發(fā)下一個字節(jié)才是合理的。另外，tasklet不允許睡眠，在考慮這個問題時，你也要注意。

closetome123

非常感謝版主的解答，我想是kernel沒有緩沖機制造成的，如果我去檢測串口硬件的標(biāo)志位，估計不大可能，我沒有kernel源碼，驅(qū)動是模塊加載上去的�？磥碜詈玫霓k法是直接控制串口的驅(qū)動了，另外這個任務(wù)實時性很高，再沒有比tasklet更好的處理方式。
再次感謝版主！~

dreamice

實時性再高，也不能超過串口處理負(fù)荷，否則就會犧牲可靠性來滿足實時性了，呵呵。
可以自己剖析一下這個驅(qū)動嘛

[ 本帖最后由 dreamice 于 2008-11-21 11:01 編輯 ]

closetome123

說的也是，一旦睡眠就至少是10ms，我得保證10ms內(nèi)的延時，萬一不行就放應(yīng)用層。
我試試放在應(yīng)用層的延時先！

qps104

原帖由 closetome123 于 2008-11-21 10:42 發(fā)表
非常感謝版主的解答，我想是kernel沒有緩沖機制造成的，如果我去檢測串口硬件的標(biāo)志位，估計不大可能，我沒有kernel源碼，驅(qū)動是模塊加載上去的�？磥碜詈玫霓k法是直接控制串口的驅(qū)動了，另外這個任務(wù)實時性很高 ...

我覺得這種情況下用工作隊列更好

dreamice

原帖由 qps104 于 2008-11-21 10:58 發(fā)表


我覺得這種情況下用工作隊列更好

工作隊列可以睡眠，且可以在不同的處理器上運行，這是它的優(yōu)點，但是，其執(zhí)行點有時候顯得無法預(yù)知，所以，必須權(quán)衡使用哪樣一種策略。