1. 引言
客戶反應(yīng)STM32L4R9 同QSPI Flash 通訊,測出來的讀取速率為10MB/s, 和理論值相差較大。
2.問題分析
按照客戶的時鐘配置和STM32L4R9 的數(shù)據(jù)手冊中的數(shù)據(jù),OSPI 讀數(shù)速率為10MB/s肯定存在問題。同時我們也可以在AN4760 應(yīng)用手冊中看到如下說明:
在客戶系統(tǒng)中,IO0~IO3的4線通訊模式下信號波形如下圖,可以看出每經(jīng)過8 個CLK周期就有很長一段時間的延時。如果提高CPU的主頻,這個延時會縮短,但客戶測到最短的延時也有200ns,并且一直存在:
3.問題解決
從客戶測試波形上看,由于是4條數(shù)據(jù)線,因此8個clock正好是4bytes,也就是32bits數(shù)據(jù)。懷疑STM32L4R9 QSPI在DMA通訊中,讀到一個word(32bits)數(shù)據(jù)后需要在內(nèi)部做一定的數(shù)據(jù)處理,造成時間延遲。
分析代碼發(fā)現(xiàn),DMA設(shè)置的是byte傳輸模式,如下面代碼:
#define BUFFERSIZE (COUNTOF(aTxBuffer) - 1)
hdma.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE;
hdma.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE;
STM32L4R9是Cortex-M4 內(nèi)核,系統(tǒng)總線是32bits的,懷疑是在32bit總線上傳輸byte數(shù)據(jù)會降低效率,造成延遲,于是修改代碼如下:
示例代碼在下面路徑,需要使用附件中的main.c文件替換掉下面文件中的main.c:
…STM32Cube_FW_L4_VxxProjects32L4R9IDISCOVERYExamplesOSPIOSPI_NOR_ReadWrite_DMAEWARM
另外程序中做如下改動:
#define BUFFERSIZE 1024 // (COUNTOF(aTxBuffer) - 1)
hdma.Init.PeriphDataAlignment = DMA_PDATAALIGN_WORD;
hdma.Init.MemDataAlignment = DMA_PDATAALIGN_WORD;
配置時請留意OSPIHandle.Init.FifoThreshold = 4; //也需要4的倍數(shù)。
修改代碼后進行測試,代碼讀 4096bytes的圖像(1026 words),發(fā)現(xiàn)每個word數(shù)據(jù)中間的延遲已經(jīng)沒有了。之前速度提不上去的問題是DMA byte設(shè)置引起,因為STM32L4R9是32bits系統(tǒng),使用8bits傳輸會降低效率,需要改為DMA 32bits配置就OK了。圖形數(shù)據(jù)傳輸?shù)目傋止?jié)數(shù)也要設(shè)置為4的倍數(shù),不足的需要補齊。
DMA改為word設(shè)置后數(shù)據(jù)傳輸時沒有延遲
4. 小結(jié)
對32位系統(tǒng)來說,使用byte的數(shù)據(jù)傳輸在一些情況下會降低效率,建議對32bits系統(tǒng)使用32bits的數(shù)據(jù)傳輸方式。
來源:STM32單片機
-
FlaSh
+關(guān)注
關(guān)注
10文章
1614瀏覽量
147655 -
cpu
+關(guān)注
關(guān)注
68文章
10804瀏覽量
210846 -
通訊
+關(guān)注
關(guān)注
9文章
890瀏覽量
34810 -
總線
+關(guān)注
關(guān)注
10文章
2859瀏覽量
87912
發(fā)布評論請先 登錄
相關(guān)推薦
評論