在做rt-thread系統移植的這段時間里,積累一些快速移植的經驗,不論是現有架構的不同型號的芯片,還是一個全新架構的移植,只需要按照一定的步驟進行,一般大的方向不會出錯。剩下的事情就是解決為什么沒有達到預期效果的問題。
移植的里程碑有如下的幾個:1.芯片工作在正常的模式,可以正常的執行c代碼邏輯2.至少有一個串口驅動3.上下文切換邏輯4.定時器可以正常的使用5.串口輸入有正常的中斷產生并能夠讀到數據針對以上的順序詳細描述問題以及解決辦法。
芯片的工作模式
不同架構的芯片一定會有對應的模式適合操作系統的運行,這是芯片設計時就考慮到的問題,所以移植也要遵循這種規則。另外也涉及到寄存器的訪問權限問題。比如armv7,其操作系統存在的模式為system模式,可以方便的切換到其他模式。還有比較典型的armv8架構的el1特權級別。當然把芯片模式切換到其他的模式,也可以,比如rt-thread整個系統運行在el3特權模式,在el3特權級別最高,但是并不是越高越好,往往el3會有更加合適的用法。其切換到邏輯一般在芯片啟動后,執行的最初一段的匯編代碼邏輯里面,一般芯片在上電后,都會進入最高特權權限的模式里,切換到操作系統特定的特權級別模式即可。
可以正常執行c代碼
完成這一步也是匯編的代碼的實現,這一步的通用關鍵操作是bss段清零,以及設置棧指針地址。 對于bss段清零的必要性是因為c語言的語法規則,以前的存儲程序的存儲器是很貴的,所以程序在生成的時候,把未初始化的全局變量和靜態變量,這些存儲空間不存入存儲器空間,然后在程序加載的時候,將這段空間指向的區域清零。而函數中的非靜態的變量則存儲在棧中,地址不確定。 如果不進行bss的清零,可能導致的問題是全局變量和靜態變量的值不確定,導致程序編程時遇到異常的現象。 清空bss段的步驟也很簡單,就是將bss這一段內存空間設置為0即可。而設置棧地址也就是sp的地址,僅僅是為了在操作系統線程還未啟動調度時,最開始的棧空間。根據c語言的函數調用規則,c語言進行函數調用時,都需要壓棧和出棧,這段棧空間是用戶自行分配的。 所以需要注意點是rt-thread啟動調度前也是有一個棧空間的,調度啟動后該棧空間不被使用,每個線程棧空間才生效。
至少有一個串口驅動
要完成這個工作,需要注意的問題是事先已經完成了串口驅動的驗證工作。也就是可以正常的接收和發送數據。完成rt-thread串口驅動對接,只需實現串口初始化,串口接收,串口發送,中斷注冊即可。 由于前期沒有中斷,實現串口發送功能就可以接著進行下面工作了。正常情況下,可以看到串口可以輸出rt-thread的logo了。
上下文切換邏輯
?對于程序的上下文,可以理解為程序當前運行的現場。其現場里面主要包含的內容有,當前所有的寄存器狀態,當前sp的值,有些處理器還有pc值等等。 對于第一個調度起來的線程,其上下文的內容是人工手動賦值的。因為并不能保證調度器執行的第一個線程是哪個具體的線程,所以每個線程都會存儲一個人工填充的上下文。 需要注意的地方主要有三點,第一個線程調度啟動后,會打開全局中斷,具體是在上下文恢復時,由匯編代碼實現。第二個是線程退出后,會啟動下一次調度,線程回收工作由空閑線程完成。第三點一定要確保壓棧的順序和出棧的順序一致性。 該功能實現正常的標志是可以正常進入main函數以及msh控制臺。但不能輸入控制,因為沒有實現串口輸入中斷,如果已經實現串口中斷,那可以msh輸入。定時器可以正常使用
定時器可以正常使用的前提中斷可以正常的產生,然后周期性的產生定時器中斷。 定時器是系統tick的關鍵,沒有定時器,系統將無法在任務中通過delay釋放CPU資源,但是可以通過主動切換任務的方式進行調度。關于rt-thread的tick的時間片多少合適的問題,這里解釋為,一般合適的10ms,對于主頻很高的芯片可以是1ms。曾經在30mhz的主頻的FPGA上驗證系統,發現并不能正常運行起來。分析因為系統定時器中斷產生的太頻繁,主頻太低,程序來不及處理完成又發生了中斷。
串口可正常輸入
該步驟可作為移植的成功的驗證工作,這一步的工作并非技術難點,但是往往前面步驟沒有成功,可能會導致這里出現不了想要的現象。 比如曾經協助一個客戶完成移植工作時,發現串口中斷打開后,只能輸入一個字符串后無反應,后來才查到中斷處理標志沒有清空。一般可以正常的輸入輸出,該系統移植就基本成功了。
移植的工作難點
?對于上面的步驟中,最難的就是棧幀的規劃,上下文切換和中斷處理。結合實際移植經驗,往往容易出問題的地方就是入棧和出棧的順序對不上,或者有些寄存器沒有存到棧中。在這個工作的時候,要檢查一下寄存器是32位還是64位,可能因為這個小細節,導致棧幀的偏移。 另外要注意的是,線程壓棧的時候,一定要壓線程退出后的回收函數,曾經也因為沒有注意這個細節導致main函數退出后,系統運行異常。 中斷里面復雜設計在于中斷的嵌套,往往在中斷里執行調度,并不會立馬執行到切換線程的上下文,這樣就破壞了現場,而是待到所有中斷執行完成后,再切換上下文。這一點在cortex-m上很好理解,中斷控制器在處理pendsv異常時,總是等待其他高優先級中斷處理完成后,再去處理優先級最低的pendsv。而對于sparc這種設計,切換任務是通過trap異常實現的,trap異常高于中斷,也就是切換線程優先級高于中斷,這是系統設計里面不合理的,在軟件設計時,往往通過設置中斷嵌套標志位,等到所有中斷執行完成后,再切換上下文,一定不能夠在中斷執行時,把上下文切換走。移植經驗分享
rt-thread的移植是有一些關鍵點的,找到這些關鍵點,可以非常順利的規劃清楚方向和目標,對于每個關鍵點進行技術攻克,這樣是最快也是最高效的做事方式。 要想移植不同芯片架構,需要非常清楚這個芯片的架構,也需要非常熟悉rt-thread系統最關鍵點底層代碼。一般熟悉rt-thread的底層代碼并不是很難,從頭讀一遍aarch64的rt-thread最小系統實現兩三天就能差不多理解,而芯片手冊的閱讀要結合實際的工作經驗,弄清楚芯片特權模式、看懂寄存器,看懂匯編基本就可以了。當然有些處理器是需要實現mmu才能正常執行的,比如aarch64,必須實現mmu的功能,即使是1:1映射。
RT-Thread開發者大會
我們將聯合重量級合作伙伴,圍繞AIoT的發展、產業技術趨勢,聚焦控制、連接、行業應用開發,通過主題演講、技術分享、應用演示等環節,助力開發者探索萬物智能的世界,期待與大家一起相聚線上直播間!
現在掃碼報名 我們將在報名者中抽取“幸運參會者100名” 贈送RT-Thread新款開發板(即將揭秘)
本次將在大會當天在直播間宣布中獎名單
更多獎品即將來襲...
-
RT-Thread
+關注
關注
31文章
1286瀏覽量
40109
原文標題:RT-Thread針對不同架構芯片移植的方法
文章出處:【微信號:RTThread,微信公眾號:RTThread物聯網操作系統】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論