1、引言 先聊聊分享這篇文章的原因，在使用STM32時，我發現對於GPIO輸出操作，可以使用GPIOx_ODR寄存器，也可以使用GPIOx_BSRR寄存器。 對應的標準外設庫API介面有 void GPIO_ToggleBits(GPIO_TypeDef* GPIOx, uint16_t PortV ...
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語句進行保護不懂其中奧秘，今天也算是明白了。
點擊查看本文所在的專輯：日常雜談
