在所有行業中大規模采用物聯網技術的結果是對嵌入式開發技能的需求日益增加。然而,嵌入式開發在歷史上一直是一個相當復雜的領域,人們不可能在一夜之間將其添加到技能中。

幸運的是,在過去的十年中,硅供應商在簡化嵌入式開發方面投入了大量的精力,特別是對于在該領域經驗很少甚至沒有經驗的人。但根據我的經驗,至少有一個領域的工作仍然過于繁瑣:圖形用戶界面(GUI)開發。許多應用程序至少需要某種圖形用戶界面:顯示器可能很小,單色,幾乎沒有任何按鈕供用戶按下,但它仍然是一個用戶界面,是嗎?

在本文中,我也將分享一些技巧和一些我用來幫助保持GUI開發愉快的工具。

硬件集成和可移植性

大多數顯示設備都帶有示例代碼和驅動程序,這些代碼和驅動程序將使您至少能夠顯示某些內容。但是GUI不僅僅是一個屏幕,因為界面也是由輸入組成的,對嗎?那些按鈕、觸摸屏輸入和系統中可能參與交互的其他傳感器如何?

這看起來可能不多,但在受約束的系統上運行時,正確處理簡單的硬件輸入(如按下的按鈕)可能需要大量工作,并且您可能很快就不得不處理復雜的定時或中斷管理問題。由于這些通常涉及低級編程,它們往往非常依賴硬件,不容易移植。

很多嵌入式開發都是用C語言完成的,因此,除了低級的引導代碼外,嵌入式代碼在理論上是相當可移植的。然而,編寫可移植GUI代碼是一個完全不同的故事,除非您在現有框架(如LVGL或Azure RTOS GUI)的基礎上進行構建,否則需要花費大量精力來抽象所有硬件依賴項,在嘗試保持*佳狀態時更是如此。

當然,并非總是有必要(或可能)擁有*可移植的GUI代碼。然而,在這個全球芯片短缺的時代,它可以被證明是非常方便的,不需要對特定類型的微控制器或LCD顯示器有嚴格的依賴。

內存管理

簡而言之:您的圖形用戶界面可能會占用大量內存,您需要更加聰明,為實際應用程序留出足夠的空間。例如,節省圖形內存的一個快速方法是仔細檢查是否可以用矢量等價物替換某些光柵圖形(例如圖標):當然,直接在屏幕上繪制一個簡單的32x32px紅方塊需要更少的代碼和RAM,而不是將其存儲為內存中的位圖。

資源管理

正確管理組成GUI項目的各種資源可能很棘手。更具體地說,您的GUI實體模型都可能由各種圖像文件、圖標、字體等組成。但是,在嵌入式開發環境中,您通常不能期望能夠在代碼中直接操作漂亮的透明PNG文件或TrueType字體!首先需要將其轉換為允許在嵌入代碼中操作的格式。

事件處理和性能

首先,C語言仍然是*常用的嵌入式編程語言,它并不完全是面向對象的。因此,即使完全有可能以上面所示的高級API為目標,也很有可能在向某個UI元素添加/更新事件處理程序時使用容易出錯的函數指針。

假設您確實找到了一種優雅的方式將事件處理程序與UI的各個部分關聯起來,那么您仍然需要實現某種類型的事件循環。事實上,您必須定期處理系統中發生的事件("按下按鈕A"等),并將它們發送給適當的事件處理程序。嵌入式編程中的一種常見模式是通過所謂的超級循環來實現:程序運行無限循環,無限次地調用系統需要執行的每個任務。

這種方法的一個好處是,執行流保持了相當的可讀性和直觀性,并且還避免了復雜的多線程或中斷處理可能導致的一些潛在問題。但是,任何運行時間過長(或崩潰!)的事件處理程序都會影響主應用程序的性能和穩定性。

隨著FreeRTOS或Azure RTOS ThreadX等嵌入式開發的實時操作系統越來越流行,一種更現代的方法是讓UI事件循環在專用的后臺任務中運行。因此,操作系統可以確保此任務(優先級較低)不會影響主應用程序的性能。

嵌入式GUI并不總是需要像fast和responsive那樣具有良好的性能。然而,盡可能高效地使用嵌入式資源被認為是一種良好的實踐。確保您的GUI和應用程序代碼的性能盡可能合理,這可能會為您節省大量資金,因為這意味著您可以堅持使用盡可能*小的MCU來完成任務。