本文導讀

本文詳細介紹了AWorks中開發設備驅動的一般方法。基于這些通用的方法，用戶可以嘗試獨立開發一些設備的驅動，以進一步加深對AWbus-lite的理解。同時，當后續遇到一些AWorks 暫不支持的設備時，也可以自行開發設備相應的驅動。

本文為《面向AWorks框架和接口的編程（上）》第三部分硬件篇——第13章——第4小節：驅動開發的一般方法。

13.4 驅動開發的一般方法

上面以LED為例，從接口定義到驅動開發都進行了詳細的介紹，對AWbus-lite中相關的概念有了更加深入的理解。完整的設備相關程序主要分為三個部分：

• 通用接口

位于最上層，與具體硬件無關，由應用程序直接訪問，構成可以跨平臺復用的應用程序。雖然通用接口看似簡單，但要完成其完善的定義并不容易，往往需要經過大量項目的積累，從接口功能和設計原則等多個方面考慮，才能定義出既簡潔又實用的通用接口，一般來講，通用接口無需用戶定義，由廣州致遠電子有限公司統一定義和維護。

• 接口實現

位于中間層，完成如抽象方法、LED服務、METHOD類型等的定義。中間層同樣與具體硬件無關，主要使用抽象方法的形式實現上層定義的通用接口。該層往往在定義通用接口時由廣州致遠電子有限公司實現。對于驅動開發者，僅需了解這里定義的各個抽象方法，以便在開發具體驅動時，根據具體硬件實現各個抽象方法。

• 具體驅動實現

位于最底層，根據具體硬件完成抽象方法的實現，定義Method對象列表，提供相應的服務。隨著AWorks的不斷發展和完善，迄今為止已經積累了大量的設備驅動，常見設備均已支持。由于實際硬件的千差萬別，用戶可能遇到AWorks暫不支持的設備（暫無對應驅動），此時，用戶可以自行開發設備驅動。

在LED驅動開發的介紹中，由于很多概念初次遇到，因而花費了較多篇幅介紹這些基本概念，略顯繁瑣。實質上，驅動開發的核心就是完成一個驅動信息結構體常量的定義，比如LED驅動開發的結果，就是完成了結構體常量__g_drvinfo_led_gpio的定義（詳見程序清單13.48）。下面，針對驅動開發進行簡要的梳理，歸納出驅動開發的一般步驟。

1、定義驅動名；

2、 確定總線類型和設備類型；

3、 定義實際設備類型；

4、 定義設備信息類型；

5、 實現三個階段的初始化函數；

6、 實現設備要提供的服務，比如LED服務；

7、 定義Method對象，以便上層獲取設備提供的服務；

8、 定義驅動結構體常量，實現驅動注冊函數。

在上一章中，直接使用了PCF85063驅動定義的驅動名、設備類型、設備信息類型等，完成了PCF85063硬件資源的定義（詳見程序清單12.12）。下面，將按照驅動開發的一般步驟，嘗試基于AWorks中現有的RTC架構，開發PCF85063實時時鐘芯片的驅動。深入理解PCF85063驅動的具體由來。

PCF85063是NXP半導體公司推出的一款低功耗實時時鐘/日歷芯片，它提供了實時時間的設置與獲取、鬧鐘、可編程時鐘輸出、定時器/報警/半分鐘/分鐘中斷輸出等功能。引腳封裝詳見圖13.3，其中，SCL和SDA為I2C接口引腳，VDD和VSS分別為電源和地；OSCI和OSCO為32.768KHz的晶振連接引腳，作為PCF85063的時鐘源；CLKOUT為時鐘信號輸出，供其它外部電路使用；INT為中斷引腳，主要用于鬧鐘等功能。

圖13.3 PCF85063引腳定義

13.4.1 定義驅動名

作為PCF85063的驅動，可以直接將驅動名定義為："pcf85063"，即：

基于此，基礎驅動信息中p_drvname的值為：AWBL_PCF85063_NAME。

13.4.2 確定總線類型和設備類型

確定驅動所處的總線類型，對PCF85063作簡要了解可知，該芯片通過I2C總線訪問，芯片所處總線的類型即為：AWBL_BUSID_I2C。總線類型是一個非常重要的信息，驅動結構體常量、設備類型的定義均與總線類型相關。

確定驅動對應設備的類型，是普通設備還是特殊的總線控制器設備。對于PCF85063設備，其不能再繼續擴展下游總線，僅能提供RTC功能，是普通設備，即對應的設備類型為：AWBL_DEVID_DEVICE。

