內(nèi)核間的通信可分為兩類:一類是控制與狀態(tài)信息的通信,另一類則是數(shù)據(jù)通信。前者一般不攜帶數(shù)據(jù),但往往有較高的實時要求;后者則主要是各類數(shù)據(jù)緩沖區(qū),通常實時性要求偏低但數(shù)據(jù)量大??刂?狀態(tài)通信有較大的通用性,并且與任務(wù)間的同步較為相似。這類通信適合由系統(tǒng)軟件實現(xiàn)并提供編程接口。數(shù)據(jù)通信則往往與具體應(yīng)用相關(guān)較大(尤其是在數(shù)據(jù)結(jié)構(gòu)上),需要量體裁衣。在實現(xiàn)時,適合由應(yīng)用軟件定義各種數(shù)據(jù)結(jié)構(gòu)。
內(nèi)核間通過共享的RAM進行通信,并且每個內(nèi)核都可以觸發(fā)對方的一個中斷源,通過準(zhǔn)備數(shù)據(jù)-觸發(fā)中斷的方式進行通信,如圖2所示。當(dāng)然,內(nèi)核也可以定期檢查共享RAM的狀態(tài)。

?
圖2:內(nèi)核間使用共享內(nèi)存通信模式圖
接下來,我們介紹基于消息隊列和消息池的控制/狀態(tài)通信方案。
消息隊列:開設(shè)兩個消息隊列,一個用于M4發(fā)送消息給M0,另一個則是M0發(fā)送消息給M4。兩個隊列的地址需事先約定好。隊列是循環(huán)隊列,可以使用簡單的數(shù)組配以讀、寫下標(biāo)來實現(xiàn),也可以使用鏈表結(jié)構(gòu)來實現(xiàn)。前者實現(xiàn)簡單、開銷小,但消息只能是定長,不便于攜帶其它信息,還有,就是必須把數(shù)組放置在共享內(nèi)存區(qū)連續(xù)的位置,靈活性低?;阪湵淼膶崿F(xiàn)用指針鏈接每則消息,每則消息除了公共的鏈表控制部分外,還可以根據(jù)消息類別攜帶各種各樣的附加參數(shù),并且可以由系統(tǒng)軟件的內(nèi)存管理機制靈活分配消息內(nèi)存,不過,缺點是相對復(fù)雜,額外開銷大。若涉及動態(tài)內(nèi)存管理,實時性將遠不如基于數(shù)組的方案。
消息隊列有一個缺點,就是消息的串行化處理,它沒有優(yōu)先級的概念。但實際上,我們有實時操作系統(tǒng)(RTOS)及嵌套中斷機制的支持,本應(yīng)實現(xiàn)消息的并發(fā)處理。
消息池:消息池在存儲結(jié)構(gòu)上其實是簡化的基于數(shù)組的消息隊列——去掉了隊列的讀、寫下標(biāo)記錄器。池中每個元素是一個消息,并且有一個字節(jié)指示每個元素的狀態(tài)——空閑/已處理、新、半處理。當(dāng)發(fā)送方寫入消息時,掃描數(shù)組以查找空閑位置;當(dāng)接收方讀取消息時,也是掃描數(shù)組以查找狀態(tài)??梢?,消息池是基于優(yōu)先級來處理消息的——小下標(biāo)的元素優(yōu)先得到處理。
消息池的可掃描性實現(xiàn)了消息的并發(fā)處理,并且可以通過中斷上下文和任務(wù)上下文分兩次“反芻式”處理。在處理消息池的中斷服務(wù)例程中,先掃描各消息完成第一次處理,執(zhí)行消息中(如果有的話)對實時性要求較高的部分。如果系統(tǒng)中沒有使用RTOS,可以在后臺的主循環(huán)中,再接下來二次掃描消息池,以完成第二次處理。對于使用了RTOS的系統(tǒng),可以根據(jù)消息的優(yōu)先級,創(chuàng)建或激活不同優(yōu)先級的任務(wù),使消息“附身”在這些任務(wù)的上下文中得到第二次處理。
消息池的一大缺點就是不宜支持較大數(shù)目的待處理消息。如有需要,可以給每則消息添加鏈表控制字段,我們可以把同一優(yōu)先級的消息鏈成一串,從而徹底消除這一局限。
若干重要的細節(jié)
內(nèi)核互斥:偽并行的多任務(wù)之間需要互斥訪問共享資源,真并行的內(nèi)核之間更是如此。尤其關(guān)鍵的是,一個內(nèi)核無法關(guān)閉另一個內(nèi)核的中斷,因此還無法通過關(guān)中斷臨界區(qū)來保護。唯一能保證的,就是不會出現(xiàn)兩個內(nèi)核同時存取相同的地址。另外,由于架構(gòu)上的局限,無法使用“自旋鎖”來互斥。為此,我們可以通過施加一些編程準(zhǔn)則來實現(xiàn)互斥。最簡易有效的方法,就是在相同地址上給每個內(nèi)核分別設(shè)置“只讀”或“只寫”的權(quán)限,或者是有條件的讀寫權(quán)限。比如,對于消息隊列的讀位置,只有接收方可以寫,而發(fā)送方只能讀取來判斷隊列是否空/滿。又如,對于消息池,盡管發(fā)送方和接收方對池中的元素狀態(tài)均可讀可寫,但有如下的條件:發(fā)送方只能把空閑狀態(tài)改為非空閑;接收方只能把各種非空閑的狀態(tài)改為空閑。再如,對于鏈表結(jié)構(gòu),可以只允許發(fā)送方更新各種指針;接收方通過更改鏈表中元素的狀態(tài)和觸發(fā)中斷,以指示發(fā)送方更新各指針的時機。
內(nèi)核鑒別:M4向下兼容M0,這使我們可以重用很多的源代碼。但是,有時需要鑒別當(dāng)前正在哪個內(nèi)核上運行。這有兩種方法,分別用于不同場合:如果在編譯期間鑒別即可,則可以在編譯器設(shè)置中,預(yù)定義諸如“CORE_M4”和“CORE_M0”的宏,使用C/C++的條件編譯來處理;若需要在運行期間區(qū)分,可以讀取一個名為“CPUID”的寄存器,根據(jù)CPUID的值來判定是M4還是M0。
初始化與可執(zhí)行映像:LPC4350在完成上電復(fù)位后,M4開始執(zhí)行代碼,而M0卻一直保持在復(fù)位狀態(tài)。這樣,我們也可以無視M0的存在,而只按單核MCU來使用。為使用M0,需要讓M4為M0準(zhǔn)備好開始執(zhí)行的全部環(huán)境,包括寄存器上下文與地址空間等,然后釋放M0。當(dāng)M0處在復(fù)位狀態(tài)時,我們可以通過JTAG發(fā)現(xiàn)M0,但是卻無法操作它。因此,如果要調(diào)試M0的程序,需要先給M4下載適當(dāng)?shù)挠诚瘢蛊溽尫臡0才可,不可能在拿到一個空白的芯片后,直接先從M0動手。
盡管M4與M0各有自己的映像,但是我們可以把M0的映像內(nèi)含于M4的映像中,這樣在生產(chǎn)時只需要燒寫一次閃存。為了并入M0的映像,工具鏈通常會提供把映像轉(zhuǎn)換成C數(shù)組定義格式的功能。通過這個功能,我們把M0的映像轉(zhuǎn)換成一個C數(shù)組的表格,并且把它和M4的源文件一同編譯連接,這樣一來,M0的映像就嵌入到M4的映像中了。M4在初始化期間,要把M0的映像拷貝到準(zhǔn)備讓M0執(zhí)行的位置。由于M0固定從零地址開始取向量,M4還需要設(shè)置M0的地址映射,把映像的首地址設(shè)置成為M0的零地址。
值得一提的是,這種“主控帶動協(xié)控”的設(shè)計哲學(xué),也是被AMP普遍采用的。
調(diào)試時的細節(jié):當(dāng)我們使用調(diào)試仿真器連接MCU時,通常都會產(chǎn)生復(fù)位信號,但范圍可僅限于內(nèi)核,也可復(fù)位全片。在調(diào)試M0時,需設(shè)置復(fù)位范圍僅包括M0,避免殃及正在運行的M4。另外,也需要編寫適當(dāng)?shù)恼{(diào)試初始化腳本,以準(zhǔn)備好內(nèi)核的執(zhí)行環(huán)境。這些工作繁瑣,但具有高度的通用性,我們可以借鑒現(xiàn)有的腳本。
我們可以同時調(diào)試M4和M0:只需運行兩個獨立的IDE進程,分別打開相應(yīng)的工程即可。經(jīng)實踐,至少在MDK+ULINK下可行。
評論