0 引言
　　MQXLite操作系統是飛思卡爾公司維護的一款開源的嵌入式實時操作系統，是已有十幾年穩定實踐運行經驗的標準版MQX（Message Queue eXecutive）嵌入式實時操作系統的輕量級版本，專門針對ARM Cortex-M系列中資源有限的MCU開發，目前僅支持M0+/M4內核的MCU，具有內核精簡、資源占用低（低于4K RAM）、執行效率高等特點[1]。
　　目前的MQXLite集成在飛思卡爾公司的圖形化快速程序設計工具——處理器專家（Processor Expert，PE）里，作為其中的一個組件提供，使用獨立的PE軟件套件或是集成了PE的開發環境（CodeWarrior或Kinetis Design Studio）可以方便地構建一個基于MQXLite的工程，實現MQXLite在PE支持芯片上的移植。但此種移植方式過度依賴于PE軟件，移植的通用性與靈活性不足，不利于工程在PE不支持的芯片平臺上移植。
　　針對此缺陷，本文對PE中生成的MQXLite代碼進行了整理與修改，提出了一種改良版的MQXLite組織架構，使得其脫離PE可獨立配置，并利用此架構構建了一個通用的工程框架模板“AMQXLITEFW”。在此框架下，分別實現了MQXLite在M0+內核的飛思卡爾KW01芯片及M4內核的德州儀器CC3200芯片上的移植，拓展了MQXLite的適用平臺。
1 移植研究
　　1.1 MQXLite的組織架構
　　通過分析MQXLite源碼包的構成，并與PE中生成的完整MQXLite工程代碼相比較，可以得出PE下MQXLite組織架構的各部分組成如下：
　　KERNEL：MQXLite的微內核，是標準版MQX內核的精簡。具有基于優先級的搶占式任務調度、中斷處理及任務間的同步與通信(輕量級)等核心功能。
　　PSP：處理器支持包（Processor Support Package，PSP），包含了MQXLite操作系統的上下文切換、中斷控制等與芯片內核密切相關的功能。
　　LDD：PE中提供的邏輯設備驅動（Logic Device Drivers，LDD），用來實現對外設I/O的訪問。
　　BSP：板級支持包（Board Support Package，BSP），包含與具體芯片及電路板相關的時鐘、中斷初始化等內容，通過圖形化的參數配置后，由PE自動生成。
　　TASK：應用任務，用于實現具體的應用功能。
　　在此架構中，KERNEL及PSP的代碼都源于MQXLite的源碼包，其中KERNEL部分是通用代碼，而PSP中穿插有部分LDD及PE生成代碼；LDD及BSP部分的代碼則完全是通過配置PE自動生成，因不同的目標芯片及實際電路板的具體情況而異；TASK中的應用任務代碼根據實際需求編寫，部分與特定平臺相關的應用任務也會調用PE生成的LDD代碼。
　　由此可見，此架構下的MQXLite與PE被緊密地捆綁在了一起。利用此架構，雖然可以在PE的幫助下快速便捷地完成MQXLite在部分目標芯片上的移植，但若想將MQXLite移植到PE不支持的芯片平臺上，實現起來較為困難。
　　可行的解決方案是設法將MQXLite從PE中獨立出來，使其能夠脫離PE單獨配置，并根據目標芯片選用第三方的驅動程序來訪問外設I/O，這樣就增強了MQXLite的移植靈活性與通用性，拓展了MQXLite的適用芯片平臺。基于以上思想，本文對此架構中的組成內容進行了適當的修改，提出了一種改良版的MQXLite組織架構，架構中各組成部分如下：
　　KERNEL：使用MQXLite源碼包中提供的KERNEL代碼。
　　PSP：使用MQXLite源碼包中提供的PSP代碼，用自行編寫的通用代碼替換PE生成代碼。
　　DRIVER：使用第三方驅動而不是PE中的LDD來實現對外設I/O的訪問。
　　BSP：自行編寫通用的時鐘、中斷初始化函數，并利用宏常量的方式傳遞參數，方便根據具體芯片及電路板的情況來進行配置修改。
　　TASK：保留應用任務代碼不變，只在調用到外設I/O驅動時將LDD驅動替換為Driver中的第三方驅動程序。

　　兩種組織架構的對比如圖1所示。相比PE下的MQXLite組織架構，此改良版的架構有獨立、通用、靈活的特點。
　　1.2 通用的工程框架模板
　　為了供移植時參考，本文結合上文提出的改良版MQXLite組織架構與本實驗室提出的基于標準版MQX的工程框架“AMQXFW”，提出了一個面向MQXLite的通用工程框架模板“AMQXLiteFW”，其在Kinetis Design Studio 3.0（KDS 3.0）集成開發環境下的工程組成如圖2所示[2]。

