關(guān)注、星標公眾號，直達精彩內(nèi)容

來源：網(wǎng)絡(luò)素材?| ZeroMing222

這系列開始談軟件上面的設(shè)計，對設(shè)計模式在面向?qū)ο罄锩鎽摳魑欢贾?，或許你在實際開發(fā)當中用到，也或許你見過別人的代碼中用到。當你程序的代碼足夠龐大的時候，你會發(fā)現(xiàn)維護寸步難行，牽一發(fā)而動全身，這個時候你就能夠理解在開發(fā)初期對程序架構(gòu)的搭建重要性。而架構(gòu)最基本熟知的其中就是設(shè)計模式，使用設(shè)計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程序的重用性。嘗試去研究優(yōu)秀的開源代碼，你會驚嘆別人對程序的掌控，這時你會稍稍明白架構(gòu)的目的所在。

文章基于《C嵌入式編程設(shè)計模式》這本書，英文是Design?Patterns?for?Embedded?Systems in C。主要是做個筆記，并添加一點個人的理解，分享出來與各位探討。比較針對嵌入式系統(tǒng)，單片機，程序已C語言為主，盡管是面向過程，但不妨礙我們使用面向?qū)ο蟮乃季S來開發(fā)。

1.?訪問硬件的設(shè)計模式

嵌入式系統(tǒng)，特別單片機最明顯的是對硬件的直接訪問。基礎(chǔ)硬件不僅有CPU，內(nèi)存，鍵盤，傳感器，通訊RS232等這樣的設(shè)備。做單片機的不得不對硬件進行控制，讀，寫操作，而這篇文章已解決管理和操作這些硬件通常的一個模式?；蛟S對你來說并不陌生，但是是否能夠系統(tǒng)的，詳細的表達出來這就不僅僅只是了解就能達到的。

下面討論的設(shè)計模式已經(jīng)在操作硬件上得到證明是可靠有效的。簡單總結(jié)說，硬件代理模式是以封裝詳細信息為目的的硬件抽象的一個原型模式，它有可能改變提供給硬件或來自硬件的信息處理方法。硬件適配器模式擴展硬件代理模式，以提供支持不同硬件接口的能力。中介者支持多種硬件設(shè)備的協(xié)調(diào)，實現(xiàn)系統(tǒng)級行為。觀察者模式是發(fā)布遙感數(shù)據(jù)到需要的軟件元素的方法。去抖動模式和中斷模式是硬件設(shè)備接口簡單重用的方法。定時器模式擴展中斷定時器為嵌入式系統(tǒng)提供精確時序。

1.1 硬件代理模式

硬件代理模式概念是對訪問硬件接口的封裝，限制客戶直接訪問硬件造成問題。

1.1.1 模式結(jié)構(gòu)

模式結(jié)構(gòu)非常簡單，可能客戶會有多個，但是每個硬件設(shè)備僅有一個硬件代理，客戶只能訪問代理接口，無法直接訪問硬件就是這個模式的目的。

1.1.2 角色

1.1.2.1 硬件設(shè)備（HardwareDevice）

硬件設(shè)備可以是各種，內(nèi)存，傳感器等，包含了端口地址，內(nèi)存地址，寄存器地址等等元素。與硬件代理的關(guān)聯(lián)是通過軟件尋址方式，對硬件的讀寫操作。

1.1.2.2 硬件代理（HardwareProxy）

這個是系統(tǒng)中的主功能。給上層應用提供的硬件訪問接口，上層應用無須詳細關(guān)心硬件的具體實現(xiàn)?；旧贤ǔＣ總€代理都有initialize()、configure()和disable()函數(shù)。大部分還會有對設(shè)備的值讀取訪問，或者寫訪問接口。但是一般不能隨意讀寫，會詳細到讀取到最終的值。

函數(shù)包括:

access()：從設(shè)備返回一個特殊值。大多數(shù)情況下，代理會對每個來自設(shè)備單獨的信息提供單獨的函數(shù)。例如返回傳感器的溫度，濕度值。

configure()：提供硬件配置的方法。一般會有參數(shù)列表，通過傳入?yún)?shù)來配置正確的工作狀態(tài)。

disable()、enable()：提供設(shè)備的安全禁用或開啟的方法。

initialize()：用于第一次啟動時候的初始化硬件。

mutate()：用于向設(shè)備寫入數(shù)據(jù)，通常總是有一個或更多的輸入?yún)?shù)。

