周立功教授新書《面向AMetal框架與接口的編程（上）》，對AMetal框架進行了詳細介紹，通過閱讀這本書，你可以學到高度復用的軟件設計原則和面向接口編程的開發(fā)思想，聚焦自己的“核心域”，改變自己的編程思維，實現(xiàn)企業(yè)和個人的共同進步。

第八章為深入理解AMetal，本文內(nèi)容為8.2 HC595 接口。

8.2 HC595 接口

HC595 是一種“串轉(zhuǎn)并”的外圍器件，可以通過GPIO 控制數(shù)據(jù)引腳和時鐘引腳實現(xiàn)數(shù)據(jù)的輸出。但在一些具有SPI 外設的MCU 中，往往使用SPI 控制HC595 輸出，使驅(qū)動程序更簡潔。為了屏蔽底層數(shù)據(jù)輸出方式的差異性，可以按照LED 通用接口的設計方法為HC595定義相關接口。

>>> 8.2.1 定義接口

1． 接口命名

由于操作的對象是HC595，因此接口命名以“am_hc595_”作為前綴。HC595 基本的操作是輸出并行數(shù)據(jù)，其相應的接口名為：

• am_hc595_send

特別地，HC595 的輸出為三態(tài)輸出，其由OE 引腳控制，因此可以定義相應接口使能輸出（正常輸出數(shù)據(jù)）或禁能輸出（高阻狀態(tài)）。其相應的的接口名為：

• am_hc595_enable

• am_hc595_disable

2． 接口參數(shù)

在LED 通用接口的設計中，通?？赡艽嬖诙鄠€LED，因而使用了唯一ID 號led_id 對多個LED 進行區(qū)分。按照這種邏輯，是否也需要使用hc595_id 來區(qū)分不同的HC595 呢？

在LED 通用接口中，使用了ID 號區(qū)分不同的LED，這就要求在接口實現(xiàn)中完成led_id到對應LED 設備之間的轉(zhuǎn)換，即通過ID 號搜索到對應的LED 設備。顯然，隨著LED 設備的增加，搜索耗時也將增加。使用ID 號區(qū)分不同的LED，雖然簡潔易懂，但效率不高。

對于操作LED 而言，通常都是秒級的，不會以極快的速率操作LED。如果LED 變化太快，則肉眼無法觀察相應的現(xiàn)象是沒有意義的。因此搜索耗時的影響對于LED 來說，可以忽略不計。雖然HC595 輸出控制的具體器件是不確定的，但作為通用輸出器件，其輸出的效率應該盡可能高，不要因為驅(qū)動實現(xiàn)的策略而影響了輸出效率，比如，常見的GPIO 能夠以MHz 的速率輸出，這種變化是us 級別的，顯然此時搜索耗時會對輸出效率產(chǎn)生一定的影響。

為了達到快速輸出的目的，最好不存在任何搜索過程，直接操作相應的HC595 對象實現(xiàn)輸出。在這種情況下，使用指向?qū)ο蟮闹羔樉褪呛芎玫慕鉀Q辦法，只要具有指向?qū)ο蟮闹羔?，就可以直接使用對象提供的方法?/p>

顯然使用指向?qū)ο蟮闹羔槪皇菫榱颂岣呓涌趯崿F(xiàn)的效率，與用戶并無直接關系。對于用戶來說，其無需關心這個指針的具體類型。為了對用戶屏蔽“指針”的概念，可以為該指針單獨定義一個類型，這就是本書中常常提及的“句柄”概念。由于現(xiàn)在還不清楚HC595對象的指針類型，可以先定義一個無類型的指針類型作為句柄類型。比如：

該類型的句柄本質(zhì)上是指向HC595 對象的指針，其本身就代表了系統(tǒng)中確定的一個HC595 對象?；诖耍薪涌诰褂迷擃愋妥鳛榈谝粋€參數(shù)，即：

• am_hc595_enable (am_hc595_handle_t handle);

• am_hc595_disable (am_hc595_handle_t handle);

• am_hc595_send (am_hc595_handle_t handle);

特別地，對于am_hc595_send()，還需要使用參數(shù)指定發(fā)送的數(shù)據(jù)，往往使用一個指向數(shù)據(jù)首地址的指針和數(shù)據(jù)的字節(jié)數(shù)表示一段數(shù)據(jù)。即可為am_hc595_send()新增兩個參數(shù)：

• am_hc595_send (am_hc595_handle_t handle, const void *p_data, size_t nbytes) ;

