首先下載官方的開發(fā)工具，包括MPLAB、XC32、Harmony，但是要想在MPLAB中創(chuàng)建Harmony的工程，得按照help_harmony_vol_I.pdf中的說明，先在MPLAB中安裝harmony的plug-in。

接下來進入我們的主題——殺雞就要用牛刀，點燈怎么用牛刀呢？那就把uCOS跑起來吧，在任務中去點燈！

原本的計劃是拿Micrium官網PIC32的BSP包過來移植，但是簡單地看了看Harmony的介紹文檔之后，發(fā)現(xiàn)它竟然支持常用的幾款RTOS，其中就有uCOS-III，隨即決定用Harmony創(chuàng)建uCOS的工程。創(chuàng)建工程、配置系統(tǒng)時鐘這兩步和參考文章中的方法都一樣，不羅嗦了；接下來開始就要自己配置Harmony Configurator了

1. 在Options中將Third Party Libraries中的uC/OS-III打開

2. 在_SYS_Tasks中點燈，后面的延遲1000個tick對于系統(tǒng)的默認配置來說就是延時1秒

然后我就發(fā)現(xiàn)沒有其他需要配置的了，難道移植uCOS的工作就這么結束了？這么簡單？不可能吧？？？趕快生成代碼、編譯、加載到板子上跑一下，果然沒那么順利，燈不閃。。。沒辦法，只能debug定位了。好在板子上自帶jtag調試模塊，打開MPLAB的debug功能，發(fā)現(xiàn)板子死在這兒了，異常！！！估計又得調一陣了。。。

不得不說MPLAB的調試功能還是相當強大的，Call Stack里還能找到發(fā)生異常的點，竟然在kernel中死了，按說uCOS的kernel已經很成熟了，不應該出這種低級問題

在前一句打個斷點看看異常是怎么發(fā)生的，結果令人詫異：就在給*p_ts賦值的時候發(fā)生了異常！這就是個局部變量啊，怎么能導致異常呢，看看它的地址確實有些詭異

翻開PIC32MX470的芯片手冊，找到芯片的memory map，發(fā)現(xiàn)0x9D0035FC竟然是Program Flash空間的地址，就這么用指針賦值的話肯定非法，可是p_ts是什么時候變成的這個值呢？

再仔細往前找，發(fā)現(xiàn)在發(fā)生異常前kernel有發(fā)生過調度，難道是調度之后寄存器恢復錯了？再跟下去發(fā)現(xiàn)確實是這樣，只要os調度后p_ts就不對了。我們知道uCOS的任務現(xiàn)場是存在棧中的，難不成有棧越界？工程里又沒什么應用代碼，應該不是應用代碼的問題，那會不會是配置的問題呢？查了下配置默認的最小堆棧size是64，系統(tǒng)中除了idle任務的堆棧是64，其他的都至少是512。MIPS和ARM不一樣，有32個通用寄存器，難不成64的堆棧size對保存現(xiàn)場來說太小了？改成128試試

修改之后重新生成代碼、編譯、下載，果然跑起來了，看來默認的64的idle任務堆棧確實設置小了

用uCOS-III點燈完成，也算小試了一把牛刀，但是沒有大規(guī)模的改代碼，就這么簡單的改了改配置就把RTOS跑了起來，這讓我心里隱隱地覺得有些不安，有什么焦慮呢，。