之前分享過的spi通訊例項：stm32硬體spi主從通訊，是基於一塊stm32的兩個spi通訊。本次來分享兩塊stm32之間的spi通訊。
下面簡單分享一下實現過程：
這裡使用stm32f429igt6作為主機，stm32f103zet6作為從機，都配置為全雙工。本例要實現的功能就是主、從機之間的資料互傳。
主機往從機傳送的資料為：
從機往主機傳送的資料為：
主機關鍵**：
從機關鍵**：
可見，主機與從機的**大多都一樣。只是從機多了一步啟動傳輸的操作，這一步很關鍵，少了這一步傳輸就不正常。這是為了製造主機傳送的同時也要接收到資料的條件。這一點參考手冊裡也有相關說明：
此處，要營造這樣的條件，必須先啟動從機，然後再啟動主機。只***主機傳送的同時有接收到資料，才能保證其時序的正常，否則可能會產生資料錯位，或者會產生多餘資料等情況。
我們平時在做實際的開發時，一般很難做到把所有**寫完，跑一遍就能成功，都是需要進行各個子模組的除錯，一步一步來，確保各個子模組都沒有問題之後，整體跑起來自然就比較穩定。
此處，我們要除錯spi主從通訊，自然也是這樣分模組進行除錯的：
若這幾個點明確了，都沒問題之後。就可以明確我們的spi主、從機的基本通訊沒有問題了，之後就可以進行我們的協議方面處理了（本例中沒有這一部分）。下面分別看一些這幾個點：
1、確認主機是否能正確傳送資料
方法：使用邏輯分析儀捕捉主機的mosi、sck這兩條訊號線，檢視其波形。實際測得地結果如下：
其中，白色為sck訊號線波形，橙色為mosi訊號線波形。顯然，從mosi波形可以看出其與我們主機傳送的資料一致，自然就可以確認主機傳送資料沒問題了。
此處，細心的朋友可能會發現時鐘線波形的兩個資料互動處的高電平總是寬一些，這裡我們的spi傳輸資料的位數設定為8bit，則每乙個資料對應的第8位對應的時鐘訊號的高電平總會長一些；若我們的spi傳輸資料的位數配置為16位，則第16位對應的時鐘訊號的高電平總會長一些。
出現這個現象其實與我們的**是有一定關係的。實際測試中發現是因為我們用while迴圈來做邏輯處理的問題，想辦法把while等待替換為if判斷，就可以改善這個問題。但是考慮到這並不會影響我們的資料，並且另一方面還有助於我們分析波形，所以使用while。
2、確認從機是否能正確傳送資料（返回資料給從機）
使用邏輯分析儀來捕捉miso的波形，其波形如下（此處只捕捉了資料波形）：
顯然，我們的從機傳送資料也是沒問題的。
3、確認從機是否接收到主機發過來的資料
顯然，從機收到的資料與主機傳送的資料一致，說明從機接收也是沒有問題的。由於手頭裡只有乙個**器，所以也就沒有同時監測主機的接收buf，監視主機的接收buf與監視從機的方法是一樣的。
1、兩塊板子一定要共地。
2、兩塊板子的mosi與miso不需要交叉連線。
提取碼：ht9j
STM32之間SPI通訊
這幾天實驗室比較忙，所以部落格這邊停了一下，繼續吧。繼串列埠中斷後，大家可以嘗試微控制器間串列埠通訊，這裡就不再多贅述。串列埠完了之後，我接著學的就是spi通訊了，作為hello moto公司推出的這種4線全雙工通訊，很節約pcb布局空間，但缺點就是沒有指定的流控制，沒有應答機制來確定訊號收到與否，...
STM32 硬體SPI主從通訊
本例子基於stm32f103zet6晶元，實現spi1與spi2的主從通訊。其中spi1配置為主機，spi2配置為從機，均配置為全雙工模式。硬體連線圖 其中，我們需要注意的是，spi的從機不能主動傳送資料，只能應答資料。本例子的資料互動過程 主機使用查詢方式傳送資料給從機。從機使用中斷接收方式接收資...
STM32與Arduino串列埠通訊實驗
首先說明一下，arduino使用的編碼方式是utf8，因此stm32的編碼方式也要使用utf8才能傳送漢字成功。然後再說明一下，stm32的串列埠接收協議裡需要接收的資料以0x0d和0x0a結尾，即末尾時 r n,而arduino的串列埠協議不需要任何結尾。stm32的編碼方式設定方式為 confi...