轉載而來，前段時間剛好用到，現(xiàn)在看了很是清晰。

本文從對比兩顆分立MCU與單芯片雙核MCU開始(以LPC4350為例)，展開介紹了非對稱雙核MCU的基礎知識與重要特點。接下來，重點介紹了核間通信的概念與幾種實現(xiàn)方式，尤其是基于消息池的控制/狀態(tài)通信。然后，對內核互斥、初始化流程等一些重要的細節(jié)展開了論述。最后提出了雙核任務分工的兩種應用模型，并分別舉例。

背景與基本概念

在開發(fā)MCU應用系統(tǒng)時，如果單顆MCU無法滿足系統(tǒng)的要求，一個很普遍的做法就是使用兩顆或更多的MCU，把一部分“雜項工作”分配給另一個有“助理”性質的低端MCU來完成。但是，采用兩顆MCU，缺點也很明顯，尤其是在芯片與PCB成本、系統(tǒng)可靠性及功耗方面都有先天的不足。此外，若采用了不同架構的MCU，還要面臨需要不同的開發(fā)工具與開發(fā)人員的挑戰(zhàn)。如果換一種思路，讓MCU內部包含兩個內核，其中一個用于主控，另一個用于協(xié)控，并且它們主控與協(xié)控在架構上能夠向下兼容、高效通信，則在很多場合下都可以既保持多機系統(tǒng)的強大，又能避免多機系統(tǒng)的不足。

事實上，這即是“非對稱多處理器(簡稱AMP)”架構的特點。AMP是與“對稱多處理器(簡稱SMP)”相對的架構，后者各處理器有一致的編程模型，并且在分配工作時主要以均衡為原則。而AMP的優(yōu)點在于精細的任務分工，靈活地適應不同情景，物盡其用，以最佳地平衡成本、性能與功耗。此外，AMP的編程難度也更低。因此，在MCU應用領域，AMP較SMP更為適合。

與獨立的雙MCU相比，AMP架構有很多優(yōu)點。其中相當關鍵的就是，再添加一個內核的代價遠比添加一個獨立的MCU要低，尤其是當兩個內核架構相似時，甚至僅相當于在現(xiàn)有硅片上再添加一兩個UART。另一方面，兩個內核可以有相同的主頻，并且可以通過總線矩陣平等地訪問片上資源。而在分立的雙MCU方案中，協(xié)控MCU的主頻常常遠低于主控，并且雙方使用低速的串行鏈路通信。

接下來，我們以恩智浦(NXP)半導體公司新推出的LPC4300系列為例(尤以LPC4350型號為代表)，對AMP MCU進行簡單介紹。

非對稱雙核MCU的特點

AMP MCU一般用于相對大型的系統(tǒng)，這些系統(tǒng)對功能和性能都有較高的要求。在功能上，應支持較多的外設。LPC4350片載2個高速USB、2個CAN、工業(yè)以太網(wǎng)、圖形LCD控制器，以及SDHC等接口;外加一些獨有的邏輯可配置外設以及眾多傳統(tǒng)外設，適用于工控、能源、醫(yī)療、音頻、車載、電機、監(jiān)控等眾多行業(yè)產(chǎn)品的開發(fā)。

性能的改善則是AMP MCU的靈魂。內核、存儲器，以及總線架構對于性能有著至關重要的影響。圖1展示了LPC4350的實現(xiàn)方式。

圖1：LPC4350的內核、存儲器以及總線連接圖

首先是內核的選擇。LPC4350基于32位的ARM Cortex-M4和Cortex-M0內核(以下簡稱M4和M0)，兩個內核均可在高達204MHz的主頻下執(zhí)行代碼。其中，M4以信號處理和浮點運算能力見長，勝任很多原先要采用DSP才能滿足的應用，并且繼承了Cortex-M3的控制能力;另一方面，M0以其成本、能效和處理能力的壓倒性優(yōu)勢，正迅速吸引開發(fā)人員從8/16位架構向上過渡。更重要的是，M4完全向下兼容M0，使用同一套開發(fā)工具即可開發(fā)、調試。

