題:
在考慮SPI或I2C時需要權衡?
Mark Harrison
2012-03-31 09:33:24 UTC
view on stackexchange narkive permalink

在決定使用SPI或I2C接口時應該考慮哪些折衷?

該加速度計/陀螺儀分接板有兩種型號,每種接口一個。哪一個更容易集成到Arduino項目中?

http://www.sparkfun.com/products/11028

enter image description here

I2C和SPI有其優勢。 I2C的設置更加複雜,一旦穩定,您就可以輕鬆擴展(只要您的總線接線不會太長或太大)。 SPI易於設置..如果需要,可以非常容易地對其進行位衝擊。 Expansion吞噬了所有選擇的芯片的I / O。如果我擁有I / O和連接器空間的奢華,並且不需要總線,那麼我總是選擇SPI。
I2C如何更複雜?我已經在不同的微處理器上使用了這兩種總線(小型PIC和尺寸合適的ARM),並且在每種情況下I2C的設置都比較簡單(即,更少的寄存器可寫)。如果有的話,由於時鐘極性和數據採樣選項,SPI更複雜。
@Armandas-沒辦法! SPI有4種可能的時鐘/數據極性模式,其中兩種占主導地位-幾乎所有SPI器件都在時鐘的下降沿更新其MISO輸出,並在時鐘的上升沿讀取其MOSI輸入。通過查看數據表,您可以在幾分鐘之內找出哪一個,然後就可以完成。如果您錯誤地選擇了錯誤的模式,則在查看示波器走線時會很快找出來。 SPI數據錯誤很少見,不會像I2C那樣陷入怪異狀態。
我說I2c更複雜,因為我曾經不得不在ARM處理器上編寫I2C驅動程序。我遵循了NXP文檔的狀態機,它大約有20個州。我花了相當多的時間弄清楚確認,何時讀/寫了最後一個字節,等等。我從未遇到過SPI的任何這些問題,只需要整理時鐘和數據即可。
在選擇答案之前,請先閱讀此處的答案:http://electronics.stackexchange.com/questions/13987/general-protocol-for-data-transfer-from-one-system-to-another/14059#14059兩者都有應用程序。
坦白說,@JonL,是迄今為止我唯一提供完整答案的人,因為我是唯一討論OP要使用的特定突破板的問題的人,並指出在*中*不可用。包括SPI和I2C,但只有I2C -因此,如果他想使用該特定板,則必須使用I2C。其他僅涉及哪個接口(SPI或I2C)更易於接口,我也介紹了該接口。
@Hans: NXP記錄的I2C實現包括諸如多主機仲裁之類的規定,這在典型應用程序中是不需要的,並且還基於基於狀態的方法進行設計。過程驅動的I2C主機的代碼比此類文檔所建議的要簡單得多。
八 答案:
stevenvh
2012-03-31 12:20:53 UTC
view on stackexchange narkive permalink

摘要

  • SPI更快。
  • 如果您的微控制器沒有I2C控制器,則I2C更複雜且不那麼容易使用。
  • I2C僅需要2條線。

I2C是在SDA線上具有雙向數據的總線系統。 SPI是點對點連接,數據輸入和數據輸出在單獨的線(MOSI和MISO)上。

基本上 SPI 由一對移位寄存器組成,在這裡您將數據移入一個移位寄存器,而將數據移出另一個。通常,每次連續8個時鐘脈衝以字節為單位寫入數據,但這不是SPI的要求。如果願意,您還可以設置16位甚至13位的字長。在I2C中,同步是通過SPI中的啟動序列完成的,而同步是由SS變為高電平(SS為低電平有效)來完成的。您可以在多少個時鐘脈衝後決定自己。如果使用13位字,SS將在13個時鐘脈衝後鎖存最後一個時鐘輸入位。
由於雙向數據位於兩條不同的線上,因此很容易接口。

標準模式下的SPI至少需要四行:SCLK(串行時鐘),MOSI(主輸出從動輸入),MISO(主輸入從動輸出)和SS(從選擇)。至少三條線:SCLK(串行時鐘),MIMO(主輸入主輸出)(MOSI或MISO線之一)和SS(從選擇),在具有多個從站的系統中,每個從站都需要一條SS線對於\ $ N \ $從站,在標準模式下有\ $ N + 3 \ $行,在雙向模式下有\ $ N + 2 \ $行。如果您不希望這樣做,則可以在標準模式下,通過將一個從站的MOSI信號連接到另一個從站的MISO信號,以菊花鏈方式連接從站。這將減慢通信速度,因為您必須循環訪問所有從機數據。

