做項目時使用官方串口DMA例程，在跑數據接收壓力測試時發現了一些細節問題，正是這些問題卡了我2天。現在終于得到解決，在此立個貼做記錄。例程現象：

1. 串口DMA在接收過程中，是不定長接收的。就算你上位只發送了1次，例程接收端總會給你2 - N段不定長數據給你。論壇上也有類似的帖子說是底層驅動的某些特性。

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

嘗試過，提高或降低tshell 或 syswork或其他線程優先級，增大串口或線程緩沖區。都不行。

解決辦法：
串口接收線程收到的數據只能再中轉到其他線程去做處理。 以下是我串口生產者，和消費者代碼。

小提示：
消費者線程的優先級要高于生產者線程的優先級（消息隊列應用），否則會出現數據覆蓋的現象。比如，高優先級生產者隊列入了3次數據，低優先級消費者線程出隊列只能取到最后一條數據。這個我也很納悶。我覺得可能跟線程搶占有關或者優先級翻轉之類的現象，解決辦法也許把消費者和生產者加上互斥鎖后應該就能解決，但是這樣的話，因為被鎖了，生產者線程有可能不能及時接受到外來數據導致丟包。