其次是存儲器的容量和組織方式。LPC4350配備多達264KB片上RAM，并且這些RAM被劃分成4組，每組連接一條單獨的總線，而并非沒有分塊。如若不然，則會出現(xiàn)兩個核競爭使用同一塊RAM的情況——性能反而還不如只用單個內核!進一步，LPC4350還有兩條總線連接到外部擴展的并行和串行存儲器，故總共有6個獨立的存儲器地址空間——LPC4350無片上閃存。對于有片上閃存的型號，片上閃存也分為兩塊。

最后是總線架構。LPC4350內部有一個八層總線矩陣。它如同一組縱橫開關，可以把CPU與包括存儲器在內的眾多從設備通過總線任意連接。合理分配總線接通關系，避免多個主設備(如CPU和DMA)同時訪問相同的存儲器或外設，可以最大地保證各條數(shù)據(jù)流并行不悖，從而可以充分發(fā)揮性能上的優(yōu)勢。

內核間通信

內核間的通信可分為兩類：一類是控制與狀態(tài)信息的通信，另一類則是數(shù)據(jù)通信。前者一般不攜帶數(shù)據(jù)，但往往有較高的實時要求;后者則主要是各類數(shù)據(jù)緩沖區(qū)，通常實時性要求偏低但數(shù)據(jù)量大?？刂?狀態(tài)通信有較大的通用性，并且與任務間的同步較為相似。這類通信適合由系統(tǒng)軟件實現(xiàn)并提供編程接口。數(shù)據(jù)通信則往往與具體應用相關較大(尤其是在數(shù)據(jù)結構上)，需要量體裁衣。在實現(xiàn)時，適合由應用軟件定義各種數(shù)據(jù)結構。

內核間通過共享的RAM進行通信，并且每個內核都可以觸發(fā)對方的一個中斷源，通過準備數(shù)據(jù)-觸發(fā)中斷的方式進行通信，如圖2所示。當然，內核也可以定期檢查共享RAM的狀態(tài)。

圖2：內核間使用共享內存通信模式圖

接下來，我們介紹基于消息隊列和消息池的控制/狀態(tài)通信方案。

消息隊列：開設兩個消息隊列，一個用于M4發(fā)送消息給M0，另一個則是M0發(fā)送消息給M4。兩個隊列的地址需事先約定好。隊列是循環(huán)隊列，可以使用簡單的數(shù)組配以讀、寫下標來實現(xiàn)，也可以使用鏈表結構來實現(xiàn)。前者實現(xiàn)簡單、開銷小，但消息只能是定長，不便于攜帶其它信息，還有，就是必須把數(shù)組放置在共享內存區(qū)連續(xù)的位置，靈活性低。基于鏈表的實現(xiàn)用指針鏈接每則消息，每則消息除了公共的鏈表控制部分外，還可以根據(jù)消息類別攜帶各種各樣的附加參數(shù)，并且可以由系統(tǒng)軟件的內存管理機制靈活分配消息內存，不過，缺點是相對復雜，額外開銷大。若涉及動態(tài)內存管理，實時性將遠不如基于數(shù)組的方案。

消息隊列有一個缺點，就是消息的串行化處理，它沒有優(yōu)先級的概念。但實際上，我們有實時操作系統(tǒng)(RTOS)及嵌套中斷機制的支持，本應實現(xiàn)消息的并發(fā)處理。

消息池：消息池在存儲結構上其實是簡化的基于數(shù)組的消息隊列——去掉了隊列的讀、寫下標記錄器。池中每個元素是一個消息，并且有一個字節(jié)指示每個元素的狀態(tài)——空閑/已處理、新、半處理。當發(fā)送方寫入消息時，掃描數(shù)組以查找空閑位置;當接收方讀取消息時，也是掃描數(shù)組以查找狀態(tài)?？梢?，消息池是基于優(yōu)先級來處理消息的——小下標的元素優(yōu)先得到處理。