像tcrosley所說,SPI的工作頻率比I2C高得多。

I2C 有點複雜。由於它是總線,因此您需要一種尋址設備的方法。您的通信從一個獨特的開始序列開始:當時鐘(SCL)為高時,數據線(SDA)被拉低,而其餘的通信數據僅在時鐘為低時才被改變。此開始序列將同步每個通信。
由於通信包括尋址,所以對於任意數量的設備(最多127個)僅需要兩條線。

編輯
很明顯,數據線是雙向的,但值得注意的是,時鐘線也是如此。從站可以延長時鐘來控制總線速度。這使I2C不太方便進行電平轉換或緩衝。 (標準模式下的SPI線都是單向的。)

發送完每個字節(地址或數據)後,接收器必須通過在SDA上放置一個確認脈衝來確認接收。如果您的微控制器具有I2C接口,則將自動進行處理。如果您的微控制器不支持它,您仍然可以對其進行位衝擊,但是對於每個確認或讀取數據,您都必須將I / O引腳從輸出切換為輸入,除非您使用I / O引腳進行讀取和讀取。

在400kHz時,標準I2C比SPI慢得多。有些高速I2C器件的工作頻率為1MHz,但仍比20MHz的SPI慢得多。

我還沒有遇到能夠處理I2C所有極端情況的微控制器,因此需要以無需成為I2C專家就可以使用的方式來處理正確的錯誤檢測和恢復。當SDA保持為低電平時,我總是不得不暫時從“智能” I2C外設跌落到臨時敲打狀態,以處理時鐘丟失的情況,這是完全痛苦的。
(但+1,因為我同意您的其餘回答)
甚至還有I2C設備在3.4MHz下工作,但是我不確定這些設備是否可以與速度較慢的設備結合使用(因為所有設備都必須能夠遵循總線尋址)。我也相信3.4MHz I2C的時序有點不同。
-1
@stevenvh:某些控制器的兩線製實現(例如賽普拉斯PSOC)要求SCK在內部時鐘至少保持一到兩個週期之前必須為低電平,然後才將其鎖存,並且不會發生嚴重故障。我不知道為什麼沒有系統時鐘脈沖他們就無法檢測和時鐘拉伸I2C啟動條件,但是這種行為意味著當這種芯片以較低的系統時鐘速度運行時,總線上的所有I2C事務必須運行緩慢)。對於以3MHz運行的PSOC而言,即使400Khz的操作速度也太快了。
應該注意的是,即使它們是總線上的唯一設備,許多SPI設備也要求SS被正確使用。 SS不僅啟用單個從站,而且還提供同步。 SS的前沿通常用於指示新消息的開始,並通過從設備邏輯進行相關的重新同步。
@stevenvh: *但是SS不僅會抑制時鐘嗎?*否,這就是重點。許多設備使用SS的前沿來指示新消息。例如,EEPROM可以將SS之後的前兩個字節作為地址,然後將隨後的字節作為數據。對於A / D,很常見的是,有意義的位在相對於SS的固定位置處傳輸,然後它繼續發送0或未定義的位。這樣可以更輕鬆地與只能執行固定倍數位(例如8或16)的硬件兼容。對於某些設備,第一個字節是操作碼,其餘字節取決於該操作碼。
@stevenvh:絕大多數SPI設備使用SS進行同步,並要求它通過事務保持有效。某些設備具有*單獨的*時鐘使能線,這將導致它們在事務處理期間忽略時鐘脈衝。如果“主線代碼”正在訪問某些其他設備(例如閃存芯片)時,中斷服務例程可能需要訪問SPI總線上的一個設備,則這很有用。
@Olin,超級貓-昨晚躺在床上,我意識到我對SPI同步的評論是完全錯誤的。錯誤。我不知道我在抽什麼煙。我將其刪除並編輯答案。
@stevenvh:雙向SPI需要四條線;許多SPI設備僅使用單向傳輸,並且需要三個。儘管移位寄存器通常在SPI總線上使用並允許菊花鏈連接,並且也有一些更複雜的外設也可以使用,但此類設備是例外而不是常規。
@stevenh LPC1300 / 1700/1800/4300系列聲稱支持1 Mbit / s的操作。我還沒有看到連接它的外圍設備!
-1
Jason S
2012-04-01 06:36:39 UTC
view on stackexchange narkive permalink

