1、引言

先聊聊分享這篇文章的原因，在使用STM32時，我發現對於GPIO輸出操作，可以使用GPIOx_ODR暫存器，也可以使用GPIOx_BSRR暫存器。

對應的標準外設庫API介面有

void GPIO_ToggleBits(GPIO_TypeDef* GPIOx, uint16_t PortVal)
void GPIO_SetBits(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)
void GPIO_ResetBits(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)

對於我來說，我一直在用GPIO_SetBits和GPIO_ResetBits介面，一直對GPIO_ToggleBits無感。最近注意的這個問題，經過查資料和FAE確認，這樣做的，目的是防止同一個port的其他GPIO被篡改。

看下GPIO_ToggleBits的具體實現

void GPIO_ToggleBits(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)
{
  /* Check the parameters */
  assert_param(IS_GPIO_ALL_PERIPH(GPIOx));
  GPIOx->ODR ^= GPIO_Pin;
}

GPIOx->ODR ^= GPIO_Pin;等於先讀取GPIOx->ODR，再修改對應的GPIO的值，最後寫入GPIOx->ODR。這就是一個讀-寫-改的常規操作。這個操作是存在風險的。在我們讀取時是存在被其他程式碼中斷的情況的。

舉個栗子，假設我們想要修改GPIO0，且bit1是一個重要的GPIO，比如電源的使能引腳。我們讀出的GPIOx->ODR是0x0001，也就是bit0為1，bit1為0。這個時候觸發了某個中斷，在中斷裡我們需要給某個系統上電，我們將GPIO1拉高了。退出中斷繼續執行剛才的程式碼，讀出的GPIOx->ODR是0x0001，將bit0清零，也就是將0寫入GPIOx->ODR。

那麼這個時候問題就大了啊，GPIO1被拉低了，等於沒給另外的系統上電。而且這種bug不易察覺，且一般情況下不必現，在客戶現場偶現，這就很抓狂了。

所以看到這裡大家也就明白了晶片廠家為什麼設計GPIOx_BSRR暫存器操作GPIO原因了。GPIOx_BSRR暫存器可以直接操作對應的GPIO，不需要讀寫改操作，就避免了上面的bug。

當然，你也可以在使用GPIOx->ODR ^= GPIO_Pin;先遮蔽所有中斷，操作後再開啟所有中斷，這是共用資源保護的一種常規操作，但GPIO作為一個使用頻率很高的外設，頻繁關閉中斷是不好的，所以還是使用GPIO_SetBits和GPIO_ResetBits介面為好。

那麼GPIOx->ODR 存在即合理，它對應的是GPIO_Write介面，可以一次寫入一個port的所有GPIO資料，這對於一些特殊場景是非常有用的，有些場景需要一次性寫入同一個port的所有GPIO，類似並口操作，這裡效率很高。

2、共用資源的保護

上文我們提到了共用資源保護，linux中採用原子操作，FreeRTOS中一般採用互斥號誌，也稱互斥鎖。希望大家都要有一種意識，像ODR這樣的暫存器也是一種共用資源。

對於共用資源的操作都是需要保護的，如果使用RTOS，對於串列埠，SPI等這樣外設一定要注意共用資源的保護。

像是ODR暫存器，一些在RTOS多個任務都要讀寫的全域性變數都需要進行保護的。在一些讀寫操作，並不是我們剛看到的GPIOx->ODR ^= GPIO_Pin;操作這麼明顯。

大家要明確，判斷語句也是讀操作。

假設在RTOS中有個全域性變數event_flg，如果它為1時，在兩個任務中都要進行一段操作，比如向語音晶片傳送一段語音。傳送完畢將event_flg清零，並且這兩個任務中的語音不能都播放。虛擬碼如下

void low_task_entry(void *pvParameters)
{
  while(1)
  {
    if(event_flg)
    {
        /*傳送語音1*/
        event_flg =0;
    }
    vTaskDelay(500);
  }
}
void high_Task_entry(void *pvParameters)
{
  while(1)
  {
    if(event_flg)
    {
        /*傳送語音2*/
        event_flg =0;
    }
    vTaskDelay(100);
  }
}

那麼就存在low_task_entry執行完第5句程式碼，判斷event_flg為1，即執行下一段程式碼時，被high_Task_entry打斷，並且在high_Task_entry中成功播放了語音，且將event_flg清零。

當回到任務low_task_entry時，雖然event_flg已經是0了，但是不好意思，退出low_task_entry已經判斷過了，現在回到函數會直接往下執行第6行程式碼，播放語音。這樣神奇的bug就出來了。

那麼有同學說，在high_Task_entry播放語音前，將某個全域性變數置為1，在low_task_entry播放語音前，再判斷這個全域性變數。是的，可以的，這是軟體層的解決辦法，能解決問題就行。

本例的是希望大家體會到判斷語句也是讀操作，注意共用資源的保護。

大家留意看一些RTOS原始碼時，某個簡單的if判斷語句也要進行保護，就是這個原因

3、後記

今天沒有特殊的後記內容，之前我看到一個RTOS原始碼經常對簡單的if語句進行保護不懂其中奧祕，今天也算是明白了。

點選檢視本文所在的專輯：日常雜談

關於共用資源保護的思考

1、引言

2、共用資源的保護

3、後記