消息池的可掃描性實現(xiàn)了消息的并發(fā)處理，并且可以通過中斷上下文和任務上下文分兩次“反芻式”處理。在處理消息池的中斷服務例程中，先掃描各消息完成第一次處理，執(zhí)行消息中(如果有的話)對實時性要求較高的部分。如果系統(tǒng)中沒有使用RTOS，可以在后臺的主循環(huán)中，再接下來二次掃描消息池，以完成第二次處理。對于使用了RTOS的系統(tǒng)，可以根據(jù)消息的優(yōu)先級，創(chuàng)建或激活不同優(yōu)先級的任務，使消息“附身”在這些任務的上下文中得到第二次處理。

消息池的一大缺點就是不宜支持較大數(shù)目的待處理消息。如有需要，可以給每則消息添加鏈表控制字段，我們可以把同一優(yōu)先級的消息鏈成一串，從而徹底消除這一局限。

若干重要的細節(jié)

內核互斥：偽并行的多任務之間需要互斥訪問共享資源，真并行的內核之間更是如此。尤其關鍵的是，一個內核無法關閉另一個內核的中斷，因此還無法通過關中斷臨界區(qū)來保護。唯一能保證的，就是不會出現(xiàn)兩個內核同時存取相同的地址。另外，由于架構上的局限，無法使用“自旋鎖”來互斥。為此，我們可以通過施加一些編程準則來實現(xiàn)互斥。最簡易有效的方法，就是在相同地址上給每個內核分別設置“只讀”或“只寫”的權限，或者是有條件的讀寫權限。比如，對于消息隊列的讀位置，只有接收方可以寫，而發(fā)送方只能讀取來判斷隊列是否空/滿。又如，對于消息池，盡管發(fā)送方和接收方對池中的元素狀態(tài)均可讀可寫，但有如下的條件：發(fā)送方只能把空閑狀態(tài)改為非空閑;接收方只能把各種非空閑的狀態(tài)改為空閑。再如，對于鏈表結構，可以只允許發(fā)送方更新各種指針;接收方通過更改鏈表中元素的狀態(tài)和觸發(fā)中斷，以指示發(fā)送方更新各指針的時機。

內核鑒別：M4向下兼容M0，這使我們可以重用很多的源代碼。但是，有時需要鑒別當前正在哪個內核上運行。這有兩種方法，分別用于不同場合：如果在編譯期間鑒別即可，則可以在編譯器設置中，預定義諸如“CORE_M4”和“CORE_M0”的宏，使用C/C++的條件編譯來處理;若需要在運行期間區(qū)分，可以讀取一個名為“CPUID”的寄存器，根據(jù)CPUID的值來判定是M4還是M0。

初始化與可執(zhí)行映像：LPC4350在完成上電復位后，M4開始執(zhí)行代碼，而M0卻一直保持在復位狀態(tài)。這樣，我們也可以無視M0的存在，而只按單核MCU來使用。為使用M0，需要讓M4為M0準備好開始執(zhí)行的全部環(huán)境，包括寄存器上下文與地址空間等，然后釋放M0。當M0處在復位狀態(tài)時，我們可以通過JTAG發(fā)現(xiàn)M0，但是卻無法操作它。因此，如果要調試M0的程序，需要先給M4下載適當?shù)挠诚?，使其釋放M0才可，不可能在拿到一個空白的芯片后，直接先從M0動手。

盡管M4與M0各有自己的映像，但是我們可以把M0的映像內含于M4的映像中，這樣在生產(chǎn)時只需要燒寫一次閃存。為了并入M0的映像，工具鏈通常會提供把映像轉換成C數(shù)組定義格式的功能。通過這個功能，我們把M0的映像轉換成一個C數(shù)組的表格，并且把它和M4的源文件一同編譯連接，這樣一來，M0的映像就嵌入到M4的映像中了。M4在初始化期間，要把M0的映像拷貝到準備讓M0執(zhí)行的位置。由于M0固定從零地址開始取向量，M4還需要設置M0的地址映射，把映像的首地址設置成為M0的零地址。

值得一提的是，這種“主控帶動協(xié)控”的設計哲學，也是被AMP普遍采用的。

