前面給小伙伴講過串口發(fā)送和接收異常的可能原因,今天我們講下SPI全雙工模式下數(shù)據(jù)接收異常的一個原因。
我們知道,SPI是一主多從的總線結構,主機和哪個從機是通過CS片選來決定的。

我們再來看下SPI的框圖:

除了有發(fā)送緩沖區(qū)和接受緩沖區(qū)外,還有一個移位寄存器,所以當使用SPI發(fā)送最后一個字節(jié)到發(fā)送緩沖區(qū)時,倒數(shù)第二個字節(jié)還在移位寄存器中沒有發(fā)出,此時如果應用程序?qū)臋CCS拉高的話,就會導致從機失效,從而不會發(fā)出正確的數(shù)據(jù)。
那么如何解決呢?
只需要在拉高CS片選前,調(diào)用下面這個語句即可:
while(SET == (spi_i2s_flag_get(SPI0,SPI_FLAG_TRANS)));
這句的意思是等待SPI通訊空閑,對應讀取的標志位是SPI_STAT 寄存器中的bit7位


當該位為0時,就標志著SPI緩沖區(qū)和移位寄存器中都沒有數(shù)據(jù)了,你就可以放心大膽的控制CS片選腳啦。
聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。
舉報投訴
-
單片機
+關注
關注
6078文章
45565瀏覽量
673181 -
嵌入式
+關注
關注
5208文章
20620瀏覽量
336668 -
SPI
+關注
關注
17文章
1897瀏覽量
102061
發(fā)布評論請先 登錄
相關推薦
熱點推薦
esp32-s3全雙工需要兩個iis組合,這樣全雙工模式下兩個iis使用的引腳是否可以配置成一樣呢?
api參考說單個iis只能半雙工,全雙工需要兩個iis組合,這樣全雙工模式下兩個iis使用的引腳
發(fā)表于 06-19 07:58
全雙工與半雙工的區(qū)別 主要是自己學習下
的線序位置上;在半雙工模式下,只需接4根線,參照T568B標準,一般使用1 、2、3、6 線序位置上的四根線,即:白橙、橙、白綠、綠 四根線;白橙、橙 用于發(fā)送數(shù)據(jù) ,白綠、綠 用于
發(fā)表于 12-14 20:59
請問SPI全雙工模式通信中主機與從機之間只接MISO線能夠正常工作嗎?
我的AD采集芯片與STM32之間通過SPI通信,只需STM以中斷的方式讀取AD采集芯片中的數(shù)據(jù),采用的是全雙工模式,但是只接了MISO線和時鐘線,并沒有接MOSI這條線。現(xiàn)在我有個疑問
發(fā)表于 08-13 02:07
STM32的串口在全雙工模式下會出現(xiàn)鎖死問題的現(xiàn)象
之前曾經(jīng)寫過一篇《關于CubeMX的串口全雙工接收發(fā)送鎖死的問題》的文章,討論了STM32的串口在全雙工模式下會出現(xiàn)鎖死問題的現(xiàn)象。當時的解
發(fā)表于 08-16 07:41
api參考說單個iis只能半雙工,全雙工需要兩個iis組合,全雙工模式下兩個iis使用的引腳是否可以配置成一樣呢?
api參考說單個iis只能半雙工,全雙工需要兩個iis組合,這樣全雙工模式下兩個iis使用的引腳
發(fā)表于 02-17 07:56
CH32V103基礎教程50-SPI-全雙工通信,軟件控制NSS模式
本章教程主要在SPI雙線全雙工模式下進行主從收發(fā)實驗,并采用軟件控制NSS方式。 1、SPI簡介及相關函數(shù)介紹關于SPI主從
發(fā)表于 04-25 16:51
CH32V103基礎教程51-SPI-全雙工通信,軟件控制NSS模式
本章教程主要在SPI雙線全雙工模式下進行主從收發(fā)實驗,并采用軟件控制NSS方式。 1、SPI簡介及相關函數(shù)介紹關于SPI主從
發(fā)表于 04-26 16:30
AT32F4xx SPI使用全雙工模式通訊
AT32F4xx SPI使用全雙工模式通訊演示AT32F403Axx SPI使用全雙工模式通訊,其余系列的使用方式與此類似。
發(fā)表于 10-27 07:27
全雙工傳輸,全雙工傳輸原理是什么?
全雙工傳輸,全雙工傳輸原理是什么?
全雙工模式(Full-duplex Transmissions)是指同時發(fā)生在兩個方向上的一種數(shù)據(jù)傳輸
發(fā)表于 03-17 16:22
?4837次閱讀
半雙工和全雙工通信模式的比較
。 首先,半雙工通信模式是指通信雙方之間交換信息的能力僅有一方,無法同時進行發(fā)送和接收操作。而全雙工通信
SPI全雙工模式下數(shù)據(jù)接收異常的一個原因
評論