本章將介紹CW32的IIC接口，并最終點亮一塊OLED屏幕，如果你對如何編寫各種模塊的驅動代碼束手無策，那本系列教程的IIC章節或許能讓你受益匪淺。

Inter-Integrated Circuit Bus，集成電路總線，簡稱IIC總線。這是一種半雙工同步總線協議，這個分類很好地概括了IIC總線的特點：

1.作為總線協議，可以在一根“信息主干道”上接入多個通信節點（也就是通信設備）；

2.同一時間只能有一個通信節點能夠在總線上講話；

3.同步傳輸意味著這種傳輸方式至少需要一根時鐘線；

IIC總線使用2根線來傳輸信號：時鐘線和數據線，相比于其他的總線協議，這種傳輸方式更節省IO資源，由于多數情況下IIC僅用于同一塊集成電路板上不同模塊之間的通信，所以它并不能傳輸很長的距離，速度也不是那么快，但硬件布線簡單，且同一塊電路板都會使用同一個電源的正負極，因此IIC總線相當實用。

本文不會詳細介紹IIC總線的時序，這里只對其通信流程進行概括，并著重介紹數據鏈路層的相關內容。從流程上看，IIC總線協議的通信過程大致如下。

假設有A、B兩個設備，他們使用IIC總線協議來傳遞信息，協議規定至少要有一個設備作為主機，其他設備作為從機，IIC是同步通信，協議規定主機來提供時鐘，因此只有主機可以主動發起一次通信。假設現在A需要向B傳遞一個信息DATA，那過程就是這樣：

1.設備A發出消息“全體目光向我看齊，我宣布個事，我要開始講話了”；

2.設備A發出的“公告”會被B看到，B作為從機就會聽A接下來要說什么，從A發出“公告”開始，A就會占用總線，此時其他設備都無法在數據線上發出消息。

3.設備A需要繼續喊話，這第二次喊話，A就需要告知總線上的設備自己到底要找誰發消息，是廣播給所有人（就像全校演講那樣），還是逮住某個設備“私聊”，IIC總線使用從機地址來區分廣播和“私聊”，如果第二次喊話的內容是廣播模式專有的“地址碼”（0x00），總線上的所有從機都會接收后續發出的數據；如果第二次喊話的內容是設備B專有的“地址碼”（一個7bit大小的數字），那這次喊話就是針對設備B的，其他的設備會發現點名私聊沒找到自己，也就會放棄對后續數據的接收。

4.假設設備A用二次喊話找到設備B進行私聊，待B回應一個應答信號（ACK）之后，A就可以開始數據的傳輸，每當B接收到A傳輸的數據，B就會給A發出一個應答信號，這個過程會持續到A完成所有數據的傳輸并發出停止信號為止——“我的話講完了，你可以掛電話了“。

如果在A不斷向B傳輸數據的過程中，B覺得自己腦子要炸了，數據太多了，需要時間消化，B可以在回發應答信號的時候發一個“我收不了了！“（NACK），A在接收到這個信號之后，就知道B已經接收到極限了，A就不會再發數據。之后A可以選擇開始新一輪的數據傳輸（回到過程1發起一個新的”喊話“）或者發出停止信號來直接關閉這次通信。

我們會發現上述過程存在很多分支選項，整個過程就像上課一樣，“老師講課學生都聽著“、”老師點名某個學生回答問題“，下面我們就從具體的格式上來把上述的抽象過程給對應上。

格式上看，任何一次完整的IIC通信需要傳輸的數據都是如下的結構：

“起始信號+從機地址|讀寫類型+ACK+數據0+ACK+數據1+ACK+數據2+……+數據N+ACK+停止信號”

起始信號=我要開始喊話了；

從機地址|讀寫類型=我要找誰講話|我要傳達or索要信息；

ACK=收到！；

數據N=需要傳達or索要的信息；

停止信號：我的話講完了；

肯定有小伙伴想問：“那IIC總線通過什么方式來表示這些信號呢？“，這些內容屬于物理層，感興趣的小伙伴可以自行百度。

前半部分主要講解了IIC總線的過程，下面介紹具體到代碼上，單片機的IIC接口應該如何去使用。

首先登場的還是喜聞樂見的IO和時鐘配置，需要注意的是，這里的IO輸出模式需要配置為開漏輸出，因為IIC接口需要從IO口收發數據，讀寫都在這一個IO上，開漏輸出就能滿足同時讀寫的需求。

對于IIC的配置其實相對來說比較簡單，配置好波特率（公式在結構體的注釋里面寫好了），使能外設，設置好應答規則，最后開啟IIC外設即可。

