MIPI RFFE Introduction and two wire communication/serial communication UART, I2C

Serial Communication and Parallel Communication

        我們要怎麼把一個8 bits的資料從A傳到B，最佳簡單的方式就是拉出8條線，每條線代表一個bit來傳輸，然後再加一條控制訊號線來控制這時候是讀入或寫出的動作，所以每一次動作都會傳送8 bits，這個我們一般稱作parallel communication. 並列埠 很早期的印表機，硬碟IDE或GPIB都是用這樣的傳輸介面。

Parallel Communication 

        另外一種傳輸技術稱為serial communication 串列埠，與parallel想比，所謂的串列與並列是指資料的排列結構，parallel是代表D7 ~ D0 並聯同時傳送，串聯是指一次傳一個bit，先傳D0然後D1....依序傳送D7，然後在接收端在整合成一個byte，資料傳送是一個接一個，串起來傳送，USB就是一種serial communication的介面。

Serial Communication

        Serial Communication與Parallel Communication的優缺點直觀上很明顯，Serial Communication的接線明顯比Parallel少，但如果傳送的clock rate一樣的話，速度Parallel Communication以上面的例子來說一次clock可以傳送8bits, 但串列傳輸只能傳一個bit，速度差了8倍。

two wire communication 

UART Tow Wire or One Wire x2 

        上面的例子是單向傳輸，所以需要一條訊號線Tx，如果要接收的話就需要另外一條線Rx. 這時候兩個設備的接線就為TX, RX 兩條線 (其實GND也算一條線，但是一般不會加進來算)。以UART Universal Asynchronous Receiver and Transmitter通用非同步收發機，因為TX and RX是分開的，所以可以達成雙向溝通，但裡面有Asynchronous非同步其實代表訊號不需要Clock來同步。
         非同步的傳輸本身就會有一個問題，那就是你怎麼知道傳送過來的訊號是1還是11或是111呢? 以下面的為例子，如果接收機是負緣取值negative edge/falling edge，接收機本身的clock速度會影響對訊號的解讀，所以UART在傳輸的時候都要設定Baud Rate. 也就是雙方要先確認彼此資料傳輸的速度才行。

Baud Rate

        這樣的架構如果Receiver是個被動讀寫的裝置(Slave)，妥善安排傳輸協定，本身可以完成one wire傳輸，簡單的概念就是有一個主控端來條控這條線上面誰來傳送資料，接收端被動接收指令。

        以下面的例子，Master端先對Receiver (Slave)傳送要求讀取的指令，傳送完後Master等待Slave回傳資料，這樣就不會有一條線上同時兩端都在發送訊號的情形發生。如果用生活中的例子比方說電影看到的對講機，就是類似的道理，其中一方老鷹要先呼叫小雞一樣，

老鷹呼叫小雞
收到請回答
Over

然後放開發射鈕後等待話筒傳來小雞回覆，

小雞回覆老鷹
Over

而且每次講完的時候都會說Over來代表這句話的結束，其實Serial Communication的原理就跟這個很像，雙方要協定好如何溝通。

I2C Two Wire 

        延續one wire communication的概念，另外一種類似one wire傳輸的方式是在原本one wire上面加入了一條clock同步訊號Synchronous，有別於非同步Asynchronous的概念，發射訊號自帶Baud Rate，所以接收端不需要知道對方的速度是怎樣就可以達成。
        Clock會由Transmitter (Master)提供，因為大家會看到同一個Clock訊號，雙方可以利用Clock訊號協定通訊協定，以I2C為例因為本身idle的時候是高準位(pull-up resistor)，在傳輸過程是以clock rising edge的訊號來判斷可以讀取Data上面的資料，falling edge的時候是data轉換過程。
        與UART/One Wire Communication相比，因為Clock由Transmitter決定，也就是clock rate已經被決定Receiver端不需要先設定或知道Baud Rate是多少? 而且Receiver端也可以不用內建clock generator。
        因為有兩條線Clock and Data (其實還有GND啦)，所以通稱two wire communication.

        I2C當初在發明的時候是為了要連結多個周邊電路，所以如果有多個Slave元件串接再一起，Master只需要拉出兩條線Clock and Data (其實還有GND啦)，所以通稱two wire communication. 

        multi device在溝通的時候，原理其實跟一推人用對講機一樣，有一個主控中心(Master)，當老鷹呼叫小雞的時候，要求回覆所在位置的時候，用場的每個人都會聽到這段指令，但因為指令裡面是指定小雞回應，所以只有小雞會回答位置，在回答位置的時候，其他母雞與公雞也都能聽到這段話，但他們會注意的關鍵字是