基于此，基礎驅動信息中bus_id的值為：AWBL_BUSID_I2C | AWBL_DEVID_DEVICE（或省略AWBL_DEVID_DEVICE，直接設置為AWBL_BUSID_I2C）。

13.4.3 定義設備類型

實際設備類型從基礎設備類型派生而來，以添加設備相關的私有成員。在AWBus-lite中，I2C總線上的設備基礎類型定義為：struct awbl_i2c_device。其定義詳見程序清單13.53。

程序清單13.53 struct awbl_i2c_device類型定義

由此可見，struct awbl_i2c_device類型是從AWBus-lite基礎設備類型派生而來的，當前并未添加任何其它成員，主要是為了方便后續擴展，增加I2C總線從機設備相關的私有成員。

基于此，PCF85063設備類型的定義形式詳見程序清單13.54。

程序清單13.54 PCF85063設備類型定義（1）

雖然PCF85063并未直接從AWBus-lite基礎設備類派生，但本質上，其還是屬于AWBus-lite基礎設備類型的派生類。對應類圖詳見圖13.4。

圖13.4 PCF85063設備類關系

顯然，要完成PCF85063設備類型的定義，重點是考慮需要增加哪些其它成員。PCF85063設備的核心功能是為系統提供RTC服務，在AWBus-lite中，定義了RTC服務結構體類型struct awbl_rtc_service，其具體定義詳見程序清單13.55。

程序清單13.55 RTC服務類型定義（awbl_rtc.h）

其中，p_next用于指向下一個RTC服務，使系統可以以鏈表的形式組織多個RTC服務。p_servinfo為RTC服務相關的信息，提供RTC服務時，必須指定RTC服務的信息，其類型struct awbl_rtc_servinfo的定義詳見程序清單13.56。

程序清單13.56 RTC服務信息定義（awbl_rtc.h）

由此可見，RTC服務信息中僅包含ID號信息。每個RTC服務都具有一個唯一ID，當用戶使用通用接口訪問RTC服務時，需要傳入一個ID號，用于指定需要使用的RTC服務。系統將傳入的ID號與各個RTC服務對應的ID號一一比對，進而查找到指定的RTC服務。

p_servfuncs指向一個虛函數表，其類型struct awbl_rtc_servopts包含了RTC服務定義的抽象方法，詳見程序清單13.57。

程序清單13.57 RTC抽象方法的定義（awbl_rtc.h）

顯然，要使PCF85063能夠提供RTC服務，驅動就必須實現這里定義的抽象方法，抽象方法的具體實現將在提供RTC服務小節中詳細介紹。

p_cookie由驅動設置，系統在調用抽象方法時，將原封不動將其的作為抽象方法的第一個參數，傳遞給驅動使用。

PCF85063可以提供RTC服務，在設備類型中，應該包含一個RTC服務結構體成員，實現RTC服務實質上就是完成RTC服務中各個成員的賦值，系統上層獲取RTC服務就是獲取指向RTC服務結構體變量的指針。基于此，可以更新PCF85063設備類型的定義，詳見程序清單13.58。

程序清單13.58 PCF85063設備類型定義（2）

當前僅僅從PCF85063的主要功能出發，完成了PCF85063設備類型的定義，若在開發過程中，發現需要在設備類型中增加新的成員，可以隨時動態添加。

13.4.4定義設備信息類型

PCF85063可以提供RTC服務，提供RTC服務時，需要一并設置相應的RTC服務信息（為p_servinfo成員賦值），以供系統使用。當前的RTC服務信息僅包含一個ID號（詳見程序清單13.56），ID號是一種唯一標識，不同設備提供的RTC服務對應的ID號是不同的，具體數值應由用戶分配，為此，用戶在使用PCF85063時，應該提供RTC服務信息，基于此，PCF85063設備信息類型的定義程序清單13.59。

程序清單13.59 PCF85063設備信息類型定義（1）

此外，PCF85063是一種I2C從機器件，I2C從機器件具有一個從機地址，該地址可以由用戶指定。為此，設備信息可以新增一個addr地址信息。完整的定義詳見程序清單13.60。

程序清單13.60 PCF85063設備信息類型定義（2）

13.4.5 實現三個階段的初始化函數

實現三個階段的初始化函數，以便為基礎驅動信息中的驅動入口點p_busfuncs（詳見程序清單13.19）賦值。在具體實現前，可以先搭建好軟件結構，詳見程序清單13.61。

程序清單13.61 三個階段初始化函數的結構性代碼

其中，__g_pcf85063_drvfuncs的地址即可作為驅動入口點p_busfuncs的值。

