[發明專利]一種基于SPI總線的雙處理器通信方法

有效

• 申請號: 201110387599.5
• 申請日: 2011-11-30
• 公開（公告）號: CN102508812A
• 公開（公告）日: 2012-06-20
• 發明（設計）人: 胡越黎;孫斌;王昆;徐磊;劉廷堯;王龍杰;虞超
• 申請（專利權）人: 上海大學
• 主分類號: G06F15/163
• 分類號: G06F15/163;G06F13/20
• 代理公司: 上海上大專利事務所(普通合伙) 31205
• 代理人: 何文欣

1.一種基于SPI總線的雙處理器通信方法，其特征在于具體操作步驟為：

a．擴展SPI物理層；在SPI的四線制基礎上增加一條接有上拉電阻握手信號線——HandShaking；

b．建立基于SPI總線雙向通信的幀格式；

c．基于SPI總線已經規定的CS信號線和我們新建立的HandShaking握手信號線，建立基于SPI總線雙向通信的同步機制；

d．在發送幀和接收幀格式的基礎上，建立流量控制機制；

e．基于CRC校驗和確認幀校驗，建立錯誤處理機制。

2.根據權利要求1所述的基于SPI總線的雙處理器通信方法，其特征在于所述步驟a的擴展SPI物理層的方法為：

在SPI四線制通信的基礎上，建立五線制用于雙向通信SPI總線，即在SPI的四線制基礎上增加一條接有上拉電阻握手信號線——HandShaking，這是一條從機到主機單向的信號線，HandShaking信號的作用主要是告知主機，從機有數據需要發送。

3.根據權利要求2所述的基于SPI總線的雙處理器通信方法，其特征在于所述步驟b建立基于SPI總線雙向通信幀格式的方法為：

在所述五線制SPI總線基礎上，采用“0比特插入法”，并將(0x7f)作為一個流量控制的標志；作為主從通信方式，幀格式主要包括發送方幀格式和接收方幀格式兩種：

①、發送方幀格式

由于SPI本身可以8位或16位傳輸，并且具有CS選通信號，作為其發送開始與發送結束的標志，所以類似于HDLC的起始和結束標志符(0x7f)可以省略，為了能夠滿足發送方的業務需求，增加了地址、控制和CRC校驗段；

發送方幀格式中的地址是指目的地址；

發送方幀格式中的控制信息包括了功能ID和長度信息，在采用8位傳輸的情況下，功能ID為4bits,而長度信息為4bits;在采用16位傳輸的情況下，功能ID和長度信息均為8bits；

發送方幀格式中的長度信息是指信息段的長度；

②、接收方幀格式

作為接收方而言，為了能夠有效控制數據流，考慮到SPI接收方的特點，針對LINUX操作系統的處理機制，接收方的同步反饋信息為奇數子節時，為接收處理器的緩沖區剩余容量，偶數子節為該處理器前一接收子節是否處理器完標志——確認字符(0x7E)。

4.根據權利要求3所述的基于SPI總線的雙處理器通信方法，其特征在于所述步驟c建立基于SPI總線雙向通信的同步機制的方法如下：

基于SPI主從模式，明建立的總線同步機制分為主機發起通信的同步機制和從機發起通信的同步機制：

①、主機發起通信的同步機制

由主機發起的數據傳送與普通的SPI傳送并沒有區別，也就是說，完全兼容傳統的SPI通信；

②、從機發起通信的同步機制

從機發起的通信由HandShaking信號向主機申請開始發送，主機在接收到HandShaking信號后，開始SPI發送；由于絕大多數MCU的中斷處理以下降沿處理為主，所以，采用了外部上拉，由從機MCU置0的方式；在主機響應中斷后，HandShaking信號由從機的發送結束中斷取消。

5.根據權利要求4所述的基于SPI總線的雙處理器通信方法，其特征在于所述步驟d建立流量控制機制的方法如下：

發送方發送過程中，每兩個Bytes就有一個接收緩沖區剩余容量單元(設該值為????????????????????????????????????????????????)，當接收方回應的接收緩沖區容量小于2()時，則發送方應停止發送.若當前正在發送過程中，則中斷當前幀，對于主機起始發送來說，即將CS信號拉高；對于從機起始發送來說，即將HankShaking信號拉高；發送方等待隨機長時間后，重新嘗試發起發送。

6.根據權利要求5所述的基于SPI總線的雙處理器通信方法，其特征在于所述步驟e建立錯誤處理機制的方法如下：

在本基于SPI總線雙向通信主要有以下兩種錯誤：一是接收方CRC校驗錯誤，二是確認字符錯誤：

①、CRC校驗錯誤

CRC校驗采用16bitCRC校驗碼，其生成多項式采用CCITT?V4.1建議的：；當出現CRC校驗錯誤是，接收方將接收緩沖區剩余容量()置為0，即中止原發送方的繼續發送，然后接收方發起發送，將控制段中的控制ID置為錯誤標識符0xf,即控制段為0xf0.發送的數據幀如下：

②、確認字符錯誤

確認字符錯誤是發送方沒有在偶字節接收到確認字符0X7E，則發送方中斷本次發送，即將主機端CS信號或者從機端HandShaking信號拉高；然后，在隨機時間間隔后重新發起發送。