前言

一、

在與RT-Thread BSP的開發者溝通中，發現SPI設備驅動在輪詢（Polling）模式下偶發出現非法訪問異常（如圖）

問題復現場景：

開發者僅需一次單消息傳輸，但未顯式初始化struct rt_spi_message的next指針。

由于next未賦值為RT_NULL，鏈式傳輸時觸發非法內存訪問（next指向不可控地址）。

修復方案 ：將next顯式置空后，異常消失。

借此機會，本文將深入解析RT-Thread SPI驅動的鏈式傳輸機制，并探討BSP對RT-Thread SPI接口的適配特點與優勢。

RT-Thread SPI鏈式傳輸機制解析

二、

1.核心數據結構：struct rt_spi_message

RT-Thread通過struct rt_spi_message描述SPI傳輸操作，支持單條或多條消息鏈式傳輸。

關鍵成員next

1）若為NULL，表示當前為鏈式傳輸的最后一條消息。
2）若非NULL，需確保next指向的rt_spi_message已正確初始化。

3）未初始化next的后果鏈式傳輸時，驅動會嘗試訪問next指向的無效地址，導致非法訪問異常。

在RT-Thread的官方wiki示例可以看到，在定義一個spi message時，需要操作next成員以便確認是否有下一條鏈式傳輸。如果沒有需要賦值為NULL。在RT-Thread的wiki可以看到，在使用rt_spi_transfer_message 傳輸兩條msg，在第二條msg的next賦值為RT_NULL代表結束。

在RT-Thread組件SPI相關也對next進行了操作，并且做了相關注釋說明

先楫BSP適配

三、

那么可能就有開發者問了，為什么別的BSP SPI驅動反而就沒事了，可以在RT-Thread的主線看到，多數廠商（如STM32）的SPI驅動未處理next指針，僅支持單條消息傳輸，但鏈式傳輸時易因next未處理導致傳輸異常。

而先楫BSP的SPI驅動嚴格按照RT-Thread規范實現鏈式傳輸邏輯，強制校驗next指針。支持單條/鏈式傳輸，兼容復雜場景。

先楫BSP對DSPI和QSPI的支持

四、

不同與其他廠家的BSP，把SPI和QSPI分開兩個驅動文件，先楫是集成在SPI驅動中，因為先楫SPI本身就是一個外設，可以支持SPI，DSPI，QSPI三種傳輸模式。

怎么開啟這三種模式，可以通過menuconfig進入到對應的界面進行選擇：分別是單線SPI，兩線DSPI，四線QSPI。

如果想在RT-Thread Studio操作，可以參考下圖：

需要注意的是：當使用四線QSPI時，對應的pinmu.c的SPI初始化需要加上QSPI的D2和D3初始化。

通過list device命令可看到：SPI0為單線SPI，SPI1為雙線DSPI，SPI2為四線QSPI

總結

五、

鏈式傳輸陷阱：未初始化next指針是SPI驅動異常的常見原因，開發者需嚴格遵循RT-Thread規范。

先楫BSP優勢

1. 嚴格適配RT-Thread鏈式傳輸邏輯，避免非法訪問。2. 集成SPI/DSPI/QSPI驅動，簡化開發流程。