uCOS-II在STM32上的移植步驟
加入技術交流群
二、
1. 首先在官網上下載基于STM32的移植工程案例，里面的移植文檔AN-1018中是作者寫的移植文檔，說的很詳細，想要移植的話，多看看這個文檔。
2. 其中有張圖，非常重要，其實就是告訴了移植者要做的工作，如下圖所示：
這個圖表達了什么信息呢，其實就是告訴移植者需要將那些文件移植到你的工程當中，首先是uC/OS-ii的源文件，就是OS_CORE.C、OS_FLAG.C.....ucos_ii.H這些文件，其實是uC/OS-ii的Port文件，包括4個，分別是OS_CPU_C.C,OS_CPU_A.ASM,OS_CPU.H,OS_DBG.C,還有是用戶應用程序里的包含文件，這個里面不能照搬，選擇使用兩個文件，分別為OS_CFG.H和INCLUDES.H，其他三個，可以自己編寫，為什么不套用另外那三個呢，主要是因為那三個文件是針對官方開發板創建的任務，里面包含的信息量太大，編譯的時候，肯定會有大量的錯誤（因為我們是一直到我們自己的板子），所以最好自己寫最簡單的，至于怎么寫，后面再詳細說，可以先建2個空文件，分別是APP.C和APP_CFG.H,這兩個文件的含義很簡單，APP是自己的應用程序C文件，APP_CFG.H是對我們自己的應用程序做的配置文件，看到這里可能會有個疑問，APP_VECT.C文件怎么處理呢，答案是舍棄，因為官方提供的案例是自己寫啟動文件，APP_VECT.C文件是向量表，我們使用的是STM32固件庫里的啟動代碼，所以就不用使用了。BSP部分有兩個文件BSP.C和BSP.H，這個也建議直接舍棄，這個是官方文檔中針對他們的的開發板寫的一些底層的設備驅動，我們自己的開發板跟他們的不同，所以根本就沒必要要，至此，將剛剛分析的這些必須的文件加入到上面創建的無操作系統裸板程序中，進行編譯?？隙〞泻芏噱e誤，下面我們就一一的修改這些錯誤。添加到項目后的文件樹，如下圖所示：
需要注意的是，這其中的app.c和app_cfg.h是自己創建的空的文件，而不是使用官網案例里提供的，如果非要使用官網里面的，那么只能不停的更正其中的錯誤啦。下面就是要修改錯誤的過程了。
3. 修改os_cfg.h 這個是配置uCOS-ii系統功能的頭文件，根據自己的需要進行裁剪任務吧，我只做了一個修改，就是：
，禁用鉤子函數，這是為了防止出現那些所謂的文檔中分析的要寫的那幾個鉤子函數出現錯誤，禁用鉤子函數了，也就不用寫鉤子函數了，其他的根據自己需要裁減吧。
4. OS_CPU_A.ASM文件的修改
這樣修改的目的，是因為MDK編程環境不認識PUBLIC，要用EXPORT.
這個也是因為編程環境的問題。
5. 修改OS_DBG.C
修改：
是編程環境的問題。6. 修改啟動代碼
這個步驟是移植的核心：上面說的其他的修改，都是一些附屬的格式方面的修改，而啟動代碼的修改才是移植的核心，這里簡單的分析2個問題，一是，什么叫移植，二是移植的操作系統如何能夠被我們的工程所應用。所謂移植，打一個恰當的比喻——器官移植，就是將A的器官移植到B身上，使A的器官能夠為B所用。所以移植絕對不是簡單的“復制”，不僅要放到你的工程項目中，更重要的是要能夠和你的項目建立聯系。那么uCOS-ii怎么跟STM32建立聯系呢？
uCOS-ii的核心作用就是任務調度，要使用STM32的一個特殊中斷——PendSV，就是可掛起系統任務中斷，通過該中斷進行系統的調度。還有就是uCOS-ii需要一個基準時間，那么STM32中有一個專用的定時器，嘀嗒定時器SysTick，這個定時器，就是專為操作系統而設計的，通過這個滴答定時器給uCOS-ii提供一個時間基準，每隔固定的時間出發一個PendSV中斷，進行任務的調度。所以呢，在官方案例的移植文檔AN-1018中也特別提到這一點，要將啟動代碼中所有“PendSV_Handler”和“SysTick_Handler”，替換成“OS_CPU_PendSVHandler”和“OS_CPU_SysTickHandler”，這樣就相當于將uCOS-ii的“神經”跟你的項目的“神經”搭在了一起。
7. 此時編譯，發現還有一個錯誤：
8. 創建任務，驗證移植效果。
另外特別注意，官網代碼的創建的第一個開始任務里有一段代碼，如下圖所示：
這個，調用了OSStatInit（）函數，這個函數的作用是啟動統計CPU占用率的函數，這個不太清楚還有沒有其他功能，建議不要使用，因為我在使用的時候，發現，創建的任務都不能工作了，索性就不使用，反倒好了。
評論