　　工程框架中的MQXLite文件夾存放操作系統的相關文件，包含6個子文件夾：app、bsp、psp、kernel、include及config。其中app對應組織架構中的“TASK”，bsp即架構中的“BSP”，include、kernel及psp共同組成了“KERNEL”及“PSP”；config則存放了MQXLite的配置文件，用于MQXLite內核功能的裁剪。
　　該工程框架模板組織結構清晰，內容簡單明了，便于工程的移植。
2 移植實現
　　利用上文提出的AMQXLiteFW通用工程框架模板及相應的第三方驅動程序，可以方便地實現MQXLite在任何ARM Cortex-M0+/M4內核芯片上的移植。下面從啟動流程、中斷系統、系統定時器及應用任務這幾個方面介紹移植的過程。
　　2.1 啟動流程
　　使用MQXLite的工程需要一個新的復位向量函數Reset_Handler()，以便于在通用的初始化操作之前完成一些與操作系統相關的額外設置。此函數用匯編語言編寫，位于boot.S文件中，主要實現如下功能：
　　(1)重置外設中斷狀態。通過對NVIC相關寄存器的操作來關閉所有外設中斷并清除所有掛起中斷標志。其中由于M0+內核與M4內核所支持的最大外設中斷數目不同（M0+：32，M4：240），所以在移植時可根據目標MCU的類型宏定義來條件編譯不同的代碼。
　　(2)切換棧指針。芯片復位后默認使用主棧指針（Main Stack Pointer，MSP），而操作系統在運行應用任務時使用進程棧指針（Process Stack Pointer，PSP），只有在進入異?；蛑袛鄷r才使用MSP。所以在復位向量函數中需要將CONTROL寄存器的第1位置1，實現從MSP到PSP的切換。此部分M0+內核與M4內核一致，無需修改。
　　(3)FPU相關設置。若目標芯片為M4內核且具有浮點運算單元FPU并決定在MQXLite中使用，則對系統控制塊SCB的CPACR及FPCCR寄存器進行設置，開啟芯片的FPU協處理器，并關閉硬件在進入異常時對FPU相關寄存器的自動壓棧操作。
　　結束以上操作后，跳轉到無操作系統下的通用啟動流程，然后進入應用主函數main()，在其中調用_mqxlite_
　　init()及_mqxlite()函數來初始化并啟動MQXLite操作系統。
　　2.2 中斷系統
　　MQXLite的中斷處理過程分為兩個相對獨立的部分：內核ISR與用戶ISR。內核ISR函數_int_kernel_isr用匯編語言編寫，以便能快速的響應中斷，它完成PSP與MSP之間的切換與上下文的保存，實現硬件中斷到用戶ISR的映射；用戶ISR則通常用C語言編寫，與無操作系統下的中斷服務例程一致，用于處理各種中斷事件[3]。
　　鑒于這種情況，MQXLite在維護ROM中的硬件中斷向量表之外，還維護了一個存儲在RAM中的用戶中斷向量表。在移植時，需要將硬件中斷向量表中的系統定時器中斷向量及所有外設中斷向量都預設為內核ISR函數，以作為它們的通用入口，接著在應用任務中調用_int_install_isr()函數將對應外設的用戶ISR注冊到用戶中斷向量表中。這樣當中斷到來時，首先會進入內核ISR，然后再查找用戶中斷向量表，轉到相應的用戶ISR，實現外設硬件中斷到用戶編寫的中斷服務例程之間的映射。整個中斷處理流程如圖3所示。