marshal()、unmarshal()：這兩個為私有函數(shù)，用于把客戶數(shù)據(jù)格式轉(zhuǎn)為硬件所需格式，后者相反，把硬件原始數(shù)據(jù)格式轉(zhuǎn)換為客戶格式。常用于加密解密，壓縮解壓縮等。

deviceAddr：是一個私有變量，提供底層直接訪問硬件的地址。必須隱藏在代理中，不能給客戶訪問的機會，所以特別注意到一些接口，是否會通過了指針把該變量暴露出去。

1.1.2.3 代理客戶（ProxyClient）

客戶代碼調(diào)用硬件代理服務來訪問硬件設(shè)備。

1.1.3 效果

該模式非常普遍并且具有封裝硬件接口以及編碼系統(tǒng)的所有優(yōu)點。這為不對客戶端進行任何改變而從根本上改變實際硬件接口提供了靈活性?；旧纤械挠布O(shè)備都能用此模式搭建，注意的是不能暴露細節(jié)，只能返回一個最后的結(jié)果，特別在讀寫操作，否則就不具備有封裝性了。

1.1.4 實現(xiàn)

可以有很多不同方法用C語言實現(xiàn)，最常見的是如linux驅(qū)動，使用結(jié)構(gòu)體里的函數(shù)指針統(tǒng)一硬件的接口。然后在具體的硬件設(shè)備上實現(xiàn)。

?

1.2 適配器模式

硬件適配器模式提供一種方法，使已經(jīng)存在硬件接口能適用應用期望?？梢哉f是在硬件代理模式基礎(chǔ)上，為了能夠適應底層不同的硬件設(shè)備，在中間增加一層適配器。比如在通訊上面在硬件上都存在RS232，RS485，程序需要在不同情況下使用232通訊或485通訊，而適配器可以提供統(tǒng)一的接口給客戶層，通過指針指向所需通訊，則可以實現(xiàn)。最大的特點是在運行中選擇，相比使用宏定義需要生成不同執(zhí)行程序，可以在程序中實現(xiàn)自適應的功能。

1.2.1 模式結(jié)構(gòu)

?

1.2.2?角色

1.2.2.1 硬件適配器（HardwareAdapter）

硬件適配器在客戶和硬件代理之間執(zhí)行匹配。客戶告知適配器所需的硬件設(shè)備，適配器執(zhí)行客戶的請求。

1.2.2.2 客戶硬件接口（HardwareInterfaceToClient）

客戶的硬件接口表示客戶期望硬件代理提供的一組服務和參數(shù)列表。僅僅作為接口，并沒有實現(xiàn)，是通過適配器提供硬件實現(xiàn)。

1.2.2.3 硬件設(shè)備（HardwareDevice）

與硬件代理模式中描述一致。

1.2.2.4 硬件代理（HardwareProxy）

與硬件代理模式中描述一致。

1.2.3 效果

該模式允許使用各種硬件代理，并且在不同的應用中使用與它們相關(guān)的硬件設(shè)備，同時亦有的應用使用不同的硬件設(shè)備時不需要做改變。我個人理解有點類似是面向?qū)ο笳Z言中的多態(tài)概念。

1.2.4 實現(xiàn)

同樣如linux系統(tǒng)驅(qū)動，創(chuàng)建一個結(jié)構(gòu)體的接口代理，硬件設(shè)備使用這些接口具體實現(xiàn)，然后使用一個指向結(jié)構(gòu)體接口的指針，把需要使用的硬件設(shè)備注冊到指針上，客戶代碼只需調(diào)用這個指針，即可操作具體的硬件設(shè)備，而且可以動態(tài)的修改指針的指向，從而實現(xiàn)動態(tài)的加載切換。

?

1.3 中介者模式

中介者模式提供的是為一組硬件設(shè)備復雜交互協(xié)調(diào)的一個方法。

1.3.1 模式結(jié)構(gòu)

?中介者模式使用一個中介類來協(xié)調(diào)各個設(shè)備集合的行為，來達到整理的一個效果。這里舉一個具體的例子，比如一臺車有4個輪子，也就4個電機設(shè)備，當向前行駛的時候四個輪子都是向前前進，這時候中介者就承擔了控制4個輪子的責任。所以說中介者其實就是一個中央控制。

1.3.2 角色

1.3.2.1 合作者接口（CollaboaratorInterface）

是被中介者調(diào)用的接口，對于硬件通常是initaialize（），enable（），reset（）等這類函數(shù)，但是具體的是在具體合作者實現(xiàn)。

1.3.2.2 中介者（Mediator）