(編輯:要清楚,以下許多問題與Ilin / Ilin正確指出的由闆對板使用I2C / SPI設備引起的信號完整性有關。)

除非您的約束會極大地推動您減少電線的數量(我們有一個項目採用的是密封連接器,每個額外的觸點都相當昂貴),盡可能避免使用I2C,並堅持使用SPI。

SPI相當易於在硬件和軟件基礎上進行處理。在硬件中,有兩條共享數據線,即主機輸入從機輸出(MISO或SOMI)和主機輸出從機輸入(MOSI或SIMO),主機生成的共享時鐘以及每個設備一個芯片選擇。 CS線變為低電平,時鐘週期並實質上移入輸入位並移出輸出位,直到事務完成為止,此時CS線變為高電平。當CS線為高電平時,從機設備不通信:它們忽略CLK和MOSI線,並將其MISO引腳置於高阻抗狀態,以供其他人使用。

使用多個SPI設備的微控制器,並且具有內置的SPI外設,將微控制器的CS輸出發送到解復用器(例如74HC138),並控制地址線在SPI事務之間選擇設備;您可以將字寫到寄存器中以使其排隊等待輸出,然後在CS引腳升為高電平後將其讀回。

由於SPI信號都是單向的,因此可以對其進行緩衝,並與隔離柵一起使用。數字隔離器,並且可以使用線路驅動器(如LVDS)從板到板發送。您唯一需要擔心的是往返傳播延遲,它將限制您的最大頻率。


I2C是一個完全不同的故事。儘管從佈線的角度來看要簡單得多,但只有兩條線SCL和SDA,這兩條線都是共享的雙向線,它們使用帶有外部上拉的開漏器件。有一個I2C協議以傳輸設備地址開始,因此如果每個設備都有自己的地址,則可以使用多個設備。

從硬件的角度來看,在具有以下條件的系統中很難使用I2C:任何明顯的噪音。為了緩衝或隔離I2C線路,您必須求助於奇異的IC-是的,它們存在,但數量不多:我們在一個項目上使用了一個,並意識到可以使用一個隔離器,但不能使用兩個串聯-它使用小的電壓降來確定物體的驅動端是哪一側,而兩個串聯的電壓降是兩個。

I2C的邏輯電平閾值取決於Vcc,因此如果在同一系統中使用3V / 3.3V和5V器件,則必須格外小心。

任何使用一英尺或兩英尺以上電纜的信號都必須擔心電纜電容。 100pf /米的電容與多芯電纜並不不同尋常。因此,您必須降低總線速度或使用較低的上拉電阻,才能正確處理額外的電容並滿足上升時間要求。

因此,假設您有一個系統,您的設計很好,就可以解決大多數信號完整性問題,並且噪聲很少(但仍然存在)。您要擔心什麼?

必須準備處理許多錯誤條件:

  • 從設備無法識別特定字節。您必須檢測到這一點,然後停止並重新啟動通信序列。 (使用SPI,如果要確保已正確接收到數據,通常可以讀回發送的數據。)

  • 您正在從從設備讀取一個字節的數據,並且該設備由於時鐘線上的噪聲而被“催眠”:您已發送必需的8個時鐘來讀取該字節,但由於噪聲,從設備認為它已收到7個時鐘,並且仍在數據線上發送0。如果設備已接收到第8個時鐘,它將釋放數據線為高電平,以便主機可以升高或降低數據線以發送ACK或NACK位,或者主機可以發送停止(P)條件。但是從機仍將數據線保持在低電平,徒勞地等待另一個時鐘。如果主機不准備嘗試額外的時鐘,則I2C總線將陷入死鎖。儘管我使用了幾種微控制器來處理正常的ACK / NACK條件,但我從未使用過一種能夠成功處理這種丟失的時鐘位(或額外的時鐘位)條件的微控制器,並且不得不退出自動I2C模式,進入位砰砰模式,添加時鐘直到數據線變高,然後重新進入自動I2C模式。另一個從站錯誤地解釋了設備地址,並認為發送的數據是為此目的而準備的。我們有一些I2C設備(I / O擴展器),因此有時會錯誤地設置寄存器。幾乎不可能檢測到這種情況,並且要對噪聲具有魯棒性,您必須定期設置所有寄存器,這樣,如果您確實遇到此錯誤,至少可以在短時間內將其修復。 (SPI永遠不會出現這個問題-如果您碰巧在CS線上出現故障,它將永遠不會持續很長時間,並且您不會被錯誤的從屬設備意外讀取數據。)