　　內核ISR與處理器所用內核有關，位于dispatch.S文件中。此文件可直接從MQXLite源碼包中獲取，并已針對M0+內核及M4內核提供了不同版本，移植時根據需要進行替換即可。用戶ISR在移植時可保持與無操作系統下的外設ISR代碼基本一致。
　　2.3 系統定時器
　　MQXLite使用Cortex-M內核中共有的Systick定時器作為系統定時器，為操作系統提供系統節拍，用于任務的調度，其初始化代碼調用了PE中的LDD驅動。為了擺脫PE，在AMQXLiteFW框架中使用了自行編寫的更為簡單通用的systick_init()函數來代替LDD驅動實現Systick定時器的初始化，然后調用_int_install_isr()函數將MQXLite內核中的滴答處理例程_time_notify_kernel()注冊到Systick的中斷向量中，實現MQXLite操作系統與Systick定時器的關聯。在移植時只需根據具體應用需求，修改bsp.h頭文件中宏定義BSP_ALARM_FREQUENCY的值（單位：Hz），即可改變系統定時器的節拍頻率。
　　2.4 應用任務
　　MQXLite不支持動態任務創建，所以需要在編譯時靜態地為所有任務預先分配好任務?？臻g，并在任務模板列表MQX_template_list中登記任務的相關屬性。
　　MQXLite只支持基于優先級的搶占式先入先出任務調度方式。為了觸發任務，在此框架中會固定地創建自啟動任務task_main，用于外設硬件模塊初始化及其他任務的創建。此任務執行完后會自我阻塞，操作系統開始根據優先級的高低對就緒隊列中的任務進行調度[4]。
　　在移植應用任務時，為了協調任務間的執行順序，既可以使用輕量級的事件、信號量、消息隊列等任務同步組件函數，也可以在任務循環體最后調用_time_delay_
　　ticks()等延時函數來主動放棄CPU的占用權[5]。
3 移植測試
　　為了檢驗提出的AMQXLiteFW框架及移植流程的通用性與有效性，本文在KW01及CC3200這兩款不同內核、不同廠商的MCU上進行了MQXLite的移植測試。
　　3.1 KW01移植測試
　　KW01為飛思卡爾公司推出的基于ARM Cortex-M0+內核的Sub-GHz無線MCU，可工作在290～1 020 MHz的無線頻率范圍內，最高主頻48 MHz，擁有128 KB的ROM及16 KB的SRAM。由于在PE V3.0.0之前并不支持這款芯片，所以利用本文提出的框架及本實驗室自行編寫的KW01外設驅動程序來構建MQXLite移植測試工程。
　　測試工程程序分為兩個部分：發送節點程序與接收節點程序。發送節點程序通過ADC內部通道采集芯片溫度及電源電壓等信息，在收到問詢幀后回發相關數據。接收節點程序對從串口接收到的PC端命令進行無線轉發，并將收到的無線數據通過串口上傳到PC端。
　　移植完成后在KDS 3.0開發環境里編譯工程并下載到測試節點中進行測試，PC端軟件運行結果可看出使用MQXLite的芯片運行正常，實現了目標功能。
　　3.2 CC3200移植測試
　　CC3200是德州儀器公司推出的基于ARM Cortex-M4內核的WiFi無線MCU，支持Wi-Fi 802.11 b/g/n及TCP/IP協議棧，主頻80 MHz，最高擁有256 KB的SRAM。此芯片的生產廠商并非飛思卡爾公司，故PE對其并不支持，測試工程利用本文提出的框架及德州儀器公司提供的外設驅動程序，嘗試將MQXLite操作系統移植到此芯片中。
　　測試程序將CC3200配置為AP模式，與存儲在外部Flash中的網頁進行交互，根據網頁上傳來的信息控制測試板上指示燈的亮滅，并從串口輸出網頁上發送過來的字符串信息。
　　移植完成后在IAR 7.2 IDE里編譯工程并下載到測試板，PC或手機連接到CC3200的WiFi熱點，通過瀏覽器訪問內置網頁進行通信與控制測試，測試結果與預期目標一致，說明MQXLite移植成功。
4 總結
　　移植測試的結果驗證了本文提出的AMQXLiteFW框架的可移植性與通用性。此框架使得MQXLite可以脫離PE移植到任何廠商的ARM Cortex-M0+/M4芯片上，為MQXLite在不同平臺上的移植提供了借鑒。此外，為了進一步提高此框架的通用性，還可以繼續研究修改MQXLite的相關代碼，使其兼容ARM Cortex微控制器軟件接口標準（CMSIS），并統一外設驅動的接口，使得工程更便于移植。
　　參考文獻
　　[1] Freesca1e Semiconductor.MQXLite Real-Time Operating System User Guide. Rev 1.1[EB/OL].(2014-4-2).http：//cache.freescale.com/files/soft_dev_tools/doc/user_guide/MQXLITEUG.pdf.
　　[2] 王宜懷，朱仕浪，姚望舒.嵌入式實時操作系統MQX應用開發技術-ARM Cortex-M微處理器[M].北京：電子工業出版社，2014.
　　[3] 石晶，王宜懷，蘇勇，等.基于ARM Cortex-M4的MQX中斷機制分析與中斷程序框架設計[J].計算機科學，2013，40(6)：41-44.
　　[4] ZHAO T，LONG D.Analysis on task scheduling operating mechanism of embedded real-time operating system MQX[C].Mechatronic Sciences, Electric Engineering and Computer(MEC)，Proceedings 2013 International Conference on.IEEE，2013：1844-1847.
　　[5] 周航慈，吳光文.基于嵌入式實時操作系統的程序設計技術[M].北京：北京航空航天大學出版社，2006.