
我正在使用 ATMEL 嵌入式控制器 (at91sam9x25e) 及其序列埠透過 RS485 Modbus RTU 發送/接收。正常通訊工作正常,但有時(在寫入時)某些套件會在訊息中的兩個字元之間以大約 3.5 毫秒的延遲被分割,因此被偵測為新訊息。
設定:
- 單聲道3.2.8
- Modbus RTU 19.2 kBaud
- RS485
- 自動RTS
我立即發送整個包裹:
try
{
Thread.Sleep(_timePreSend);
_serialPort.Write(buffer, offset, count);
} catch(Exception err)
{
log.Error(err.Message);
} finally
{
Thread.Sleep(2);
}
我之前使用了 2 毫秒,當時我手動啟用/停用 RTS,以便它傳輸緩衝區(UART 或 FIFO)中的最後一位。
從示波器捕捉:
120318000100020032000403200000001C000500000000000000003D <- 間隙 -> B6
stty 的輸出:
stty -F /dev/ttyS4 -a
speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
造成這種差距的原因可能是什麼?我可以做什麼來避免它?
答案1
很難確切地說是什麼原因造成的。不幸的是,Linux 序列埠不提供時序保證,且普通的 UART 協定不應該有這樣嚴格的時序要求。如果你的協定需要這種時序保證,你將不得不深入研究你的核心驅動程序,也許編寫你自己的驅動程式來保證所有位元組的原子傳遞沒有間隙,可能使用中斷來確保 UART 緩衝區是總是及時補充。如果沒有核心的幫助,您無法從使用者空間做出這種保證。
也就是說,您可以嘗試找出導致分裂的原因,也許可以解決它,並憑經驗確定它在實踐中足夠可靠,可以滿足您的目的。延遲總是在最後一個位元組之前嗎?如果是這樣,聽起來堆疊中的某些東西由於某種原因正在緩衝一個字符,也許是為了通過一次向硬體傳遞多個字節來優化吞吐量,並且在短暫的超時後僅傳遞單個字節。您應該首先確保您的用戶空間應用程式運作正常:透過運行它來檢查系統調用,並確保資料包在單一系統調用strace
中寫入核心。write
如果是,則需要閱讀 UART 驅動程式的核心原始碼並查看是否涉及任何奇怪的緩衝。
另一種可能性是核心驅動程式只是處理核心執行緒中的資料(或直接在進程上下文中),而您看到的間隙是另一個正在調度的進程。如果是這樣,解決這個問題的唯一方法是修改核心驅動程式或編寫自己的驅動程序,以便它以嚴格即時的方式處理傳輸,而不允許其他進程優先(例如,在中斷上下文中執行所有操作)。
答案2
我終於發現了這種行為的問題所在。我在通訊循環中使用了一些繁忙等待,這導致 CPU 負載過重。然後我讀到,使用 SerialPort 命令,例如BytesToRead 和 Read根本不理想: 如果必須使用.NET System.IO.Port.Serialport
因此我嘗試使用 ByteStream 的非同步函數ReadAsync 和 WriteAsync正如我的新問題所述使用串列埠和 ReadAsync 逾時的正確方法而且我的 CPU 使用率少了很多,而且不再有任何間隙。