用於發送圖像數據的串行協議

我們有一個定製的微控制器卡（ST32/ARM Cortex M3），它有一個攝像頭。相機以1280x1024分辨率捕捉10位灰度。我們需要通過串行將圖像數據發送回PC主機。這是相當大的數據;假設一切正常，在115200波特傳輸將是3分鐘。任何我爲確保魯棒性而執行的操作似乎都會減慢進程速度（例如，拆分成塊，校驗和塊，如果發生損壞則要求重新發送）。所以想知道人們如何在速度和誠信之間做出妥協。用於發送圖像數據的串行協議

我們目前正在看到約6分鐘的實際轉換時間。我們必須將UART波特率設置爲一個奇怪的值 - 1036800 - 因爲在115200時出現了問題（PC運行在115200）。我比硬件更軟件，所以任何想法爲什麼可能發生會有所幫助！

來源

2013-07-31 Julian Gold

您的波特率計算結果偏離了9倍。也許您有一個72 MHz的部件，它使用8 MHz時鐘的x9 PLL，並且基於假設PLL爲活動的，但實際上在沒有PLL的情況下運行（或至少計時外設），比計算所假設的慢9倍。或者，也許你有一個預分頻器在外設時鐘 –

首先對圖片進行一些簡單的壓縮。

運行長度編碼或增量編碼可以減少要發送的數據。

有很多更好的算法，如TIFF，但您可能想要在TIFF的緩衝區中更換複雜的TIFF，以便在嵌入式一側使用更簡單的軟件。

然後你可以爲你的壓縮數據提供一些簡單的Xmodem。

這也是作爲標準協議的有用特性。

這可能會導致您使用終端+ xmodem傳輸樣式接口到您的主機。這將使調試界面非常簡單。

來源

2013-07-31 09:37:25

有效。數據是10位灰度，所以很明顯，我可以立即將這些位打包，立即節省10/16。但是隨後我增加了數據的熵，所以RLE根本不會表現的很好。將需要進行實驗，看看是否只是打包，只是做RLE，或者兩者都能改善事情。 –

Tim Williscroft關於壓縮數據的答案是一個不錯的第一步。

現在從串行協議方面來說，實際傳輸速率很大程度上取決於您如何配置和實現軟件雙方。波特率不是唯一需要關注的東西：

您是否正在使用硬件流量控制？如果使用硬件流量控制，您將能夠顯着提高波特率（x10）而不會產生溢出錯誤。
從STM32你使用DMA，中斷甚至值得輪詢的方法來管理數據傳輸？我不知道你正在使用的確切STM32引用，但是在我使用的STM32上，UART傳輸FIFO限制爲1個字節。所以如果你有性能問題，你只是有義務使用DMA。
仍然從STM32方面來看，您可以大大提高性能，關注應用程序正在進行的總線訪問（以及可能的衝突仲裁）。
此外，在STM32上，所有時鐘都是可配置的。使用外部高速振盪器（如果有板上可用的）可能是改善內部RC振盪器性能的好方法。還要注意內部總線時鐘配置！
現在從PC端來看，性能可能會受到影響，具體取決於您的應用如何緩衝對待接收到的數據。

要做的第一件事是看看時間在哪裏：用示波器觀察你的UART信號。正如你所說的，轉移需要兩倍的理論時間，你不應該看到連續的信號。沒有硬件流量控制，STM32需要時間來輸出數據。通過硬件流量控制，還可以查看流量控制信號以確定哪一側導致暫停（可能都是）。

來源

2013-08-01 10:24:11 greydet

用於發送圖像數據的串行協議

回答

相關問題