在模式中協(xié)調(diào)所有的具體合作者。中介者對于每個具體合作者都有一個鏈接，以便他能給具體合作者發(fā)送信息。此外，當有事情發(fā)生時，每個具體合作者必須能給中介者發(fā)送消息。中介者提供協(xié)調(diào)的邏輯。

1.3.2.3 具體合作者（SpecificCollaborator）

表示一個硬件設(shè)備?？梢詮闹薪檎攉@取命令，也可以發(fā)送信息給中介者。

1.3.3 效果

該模式創(chuàng)建中介者來協(xié)調(diào)合作具體硬件，但是對客戶來說又不需要直接耦合硬件設(shè)備，極大的簡化了整理的設(shè)計。很多嵌入式系統(tǒng)必須高精度時間相應，動作的延時可能造成不可估計的影響，中介者能夠在這些規(guī)定時間反應很重要。

1.3.4 實現(xiàn)

中介者的實現(xiàn)可以通過指針數(shù)組，鏈表等，能夠連接到每個具體的合作者。另外統(tǒng)一接口能夠給中介者代碼上帶來很多便利。

?

1.4 觀察者模式

觀察者模式非常的普遍，你可以在任何地方看到它的身影。這模式提供一個方法來“監(jiān)聽”所感興趣的消息，而不需要修改數(shù)據(jù)服務器，這意味著傳感器數(shù)據(jù)很容易分享給所需的客戶。

1.4.1 模式結(jié)構(gòu)

?觀察者模式，另外一個名字是“發(fā)布-訂閱模式”。首先模式下數(shù)據(jù)服務器不需要清楚客戶，相反是由客戶通知數(shù)據(jù)服務器，也就是訂閱。訂閱意思是允許數(shù)據(jù)服務器在通知列表中添加（和刪除）自身。最常見的通知策略是當新數(shù)據(jù)到達服務器時，服務器發(fā)送數(shù)據(jù)。但是客戶也能定期更新，向服務器獲取數(shù)據(jù)，以減小服務器的計算負擔，確?？蛻艟哂袑崟r數(shù)據(jù)。另外更復雜的模式是在數(shù)據(jù)服務器和客戶中間添加一層中央控制器，用于連接服務器與客戶的通訊，這樣服務器就完全不需要與客戶直接聯(lián)系。如果有大量使用消息使用觀察者模式，添加中央不失為一種好方法。

1.4.2 角色

1.4.2.1 抽象客戶接口（AbstratClient）

它包含了accept（Datum）函數(shù)，當AbstratClient訂閱時或者AbstratSubject認為有適合發(fā)送數(shù)據(jù)去調(diào)用它。AbstratClient是抽象的，不提供任何具體實現(xiàn)。

1.4.2.2 抽象發(fā)布接口（AbstratSubject）

在模式中AbstratSubject是數(shù)據(jù)服務器。在提供模式相關(guān)的3個函數(shù)。subscribe（acceptPtr）服務添加指向接收函數(shù)通知列表的指針。unsubscribe（acceptPtr）函數(shù)從通知列表中刪除接收功能。最后，notify（）函數(shù)遍歷通知列表通知訂閱的客戶。

1.4.2.3 具體客戶（concreteClient）

concreteClient是AbstratClient接口的具體實現(xiàn)。

1.4.2.4 具體發(fā)布（concreteSubject）

concreteSubject是AbstratSubject接口的具體實現(xiàn)。不僅提供函數(shù)的實現(xiàn)，而且提供獲取和管理它發(fā)布數(shù)據(jù)的方法。扮演concreteSubject也可以是硬件設(shè)備，傳感器等。

1.4.2.5 數(shù)據(jù)（Datum）

該元素是實際的數(shù)據(jù)包，可以是int，更多的是復雜的結(jié)構(gòu)體。

1.4.2.6 回調(diào)接口（NotificationHandle）

NotificationHandle是調(diào)用客戶的accept方法的代表。最常見的實現(xiàn)方式是函數(shù)指針。

1.4.3 效果

觀察者模式是在服務器分配數(shù)據(jù)的過程，并且在運行時可以動態(tài)地管理客戶列表。實際一個例子，讀取硬件的值，通常我們可能是使用輪詢的方式讀取，輪詢的弊端是響應不及時，讀取間隔時間很難去固定和評估。另一種方法是定時中斷讀取，但是定時讀取未必每次都會有數(shù)據(jù)產(chǎn)生。還有是觸發(fā)中斷的方法，如果在中斷讀取數(shù)據(jù)后，需要計算，在中斷里進行可能不太好，原則是盡量不要中斷占用太多的CPU。這個時候觀察者模式的好處體現(xiàn)出來了，首先能夠保證響應及時，因為使用的回調(diào)方式，第二能一個硬件發(fā)布，多個接收客戶，一對多的模式，第三能夠確保每次執(zhí)行客戶回調(diào)都能有數(shù)據(jù)產(chǎn)生。其實觀察者模式隨處可見，ROS系統(tǒng)的節(jié)點通訊就是基于這個策略。該模式明顯的缺點是實現(xiàn)較復雜，而且當然也不是所有情況都適應，希望各位能夠詳細分析后，選擇合適的方法。