調試時的細節(jié)：當我們使用調試仿真器連接MCU時，通常都會產(chǎn)生復位信號，但范圍可僅限于內核，也可復位全片。在調試M0時，需設置復位范圍僅包括M0，避免殃及正在運行的M4。另外，也需要編寫適當?shù)恼{試初始化腳本，以準備好內核的執(zhí)行環(huán)境。這些工作繁瑣，但具有高度的通用性，我們可以借鑒現(xiàn)有的腳本。

我們可以同時調試M4和M0：只需運行兩個獨立的IDE進程，分別打開相應的工程即可。經(jīng)實踐，至少在MDK+ULINK下可行。

核間任務分工

M0沒有M4強大的處理能力，但是作為一個CPU，亦有完整的中斷系統(tǒng)和基本的算術與數(shù)據(jù)傳送能力，并且在LPC4350上，可以在高達204MHz的主頻下運行。合理地分擔一些任務給M0，才能利用雙核設計的優(yōu)勢。接下來，我們討論兩種主要的任務分工模型。

處理高頻中斷——智能“DMA”：中斷的響應是有額外開銷的：既包括CPU的中斷模型本身產(chǎn)生的硬件開銷，也包括操作系統(tǒng)的中斷管理產(chǎn)生的軟件開銷，當然，也還有中斷服務程序本身執(zhí)行的開銷。當中斷的頻率很高時(比如：高達幾十甚至幾百kHz)，中斷的響應將對CPU時間產(chǎn)生不可忽略的額外開銷。更重要的是，中斷的響應是由硬件處理，并凌駕于任務管理之上的，這可以影響任何任務的執(zhí)行而不論其優(yōu)先級如何。DMA明顯改善了這一狀況。但是當DMA通道或總線分配不足，或者是設備不受DMA支持時，我們就可以讓M0來響應這些高頻的中斷，合理組織數(shù)據(jù)緩沖區(qū)，而如同一個智能的DMA一樣。

例如：在調光設備中，需要進行多達幾十甚至上百路的AD采樣來獲取每路燈光的預期亮度，以及同樣多的LED來指示實際輸出的亮度。后者需要非常多的PWM，極可能已超出硬件PWM通道的數(shù)目。因此，在實現(xiàn)AD采樣與軟件PWM時，均需要快速的通道數(shù)據(jù)流處理與高頻LED刷新，以保證PWM精度。這兩者很容易導致高達幾十kHz的中斷請求，僅中斷響應的額外開銷就可占用一半以上的CPU時間。傳統(tǒng)的做法是使用若干顆MCU來分攤并由主控輪詢。在LPC4350下，則可由M0來處理這些任務。同樣的例子也適用于PLC應用，它需要快速地刷新多路控制。

為弱計算操作提供額外的處理能力：M0的整體性能約是M4的72%，但對于弱計算操作(如：加減乘與邏輯運算，移位，以及簡單的數(shù)據(jù)傳送)，并沒有太多劣勢。弱計算操作在程序中往往占一半以上的比例，尤其體現(xiàn)在驅動程序及一些通信協(xié)議棧上。合理地分配一部分弱計算操作任務給M0，可以有效提升整體的處理能力。這樣，完成相同的任務只需更低的主頻，而降低功耗，或者反過來，能夠在有限的主頻下完成需求更大的任務。

例如：在高精密工業(yè)運動控制中，對于電機的控制往往需要運算量很大的算法，同時又要處理如CAN、工業(yè)以太網(wǎng)，以及各種現(xiàn)場總線的通信。我們可以讓M4來運行電機控制算法，而通信協(xié)議棧與驅動程序則由M0來完成。同樣的例子也適用于嵌入式音頻——由M4執(zhí)行音頻編解碼與音效處理算法，而M0則負責音頻總線、USB等事務。

本文小結

通過以上的介紹可以看出，相比傳統(tǒng)的使用多顆MCU的方案，非對稱雙核MCU在性能、成本、功耗、生產(chǎn)等諸多環(huán)節(jié)都有明顯的優(yōu)勢。核間通信稍顯復雜，但作為基礎設施可由底層系統(tǒng)軟件來實現(xiàn)。在具體開發(fā)時，應根據(jù)實際問題合理分配任務，并且在初始化流程、內核鑒別以及調試上，需注意一些操作細節(jié)。