其中，p_data 指向了數(shù)據(jù)的首地址，使用void *類型，使其可以指向任意數(shù)據(jù)類型的首地址，使用const修飾符，表明本接口僅用于發(fā)送數(shù)據(jù)，不會改變數(shù)據(jù)內(nèi)容；nbytes 指定了發(fā)送數(shù)據(jù)的字節(jié)數(shù)，若只有單個HC595，則輸出是單個字節(jié)（8 位），若有多個HC595 級聯(lián)，則輸出是n 個字節(jié)（n 為HC595 的個數(shù)，共計8×n 位）。

實際中，單個HC595 只能輸出8位數(shù)據(jù)，為了輸出更多位數(shù)的數(shù)據(jù)，可以使用級聯(lián)的方式將多個HC595級聯(lián)起來。因此，這里的HC595“句柄”代表的HC595 設備可能包含多個級聯(lián)的HC595，以實現(xiàn)多位數(shù)據(jù)的輸出。

3． 返回值

接口無特殊說明，直接將所有接口的返回值定義為int 類型的標準錯誤號?；诖耍琀C595 接口的完整定義詳見表8.4。其對應的類圖詳見圖8.5。

表8.4 HC595 通用接口（am_hc595.h）

圖8.5 HC595 對應的類圖

特別注意，當前接口中的am_hc595_handle_t 類型為void *類型，最終，其需要是指向?qū)ο蟮闹羔橆愋?。隨著后文對接口實現(xiàn)的介紹，會定義相應的設備類型，到時再更新具體的定義。

>>> 8.2.2 實現(xiàn)接口

1． 抽象的HC595 設備類

與LED 通用接口的實現(xiàn)類似，為了屏蔽底層實現(xiàn)的差異性，可以將一些與底層硬件相關的功能進行抽象，根據(jù)三個接口，可以定義相應的三個抽象方法，并將其存放在一個虛函數(shù)表中。即：

類似地，將抽象方法和p_cookie 定義在一起，即為抽象的HC595 設備。比如：

顯然，具體的HC595 設備直接從抽象的HC595 設備派生，然后由具體的HC595 設備根據(jù)實際的硬件，實現(xiàn)3 個抽象方法。

與抽象LED 設備的定義相比可以發(fā)現(xiàn)，這里定義抽象設備的方法和抽象LED 設備定義的方法是完全一致的，可以將這種方法作為定義一種抽象設備的模板，即：首先，根據(jù)接口的定義，整理需要具體設備實現(xiàn)那些功能，然后將這些功能一一抽象為方法，并將它們存放在一個虛函數(shù)表中，這些抽象方法的第一個參數(shù)均為p_cookie。最后，將虛函數(shù)表和p_cookie整合在一個新的結(jié)構體中，該結(jié)構體類型即為抽象設備類型。偽代碼詳見程序清單8.18。

程序清單8.18 抽象設備定義的一般方法

偽代碼中，[name]表示當前模塊的具體名字，如led。當然，如果需要，可以在抽象籌備中添加其它需要的成員，如LED 設備中，使用鏈表管理多個LED 設備，因此還具有p_next指針成員。

在HC595 接口中，使用了handle 作為第一個參數(shù)，其本質(zhì)上是指向設備的指針，由于所有具體設備的都是從抽象的HC595 設備派生的，因此，handle 的類型可以定義為：

如此一來，所有接口的實現(xiàn)都可以直接調(diào)用抽象方法實現(xiàn)，而抽象方法的具體實現(xiàn)是由具體的HC595 設備完成的。各HC595 接口的實現(xiàn)詳見程序清單8.19。

程序清單8.19 HC595 接口實現(xiàn)

由于handle 是直接指向設備的指針，可以通過handle 直接找到相應的方法，因此，在整個接口的實現(xiàn)過程中，沒有任何查詢搜索的過程，效率較高。除此之外，當handle 直接指向設備后，也就無需再集中對各個HC595 設備進行管理，如LED 設備，由于存在查詢搜索過程，因此不得不使用單向鏈表將系統(tǒng)中的各個LED 設備鏈起來，便于查找。

在接口實現(xiàn)中，沒有與硬件相關的實現(xiàn)代碼，僅僅是簡單的調(diào)用了抽象方法。抽象方法需要由具體的HC595 設備來完成。由于各個接口的實現(xiàn)非常簡單，往往將其實現(xiàn)直接以內(nèi)聯(lián)函數(shù)的形式存放在.h 文件中。

