前言
很多同學都問過這個問題,移植RTOS到一個開發板上,難么?需要學習哪些知識? 從我學習國內常見的RTOS,以及一些構建系統的經驗上看。真正要做移植的工作,需要的知識范圍還是非常廣泛的。
1. 理解這個RTOS的系統源碼目錄組成,源碼層級結構(需要知道廠家SDK放哪里,系統層的Driver驅動,板級配置目錄,工程模板目錄)
2. 理解構建系統(需要知道對應的RTOS所使用的構建系統相關配置,清楚板級的宏定義開關在哪里設置,RTOS配置,以及c文件和h文件如何添加)
3. 理解RTOS的啟動流程(萬一移植后編譯成功,但是無法運行系統時,要清楚如何調試,找到問題點)
4. 理解所移植的MCU的系統時鐘配置,外設配置等等內容
5. 理解RTOS的系統調度和內存管理(萬一無法運行系統,不清楚這些就不能調試)
6. 熟悉調試工具(不管是什么IDE,什么link,都需要熟悉至少一種自己常用的)
個人覺得,移植RTOS其實是一個非常嚴謹的工作,需要的知識除了上面列舉的這些,當然越多越好。有興趣移植的話,建議先把調試工具,RTOS的系統調度、內存管理和啟動流程先給熟悉了,否則一旦碰到問題就不知道自己錯在哪里。
為什么我要先過一遍OneOS的啟動流程
首先我對RTOS的基礎知識還是有一些的,其次也比較熟悉OneOS的目錄結構和系統結構,對構建系統也稍微有一些了解(非常不喜歡Scons,但是沒辦法,OneOS沒有別的構建方式)。 由于長期沒有玩OneOS,對OneOS的啟動流程有點生疏了,為了快速梳理一遍啟動的相關流程和細節,我找到了AliOS-Things的DeveloperKit開發板。這是一塊stm32l496的開發板,目前OneOS的支持也挺好的,串口、SPI屏幕,GPIO等外設都支持得很好了。代碼量相對來說也是比較少的,所以選用這一塊開發板作為熟悉啟動流程的板子。點亮圖片如下:
準備工作
一、安裝編譯工具鏈: 下載gcc-arm-none-eabi工具鏈(arm官網有,自己喜歡哪個版本就下哪個),并安裝。
二、安裝OpenOCD(需要配置好PATH環境變量)和VSCode(隨便裝裝就行,插件只需要Cortex-Debu),網上已經有教程了,不再累贅。
三、下載源碼和編譯 到gitee上克隆OneOS源碼,然后打開OneOS源碼目錄(git clone下來的),切換到v2.3.0版本,并打開根目錄下projects目錄,按教程生成stm32l496-ali-developerkit模板的工程,并編譯好。
開始調試
我用的是VSCode,要調試嵌入式設備,僅僅需要安裝Cortex-Debug這個插件就可以開始調試了(編譯工具鏈和OpenOCD需要提前安裝和配置好)。按下圖的順序創建launch.json調試配置文件。
1. 創建launch.json文件:
2. 選擇Cortex Debug調試器
3. 在打開的launch.json文件編輯中,將文件內容替換成以下內容。
{
// 使用 IntelliSense 了解相關屬性。
// 懸停以查看現有屬性的描述。
// 欲了解更多信息,請訪問: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Cortex Debug",
"cwd": "${workspaceFolder}/build", // 調試時的工作目錄應和編譯目錄一致,否則在調試中會定位不到源碼
"executable": "${workspaceFolder}/out/oneos.elf", // 修改成編譯生成的elf文件路徑
"request": "launch",
"type": "cortex-debug",
"runToEntryPoint": "Reset_Handler", // 入口點改成stm32的復位入口函數
"servertype": "openocd", // GDB Server修改成openocd
"configFiles": [
"interface/stlink.cfg", // 使用板載stlink
"target/stm32l4x.cfg" // 調試目標為stm32l4x
]
}
]
}
進入調試狀態
點擊綠色的小三角開始調試,30秒左右就正式進入調試狀態了如下圖。
在這里,我們先不著急執行程序,往下拉到110行,會發現程序入口點被修改成了entry,如下圖:
注意:很多RTOS都會修改啟動文件,替換程序入口點。因為需要在用戶應用調用之前,先初始化RTOS的相關內容。對于用戶來說,這些初始化的東西在大部分的時候是不需要關注的(寫應用時重點關注應用邏輯,外設初始化、操作系統初始化這些是移植時就要完善好的)。假如是一款全新的芯片(源碼中找不到類似或者已有的芯片支持和啟動文件的)要移植進來,需要關注入口點,否則就算編譯通過了,也沒辦法正常啟動系統。
OneOS啟動流程學習
當我們跟著entry函數,會發現它實際上調用的是_k_startup函數,如下圖:
真正的啟動流程_k_startup函數
然后在_k_startup函數中,有不同功能的函數,大致如下圖:
對于移植工作來說,最容易讓人迷惑的,也就是_k_core_auto_init這個函數的內容,函數實現如下圖:
是不是完全看不懂它做了什么,其實這就是有名的Init Call機制。因為RTOS運行前,需要做相當多的準備工作,而根據用戶的組件設定的不同(例如使用了不同的組件),調用的內容也會有所區別。所以對于這些變化的準備工作,如果都寫在一個函數里,會很亂,也很難看。所以不少RTOS都借鑒了Linux的Init Call機制。 通過一段區分了不同初始化級別的指針,按順序取出指針并執行對應的初始化函數。
Init Call 機制的簡單理解
其實我們并不需要過于在意Init Call機制是如何實現的,我們只需要知道,它是保存在Flash中的一段指針,通過這些指針可以有順序的對初始化函數進行調用即可。以下是在Map文件中搜索.init_call找到的對應內容。在文件中我們不難看出, 當前的工程里一共分了1、2、3、4、5、7個啟動等級(別問我為啥沒有6,以為map文件里沒有),并保存了對應等級需要執行的函數指針。
1. 現在我們繼續跟著啟動流程走,點擊單步執行,進入 Init Call 機制 指定的第一個函數(cotex_m_set_vector)中,大部分情況下可以不用管它,應該是處理中斷向量表指針之類的內容。
2. 單步跳出這個函數后,接下來進入 Init Call 機制 指定的第二個函數(os_hw_board_init),這個函數調用了**板級的外設初始化函數**,這個在我們移植的時候需要注意把板級外設初始化的函數更名成下圖的名稱。同時在圖中也可以看到Init Call 機制實現的重要一環,OS_PREV_INIT(函數名稱, 啟動等級)。正是通過一行,編譯器才會將這個函數指針存入Init Call 機制在flash中指定的固定指針段里。
1. 單步跳出這個函數后,接下來進入 Init Call 機制 指定的第三個函數(driver_stm32_usart_early_driver_init),這個函數給系統的前期輸出指派了對應的串口設備(oneos_config.h文件中定義的OS_CONSOLE_DEVICE_NAME串口名稱一致的設備)。若發現沒有串口輸出信息,可以先檢查是否正確初始化了對應串口,以及是否正確指派了串口設備。
接下來的啟動過程,就不再去分析了(太菜,后面的也不知道怎么解釋)。我們移植前期需要關注的啟動內容,大概就是這些了。基本上完成一個移植工作,串口正常工作,系統調度正常運行,這兩個工作是優先保障的。因為串口Debug也是一個常用的技巧,大部分時候串口輸出可以幫助調試。而完成了串口和線程調度,移植的初步階段就完成了。RTOS的Shell交互,也是非常有用的一個工具。以下是進入OneOS的啟動信息和shell截圖。可以通過在shell中查看線程信息,線程堆信息等待內容。甚至可以在shell中開啟外設,修改外設狀態等(需要編寫shell命令進行支持)。
本次分享就暫時告一段路,移植經驗的分享會接著做構建系統部分的。
審核編輯 黃昊宇
-
單片機
+關注
關注
6037文章
44558瀏覽量
635298 -
移植
+關注
關注
1文章
379瀏覽量
28132 -
RTOS
+關注
關注
22文章
813瀏覽量
119636 -
BSP
+關注
關注
1文章
87瀏覽量
26152
發布評論請先 登錄
相關推薦
評論