淺析RT-Thread針對不同架構芯片移植的方法

在做rt-thread系統(tǒng)移植的這段時間里，積累一些快速移植的經驗，不論是現(xiàn)有架構的不同型號的芯片，還是一個全新架構的移植，只需要按照一定的步驟進行，一般大的方向不會出錯。剩下的事情就是解決為什么沒有達到預期效果的問題。

移植的里程碑有如下的幾個：1.芯片工作在正常的模式，可以正常的執(zhí)行c代碼邏輯 2.至少有一個串口驅動 3.上下文切換邏輯 4.定時器可以正常的使用 5.串口輸入有正常的中斷產生并能夠讀到數(shù)據(jù) 針對以上的順序詳細描述問題以及解決辦法。

芯片的工作模式

不同架構的芯片一定會有對應的模式適合操作系統(tǒng)的運行，這是芯片設計時就考慮到的問題，所以移植也要遵循這種規(guī)則。另外也涉及到寄存器的訪問權限問題。 比如armv7，其操作系統(tǒng)存在的模式為system模式，可以方便的切換到其他模式。還有比較典型的armv8架構的el1特權級別。當然把芯片模式切換到其他的模式，也可以，比如rt-thread整個系統(tǒng)運行在el3特權模式，在el3特權級別最高，但是并不是越高越好，往往el3會有更加合適的用法。其切換到邏輯一般在芯片啟動后，執(zhí)行的最初一段的匯編代碼邏輯里面，一般芯片在上電后，都會進入最高特權權限的模式里，切換到操作系統(tǒng)特定的特權級別模式即可。

可以正常執(zhí)行c代碼

完成這一步也是匯編的代碼的實現(xiàn)，這一步的通用關鍵操作是bss段清零，以及設置棧指針地址。 對于bss段清零的必要性是因為c語言的語法規(guī)則，以前的存儲程序的存儲器是很貴的，所以程序在生成的時候，把未初始化的全局變量和靜態(tài)變量，這些存儲空間不存入存儲器空間，然后在程序加載的時候，將這段空間指向的區(qū)域清零。而函數(shù)中的非靜態(tài)的變量則存儲在棧中，地址不確定。

如果不進行bss的清零，可能導致的問題是全局變量和靜態(tài)變量的值不確定，導致程序編程時遇到異常的現(xiàn)象。 清空bss段的步驟也很簡單，就是將bss這一段內存空間設置為0即可。 而設置棧地址也就是sp的地址，僅僅是為了在操作系統(tǒng)線程還未啟動調度時，最開始的?？臻g。根據(jù)c語言的函數(shù)調用規(guī)則，c語言進行函數(shù)調用時，都需要壓棧和出棧，這段?？臻g是用戶自行分配的。 所以需要注意點是rt-thread啟動調度前也是有一個?？臻g的，調度啟動后該?？臻g不被使用，每個線程?？臻g才生效。

至少有一個串口驅動

要完成這個工作，需要注意的問題是事先已經完成了串口驅動的驗證工作。也就是可以正常的接收和發(fā)送數(shù)據(jù)。完成rt-thread串口驅動對接，只需實現(xiàn)串口初始化，串口接收，串口發(fā)送，中斷注冊即可。 由于前期沒有中斷，實現(xiàn)串口發(fā)送功能就可以接著進行下面工作了。 正常情況下，可以看到串口可以輸出rt-thread的logo了。

上下文切換邏輯

對于程序的上下文，可以理解為程序當前運行的現(xiàn)場。其現(xiàn)場里面主要包含的內容有，當前所有的寄存器狀態(tài)，當前sp的值，有些處理器還有pc值等等。

對于第一個調度起來的線程，其上下文的內容是人工手動賦值的。因為并不能保證調度器執(zhí)行的第一個線程是哪個具體的線程，所以每個線程都會存儲一個人工填充的上下文。 需要注意的地方主要有三點，第一個線程調度啟動后，會打開全局中斷，具體是在上下文恢復時，由匯編代碼實現(xiàn)。第二個是線程退出后，會啟動下一次調度，線程回收工作由空閑線程完成。第三點一定要確保壓棧的順序和出棧的順序一致性。

