DEBUGIN在BASIC Stamp上影響SPI的突發速度

我有一個Parallax BASIC Stamp板上的應用程序，它讀取文本命令並根據命令執行測試用例。一個測試用例通過SPI總線發送數據並從SPI總線讀取失敗，這取決於DEBUGIN文本的突發速率。DEBUGIN在BASIC Stamp上影響SPI的突發速度

印章板通過19200波特的串行端口連接到PC（四核+2GHZ）。

當我使用BASIC Stamp Terminal或超級終端向郵票板發送命令時，測試通過。當我通過C＃應用程序發送相同的命令時，測試失敗。主要區別在於文本發送到郵票板的爆率。

人類發送文本比計算機（應用程序）慢。當使用超級終端時，一個字符以19200波特發送。該應用程序以19200波特發送8個字符，字符之間沒有間隔。

我正在尋找解釋如何DEBUGIN語句（通過串行端口輸入）影響SHIFTIN或SHIFTOUT命令，或者如果有人知道如何解決此問題。

不幸的是，DEBUGIN命令的波特率不能改變。另一種方法是使用串行端口命令以較慢的速度（使用額外的寶貴空間，這對我的項目幾乎沒有任何影響）具有自定義版本（包括將文本轉換爲數字）。

如果發佈到StackEchange是錯誤的論壇，請遷移併發布它被遷移的原因。

聽起來好像微控制器端沒有設置好爲UART和SPI外設提供服務，因此後續字符到達UART的速度太快會導致SPI無法服務，或者可能導致UART上的某些字符丟失。

強大的解決方案是瞭解問題並將其修復到微控制器代碼的體系結構中。例如，您可能需要使用中斷，並讓中斷服務程序在較長的軟件管理的fifo和外設硬件中的常用1-或2-深fifo之間移動字符。

一個可行但風險更大的解決方案是讓C＃應用程序在它發送的字符之間插入延遲，以充分利用人類速度鍵入的顯然效果。這個主題的一個變體是讓嵌入式設備回顯字符，讓C＃程序在發送下一個字符之前等待每個字符的回顯（您還需要一個轉義字符來清除嵌入的命令緩衝區，並重新開始C＃程序決定宣佈嵌入式設備超時並重新開始）

另一個想法是縮短必須發送的數據。用於嵌入式系統的人類可讀命令語言非常棒，因爲您已經注意到可以使用終端應用程序與它們一起玩。但是，如果嵌入式系統受到極大限制，使用打包二進制或十六進制格式可以更容易解析。一個極端的單字符命令在其執行期間暫停是最簡單的情況（如果主要使用字母數字，則可以使用終端程序）

2011-02-24 05:18:09

不幸的是，低級代碼是Parallax BASIC解釋器的一部分，所以我無法控制驅動程序（也無法訪問）。在發送字符（來自PC）後，我已經嘗試了1秒的延遲而沒有任何影響。下一個解決方法是讓印章板只從SPI總線上讀取並向PC回報。 – 2011-02-24 21:30:16

回答