串口DMA跑數(shù)據(jù)接收壓力測(cè)試的問(wèn)題及其解決辦法

做項(xiàng)目時(shí)使用官方串口DMA例程，在跑數(shù)據(jù)接收壓力測(cè)試時(shí)發(fā)現(xiàn)了一些細(xì)節(jié)問(wèn)題，正是這些問(wèn)題卡了我2天?，F(xiàn)在終于得到解決，在此立個(gè)貼做記錄。例程現(xiàn)象：

1. 串口DMA在接收過(guò)程中，是不定長(zhǎng)接收的。就算你上位只發(fā)送了1次，例程接收端總會(huì)給你2 - N段不定長(zhǎng)數(shù)據(jù)給你。論壇上也有類似的帖子說(shuō)是底層驅(qū)動(dòng)的某些特性。

2. 串口DMA在接收線程中serial_thread_entry里面不可以做協(xié)議數(shù)據(jù)解析，盡管這是個(gè)獨(dú)立的線程，盡管你的數(shù)據(jù)解析函數(shù)沒(méi)有任何阻塞線程的動(dòng)作，都不行。你必須把接收到的數(shù)據(jù)通過(guò)其他途徑轉(zhuǎn)移到其他線程去處理（比如消息隊(duì)列）。否則會(huì)產(chǎn)生意想不到異常，現(xiàn)象是在運(yùn)行一段時(shí)間后tshell卡死，或者當(dāng)前接收線程直接在ps列表消失，但是依然可以接收數(shù)據(jù)，無(wú)論哪樣最終都會(huì)讓tshell完全卡死加死機(jī)，就連cmTraceback也救不了（不能百分百觸發(fā)異常播報(bào)），cmTraceback只會(huì)告訴你的shell串口在接收中斷處有問(wèn)題，但是具體什么問(wèn)題我看不出。個(gè)人懷疑是 rx_length = rt_device_read(msg.dev, 0, rx_buffer, msg.size); 這個(gè)函數(shù)有隱藏阻塞，如果在下文加上長(zhǎng)延時(shí)的數(shù)據(jù)解析會(huì)導(dǎo)致跟tshell沖突。

嘗試過(guò)，提高或降低tshell 或 syswork或其他線程優(yōu)先級(jí)，增大串口或線程緩沖區(qū)。都不行。

解決辦法：
串口接收線程收到的數(shù)據(jù)只能再中轉(zhuǎn)到其他線程去做處理。 以下是我串口生產(chǎn)者，和消費(fèi)者代碼。

小提示：
消費(fèi)者線程的優(yōu)先級(jí)要高于生產(chǎn)者線程的優(yōu)先級(jí)（消息隊(duì)列應(yīng)用），否則會(huì)出現(xiàn)數(shù)據(jù)覆蓋的現(xiàn)象。比如，高優(yōu)先級(jí)生產(chǎn)者隊(duì)列入了3次數(shù)據(jù)，低優(yōu)先級(jí)消費(fèi)者線程出隊(duì)列只能取到最后一條數(shù)據(jù)。這個(gè)我也很納悶。我覺(jué)得可能跟線程搶占有關(guān)或者優(yōu)先級(jí)翻轉(zhuǎn)之類的現(xiàn)象，解決辦法也許把消費(fèi)者和生產(chǎn)者加上互斥鎖后應(yīng)該就能解決，但是這樣的話，因?yàn)楸绘i了，生產(chǎn)者線程有可能不能及時(shí)接受到外來(lái)數(shù)據(jù)導(dǎo)致丟包。