該功能實現(xiàn)正常的標志是可以正常進入main函數(shù)以及msh控制臺。但不能輸入控制，因為沒有實現(xiàn)串口輸入中斷，如果已經實現(xiàn)串口中斷，那可以msh輸入。

定時器可以正常使用

定時器可以正常使用的前提中斷可以正常的產生，然后周期性的產生定時器中斷。 定時器是系統(tǒng)tick的關鍵，沒有定時器，系統(tǒng)將無法在任務中通過delay釋放CPU資源，但是可以通過主動切換任務的方式進行調度。 關于rt-thread的tick的時間片多少合適的問題，這里解釋為，一般合適的10ms，對于主頻很高的芯片可以是1ms。曾經在30mhz的主頻的FPGA上驗證系統(tǒng)，發(fā)現(xiàn)并不能正常運行起來。分析因為系統(tǒng)定時器中斷產生的太頻繁，主頻太低，程序來不及處理完成又發(fā)生了中斷。

串口可正常輸入

該步驟可作為移植的成功的驗證工作，這一步的工作并非技術難點，但是往往前面步驟沒有成功，可能會導致這里出現(xiàn)不了想要的現(xiàn)象。 比如曾經協(xié)助一個客戶完成移植工作時，發(fā)現(xiàn)串口中斷打開后，只能輸入一個字符串后無反應，后來才查到中斷處理標志沒有清空。 一般可以正常的輸入輸出，該系統(tǒng)移植就基本成功了。

移植的工作難點

對于上面的步驟中，最難的就是棧幀的規(guī)劃，上下文切換和中斷處理。 結合實際移植經驗，往往容易出問題的地方就是入棧和出棧的順序對不上，或者有些寄存器沒有存到棧中。在這個工作的時候，要檢查一下寄存器是32位還是64位，可能因為這個小細節(jié)，導致棧幀的偏移。 另外要注意的是，線程壓棧的時候，一定要壓線程退出后的回收函數(shù)，曾經也因為沒有注意這個細節(jié)導致main函數(shù)退出后，系統(tǒng)運行異常。

中斷里面復雜設計在于中斷的嵌套，往往在中斷里執(zhí)行調度，并不會立馬執(zhí)行到切換線程的上下文，這樣就破壞了現(xiàn)場，而是待到所有中斷執(zhí)行完成后，再切換上下文。這一點在cortex-m上很好理解，中斷控制器在處理pendsv異常時，總是等待其他高優(yōu)先級中斷處理完成后，再去處理優(yōu)先級最低的pendsv。而對于sparc這種設計，切換任務是通過trap異常實現(xiàn)的，trap異常高于中斷，也就是切換線程優(yōu)先級高于中斷，這是系統(tǒng)設計里面不合理的，在軟件設計時，往往通過設置中斷嵌套標志位，等到所有中斷執(zhí)行完成后，再切換上下文，一定不能夠在中斷執(zhí)行時，把上下文切換走。

移植經驗分享

rt-thread的移植是有一些關鍵點的，找到這些關鍵點，可以非常順利的規(guī)劃清楚方向和目標，對于每個關鍵點進行技術攻克，這樣是最快也是最高效的做事方式。 要想移植不同芯片架構，需要非常清楚這個芯片的架構，也需要非常熟悉rt-thread系統(tǒng)最關鍵點底層代碼。一般熟悉rt-thread的底層代碼并不是很難，從頭讀一遍aarch64的rt-thread最小系統(tǒng)實現(xiàn)兩三天就能差不多理解，而芯片手冊的閱讀要結合實際的工作經驗，弄清楚芯片特權模式、看懂寄存器，看懂匯編基本就可以了。當然有些處理器是需要實現(xiàn)mmu才能正常執(zhí)行的，比如aarch64，必須實現(xiàn)mmu的功能，即使是1：1映射。

編輯：jq