UART串口是嵌入式開發(fā)常見的一種通信方式，但還是有不少人不知道怎么使用串口。

今天就來圍繞串口，簡(jiǎn)單分享幾點(diǎn)內(nèi)容：

串口接收方式

處理接收數(shù)據(jù)

通信協(xié)議解析

串口接收方式

串口接收（通信另一端）的數(shù)據(jù)，常見的方式：

輪詢（查詢）接收寄存器

中斷接收數(shù)據(jù)

輪詢，就是間隔一定時(shí)間（一般ms，甚至us）去查詢一下接收寄存器是否有數(shù)據(jù)，如果有數(shù)據(jù)，就處理接收到的數(shù)據(jù)。

中斷，平時(shí)沒有數(shù)據(jù)接收時(shí)，CPU干自己的事。當(dāng)有接收數(shù)據(jù)時(shí)，UART串口控制器會(huì)響應(yīng)中斷，通知CPU有事干了。

輪詢方式，大家想過有哪些弊端嗎？

效率低：CPU大部分時(shí)間都是去做查詢的工作；

響應(yīng)不實(shí)時(shí)：如果短時(shí)間內(nèi)有多個(gè)接收數(shù)據(jù)，CPU正在處理一件相對(duì)耗時(shí)的事情（比如：發(fā)送一個(gè)數(shù)據(jù)包），沒來得及查詢接收到的數(shù)據(jù)，此時(shí)，數(shù)據(jù)就可能丟失。（特別是早些年串口沒有FIFO功能的時(shí)候）

所以，不管是UART串口，還是I2C、 SPI、 CAN等串行通信，用的最多，最常見的還是中斷接收，很少有用輪詢的方式。

我之前維護(hù)一個(gè)老代碼（坑），CLI串口用輪詢方式，出現(xiàn)丟數(shù)據(jù)、溢出錯(cuò)誤等眾多問題，讓我還加了好幾個(gè)班。。。

處理接收數(shù)據(jù)

中斷有數(shù)據(jù)來了，大家怎么處理接收到的數(shù)據(jù)？

我見過有些小項(xiàng)目，直接在中斷函數(shù)里面做一些應(yīng)用的情況。比如：串口中斷接收一個(gè)傳感器發(fā)過來的數(shù)據(jù)，顯示數(shù)據(jù)并做一些響應(yīng)的動(dòng)作。

中斷函數(shù)，代碼能少盡少，耗時(shí)能少盡少，不能處理太多耗時(shí)的復(fù)雜的邏輯、應(yīng)用等。

中斷有數(shù)據(jù)來了，一般是通過FIFO方式處理。

1.簡(jiǎn)單的數(shù)組接收、應(yīng)用解析并處理

比如：

static uint8_t gRxCnt = 0;
static uint8_t gRxBuf[10];


void USART1_IRQHandler(void)
{
  //...
  gDgus_RxBuf[gRxCnt] = (uint8_t)USART_ReceiveData(USART1);
  gRxCnt++;
  //...
  
}


void App(void)
{
  //...
  if(0 < gRxCnt)
  {
    //拷貝接收到的數(shù)據(jù)
????gRxCnt?=?0;
????//解析接收數(shù)據(jù)并處理
  }
}

2.中斷函數(shù)接收一幀完整數(shù)據(jù)再處理

比如：

void USART1_IRQHandler(void)
{
  static uint8_t RxCnt = 0;                      //計(jì)數(shù)值
  static uint8_t RxNum = 0;                      //數(shù)量


  if((USART1->SR & USART_FLAG_RXNE) == USART_FLAG_RXNE)
  {
    gDgus_RxBuf[RxCnt] = (uint8_t)USART_ReceiveData(USART1);
    RxCnt++;


    /* 判斷幀頭 */
    if(gDgus_RxBuf[0] != DGUS_FRAME_HEAD1)       //接收到幀頭1
    {
      RxCnt = 0;
      return;
    }
    if((2 == RxCnt) && (gDgus_RxBuf[1] != DGUS_FRAME_HEAD2))
    {
      RxCnt = 0;
      return;
    }


    /* 確定一幀數(shù)據(jù)長(zhǎng)度 */
    if(RxCnt == 3)
    {
      RxNum = gDgus_RxBuf[2] + 3;
    }


    /* 接收完一幀數(shù)據(jù) */
    if((6 <= RxCnt) && (RxNum <= RxCnt))
    {
      RxCnt = 0;
      OSMboxPost(EventMBox_Touch, gDgus_RxBuf);  //發(fā)送消息郵箱(執(zhí)行觸控操作)
    }
  }
}