Over

因為聽到Over後他們要在聽專注下一段話是不是老鷹在呼叫。

        底下是I2C Read Register的Protocol (from TI)，第一個byte包含7bits的Slave ID，然後1bit R/W來決定這個是讀或是寫，然後後面跟著要讀取的Register Address 兩次......別問為什麼兩次這就是協定，然後就是Slave等待回應Data. 傳後完後一個Stop (Data)。

MIPI RFFE

        MIPI RFFE是MIPI聯盟下的其中一個通訊協定，MIPI Alliance主要是促進手機通訊介面一致化，這個也協助手機業後面快速發展的一個推手，最主要的目的是統一介面，某種程度上如果你手機製造商用了A家的面板，但如果想要換B家如果兩家的介面都是不一樣的，那製造商勢必要花時間來開發B廠商的驅動程式，其實可以想像IC與IC之間的USB，大家都走一樣的傳輸協定，無論是鏡頭的開發者或顯示器的開發者都可以專注在本業上面。

        MIPI RFFE 為RF Front End的縮寫，目的就是來控制這些周邊射頻元件，整個通訊協定與I2C類似，也是two wire communication的架構(Clock and Data)。

Fundamental features

• High performance (up to 52 MHz bus speed)
• Low power
• Low EMI
• Point to multi-point

https://mipi.org/specifications/rf-front-end

      會有MIPI RFFE的產生其實與智慧型手機發展有關，手機在2G雙頻，四頻到3G 4G，又要支援CA等等，當初入門的3G手機，TXM就有六個TRX Port, IDLE HBTX, LBTX 9種狀態，所以至少要四條控制線(GPIO)來控制這顆元件，但當你其他元件進來的時候所需要的GPIO就越來越多，而且因為全部都是從Modem接出去，整個PCB布局的複雜度也會隨著元件數量往上提升，但如果改用MIPI RFFE (two wire bus)，每顆元件就只要三條線.....多一條是因為還要有電源Vio，在布局上面因為是串聯所以彈性也比較大。

        

GPIO vs MIPI RFFE

        那為什麼不用I2C就好了呢? 這邊有幾個比較重點的理由，

1. MIPI RFFE不用pull-up and pull-down電阻

2. 整個Protocol是為了手機量身訂做，比方說有制定Broadcast Trig協定，在時序要求精準的通訊系統可以有更精準的Timing控制。

3. 可以動態修改USID，MIPI USID為4個bits，在同一個bus上面可能會遇到相同的USID，但MIPI 有制定獨一無二的Manufacturer ID還有自訂的Product ID，所以系統可以透過特定的程序在開機的時候動態修改USID，方便在更換不同廠商pin to pin元件的管理。

4. Clock Rate up to 26MHz. (這大概是最重要的一點吧)

http://mid.mipi.org/

         底下是GMSK傳輸的時序圖，其實無論是2G, 3G, 4G，傳輸的單位都是以一個Time Slot來區分，因為移動通訊手機與基地台的位置會一直變化，傳輸的功率與內容要一直隨著環境的改變來調整，所以每一個Time Slot的傳輸過程如果以傳統的GPIO，Rising Edge訊號打開，Falling Edge訊號關閉，如果改成I2C的話最大的問題會是傳送一個command總長度是多少?

        以一個I2C寫入的指令8bits slave ID, 8bits address, 8bits data. 不含Parity Bit總共需要24bits來完成一個指令傳送，如果clock rate為 100kHz, 那一個clock tiime為10us, 送完一個command所需要的時間為240us.

24*10us  = 240us........

        這樣的速度是沒辦法應用在行動通訊上面的，如果clock rate拉高到10MHz, 那一個clock cycle時間就會縮短到0.1us. 送相同的指令就會縮短到2.4us. 這可以滿足目前行動通訊slot to slot之間的要求。

24*10.1us = 2.4us

        底下是MIPI RFFE Write Frame，另外MIPI RFFE對Register 0還會特別設計一個Frame，跟一般的指令Write相比，同樣要對Register 0寫入

特別指令Register 0要敲的bit數為:          16bits

一般指令Register Write要敲的bit數為:   24bits.

如果有對timing控制特別敏感的，指令長度還是快了一些，因為大部分device開關的logic table都會設定在register 0的位置。

        下次有時間再來聊聊MIPI RFFE的一些無聊的設定還有MIPI Alliance新制定的I3C吧