在實現各個初始化函數前，需要梳理出具體要執行哪些初始化操作。對于PCF85063，本驅動僅使用其提供的通用實時時鐘功能，即獲取或設置當前時間（年、月、日、時、分、秒等時間信息），鬧鐘、中斷、時鐘輸出等功能均不使用。PCF85063在上電后，其時間即會正常運行，鬧鐘等功能處于關閉狀態，由此可見，時鐘方面，并不需要作任何特殊的操作。

特別地，PCF85063可以通過CLKOUT引腳輸出時鐘信號，信號的頻率可以通過控制和狀態寄存器2（control and status register2，寄存器地址為0x01）的低三位（bit2 ~ bit0）進行設定，詳見表13.8。這些信息更加詳細的說明可以通過PCF85063的數據手冊獲得。

表13.8 CLKOUT控制值與輸出頻率的關系

控制值的默認值為000，即輸出頻率為32768。由于本驅動并未使用CLKOUT功能，因此，應該將其輸出關閉，避免其對外部電路產生影響，這就需要將控制值修改為111。

PCF85063需要通過I2C總線對其中的寄存器值進行訪問。在AWBus-lite中，提供了I2C讀寫函數，用于對I2C從機設備進行讀寫，接口原型詳見表13.9。

表13.9 I2C標準接口函數

在外設通用接口的介紹中，講解了I2C通用接口（詳見表7.14，接口命名前綴為“aw_”），對比可以發現，它們的形式非常類似，不同之處的僅有兩點。

• 操作的對象類型不同

在這里，以“awbl_”為前綴的讀寫接口操作的對象（第一個參數）是AWBus-lite中的I2C從機設備，類型為struct awbl_i2c_device，該類型的從機設備掛載在AWBus-lite中，基于AWBus-lite拓撲結構，可以知道該從機設備掛載的位置，從而獲得其對應的I2C總線控制器，進而完成讀寫操作。

以“aw_”為前綴的通用I2C讀寫接口操作的對象是用戶使用aw_i2c_mkdev()接口定義的通用I2C從機設備，類型為aw_i2c_device_t，這類設備是應用程序直接操作的設備，并沒有掛載在AWBus-lite中，其對應的I2C總線控制器無法通過AWbus-lite的拓撲結構獲得，因而，在定義設備時，必須通過ID號指定該從機設備對應的總線ID，系統通過ID找到對應的I2C總線控制器，進而完成讀寫操作。

顯然，在PCF85063驅動程序中，I2C總線操作的對象是PCF85063。

PCF85063設備類型是基于struct awbl_i2c_device類型派生而來的，而struct awbl_i2c_device類型是基于AWBus-lite基礎設備類型派生而來的，因此，在各階段初始化函數中，若要對PCF85063進行讀寫操作，則可以將基礎設備類型的p_dev指針（其實際指向的是PCF85063設備）直接強制轉換為struct awbl_i2c_device類型的指針使用。

• 參數個數不同

在通用I2C讀寫接口中，除p_dev外，僅subaddr、p_buf和nbytes三個參數，分別表示寄存器子地址、讀/寫數據緩存、讀/寫數據字節數。而這里的讀寫接口多了flags和addr兩個參數，分別表示從機設備屬性和從機設備地址，實際上，通用I2C接口也有這兩個信息，不過是在使用aw_i2c_mkdev()定義從機設備時，存儲在了從機設備中，對于通用I2C接口，這兩個信息在aw_i2c_mkdev()接口中指定。本質上，它們表示的含義是完全相同的。

從機屬性的定義詳見表7.15，主要指定了從機地址的位數、是否忽略無應答和器件內子地址（通常又稱之為“寄存器地址”）的字節數；從機地址即I2C設備的從機地址。

例如，要將控制和狀態寄存器2（寄存器地址為0x01）的低3位修改為111，以禁能CLKOUT輸出，范例程序詳見程序清單13.62。

程序清單13.62 禁能CLKOUT輸出的范例程序

程序中，首先將p_dev轉換為了PCF85063設備類型指針，并通過p_dev獲得了設備信息，以獲取其中的從機地址信息。然后使用讀取接口讀取出地址0x01的值，若其低三位不為111，則修改為111并重新寫入寄存器中。

該段程序作為PCF85063的初始化程序，應該處于哪一階段呢，由于I2C是一種相對低速的通信接口，讀寫數據往往比較耗時（毫秒級別），因此，建議放在第三階段中。為此，可以完善第三階段初始化函數的實現，詳見程序清單13.63。

程序清單13.63 第三階段初始化函數的實現

程序中，為了程序的簡潔和可讀性，使用宏的形式對p_dev的強制轉換、設備信息的獲取以及寄存器地址常量進行了定義。