如果存在錯誤檢測(CRC碼),則協議中的許多情況都可以正確處理,但是很少有設備具備此功能。


我發現我必須在I2C主設備中構建複雜的軟件才能處理這些情況。我認為,除非接線方面的限制迫使我們使用I2C而不是SPI,否則這是不值得的。

您對IIC的宗教厭惡在這裡無處可尋。 IIC和SPI都擅長於各自的工作,並且各有千秋。您對IIC的大多數反對意見都來自對IIC的不當使用。儘管IIC通常在電源行業中用於控制智能電源,但應該將其視為僅板載。如果您發現自己需要IIC緩衝區,那麼就很強烈地表明IIC不是正確的解決方案。但是,IIC對於所有在同一板上的低速設備非常有效。
* I2C的邏輯電平閾值取決於Vcc,因此,如果在同一系統中使用3V / 3.3V和5V器件,則必須格外小心。不,這是錯誤的。 IIC邏輯閾值為固定電壓。通過將線路上拉至僅3.3 V,可以輕鬆混合5 V和3.3 V系統。
Olin-您能指出規格中的固定電壓閾值嗎?我的印像是它們也被固定(SMBus閾值*被固定),但是我查看了《恩智浦I2C用戶手冊》(UM10204),他們將閾值引用為0.3VDD和0.7VDD。
這不是對I2C的宗教厭惡,而是對I2C的實際厭惡。您是對的,因為車載系統使它變得更加容易。我會在合理的情況下使用它,但這會增加軟件成本,而且太多的硬件工程師只是將I2C設備粘貼在板上,而沒有討論導致更多軟件麻煩的折衷方案。
我不記得確切看到的位置了,在周圍稍加摸索似乎確實有些困惑和不同的選擇,但是我敢肯定我記得例如1.5V是最大邏輯低閾值。
IIC在電氣上更容易實現,而SPI在固件中可能更容易實現。但是,從兩個方面來看,兩者都非常容易和直接。
I2C設計用於電氣清潔的環境,不能輕易“強化”以用於更惡劣的環境。話雖這麼說,對於電清潔環境中的處理器間通信,I2C比SPI方便得多。 UART可能會更好,但是處理器似乎永遠都不夠用,許多控制器的UART與時鐘系統集成在一起的方式使得很難更改時鐘速度而又不會破壞另一端可能決定異步發送的任何數據。
@Olin-過去似乎使用固定的1.5 V閾值,但根據最新版本的規範,閾值確實為0.3 Vcc和0.7 Vcc。規格中的[此引號](http://electronics.stackexchange.com/a/35048/2064)提到了傳統設備的1.5V。
@JasonS到現在已經6年了,評論中有很多有用的討論。是否有可能在每種情況下都有一系列情況,I2C可靠性和錯誤模式?例如。當寫入單個設備時,似乎100%可以。當寫入多個設備時,某些設備可能會誤解數據。從單個設備讀取數據時,可能必須進行位撞擊和重置。從多個設備讀取數據時,可能需要重新啟動電源才能消除死鎖?
tcrosley
2012-03-31 11:44:25 UTC
view on stackexchange narkive permalink

SparkFun的設備分線板實際上僅適用於I2C版本(MPU-6500)。 MPU-6000版本在同一芯片上同時具有SPI和I2C接口,我看不到SparkFun在該芯片上有一塊板。因此,我相信如果您想使用該特定板子,則只能使用I2C。但是出於以下原因,我還是建議您在任何情況下都使用I2C。

通常,您會發現從硬件角度來看,I2C總線比SPI總線更易於使用。 I2C是2線總線(SCL / SDA):

  SCL –串行時鐘。SDA–串行數據(雙向)。 

SPI是4有線總線(SCLK / MOSI / MISO / CS):

  SCLK –串行時鐘。MOSI–主輸出,從輸入。從CPU到外圍設備的數據。MISO–主輸入,從輸出。數據從外設返回到CPU。CS–片選。 

您可以將多個設備連接到一條I2C總線。每個設備都有內置於芯片中的自己的一組地址。該地址實際上在總線上作為每個命令的第一個字節(連同讀/寫位)一起廣播。對於相同的功能,這以及其他一些開銷要求通過I2C總線與SPI發送更多位。

不同類別的設備(內存,I / O,LCD等)具有不同的地址範圍。某些設備在系統中通常不止一次使用(例如PCF8574 I / O擴展器),它們使用一條或多條地址線(對於PCF8574為AD0-2),可以將其綁定為高電平或低電平以指定低位地址的。 MPU-6500具有一條這樣的地址線(AD0),因此其中兩個可以在同一系統中使用。

您還可以在SPI總線上具有多個設備,但是每個設備必須具有自己的片選(CS)線。因此4線描述有點用詞不當-實際上是3線接口+每個設備增加一條線。我對Arduino系列板沒有經驗,但是我相信這會使在Arduino上使用SPI更加困難,因為如果您需要大量的芯片選擇線,那麼各種屏蔽使用的通用引腳分配將變得很麻煩。

我相信大多數Arduino板都以5伏電壓運行,而一些較新的板則以3.3v電壓運行。 MPU-6500在3.3v下運行。如果5v CPU上I2C總線的最小輸入“高”電壓為3v或以下,則可以通過在SCL和SDA線上僅提供10K上拉電阻至3.3v來避免電平轉換問題,因為總線是開放的,集電極。確保已禁用CPU上的任何5v內部上拉電阻。 ,或大於3.3v的3.5v,因此您需要某種有源電平轉換,TI PCA9306在芯片的5v和3.3v側均需要上拉電阻,成本僅為78

為什麼要在I2C上選擇SPI?主要是因為SPI的運行速度要快得多-在某些情況下高達10兆赫茲,而I2C通常限於400 KHz。對於MPU-6050 / 6000加速度計來說,這並不是真正的問題,因為它在I2C上以400 KHz運行,而在SPI上僅以1 MHz運行-差別不大。

在I2C上選擇SPI的另一個原因:所有線路都是單向的,這使電平轉換器之類的工作變得容易一些。
-1
I2C比SPI更容易嗎?如果您可以將所有內容連接在一起,那麼I2C唯一簡單的事情就是連接性。否則,在I2C中,信號完整性會更困難;在I2C中,強大的軟件實現會變得更困難。
-1
您可以將音頻輸出到I2C DAC給我留下了深刻的印象! (最大時鐘速率是多少?)如果您使用的是短期運行的板載IC,則發生鎖定的可能性非常小,但仍然存在。 (而且,如果您只是向I2C寫入數據,就永遠不會遇到它。它要求您從願意永遠等待它認為丟失/多餘的時鐘的設備上進行讀取。)
@JasonS,音頻僅為8KHz的語音質量-我正在使用128 us中斷來輸出每個16位樣本。 I2C也會在自己的中斷上運行。空閒時間用於從SD卡讀取數據。關於鎖定從來沒有寫過的好點。除了ADC,我通常將I2C用於輸出設備。但是,您是否知道Wii遙控器和Wii Nunchuck(通過3'電纜)之間的只讀接口(2個按鈕,加速計和操縱桿)是400 KHz的I2C嗎?網路上的許多資訊都重新入侵了這個裝置的介面。
-1
對我的不贊成表示歉意;如果您進行令牌編輯(添加空格或其他內容),則我將刪除下注。
JasonS,我編輯了答案以使內容更清楚,從硬件的角度來看,I2C總線通常更易於使用(儘管存在級別轉換問題)。
-1 --------> +1
Armandas
2012-03-31 11:54:05 UTC
view on stackexchange narkive permalink

通常,SPI是一條更快的總線-時鐘頻率可以在MHz範圍內。但是,SPI至少需要3條線進行雙向通信,並為總線上的每個設備選擇一個附加的從設備選擇。課程)。但是,速度在kHz範圍內(典型值為100-400kHz)。

如今,大多數微控制器都為兩條總線提供硬件支持,因此兩者的使用同樣簡單。

-1:兩者使用起來都不一樣簡單。 I2C具有許多複雜的錯誤處理和恢復功能,微控制器外設通常不處理這些錯誤和恢復(某些情況下在PIC18,PIC30或TI C28xx DSP中不是這樣)-您擁有可以處理大部分I2C但無法處理所有情況的外設)
@Jason:您似乎對IIC存有偏見,但因此而向其他人討債是不公平的。 IIC和SPI都很“容易”,每個都有自己的皺紋。 SPI需要額外的線路,這並不容易。 IIC稍微複雜一點,但是要完成所有固件實現仍然很容易,我有時可能會這樣做。它不需要那麼多代碼。兩者都有自己的位置,而且兩者都很容易,以至於不會成為任何知道他們正在做什麼的人的因素。
不公平。當“更簡單易用”的陳述被更正或至少得到了澄清時,我很高興表示支持。我挑戰任何人在具有智能I2C和SPI外圍設備的微處理器上編寫軟件,以與具有I2C和SPI變體的IC系列接口,並通過任何客觀的方法(代碼行,狀態數,圈複雜度)向我展示軟件的複雜性等),以證明它們使用起來同樣簡單。示例:Microchip 24LC256 / 25LC256 EEPROM,MCP23017 / 23S17 I / O擴展器。
我剛剛檢查了@Jason:,在8位PIC上用於IIC的* firmware *實現的通用IIC代碼只有311行,其中可能有一半以上是註釋。這使您可以在啟動,放置,獲取,停止等例程級別上與IIC總線建立過程接口。一個模塊來驅動一個簡單的EEPROM是272行,可能也是1/2條註釋,並且包括一些高級管理,例如默認數據,UART調試接口等。這是如此瑣碎,以至於爭論是否少花10條指令比SPI毫無意義。
-1
-1
好吧,我想採取一種生氣的語調都在我的意見,其他職位和我自己的答案道歉。我要承認的是,有一些方法可以使用片上外設來編寫I2C軟件,這些方法相對容易,而忽略了某些罕見的錯誤情況。話雖如此,我仍然認為說I2C容易是一種誤導。而且我認為我沒有誤用I2C。看一下TMP75-一個I2C溫度傳感器。您最多可以將其中27個放在公共汽車上。 (我們的系統有8個。)有人會把它們都放在一塊板上嗎?數據表不會警告您其他問題。
奧林(Olin):很好奇-您的實現是阻塞還是非阻塞(例如,由狀態驅動)?我可以看到,阻塞實現可以處理錯誤情況而不會帶來太多麻煩。我有一個對實時性有嚴格要求的系統,由於所有不同的錯誤情況,我不得不將I2C處理分解為一個狀態機-而SPI處理是小菜一碟;我們只需要切換CS地址,降低CS使能線,將發送數據放入隊列,等待幾微秒,升高CS使能線並讀取接收數據即可。
安德魯:“絕對不會遇到您在答案中描述的問題。”當然可以,尤其是在板載I2C總線且走線相對較短的情況下。更少的噪聲=丟失I2C時鐘的可能性降低到很小的程度。我們在工業噪聲系統中有8個TMP75傳感器。 (回想起來,我希望我們的設計師使用模擬溫度傳感器。)如果偶爾出現數據錯誤(我們確實會得到),那也不會太糟。但是問題是,您可能會陷入僵局,即使錯誤的可能性很小,一旦出現錯誤,沒有正確的錯誤處理,轉義的可能性就是0。
@Armandas:為我的歉意道歉;如果您進行令牌編輯(添加空格或其他內容),則我將刪除下注。
我要說的是@JasonS:I2C專為板載應用程序而設計。它可以擴展以通過電纜傳輸,但這不是其預期的應用,因此您必須進行設計以增加複雜性。就殭屍設備而言:沒有理智的I2C從設備會無限延長時鐘,如果您對時鐘有控制權,則可以中止I2C傳輸並重置總線。這似乎不是您要證明的瘋狂的困難系統。
@Andrew Kohlsmith-“ I2C設計用於車載應用。”-顯然,I2C設備製造商不同意您的看法。拿[TMP100](http://www.ti.com/product/tmp100)。產品頁面明確指出:“ TMP100和TMP101非常適合在各種通信,計算機,消費者,環境,工業和儀器儀表應用中進行擴展溫度測量。” [TMP75](http:// www.ti.com/product/tmp75)
就其價值而言,我已經在大約15'長的I2C總線上運行了8個TMP100,但是環境中的噪音很小。該項目的整個I2C接口有點麻煩,這實在太麻煩了。
我認為整個論點可以歸結為具有不同觀點的人們。您有Jason S,他似乎正在設計極高可靠性的硬實時工業控制系統,還有Andrew Kohlsmith和Olin Lathrop,他們設計了更多面向消費者的設備。在0.001%的錯誤率是一個嚴重而嚴重的問題的環境中(尤其是如果您不能等待〜1秒讓事情超時),I2C可能不可行。但是,在許多情況下,這樣的錯誤是非常不可能發生的,不會引起問題,或者它引入的延遲也沒有問題。
就我個人而言,我會使用I2C上的SPI,但這更多是因為我在編程方面很差,並且發現一條額外引線的複雜性微不足道。 YMMV。
@JasonS不用擔心,這是一個簡單的答案,並且明智地選擇了正確的解決方案。
TMP100的@FakeName沒有聲明要用於板外溫度感測的任何地方。您的報價僅說明在某些應用中是理想選擇。您可以在這些應用程序中通過設備感應溫度。標準的營銷絨毛,僅此而已。 Maxim對於列出任何設備龐大的應用程序尤其不利。
@FakeName構建熱線風速計時,我使用了雙晶體管設備,該設備通過雙絞線連接到標準SMBus溫度/風扇控制器。如您所知,SMBus是增強的I2C,但是該芯片是板載的,從未有任何通信麻煩。我認為您未正確使用溫度傳感器。
@FakeName您不正確;我花了13年時間從事工業電力電子學。 (啟動和監視大型三相電動機是一個非常嘈雜的環境)並不是說SPI更可靠,而是要設計出計劃並考慮了所有故障模式的系統,並在需要時將恢復選項內置到系統中。我從來沒有遇到過噪聲尖峰殺死我的I2C(或SPI)通信,但我也從來沒有完全依靠I2C控制器來為我做任何事情。這是規劃和設計的問題,而不是一輛公交車會更好。
“但是我也從來沒有完全依靠I2C控制器來為我做所有事情” –這並不容易,這就是我的觀點。
@akohlsmith:單主機單從I2C應該具有“位爆炸”主機的魯棒性。如果有多個從設備,並且兩個從設備同時以不同的方式被“混淆”,則總線可能無法恢復鎖定(例如,如果兩個或多個填充有零的內存芯片都認為主設備正在嘗試讀取它們,但是它們的位計數器處於不同步狀態,則每個僅在對方聲明時才釋放SDA,除非主機能夠驅動足以使所有從機過載的“高電平”,否則主機無法做任何事情來釋放總線。
supercat
2012-04-02 21:57:55 UTC
view on stackexchange narkive permalink

SPI的運行速度比I2C快得多(某些SPI設備的運行頻率超過60MHz;我不知道“官方” I2C規範是否允許設備超過1MHz)。使用任何一種協議來實現從設備都需要硬件支持,而兩者都可以輕鬆實現“軟件位爆炸”主設備。使用相對最少的硬件,就可以構造一個符合I2C標準的從設備,即使主機可以一次決定在500us的時間內無視總線,而又不需要額外的握手電纜,它也可以正常運行。但是,可靠的SPI操作,即使有硬件支持,也通常要求添加一條握手線,或者要求主機“手動”在每個字節等於從站的最壞情況響應後添加一個延遲。時間。

如果我有德魯特,控制器的SPI支持將包含一些簡單的額外功能,以提供具有握手和喚醒功能的控制器之間的8位透明雙向數據傳輸,總共使用三根單向電線(時鐘和來自主設備的MOSI [master-out-slave-in]; MISO [slave]中的MISO [master-in-slave-out])。相比之下,當帶有“備用” SPI端口的微控制器之間有效而可靠的通信時,兩個處理器都可能被獨立延遲任意長度的時間,則需要使用更多的電線(啟動芯片選擇,時鐘,MISO和MOSI)如果從站可能開始異步發送數據(例如,因為有人按下了按鈕),那麼一個從站必須要么使用另一根線作為“喚醒”信號,要么讓主站反复輪詢從站以查看是否有數據。

I2C並沒有提供我的“改進”的SPI所具有的所有功能,但它確實提供了SPI所缺乏的內置握手功能,並且在許多實現中,即使當I2C喚醒時,它也可能會被喚醒。大師是一個軟件位棒。因此,對於處理器間通信,我強烈建議通過SPI使用I2C,除非需要的速度比SPI所能提供的更高,並且可以使用額外的引腳。對於需要低引腳數的處理器間通信,UART有很多建議。

I2C有一個高速版本,允許1MHz的頻率。正常的I2C為400kHz。
@TheResistance:我知道正常的I2C為400kHz,但版本規定高達1MHz。我不知道是否指定了更快的版本。
根據規範,400kbps(不是kHz,我在這裡使用了錯誤的單位)是快速模式,1Mbps是快速模式Plus,並且有一個高達3.4Mbps的高速模式。超快速可達5Mbps,但是單向的。
@TheResistance:謝謝。我沒有聽說過這些更高版本。 “單向”到底是什麼意思?我知道SPI從機到主機的通信速度可以快於主機到從機,因為可以保證從機在主機之後獲得時鐘,但是我不確定I2C的等效概念。有一個鏈接?
在[此處](http://www.nxp.com/documents/user_manual/UM10204.pdf)查找規範。在第23頁上說,超高速可用於不發回數據(僅寫)甚至不發回數據的設備。
@TheResistance:超快速格式似乎有點奇怪。當我需要推挽式通信以使用最少的導線與CPLD進行通信時,我使用SPI,但如果在時鐘較低時在MOSI上接收到兩個或多個上升沿,則通信接口會重置(通過將MOSI切換為通用來生成I / O)。這種方法幾乎允許使用任何控制器的SPI主控硬件(許多I2C實現不能配置為推挽),並且每個字節之後都不需要額外的時鐘。
PkP
2014-12-17 05:12:54 UTC
view on stackexchange narkive permalink

在這裡的出色答案中已經對這個問題進行了詳盡的探討,但是從芯片製造商的角度來看,I 2 SUP> CI可能還存在另一種觀點。

I 2 SUP> C的電氣接口是開放集電極。現在呼吸,思考其中的含義。使用I 2 SUP> C,我可以設計與總線的工作電壓完全無關的芯片。我需要做的就是將SDA線拉低(如果我願意),然後將SCL和SDA的電壓與一些我可以選擇的接地基準閾值電壓進行比較。而且,如果我不使用常規的高端保護結構並用其他結構替換,我可以製造出完全可以獨立於系統其餘部分使用的芯片-SCL,SDA永遠不會向我的芯片提供電流當然不會向這些引腳提供任何電流。這就是為什麼它對於實時時鐘和諸如此類的其他低功耗設備如此之好。

Adam Haun
2014-12-17 06:03:49 UTC
view on stackexchange narkive permalink

在其他答案中我沒有看到的一件事是I2C在同一總線上支持多個主機。如果您需要雙向通信並且不想使用基於輪詢的方法,則I2C將完成這項工作。

在更長的距離上,CAN具有相同的功能並且更加堅固。但是CAN是一種異步協議,需要硬件支持和收發器,因此在低成本系統中可能不是一個選擇。

好的一點(在多主機上),我還看到了帶有中斷引腳的SPI設備,而一個設備仍然是主機,兩者都可以實例化(雙向)通信。對於遠程設備,當然有更可靠和更好的選擇(例如CAN)。
lansuperman
2017-05-03 22:14:37 UTC
view on stackexchange narkive permalink

使用SPI協議,只要同步時鐘上升,就將位直接寫入設備。xnor邏輯電路可用於匹配內存中的“自製”地址,以選擇所需設備,就好像它是i2c設備一樣。

i2c將授權電路集成到設備的格式中,標準...等複雜而又不同,使用spi,您可以使用spi存儲器在屏幕上顯示視頻,但不能使用i2c。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...