1.4.4 實現(xiàn)

該模式復雜的方面在通知句柄的實現(xiàn)，以及通知句柄列表的管理。通知句柄通常是一個回調(diào)函數(shù)指針。通知列表最簡單的方式是定義足夠大的數(shù)組來包含所有潛在用戶，但是實際占用空間大浪費內(nèi)存，所以并不常用。另一個常見的是使用鏈表管理，也就是給每個通知句柄添加在鏈表上，這樣只要遍歷鏈表即可通知所有客戶，強烈推薦使用鏈表形式。

?

1.5 去抖動模式

這個模式用于消除來自硬件金屬表面間歇性連接引起的多個假時間。

1.5.1 模式結(jié)構(gòu)

?解決的方案是接受第一次發(fā)生的事件，等待抖動減弱，然后再對讀取它的狀態(tài)。

1.5.2 角色

1.5.2.1 應用客戶（ApplicationClient）

該元素是去抖動最后的接受者。當在抖動消除后，使用deviceEventReceive（）接收最后讀取到的值。

1.5.2.2 具體硬件（BouncingDevice）

代表了硬件設(shè)備。這個設(shè)備絕大部分都是全硬件，機械特性的，所以才會引起抖動的現(xiàn)象。sendEvent（）用于發(fā)送事件，激活中斷接收到首次的響應。getState（）操作時通過讀取內(nèi)存或IO端口顯示，讀取具體的硬件值。deviceState通常是二值屬性，即ON或OFF。

1.5.2.3 硬件客戶（DeviceClient）

是用于處理進入事件的中斷，去除抖動，并讀取確保代表實際設(shè)備狀態(tài)。它的eventRecevie（）函數(shù)通過BouncingDevice的sendEvent（）函數(shù)激活。同時，它需要設(shè)置延時定時器，去抖動事件過后，如果狀態(tài)與第一次讀取的一致，證明值是真實的。這樣它就發(fā)送相應的信息給ApplicationClient。舊狀態(tài)保存在變量oldState中，每當狀態(tài)發(fā)生改變的時候更新這個變量。

1.5.2.4 定時器（DebouncingTimer）

這個定時器可以通過delay（）服務來提供空閑等待?？梢允褂脀hile（）等待，或者硬件定時器實現(xiàn)。

1.5.3 效果

通常去抖動的任務是由軟件來承擔，這是一個簡單的去抖動，應用程序只需要關(guān)心硬件狀態(tài)產(chǎn)生的真實值才接收。

1.5.4 實現(xiàn)

硬件客戶通常使用中斷來通知應用客戶?；蛘呤褂糜^察者模式混合也可以給等個客戶提供信號。在RTOS系統(tǒng)去抖動必須注意時間單位的延時時間，比如如果想要45毫秒的延時，那么必須使用大于等于期望時間最接近時間精度。如果在等待去抖動時，你不介意完全占用CPU，那么這就很簡單，使用while（loop--）循環(huán)就好了。

?

1.6 中斷模式

在嵌入式系統(tǒng)，硬件設(shè)備很多時候都是自主發(fā)生，如果你不加以注意，這些事件就會丟失。當一個你感興趣的事件發(fā)生時，使用中斷來通知是非常有效的方法?；旧闲酒贾С滞獠坑布袛嗟姆绞?。中斷能保證響應的及時，但是中斷會搶占CPU的控制，所以中斷里面不適合處理算法等這種耗時長的任務。這個模式下可以是純軟件的中斷模式。

1.6.1?模式結(jié)構(gòu)

?確保中斷函數(shù)一般是沒有入?yún)?，和返回值的?/p>

1.6.2 角色

1.6.2.1 中斷響應（InterruptHandler）

是中斷模式里面唯一有具體行為的元素。它能夠安裝和卸載中斷向量的功能。install（）函數(shù)運行時，拷貝傳入的中斷句柄到向量表中，使用合適的中斷服務程序地址。deinstall（）函數(shù)相反，用于卸載回復原本的向量表。

每個handleInterrupt_x（）函數(shù)處理指定的中斷。