由于不再需要執行其他初始化操作，因此，第一階段和第二階段的初始化函數可以為空。

13.4.6 實現通用服務

PCF85063可以提供RTC服務，在提供RTC服務前，需要完成設備中rtc_serv的賦值，其類型為struct awbl_rtc_service，回顧其具體定義，詳見程序清單13.64。

程序清單13.64 RTC服務類型定義（awbl_rtc.h）

1. p_next成員賦值

p_next用于系統組織多個RTC服務，對于單個RTC服務的提供者，其值設置為NULL。詳見程序清單13.65。

程序清單13.65 p_next成員的賦值

2. p_servinfo成員賦值

p_servinfo用于指向RTC服務信息，RTC服務信息由用戶通過設備信息提供，基于此，其值直接設置為指向設備信息中的rtc_servinfo即可，詳見程序清單13.66。

程序清單13.66 p_servinfo成員的賦值

3. p_servopts成員賦值

p_servopts是實現RTC服務的核心，其定義了RTC抽象方法，驅動需要實現這些抽象方法， struct awbl_rtc_servopts類型的定義詳見程序清單13.57，其中定義了三個抽象方法：

• time_get：獲取時間

• time_set：設置時間

• dev_ctrl：控制函數，當前未使用，保留給后續擴展，設置為NULL即可在具體實現前，可以先搭建好軟件結構，詳見程序清單13.67。

程序清單13.67 實現RTC服務中定義的抽象方法結構性代碼

其中，__g_pcf85063_servopts的地址即可作為RTC服務中p_servopts的值。接下來，需要具體實現時間獲取和時間設置函數。

在PCF85063中，地址0x04 ~ 0x0A的寄存器存儲了時間信息，詳見表13.10。對這些寄存器的讀寫即可完成時間信息的獲取和設置。

表13.10 時間信息相關寄存器

注意，在寄存器中，數值的存儲形式是BCD格式，即數值的十位和個位分別使用4位二進制數（一位十六進制數）進行表示。例如，秒值為23，則十位2使用4位二進制表示，即0010，個位3使用4位二進制表示，即0011，最終的結果即為0010 0011。對于秒值，由于十位的最大值為5，需要使用3位二進制表示，因此，秒值占用的實際有效位為7位（十位占用3位，個位占用4位）。不同秒值對應的寄存器值詳見表13.11。

表13.11 秒值對應的寄存器值

分值與秒值的有效范圍相同，占用7位有效位；對于小時值，PCF85063支持24小時制（默認）和12小時制，但在AWorks平臺中，細分時間統一使用了24小時制，基于此，PCF85063也僅使用默認的24小時制，此時，小時值的有效范圍為0 ~ 23，由于十位的最大值為2，需要使用2位二進制表示，因此，小時值占用的實際有效位為6位（十位占用2位，個位占用4位）；對于日期值，其有效范圍為1 ~ 31，十位最大值為3，需要使用2位二進制表示，因此，日期值占用的實際有效位為6位（十位占用2位，個位占用4位）；對于星期值，其有效范圍為0 ~ 6，僅包含個位，且最大值為6，只需要使用3位二進制數即可表示，因此，星期值占用的實際有效位為3位（僅個位占用3位）；對于月份值，其有效范圍為1 ~ 12，十位最大值為1，需要使用1位二進制表示，因此，月份值占用的實際有效位為5位（十位占用1位，個位占用4位）；對于年份值，8位寄存器值全部用于表示年份值，十位和個位均占用4位，對于BCD碼，使用4位二進制表示一位十進制數，個位和十位的最大值均為9，因此，年份值的有效范圍為0 ~ 99。

為便于BCD碼數據和實際數值之間相互轉換，在AWorks中，定義了兩個宏輔助宏，詳見程序清單13.68。

程序清單13.68 BCD碼轉換輔助宏（aw_common.h）

對于獲取時間，可以讀取出各個寄存器的值，然后為p_tm細分時間結構體中的各個成員賦值，范例程序詳見程序清單13.69。

程序清單13.69 時間獲取函數的實現范例

程序中，將p_cookie強制轉換為指向設備自身的指針。這是由于在為RTC服務中的p_cookie成員賦值時，往往將其賦值為指向設備自身的指針，下一小節將詳細介紹。