中斷函數(shù)解析完一幀數(shù)據(jù)，可以通過標(biāo)志位通知應(yīng)用（裸機(jī)時(shí)），也可以通過消息隊(duì)列、郵箱等方式發(fā)送到應(yīng)用（RTOS時(shí)）。

3.RTOS隊(duì)列、郵箱接收

比如：

void DEBUG_COM_IRQHandler(void)
{
  static uint8_t Data;


  if(USART_GetITStatus(DEBUG_COM, USART_IT_RXNE) != RESET)
  {
    Data = USART_ReceiveData(DEBUG_COM);
????CLI_RcvDateFromISR(Data);?//下面把這個(gè)函數(shù)分離出來了
  }
}


void CLI_RcvDateFromISR(uint8_t RcvData)
{
  static portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;


  if(xCLIRcvQueue != NULL)
  {
    xQueueSendFromISR(xCLIRcvQueue, &RcvData, &xHigherPriorityTaskWoken);
  }
}

中斷來一字節(jié)數(shù)據(jù)，就通過消息隊(duì)列發(fā)送一個(gè)字節(jié)數(shù)據(jù)，如果沒有及時(shí)出來這個(gè)數(shù)據(jù)，也是存儲(chǔ)在隊(duì)列中。

通信協(xié)議解析

像上面第2種，簡(jiǎn)單通信協(xié)議，項(xiàng)目相對(duì)較小的情況下，可以直接在中斷函數(shù)里面處理。

但是，如果項(xiàng)目相對(duì)較大、復(fù)雜一點(diǎn)，協(xié)議也先對(duì)復(fù)雜一點(diǎn)，上面第2種在函數(shù)內(nèi)部出來方式就不可取。

1.裸機(jī)環(huán)境

裸機(jī)的情況下，建議用第一種：中斷數(shù)組緩存數(shù)據(jù)（FIFO），應(yīng)用解析通信協(xié)議。

2.RTOS環(huán)境

RTOS情況下，建議用第三種方式：消息隊(duì)列、郵箱等方式接收數(shù)據(jù)，然后發(fā)送（通知）應(yīng)用解析協(xié)議。

當(dāng)然，以上說的都只是常見的方式，具體還需要結(jié)合你項(xiàng)目實(shí)際情況。

同時(shí)，其它類似I2C、CAN等通信，如有協(xié)議解析，也是類似。

比如之前給大家分享的MavLink，我就用CAN實(shí)現(xiàn)過：

void CAN_RX_IRQHandler(void)
{
  static CanRxMsg RxMessage;
  static MAVRCV_QUEUE_TypeDef MAVRcvQueue_Union;


  CAN_Receive(CAN1, CAN_FIFO0, &RxMessage);
                                                 //拷貝長(zhǎng)度、 數(shù)據(jù)
  MAVRcvQueue_Union.MAVRcvStruct.MAVLink_Len = RxMessage.DLC;
  memcpy(&MAVRcvQueue_Union.MAVRcvStruct.MAVLink_Buf[0], &RxMessage.Data[0], RxMessage.DLC);


  MAVLink_RcvDateFromISR(&MAVRcvQueue_Union.MAVLinkRcv_Queue[0]);
}

最后，以上內(nèi)容，僅提供思路，代碼不一定適合項(xiàng)目。

編輯：黃飛

?