為便于查閱，如程序清單8.20 所示展示了抽象HC59 設備接口文件（am_hc595.h）的內(nèi)容。其對應的類圖詳見圖8.6。

程序清單8.20 am_hc595.h 文件內(nèi)容

圖8.6 抽象的HC595 設備類

程序中，am_static_inline 是內(nèi)聯(lián)函數(shù)的標識，其在am_types.h 文件中定義，定義的實際內(nèi)容與編譯器相關，如使用GCC 編譯器，則其定義如下：

由于在不同編譯器中，內(nèi)聯(lián)函數(shù)的標識不盡相同，為了使用戶使用統(tǒng)一的標識，AMetal統(tǒng)一將內(nèi)聯(lián)標識符定義為了am_static_inline，使得用戶在任何編譯器中均可使用該標識作為內(nèi)聯(lián)標識，無需關心與編譯器相關的細節(jié)問題。

2． 具體的HC595 設備類

以使用SPI 控制HC595 輸出數(shù)據(jù)為例，簡述具體HC595 設備的實現(xiàn)方法。首先應該基于抽象設備類派生一個具體的設備類，其類圖詳見圖8.7，

圖8.7 具體的HC595 設備類

可直接定義具體的HC595 設備類：

am_hc595_spi_dev_t 即為具體的HC595 設備類。具有該類型后，即可使用該類型定義一個具體的HC595 設備實例：

在使用SPI 控制HC595 時，需要知道HC595 相關的信息，如鎖存引腳、輸出使能引腳、SPI 時鐘頻率等信息。

特別地，當SPI 輸出數(shù)據(jù)時，可以指定數(shù)據(jù)輸出時的位順序：最高位先輸出或最低位先輸出。最先輸出的位決定了HC595 輸出端Q7 的電平，最后輸出的位決定了HC595 輸出端Q0 的電平。顯然，位的輸出順序直接影響了HC595 的輸出，因此，具體輸出順序應該是由用戶來決定的。

基于此，將需要由用戶提供的設備相關信息存放到一個新的設備信息結(jié)構體類型中：

若使用MiniPort-595，其與AM824-Core 聯(lián)合使用時，則其對應的設備實例信息可以定義如下：

同理，在設備類中需要維持一個指向設備信息的指針。此外，由于使用SPI 控制HC595時，HC595 相當于是一個SPI 從設備，為了使用SPI 接口與之通信，需要為HC595 定義一個與之對應的SPI 從設備，新增兩個成員，完整的HC595 設備定義即為：

顯然，在使用SPI 控制HC595 前，需要完成設備中各成員的賦值，這些工作通常在驅(qū)動的初始化函數(shù)中完成，定義初始化函數(shù)的原型為：

其中：

• p_dev 為指向am_hc595_spi_dev_t 類型實例的指針；

• p_info 為指向am_hc595_spi_info_t 類型實例信息的指針；

• handle 為SPI 句柄，便于使用SPI 輸出數(shù)據(jù)，初始化函數(shù)的返回值即為HC595 句柄。基于前面定義的設備實例和實例信息，其調(diào)用形式如下：

返回值即為HC595 實例的句柄，可以作為HC595 通用接口的第一個參數(shù)（handle）的實參。初始化函數(shù)的實現(xiàn)范例詳見程序清單8.21。

程序清單8.21 初始化函數(shù)實現(xiàn)范例（SPI 控制HC595）

程序中，首先建立了標準的SPI 從設備，便于后續(xù)使用SPI 接口發(fā)送數(shù)據(jù)，然后初始化了p_info 成員，接著完成了抽象HC595 設備中p_funcs 和p_cookie 的賦值，最后，返回設備地址作為用戶操作HC595 的句柄。其中，pfuncs 賦值為了&__g_hc595_spi_drv_funcs，其中包含了3 個抽象方法的具體實現(xiàn)，完整定義詳見程序清單8.22。

程序清單8.22 抽象方法的實現(xiàn)（SPI 控制HC595）

由此可見，使用GPIO 接口am_gpio_set()控制OE 引腳的輸出電平實現(xiàn)了HC595 的使能和禁能函數(shù)，使用SPI 接口函數(shù)am_spi_write_then_write()實現(xiàn)了發(fā)送數(shù)據(jù)函數(shù)。

為了便于查閱，如程序清單8.23 所示展示了具體HC595 設備接口文件（am_hc595_spi.h）的內(nèi)容。

程序清單8.23 am_hc595_spi.h 文件內(nèi)容