1.6.2.2 中斷向量表（InterruptVectorTable）

就是中斷服務程序的地址數(shù)組。它依賴在指定的內(nèi)存位置上。當中斷號x出現(xiàn)時，CPU掛起當前進程，調(diào)用這個數(shù)組中相應的第x個索引地址。

1.6.2.3 向量指針（VectorPtr）

VectorPtr是數(shù)據(jù)類型，具體是一個沒有參數(shù)和返回值的函數(shù)指針。

1.6.3 效果

該模式最大的優(yōu)勢是可以高響應處理感興趣的事件。通常情況下，當中斷服務程序執(zhí)行時，關(guān)閉中斷，這意味著中斷服務程序必須快速執(zhí)行以確保不會丟失其他中斷。

使用中斷有點特別注意是資源的保護。當有可能會在中斷和普通程序中處理了同一個元素，設(shè)想當普通程序讀取數(shù)據(jù)中途發(fā)生了中斷，而中斷會導致普通程序暫停，然后在中斷里面修改了數(shù)據(jù)返回。普通函數(shù)將會讀取損壞的數(shù)據(jù)，即部分是新數(shù)據(jù)，部分是舊數(shù)據(jù)。解決方法有1.在普通函數(shù)讀取數(shù)據(jù)時禁止中斷，訪問完成后恢復中斷。2.使用互斥信號量。

1.6.4 實現(xiàn)

中斷函數(shù)執(zhí)行之前必須保存現(xiàn)場，在執(zhí)行完成需要恢復現(xiàn)場。事實上每個中斷服務程序必須：

1. 保存CPU寄存器，包括CPU指令指針和任何處理器標志，如進位，奇偶校驗。

2. 清除終端位。

3. 執(zhí)行適當處理。

4. 恢復CPU寄存器。

5. 返回。

?

1.7 輪詢模式

另一種從硬件獲取數(shù)據(jù)常用的模式是定期檢查，稱為輪詢過程。當數(shù)據(jù)或信號不是很緊急，或者當數(shù)據(jù)可用時，硬件沒有能力產(chǎn)生中斷，又或者硬件本身能保留數(shù)據(jù)到下次讀取情況，這是輪詢就非常好用。

1.7.1?模式結(jié)構(gòu)

?輪詢模式是讀取硬件上數(shù)據(jù)最簡單的方法。輪詢能夠定期或不定期進行，可以是定時器讀取，也可以當系統(tǒng)需要時讀取。

1.7.2?角色

1.7.2.1 應用過程（ApplicationProcessingElement）

這個元素用于循環(huán)調(diào)用poll（）操作。這個也可以是定時器中斷里面。

1.7.2.2 硬件（Device）

Device通過可訪問的函數(shù)提供數(shù)據(jù)或設(shè)備狀態(tài)信息。這個類上面實例了兩個方法，getData（）用來獲取數(shù)據(jù)，getState（）用來獲取數(shù)據(jù)狀態(tài)。MAX_POLL_DEVICE連接到所有的硬件設(shè)備，以便poll（）函數(shù)全部能夠掃描并通知給客戶。

1.7.2.3 輪詢者（OpportunisticPoller）

具有poll（）函數(shù)，用于掃描連接的設(shè)備以讀取數(shù)據(jù)和狀態(tài)，并把數(shù)據(jù)轉(zhuǎn)發(fā)給客戶。這個元素可以添加定時器操作，實現(xiàn)定期讀取數(shù)據(jù)的功能。

1.7.2.4 客戶（PollDataClient）

該元素來自一個或多個設(shè)備數(shù)據(jù)和狀態(tài)信息的客戶。

1.7.3 效果

輪詢比使用中斷服務簡單的多，能夠同時檢測多種不同的設(shè)備，但是基本上沒有中斷響應那樣及時，所以使用輪詢最好確保最長的讀取間隔時間，確保在一個時間內(nèi)至少讀取一次數(shù)據(jù)，否則數(shù)據(jù)將會丟失，但有時候這不是一個問題，所以具體情況就具體分析。

1.7.4 實現(xiàn)

最簡單的顯示方法是在系統(tǒng)操作的主進程循環(huán)中插入硬件檢查，這叫做“對稱機會輪詢”，因為它總是以同樣的方式操作，即使處理循環(huán)事件長度可能變化。非對稱機會輪詢是在整個進程中方便時候讀取新數(shù)據(jù)（對稱是固定位置讀取數(shù)據(jù)，非對稱是在需要的時候再讀?。@種方式具有更好的響應，但是對主流程有更大影響，而且難以維護。

???????????????? ?END ?????????????????