接著就是比較重要的部分了，IIC接口的收發并不是全自動的，因為一個完整的通信不僅包括發數據（地址、數據什么的），還包含收數據（啥也不干也得接收ACK信號），所以IIC通信的每個部分基本上都是收發易位的過程，IIC外設并不會自動完成這個復雜的過程，每個部分的信號是否發送、以及發送的情況都需要開發者自己去查看（開發者：改為手動操作，全部讓我來！）。

編者寫了幾個帶自檢功能的IIC函數，這幾個簡單的函數可以滿足驅動OLED的需求。

編寫這四個函數可以方便我們后續對OLED驅動的開發，現在我要詳細說明一下這四個函數的內在邏輯。

首先是起始信號，我們可以看到發起始信號的函數顯示打開了一個開關，等待某個標志成立之后又關掉了那個開關，這里結合手冊進行說明。IIC協議中，起始信號是“SCL維持高電平，SDA線電平拉低”這一現象，手冊中也有詳細描述：

又由于CW32的IIC接口并不會在起始信號發出之后自動停發起始信號，因此如果不在監測到起始信號發出之后關閉起始信號的發送，那么數據傳輸就無法開始，IIC設備會一直發送RESTART信號來占用總線，通信就會失敗。

對于總線的狀態——“我發的信號到底成功發出去沒有呢？”，CW32提供了IIC狀態碼來指示總線狀態，根據IIC設備不同的工作模式，一共會有26種總線狀態，我們并不會用到全部的狀態，但可能用到的狀態都可以放到枚舉類型里面，就像這樣：

以起始信號發送函數為例，其返回值就是已發送起始信號的狀態碼（0x08），如果起始信號發送失敗，死循環就無法跳出，程序死機（雖然實際上不應該這么寫，此處只做演示，編者就小小地偷一下懶）。

視線來到發送從機地址和讀寫指令的函數，就像本文前半部分講的一樣，喊話宣言之后需要指名道姓自己需要私聊的對象。從機地址本身只有7bit，占據整個字節的高7位，0號bit位表示這一次通信是為了傳達信息還是索取信息，0位為0則傳達（也就是寫），為1則索取（也就是讀）。當成功發送從機地址這一個字節之后，IIC狀態碼也會改變，對比狀態碼之后即可確認從機地址字節發送成功并收到了從機的ACK信號，這表示從機確認收到了這個字節的消息。

發送數據的函數和發送從機地址的函數很相似，只不過整個字節都表示數據，并沒有什么獨特的含義。

最后就是發送停止信號的函數，與起始信號不同，停止信號成功發出之后，總線會進入空閑狀態，并且停止信號使能位會被硬件自動清零。

捋清邏輯之后，我就要說明一個非常重要的細節，仔細觀察會發現，所有的IIC信號發送函數都有一個清除中斷標志的操作，這里明明不是中斷，為什么要寫這個語句呢？因為CW32的IIC接口，其發送數據的觸發條件，就是中斷標志位被清除。根據手冊的描述，只要IIC狀態碼改變，中斷標志位就會被硬件置位，在開啟中斷的情況下，程序會進入中斷服務函數，如果不開啟中斷，程序的執行順序不會改變，這個標志位也就只是一個發送開關。

這個發送邏輯某種程度上很反直覺，因為大部分的通信接口，都是拿“數據緩沖區被寫入數據”來觸發發送行為的，而此處的send函數，均不具備發送功能，與其叫send_data，不如叫set_data更合適，他們的作用只是把數據裝載到IIC的數據寄存器，因此如果想要發送，就需要在清除中斷標志位之前將數據寫入數據寄存器。手冊上也詳細描述了這一點：

這樣一來，IIC通信就具備基本的發送功能了，對于常見的EEPROM讀寫，CW32的IIC庫提供了連續讀寫的函數，開發者可以直接使用：

個人評價：大部分人在需要使用IIC的時候，都會直接移植軟件模擬的IIC接口，但是在更多的地方，我還是推薦使用硬件IIC，尤其是需要使用IIC大量讀寫數據的場合。而CW32的IIC接口，在不考慮發送觸發與中斷綁定這一反直覺因素的情況下，其內部的處理邏輯相比其他MCU的IIC接口，還是頗具優勢的（讀者可以自行對比STM32的IIC接口，STM32的IIC讀寫邏輯不能完全手動操作，效率不夠高），尤其是每次發送之后，不必要立刻進行下一個字節的發送，只要IIC總線還保持在建立狀態，開發者可以在之后一段時間內的任意時刻發送下一個字節，這直接省去了等待發送完成的時間（當然本文并沒有采取這種寫法），提高了程序整體的運行效率。