讀取時間信息時，直接從秒寄存器開始，連續讀取了7個寄存器的值，以便一次性讀取出所有時間信息。讀取的時間值為BCD碼，在為細分時間賦值前需要將其轉換為實際數值。特別地，在細分時間中，tm_year是從1900年開始計算的，而PCF85063的年值有效范圍為0 ~ 99，實際年份的表示范圍則為1900 ~ 1999，滿足不了實際需求。為了擴大表示范圍，當tm_year小于70時（即PCF85063中年值寄存器的值小于70時），將tm_year的值增加100。如此一來，當年值寄存器的值為0 ~ 69時，實際表示的年值為100 ~ 169，當值為70 ~ 99時，表示的年值依舊就是70 ~ 99，使得年值的范圍擴大到了70 ~ 169，對應的年份范圍即為1970 ~ 2069，1970也是很多操作系統中的時間起點。

時間設置是一個相反的過程，即將細分時間中的值設置到PCF85063的相應寄存器中，范例程序詳見程序清單13.70。

程序清單13.70 時間設置函數的實現范例

程序中，首先將細分時間值依次存儲到data數組中，然后一次性寫入所有時間信息。值得注意的是，在細分時間中，tm_mon表示月份，其值為實際月份減一（有效值為0 ~ 11）。而在PCF85063中，月份寄存器中的有效值為1 ~ 12，表示的是實際月份，因此，在將細分時間值寫入PCF85063的寄存器時，需要作加1操作，以將tm_mon轉換為實際月份。特別地，在驅動中，將tm_year的范圍限制在了70 ~ 169，以表示年份1970 ~ 2069。若tm_year的值超過該范圍，則表示是無效時間。年值寄存器的有效范圍為0 ~ 99，根據規則（小于70時加上100），年值為100 ~ 169時，寄存器的值應為0 ~ 69 ；年值為70 ~ 99時，寄存器的值保持不變，同樣為70 ~ 99。年值寄存器的值不能超過100，大于100時，應該減去100，程序中，巧妙的將tm_year的值對100取余作為最終年值寄存器的值，完成了這一操作。

4. p_cookie成員賦值

p_cookie用于系統在調用設備實現的抽象方法時，“原封不動”的傳遞給各個抽象方法的p_cookie參數。這樣一來，傳入抽象方法中的p_cookie與RTC服務中的p_cookie是完全相同的。通常情況下，p_cookie都起到一個p_this的作用，用于指向設備自身，基于此，直接將RTC服務中p_cookie設置為p_this，詳見程序清單13.71。

程序清單13.71 p_cookie成員的賦值

正因為如此，在程序清單13.69和程序清單13.70所示的RTC抽象方法的實現中，可以直接將p_cookie強制轉換為指向設備自身的指針。

至此，清楚了RTC服務中各成員應該設置的具體值，可以在系統獲取RTC服務時，再進行相關成員的賦值。

13.4.7 定義Method對象

已知獲取RTC服務的Method類型為：awbl_rtcserv_get。為了使PCF85063可以向系統提供RTC服務，需要使用該類型定義Method對象，核心需要實現一個用于系統獲取RTC服務的入口函數，范例程序詳見程序清單13.72。

程序清單13.72 獲取RTC服務的入口函數實現范例

基于此，可以完成一個Method對象的定義，即：

一個驅動提供的所有Method對象應該存放在一個列表中，由于PCF85063設備僅能提供RTC服務，因此，Method對象列表中僅包含一個用于獲取RTC服務的Method對象，詳見程序清單13.73。

程序清單13.73 PCF85063設備驅動Method對象列表定義

其中，__g_pcf85063_dev_methods即可作為基礎驅動信息中p_methods的值。

13.4.8 定義驅動結構體常量，實現驅動注冊函數

驅動信息常量的實際類型與設備所處的總線類型相關。PCF85063設備掛在I2C總線上，I2C總線上的所有設備驅動對應的信息結構體類型為awbl_i2c_drvinfo_t，其是直接從基礎驅動信息類型派生而來的，具體定義詳見程序清單13.74。

程序清單13.74 awbl_i2c_drvinfo_t類型定義（awbl_i2cbus.h）

由此可見，其并未擴展任何其它新的成員，和基礎驅動信息是完全一樣的，可以定義用于描述PCF85063驅動的信息常量，詳見程序清單13.75。

程序清單13.75 定義描述PCF85063驅動的信息常量

用戶若需使用該驅動，還需要將驅動注冊到系統中，可以提供一個用于注冊PCF85063驅動的專用函數，其實現詳見程序清單13.76。

程序清單13.76 注冊PCF85063驅動的專用函數

為便于查閱，PCF85063完整的驅動文件內容詳見程序清單13.77和程序清單13.78。

程序清單13.77 PCF85063驅動頭文件（awbl_pcf85063.h）

程序清單13.78 PCF85063驅動源文件（awbl_pcf85063.c）