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

接下來進(jìn)入我們的主題——?dú)㈦u就要用牛刀，點(diǎn)燈怎么用牛刀呢？那就把uCOS跑起來吧，在任務(wù)中去點(diǎn)燈！

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

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

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

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

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

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

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

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

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

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