亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: 驅動中寫串口問題。 [打印本頁]

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

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

于是，你這個現象也就很好解釋了。

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

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

作者: dreamice 時間: 2008-11-21 10:44
標題: 回復 #3 closetome123 的帖子
實時性再高，也不能超過串口處理負荷，否則就會犧牲可靠性來滿足實時性了，呵呵。
可以自己剖析一下這個驅動嘛

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

作者: closetome123 時間: 2008-11-21 10:53
說的也是，一旦睡眠就至少是10ms，我得保證10ms內的延時，萬一不行就放應用層。
我試試放在應用層的延時先！

作者: qps104 時間: 2008-11-21 10:58

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

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

作者: dreamice 時間: 2008-11-21 11:05

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

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

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

歡迎光臨 Chinaunix (http://www.72891.cn/)

^{<thead id="yh1ju"></thead>}