|
一、串口使用：
原則：盡量中斷中不要有延時(比如自定義delay 和自定義printf串口打印，明顯找事啊這么慢能不發生溢出error嘛)，接收和發送盡量分開處理
1.串口發送數據丟失：
1）通常是因為發送之前未檢測TC狀態位之前是否處于發送完成標志導致，關于STM32之·的測試程序來講會導致第一個字符丟失，之后都完全正常。
因此發送一串數據的邏輯必須按照先檢測TC再發送字符的順序進行.即：
void Usart1_Send_Data(u8 *buf,u32 len)
{
u32 i;
for(i = 0;i
{
while(USART_GetFlagStatus(USART1,USART_FLAG_TC) == RESET) ; //
USART_SendData( USART1,*(buf+i));
}
while(USART_GetFlagStatus(USART1,USART_FLAG_TC) == RESET) ; //提升代碼健壯性
}
//綠色部分提高了代碼的健壯性，雖說可有可無，但是避免其他部分代碼出現類似不檢測發送的問題。
2）監測發送狀態位用TC而盡量不要使用TXE，畢竟前者是監測的是否數據發送完而后者只是監測緩存區是否移位到移位寄存器而已。（在485這種半雙工的模式下就有差別，后者會導致自己發送后自己又接收到數據）
2.接收數據丟失：
何時串口需要使用流控（即串口硬件流控制）：硬件流控制是用在單片機與另一臺設備串口通信時，單片機處理速度相對比如PC機慢，單片機接收數據處理速度低于pc機發送速度，這樣會造成數據丟失，這樣就需要加入硬件流控了。流控制能解決這個問題，當接收端數據處理不過來時，就發出“不再接收”的信號，發送端就停止發送，直到收到“可以繼續發送”的信號再發送數據。因此流控制可以控制數據傳輸的進程，防止數據的丟失。我們通常在串口助手這種速率情況下單片機處理速度是完全ok的，不需流控。只是應用在兩者處理速度確實差異較大情況下;另外接收數據丟失就是自己在中斷中添加了延遲操作比如delay 或者printf這種超消耗時間并伴隨著數據溢出error出現這種低級錯誤！！
3.關于串口數據的接收與發送處理的幾種模式：（以只以接收中斷為例）
1）（一般用于測試）接收一個字符就發送一個字符：
這種模式多用在串口測試收發的數據，即用在測試中較多，可以在串口接收中斷將收到的數據直接發送即可：邏輯即以下代碼：（像這種中斷中接收中斷中發送的模式通常只在我們測試環境中使用，而實際通信中接收和發送一般都是分開的，接收我們設立專門的緩存區，
void USART1_IRQHandler(void)
{
u8 res=0;
if(USART_GetITStatus(USART1, USART_IT_RXNE) != RESET)
{
res =USART_ReceiveData(USART1);
while (USART_GetFlagStatus(UART1, USART_FLAG_TC) == RESET);
USART_SendData(UART1, res);
}
}
2）（用于實際應用）建立接收緩存區，串口驅動層存取數據和進行數據緩存大小的簡單、幀是否結束 判斷，而受到數據根據具體協議由協議層對接收到的數據進行校驗；接收與發送是不同的進程，通過一個自定義狀態寄存器實現數據的檢測。
void USART1_IRQHandler(void)
{
u8 res,num;
if( USART_GetITStatus(USART1,USART_IT_RXNE) ==SET)
{
res = USART_ReceiveData(USART1);
num = Usart1_Rx_Sta&0x03ff; //接收數據序號
//可接收數據幀
if( !(Usart1_Rx_Sta>>15) )
{
Usart1_Buf[num] =res;
Usart1_Rx_Sta++;
Fream_Record(res); //調用協議層處理
if( ( Usart1_Rx_Sta&0x03ff) >=USART1_BUF_SIZE ) //越界
Data_Reset();
if( (Usart1_Rx_Sta>>12&0x07) == FRAME_HEAD )
Usart1_Rx_Sta|=0x01<<15; //接受完一幀
}
}
}
總結來說上面即兩種方式
法1 UART 的發送寄存器空的位測試
命令
法2 完整的接收到來自發送設備的數
據, 來確認發送數據完成, 以便及時地關閉
發送（即接收到完整幀）
畢竟軟件是活的，方法思路不是死的，下面這兩種思路用于測試也不錯的：
1.通過串口接收中斷一個字節一個字節接收數據，同時用定時器來計算接收到數據的時間間隔，如果超過一定時間沒有接收到數據則判斷為一幀數據接受完，然后再對數據進行解析
2，通過DMA接收，加串口空閑中斷方式，只在接收完一幀數據后才會產生中斷，然后對數據進行解析。
二、關于串口助手：（由于我們串口一般按字節接收）
注意：有的串口助手比如正點原子提供的ATKXCOM串口助手本身其實就是有很大問題的。
串口助手發送有兩種模式，普通字符串和十六進制形式。
若發送選字符串形式，那么發送的每個都是字符而不是"十進制數"，比如空格也是字符，并不是沒有發數據！！
而選擇十六進制數形式，則意味著每兩個十六進制數構成一個字節發送（由于我們串口正常都是按照8bit即單字節接收）。既然是十六進制，那么你發送的數值形式至少滿足是0-f之間啊。像sscom這種串口助手上如果非正常輸入就會有警告提示，這是相對好的一點。
串口的應用.png (10.53 KB, 下載次數: 46)
下載附件
2018-11-27 17:04 上傳
[size=0.83em]
而我們說像ATKXCOM這種串口助手的更大的問題是如果非十六進制下是否做了處理，像sscom在十六進制下空格是忽視的，也就是無效，這是很容易接受的，畢竟不是十六進制，并且十六進制下發送新行按鈕即回車和換行這種非十六進制是屏蔽的，也是無效，這是應該的。而ATKXCOM1.4版本本身竟然在十六進制下將空格和新行也發了出去，這本身就是錯誤的，而2.0版本依然沒有改新行這個功能在十六進制下屏蔽這個問題。這個最簡單的方法就是可查看助手下面發送數據計數即可看出，所以ATKXCOM串口助手這種帶問題的串口不要使用...
總結串口助手：
1：勾選發送換行只有在是字符串格式下才有效，空格有效；十六進制模式只能發送十六進制數，空格無效，新行無效。
2：下面記錄的發送數據個數可記錄我們實際發送的數據個數
三、串口使用不要時不要添加多余操作：
1）比如在初始化串口中無故添加 USART_ClearFlag(USART3,USART_FLAG_TC)某個串口狀態，如果程序中有重新初始化串口也就是重復無條件執行USART_ClearFlag(USART3,USART_FLAG_TC)會導致某串口掛掉或者整個板子掛掉
2）爭強代碼健壯性可在串口初始化開始先進行串口復位操作
四、串口部分寄存器位說明
SR狀態寄存器先讀狀態再讀數據（調用對應接口）實現的是清除SR狀態位，但并不會使接收緩存器(DR）內數據丟失，仍是當前數據
五、關于STM32帶奇偶校驗接收發送的串口配置問題
STM32如果串口含有就校驗那么32自身的串口的數據位應配置為9位模式，其最高位硬件給為校驗位（實際數據位仍是8位），而如果我們配置數據位為8位，則最高位會配置為奇偶校驗位，那么實際數據位只有7位，這時與串口通信的PC為7位數據位才數據可能正確。具體參見STM32手冊p519下圖[size=0.83em]
串口的應用1.jpg (45.01 KB, 下載次數: 37)
下載附件
2018-11-27 17:03 上傳
換句話說就是STM32的“數據位”長度不同于我們實際串口專指的“數據部分”的長度。當無奇偶校驗時，則32的數據位就是實際的數據部分長度，與串口助手上數據位一樣；而當有就校驗時，由奇偶校驗位會占用32所謂“數據位”最高位，因此當32串口配置9位時實際數據位為8位，配置為8位時實際數據位為7位。
即：如果PC端設置為： 數據位=8，停止位=1，奇偶檢驗=偶/奇
則STM32的設置為：數據位=9，停止位=1，奇偶檢驗=偶/奇
請記住，在STM32上，奇偶檢驗位要計算在數據位中。
2.串口助手有的不支持奇偶校驗功能，比如丁丁（sscomm）的3.3版本不支持，而4.2版本則支持這個功能，而正點原子串口助手本身bug太多就不推薦使用了
四、網絡助手無非基于本地ip的一個應用進程，因此其處于本地ip的應用層，這點要注意。也就意味著應用層以下的協議你是不能用網絡助手作為一個進程進行通信使用的
|
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
。
