STM32中斷中呼叫OLED顯示出現OLED花屏

在tim5中斷處理函式中，我寫了oled顯示，經過debug發現程式執行到oled顯示語句的時候，oled就會花屏。

//中斷服務處理函式

void tim5_irqhandler()

後來在網上搜了一下，發現很多人遇到這個問題，初學嵌入式開發，在寫驅動的時候，有一條非常經典的戒律：中斷服務程式裡，不能呼叫printf,malloc 函式。

大致理解就是， printf 放在中斷裡，相當於中斷中嵌入中斷，這樣的函式可能被阻塞，中斷中不能呼叫有可能被阻塞的函式。

原因可參考：

首先，我們要清楚中斷發生時，系統的狀態如何。一般系統都有特定的中斷執行上下文，但不是任務上下文，所以在這個上下文中不能按照普通任務一樣排程（也可以在當前任務中斷，不同系統可能有所不同），這是中斷運**況。

其次，發生中斷時，大多數系統都是把系統中斷關閉，盡快處理完再開啟。也可以實現中斷巢狀，將更高階別的中斷開啟，但需要很好的處理中斷上下文。

最後要明確的是，系統任務排程是什麼時候發生。一般都是在任務主動讓出，系統定時中斷，系統呼叫中斷返回。

printf, malloc等函式，要用到系統全域性資源，具體還要看系統底層具體實現。大部分標準的實現應該用到了訊號等互斥手段，達到全域性同步和共享的目的。也有的可能沒有加以多工保護同步機制，訪問其全域性資源存在衝突問題。

結合上面說明的情況，可以看出在中斷中呼叫printf,malloc等函式，可能存在幾種情況：

。關中斷處理時，有可能導致中斷休眠。這種情況下，大部分系統都會掛了（有的可能還能排程？很少）。

。中斷不關，高優先順序的中斷還可以產生，還可以排程（系統比較複雜，估計很少）。

。如果不加多工保護機制，對於全域性資源，存在可重入問題。中斷可能發生在任何時候任何函式裡，全域性資源可能存在訪問衝突，後果不能預料。

所以，掛起和可重入都有可能發生，具體看系統情況。並且也可以設計避免其發生。但大多數系統都是針對實時多工的，這個是重點，而不會因為這樣的不重要的需求和改變了其本質的工作方式，甚至影響了系統效能。