)
RT-Thread系列學習筆記寫到第五篇這次踩進了SPI驅動框架。剛開始接觸這套框架時我一度被里面各種結構體和回調函數(shù)繞暈總覺得一個簡單的SPI讀寫為什么要包這么多層。直到在某次項目里需要同時掛載Flash、SD卡和一塊LCD屏才發(fā)現(xiàn)這套框架幫你省掉的不僅是重復造輪子還有大量排查片選沖突、時鐘極性錯誤、DMA緩沖對齊這類頭疼問題的時間。這篇文章不打算貼大段源碼——RT-Thread的源碼注釋已經(jīng)寫得夠清楚了我主要想拆解SPI框架這些層級到底為了什么而存在以及你在實際調驅動、寫應用時該在哪個位置下手哪些是常年踩坑的雷區(qū)。1. SPI驅動整體框架拆解為什么RT-Thread要把SPI分這么多層1.1 從一段最樸素的應用代碼說起先看一個常見的使用場景往一塊SPI NOR Flash里寫入一頁數(shù)據(jù)?；赗T-Thread的SPI設備驅動接口典型代碼如下#include rtthread.h #include rtdevice.h #include spi_flash.h static struct rt_spi_device *flash_dev; static int spi_flash_init(void) { struct rt_spi_device *spi_dev (struct rt_spi_device *)rt_malloc(sizeof(struct rt_spi_device)); rt_hw_spi_device_attach(spi1, spi10, GPIOA, GPIO_PIN_4); flash_dev (struct rt_spi_device *)rt_device_find(spi10); if (!flash_dev) { return -RT_ERROR; } return RT_EOK; } INIT_APP_EXPORT(spi_flash_init);從應用視角看你在“spi1”這個總線上注冊了一個名為“spi10”的設備之后通過rt_device_find(spi10)找到它對它執(zhí)行rt_device_read、rt_device_write、rt_device_control就完成了一次SPI通信。但如果你真的只把rt_device_write當SPI收發(fā)用很快會撞上邏輯分析儀顯示出的詭異波形——為什么有的數(shù)據(jù)命令不對為什么CS片選信號在一條消息里被反復拉低拉高這些都是沒理解框架分層導致的。1.2 RT-Thread SPI框架的三層分工RT-Thread的SPI驅動模型本質是一套“總線驅動 核心調度 會話管理”的抽象架構。它可以按下面三個層次來理解第一層物理SPI控制器驅動BSP層。這類驅動直接面向芯片上的SPI外設寄存器負責處理CR1、CR2、DR、SR這些外設寄存器配置引腳、時鐘極性、分頻系數(shù)。RT-Thread里最典型的實現(xiàn)就是drv_spi.c這種BSP文件它最終要做的事情是填充一個struct rt_spi_ops結構體把這個結構體注冊到總線上。第二層SPI核心層。這是整個框架的“調度中心”代碼路徑在components/drivers/spi/spi_core.c。它不直接操作任何芯片寄存器只處理設備注冊、總線申請、片選管理、消息鏈表遍歷等邏輯。你需要重點理解的就兩個接口rt_spi_transfer_message和rt_spi_take_bus。第三層SPI設備會話層。這一層處理“針對某個具體設備發(fā)一次完整事務”的邏輯典型代表是spi_msd.cSD卡、spi_flash.cNOR Flash、spi_wifi.cESP8266等模塊。它們把協(xié)議解析、命令拼裝、等待響應這些邏輯封裝成可復用的設備驅動。這三層對應到整套框架處理流程上就是下面這種關系應用層調用 rt_device_write(spi_dev, 0, buf, len) - 核心層 rt_spi_transfer_message(...) - 構造 rt_spi_message 鏈表 - 申請總線所有權 - 拉低片選 - 調 ops-transfer 執(zhí)行物理收發(fā) - 釋放片選/釋放總線這套分層模型中你平時直接接觸最多的是第一層和第三層。第一層是移植時需要你動手改的第三層是你拿到一款新外設時通常要自己寫的但二者之間的核心層才是保證SPI不出亂子的關鍵。1.3 這套分層替應用層解決了什么難題有人會問單片機裸機時直接往寄存器里扔數(shù)據(jù)也一樣能用為什么要引入這么多層我給你列一個實際會踩到的場景板子上有一片SPI Flash和一張SPI接口的SD卡兩者掛在同一條SPI總線的不同片選引腳上。裸機開發(fā)時你需要在應用層自己維護“當前總線屬于誰”這個狀態(tài)。讀Flash時要把片選切到Flash讀完切回來再操作SD卡前又得確保上一次會話徹底結束。如果應用層的兩個線程同時操作Flash和SD卡第一個線程讀Flash讀到一半第二個線程把片選切到了SD卡——波形直接亂掉數(shù)據(jù)全錯。RT-Thread核心層引入了一個“虛擬所有權”概念rt_spi_take_bus會先獲得總線所有權其他設備的消息只能排隊等待拿到總線所有權后rt_spi_take_cs只會拉低目標設備的片選。這樣的設計天然保證了總線上同時只存在一個“說話者”?；谶@個機制你在應用層根本不用關心總線沖突上層代碼只需要用標準的rt_device_write把請求丟出去剩下的會話調度由核心層處理。2. 關鍵數(shù)據(jù)結構與接口解析這些結構體背后鎖定了什么資源2.1 struct spi_device一個外設在框架中的存在形態(tài)這個結構體定義在rtdef.h中的struct rt_spi_device但更關鍵的是它內部的配置指針struct rt_spi_device { struct rt_device parent; struct rt_spi_bus *bus; struct rt_spi_configuration *config; void *user_data; };這里最值得關注的是bus和config兩個成員。bus指向這個設備掛在哪條總線上這意味著一個SPI設備的“身份”由它所屬的總線決定而不是由硬件片選引腳決定。這樣的設計讓“總線分離”變得非常簡單——同一條SPI總線上可以掛多個設備它們共用同一套物理外設只是各自維護自己的配置參數(shù)。config則指向一個rt_spi_configuration里面保存了該設備的參數(shù)模式、位寬、最大頻率、保留字節(jié)。這個指針在設備注冊時會被綁定。它解決問題的方式很巧妙同一條總線上掛Flash和SD卡時Flash可能需要Mode 0SD卡可能需要Mode 3兩者頻率也不一樣。每次切換設備時核心層會比較新設備所需的配置與當前總線上實際配置是否一致若不一致則調用ops-configure重新配置硬件。這套機制讓你不需要在切換設備時手動去改寄存器——框架全做了。2.2 struct rt_spi_configuration四個字段四個坑struct rt_spi_configuration { rt_uint8_t mode; rt_uint8_t data_width; rt_uint16_t reserved; rt_uint32_t max_hz; };mode這個字段是最容易看錯、又最隱蔽的。它其實不是只存一個數(shù)字而是把多項參數(shù)按位組合在一起常見的取值包括#define RT_SPI_CPHA (10) /* clock phase */ #define RT_SPI_CPOL (11) /* clock polarity */ #define RT_SPI_MSB (02) /* MSB First */ #define RT_SPI_LSB (12) /* LSB First */ #define RT_SPI_3WIRE (13) /* SI/SO pin shared */ #define RT_SPI_MASTER (04) /* master role */ #define RT_SPI_SLAVE (14) /* slave role */所以一個SPI設備最常用的“模式0”實際上對應RT_SPI_CPHA | RT_SPI_CPOL這一組合也就是讓時鐘空閑時為低、數(shù)據(jù)在第一個上升沿采樣。另一個容易讓人栽跟頭的坑是RT_SPI_MSB和RT_SPI_LSB它的值為0意味著你如果直接把模式變量和0做“或”運算MSB其實是默認選擇不會改變數(shù)值。這可能讓很多人誤以為“我沒有設置MSB/LSB”實際上框架已經(jīng)把MSB作為默認值了。這一點在與某些特殊外設對接時很重要——如果對端期望LSB先傳必須顯式把RT_SPI_LSB寫進mode里。max_hz則是設備的最高通信速率。注意它不是實際頻率而是一個上限值?？偩€驅動在初始化時會根據(jù)這個值去計算分頻系數(shù)實際頻率不高于它即可。我曾經(jīng)遇到一個奇怪現(xiàn)象一塊LCD屏明明支持36MHz時鐘但接到某個板子上跑到18MHz就花屏最后定位發(fā)現(xiàn)是PCB走線太長、干擾嚴重。從框架層面看只需調低max_hz就能解決問題——這個字段的設計本身就是給你這種場景做限速用的。data_width一般填88位極少數(shù)設備用16位或32位模式。RT-Thread官方目前對非8位模式的支持在部分BSP里還不夠完善所以如果你要接一個12位或16位并行的屏最好先確認當前BSP的SPI驅動是否支持非8位模式否則就需要在ops-transfer里面自己拼字節(jié)。2.3 struct rt_spi_ops底層驅動的“能力表”struct rt_spi_ops { rt_err_t (*configure)(struct rt_spi_device *device, struct rt_spi_configuration *configuration); rt_uint32_t (*xfer)(struct rt_spi_device *device, struct rt_spi_message *message); };這套回調接口非常簡單只有兩個函數(shù)指針。configure負責根據(jù)配置重新初始化SPI外設設置時鐘極性、數(shù)據(jù)位寬、預分頻。xfer負責真正發(fā)出一幀數(shù)據(jù)返回實際發(fā)送的字節(jié)數(shù)。我見過不少驅動移植者在這兩個函數(shù)上踩坑其中比較典型的情況是只實現(xiàn)了xferconfigure里什么都不做。你在調試時可能發(fā)現(xiàn)第一幀數(shù)據(jù)正常、第二幀數(shù)據(jù)就亂了。原因很簡單——如果configure不生效RT-Thread核心層在比較新舊配置不同后卻得不到硬件層面的真正重新配置。例如總線上掛著Flash和SD卡。Flash要求模式0SD卡要求模式3。程序先操作Flash一切正常再操作SD卡時核心層發(fā)現(xiàn)mode變了于是調ops-configure但你的configure是空函數(shù)底層SPI外設寄存器還保持著模式0的配置。于是SD卡收到波形完全錯誤。這種情況是最難排查的因為單純看代碼邏輯似乎沒有問題只能靠邏輯分析儀抓波形才能發(fā)現(xiàn)。2.4 struct rt_spi_message一次會話中的最小事務單元struct rt_spi_message { const void *send_buf; void *recv_buf; rt_size_t length; struct rt_spi_message *next; unsigned int cs_take : 1; unsigned int cs_release : 1; unsigned int reserved : 30; };這是整個SPI框架中最重要的數(shù)據(jù)結構。它的設計思想是一次rt_spi_transfer_message調用可以攜帶一串消息linked list of messages這串消息作為一個整體被傳輸中途不會釋放片選。send_buf和recv_buf分別指向發(fā)送緩沖區(qū)和接收緩沖區(qū)。當只發(fā)不收時recv_buf可以填RT_NULL驅動程序會自動丟棄讀到的數(shù)據(jù)。當只收不發(fā)時send_buf填RT_NULL驅動會發(fā)送全0或全1的填充字節(jié)具體看BSP實現(xiàn)。最容易被忽略的是cs_take和cs_release這兩個位域。它們控制這次消息是否需要拉低片選和釋放片選。你可能會想為什么不每次都把片選拉低再釋放因為有些外設的操作是一個“復合事務”——例如W25Q系列Flash的讀操作需要先發(fā)命令字節(jié)地址字節(jié)然后連續(xù)讀數(shù)據(jù)。如果每發(fā)一個字節(jié)就拉一次片選Flash根本不會進入讀狀態(tài)讀回來的永遠是亂碼。正確做法是struct rt_spi_message msg1 { .send_buf cmd, .recv_buf RT_NULL, .length 1, .cs_take 1, .cs_release 0 }; struct rt_spi_message msg2 { .send_buf addr, .recv_buf RT_NULL, .length 3, .cs_take 0, .cs_release 0 }; struct rt_spi_message msg3 { .send_buf RT_NULL, .recv_buf buf, .length len, .cs_take 0, .cs_release 1 }; msg1.next msg2; msg2.next msg3; msg3.next RT_NULL; rt_spi_transfer_message(spi_dev, msg1);這樣整個過程片選只拉低一次命令、地址、數(shù)據(jù)作為一個整體被發(fā)出去。理解了這個機制芯片手冊上凡是“CS must stay low during the entire instruction sequence”的約束你都能在框架中找到對應的實現(xiàn)方式。3. 消息傳輸流程與片選控制從線程安全到復合時序的細節(jié)把控3.1 rt_spi_transfer_message 的完整執(zhí)行鏈路rt_spi_transfer_message大概是你在核心層唯一需要仔細讀一遍的函數(shù)我建議你打開源碼把它的邏輯走一遍調用rt_spi_take_bus等待并獲取總線所有權。遍歷消息鏈表中的每一個rt_spi_message。若cs_take為1則調rt_spi_take_cs拉低片選。調用ops-xfer執(zhí)行物理收發(fā)。若cs_release為1則調rt_spi_release_cs釋放片選。全部消息處理完畢后調用rt_spi_release_bus釋放總線。注意核心層不會在消息之間自動拉低或釋放片選它完全依賴cs_take和cs_release兩個標志位。如果你在一個消息鏈表里設置了第一條cs_take1、最后一條cs_release1中間幾條都不設置那么片選在整個鏈表中從頭到尾都是低電平。這套機制還會自動處理配置切換。在遍歷消息鏈表之前核心層會比較當前總線上綁定設備的配置與待處理設備的配置是否一致。如果不一致它會調用ops-configure先重新配置再開始發(fā)送。所以你在同一條總線上交替訪問Flash和SD卡時可以不必擔心模式混用。3.2 為什么先拿總線再拉片選防搶戰(zhàn)的多線程思維這個順序不是拍腦袋定的它解決的是一個非常具體的并發(fā)問題。假設總線上同時掛了兩張SPI Flash分別用PA4和PA5做片選。線程A正在操作Flash1拉了PA4準備發(fā)一長串數(shù)據(jù)。此時線程B被調度它需要操作Flash2它拉了PA5也在發(fā)數(shù)據(jù)。但底層SPI外設只有一個兩個線程的數(shù)據(jù)會交疊混發(fā)雙方的結果全錯。RT-Thread的設計是SPI總線上有一個“所有者”概念bus-owner字段。rt_spi_take_bus會用互斥鎖保護這個字段誰拿到所有權誰才能操作物理外設rt_spi_take_cs則確保只有當前所有者才能拉片選。線程B在拿不到所有權時會被掛起休眠直到線程A發(fā)送完畢、釋放總線。所以我的建議是在應用中永遠不要直接寫片選引腳也不要直接調用底層BSP的xfer函數(shù)。一切訪問都走rt_spi_transfer_message或設備驅動接口不然多線程環(huán)境下的SPI總線一定會在你最忙的時候出亂子。3.3 硬件片選與軟件片選的本質差異及選擇關于SPI片選RT-Thread的BSP通常支持兩種方案硬件片選由芯片SPI外設內部的NSS邏輯自動控制。你只需配置GPIO復用功能發(fā)送數(shù)據(jù)時外設自動拉低片選發(fā)完自動拉高。軟件片選由普通GPIO手動拉高拉低通常在rt_spi_take_cs和rt_spi_release_cs里實現(xiàn)。兩種方案在RT-Thread里差別很明顯對比項硬件片選軟件片選CPU負擔低外設自動控制高每個事務都要GPIO寫入時序精度高由硬件保證時序關系低受中斷和調度影響復合事務較難實現(xiàn)連續(xù)片選往往需要特殊寄存器配置方便CS的拉低和拉高完全由軟件控制多設備支持可能需要多個NSS引腳部分MCU只有一個NSS任意GPIO均可擴展靈活誤操作風險某些時序下可能提前釋放片選完全可控只要代碼沒寫錯實戰(zhàn)中只要不是追求極限速率我通常偏向軟件片選。原因很簡單靈活度高遇到復合事務也好處理。尤其你還要用RT-Thread這類RTOS中斷優(yōu)先級變化可能導致響應稍有波動但軟件片選通過操作GPIO寄存器來控制實際誤差在微秒級以內對絕大多數(shù)外設完全夠用。不過要注意一點用軟件片選時必須確保GPIO配置為推挽輸出且初始狀態(tài)為高電平。這聽起來是基礎常識但很多新人在用STM32CubeMX自動生成初始化代碼后又手動改了引腳復用功能導致初始化順序不對片選腳一直輸出低電平結果總線上所有設備都處于選通狀態(tài)出現(xiàn)兩臺設備同時搶應答的靈異現(xiàn)象。3.4 DMA配合SPI時的消息構造技巧SPI外設加DMA是提升吞吐率的常見組合。RT-Thread消息結構體的send_buf和recv_buf本身不限制緩沖區(qū)來源所以在使用DMA時一個容易忽略的約束是緩沖區(qū)對齊和內存屬性。如果你的MCU帶D-Cache且緩沖區(qū)定義在可緩存內存區(qū)域發(fā)送和接收時可能出現(xiàn)緩存一致性問題CPU往DMA緩沖區(qū)寫了命令字但DMA讀到的還是Cache里的舊數(shù)據(jù)。這是嵌入式開發(fā)中比較隱蔽的坑常見征兆是單獨調試SPI正常加進RT-Thread后第一次讀數(shù)據(jù)正常后續(xù)讀出來的全是上一次的殘影。解決思路有下面幾種為DMA緩沖區(qū)單獨分配在非緩存內存比如STM32的__attribute__((section(.noncached)))。收發(fā)前后手動調用rt_hw_cpu_dcache_ops做cache清理和無效化。使用RT-Thread提供的rt_dma_alloc等接口統(tǒng)一從DMA安全內存池分配緩沖區(qū)。另外DMA模式下recv_buf不能隨便傳RT_NULL。若你只想發(fā)送且不關心接收請把recv_buf指向一個真實的接收緩沖區(qū)哪怕這個緩沖區(qū)不大避免DMA寫空指針導致HardFault。4. 從設備模式SPI Slave驅動要點方向反過來的玩法4.1 RT-Thread如何描述一個SPI從設備SPI這個總線有個特點它天生就是一主多從的結構。但有些應用場景下你的設備需要被別人當外設訪問——比如板子作為某個主控的協(xié)處理器主控通過SPI向你的板子下發(fā)命令。這種場景下你需要使用RT-Thread的SPI從設備框架。RT-Thread提供了一組從設備模式相關接口rt_err_t rt_spi_slave_register(struct rt_spi_bus *bus, const char *name, rt_spi_slave_cb_t cb, void *user_data); rt_err_t rt_spi_slave_config(struct rt_spi_device *device, struct rt_spi_configuration *config); rt_err_t rt_spi_slave_send(struct rt_spi_device *device, const void *buf, rt_size_t len);從設備模式下你不能主動發(fā)起傳輸只能提前準備好接收緩沖區(qū)等待主控來“拉”數(shù)據(jù)。這與主設備模式在編程模型上是完全不同的。RT-Thread的從設備框架用rt_spi_slave_send把數(shù)據(jù)準備好然后等待外部主控發(fā)起SPI時鐘數(shù)據(jù)才被真正移出。4.2 從設備回調機制與數(shù)據(jù)就緒通知當你作為從設備時寄存器層面的收發(fā)邏輯往往依賴硬件中斷。每一個SPI字節(jié)到達都會觸發(fā)一次接收中斷由BSP驅動把數(shù)據(jù)讀入FIFO或DMA緩沖區(qū)。RT-Thread從設備框架提供回調函數(shù)通常是某次完整事務結束時核心層調用回調通知應用層“數(shù)據(jù)已經(jīng)準備好了”。static rt_err_t spi_slave_callback(struct rt_spi_slave_device *device, const void *send_buf, void *recv_buf, rt_size_t len, void *user_data) { /* 在這里處理收到的數(shù)據(jù) */ return RT_EOK; }實際開發(fā)中這個回調函數(shù)里盡量只做“搬運”工作——比如把recv_buf拷貝到應用緩沖區(qū)或者設置一個事件標志喚醒應用線程。不要在這里做耗時處理比如解析JSON或寫Flash這會直接影響下一次SPI事務的響應速度。主控端可能只等了幾個微秒就再次發(fā)起傳輸你回調還沒跑完數(shù)據(jù)就丟了。4.3 主從設備同總線復用時的注意事項如果你在一個芯片上既想當SPI主設備讀外設又想當SPI從設備被外部主控訪問這是可以做到的但要注意引腳模式的切換。例如一個典型的處理方式是平時配置成SPI主模式外部主控通過一個GPIO電平變化觸發(fā)你切換到從模式。你在切換模式時需要重新初始化整個SPI外設并把引腳復用從主設備模式切到從設備模式。這個過程中框架層面的ops-configure就會反復被調用所以你的configure實現(xiàn)必須足夠健壯能處理運行時的反復切換。我在一次產(chǎn)測工具開發(fā)中就是讓板子既能自動掃描總線上兩塊Flash又能把整塊板子虛擬成一個SPI從設備供產(chǎn)測上位機讀寫。當時的實現(xiàn)方式是默認進入從設備模式收到產(chǎn)測上位機的“切換主模式”命令后重新執(zhí)行ops-configure把外設切成主模式之后就可以正常枚舉Flash了。這個功能完全建立在RT-Thread這套可重入的configure機制上——如果你在configure里只做一次性初始化、不做運行時重置那這套方案就完全失效了。5. 常見問題排查與調試技巧用邏輯分析儀和時間線思維抓SPI問題5.1 典型報錯與故障速查表下面整理了幾種我在使用RT-Thread SPI框架時遇到的問題。許多問題都不在框架本身而是外部因素但癥狀往往先從框架層表現(xiàn)出來。癥狀可能原因解決方案rt_spi_take_bus超時返回錯誤另一個線程長時間占用總線或中斷里占用了總線檢查是否在中斷里直接調用了SPI設備接口可臨時增大獲取總線超時時間讀回數(shù)據(jù)全為0xFFSPI模式配置錯誤CPOL/CPHA不匹配設備不在位片選沒拉低先用邏輯分析儀抓波形再核對設備手冊要求的模式讀回數(shù)據(jù)全為0x00極性配置或從設備未準備發(fā)送DMA緩沖區(qū)未正確初始化查看是否有數(shù)據(jù)從MOSI發(fā)出來發(fā)送數(shù)據(jù)對但命令無響應復合事務中片選被反復拉低檢查消息鏈表里cs_take和cs_release是否只在首尾設置第一次讀寫正常之后全錯上電后設備初始化時序未對齊Flash需要等待WIP清除在設備驅動中加狀態(tài)輪詢核對設備上電時序同總線多設備互相干擾軟件片選GPIO初始狀態(tài)為低或某設備發(fā)送時未正確拉高其他設備片選初始化階段把所有片選腳置高確認消息里cs_release確實觸發(fā)DMA模式讀到舊數(shù)據(jù)D-Cache未刷出或未無效化分配非緩存內存收發(fā)前后做cache維護5.2 一次SPI Flash驅動“寫進去讀不出”的完整排查我分享一個真實案例某塊開發(fā)板SPI Flash能讀到JEDEC ID和狀態(tài)寄存器說明讀命令和時序都正常但就是寫入后讀出來全是“0xFF”。排查過程是這樣的第一步檢查Flash是否真的處于寫使能狀態(tài)。用邏輯分析儀抓寫使能0x06命令時序波形顯示片選正常、時鐘正常但命令發(fā)出后沒有等待狀態(tài)寄存器中的WIP位清零。這會導致后續(xù)頁編程命令進來時Flash還在忙于上一次操作直接忽略新命令。第二步修改驅動代碼在寫使能后輪詢狀態(tài)寄存器確保WIP清零后再發(fā)送頁編程命令。這里建議用消息鏈表把“寫命令地址數(shù)據(jù)”串起來保持片選在整個寫周期低位。結果還是失敗。第三步仔細對比波形后發(fā)現(xiàn)頁編程命令后Flash返回的狀態(tài)值一直是0x00但數(shù)據(jù)引腳在讀取狀態(tài)時變成了高阻態(tài)。排查到這一步方向轉向硬件電氣特性板子上Flash的DO引腳與SD卡分線器共用而分線器的上拉電阻選擇了10k——不夠強。SPI速度較高時線路電容導致信號建立不完整。更換更小阻值的上拉電阻后問題徹底解決。這輪排查的經(jīng)驗是SPI問題優(yōu)先抓波形再改代碼。邏輯分析儀能看到片選、時鐘、數(shù)據(jù)三者的相對時序比打日志高效得多。尤其在RT-Thread這類多線程環(huán)境下打日志會引入額外調度延遲可能掩蓋真實時序問題。5.3 調試SPI消息鏈表的有效手段構造測試消息如果你懷疑是RT-Thread核心層在處理消息鏈表時出了問題這兩種情形比較少見但值得確認可以直接在應用層構造一組短消息做最小復現(xiàn)。static struct rt_spi_message test_msg; static rt_uint8_t send_data[4] {0xAA, 0x55, 0xAA, 0x55}; static rt_uint8_t recv_data[4] {0}; void spi_debug_loopback(void) { test_msg.send_buf send_data; test_msg.recv_buf recv_data; test_msg.length sizeof(send_data); test_msg.cs_take 1; test_msg.cs_release 1; test_msg.next RT_NULL; rt_spi_transfer_message(spi_dev, test_msg); }如果數(shù)據(jù)在主控側自發(fā)自收后能正確回讀說明物理鏈路和核心調度基本沒問題。接下來再逐步拆成多條消息驗證cs_take/cs_release的組合是否正確。這種“分而治之”的方式很快能定位到具體是哪一類消息組合導致片選異常。5.4 借助RT-Thread FinSH命令快速驗證SPI設備RT-Thread的FinSH控制臺很適合做SPI驅動基調。比如你已經(jīng)注冊好了“spi10”這個設備可以直接在FinSH里執(zhí)行msh spi loop spi10 0x9F 3這個命令會往spi10發(fā)送一字節(jié)0x9F并讀回3字節(jié)。如果讀回的值符合你預期就說明整條設備鏈路已經(jīng)打通如果讀不到就能排除大量上層邏輯集中精力檢查物理連接和初始化順序。在BSP里往往也提供list_device、list_spi這類命令能快速查看哪些SPI設備注冊成功、當前配置如何。這是我最常用的初始調試手段先確認設備注冊再測回環(huán)再做協(xié)議調試。6. 基于框架寫好自己的設備驅動從零到可復用的實踐路徑6.1 驅動代碼應該放在哪一層很多新手拿到一個SPI外設第一反應是在應用層堆一個讀寫函數(shù)到處調用。這在臨時驗證功能時可行但從可維護性角度不推薦。建議的做法是把設備驅動做成一個獨立文件然后通過設備注冊機制掛到設備框架里。以某個SPI DAC為例正確的組織方式是寫一個spi_dac.c實現(xiàn)dac_write_value(struct rt_spi_device *dev, rt_uint16_t value)這樣的基礎接口。對外暴露rt_device_write風格的讀寫接口讓上層應用不感知SPI的存在。在初始化線程里調用rt_hw_spi_device_attach掛載設備再調用注冊函數(shù)完成設備對象注冊。這樣后續(xù)如果換用I2C版本的DAC只需要替換底層驅動文件應用層代碼一行都不用改。設備框架的意義就在于此。6.2 不自帶SPI控制器的芯片怎么接SPI外設討論一個延伸問題有些MCU沒有硬件SPI外設或用完硬件SPI后仍有多余外設要接這時候可以用GPIO模擬SPI。RT-Thread的框架能不能支持這種答案是能但需要在ops-xfer內部自己翻轉GPIO。這種模擬SPI的驅動實現(xiàn)本質上和硬件SPI驅動的接口形式一致static rt_uint32_t soft_spi_xfer(struct rt_spi_device *device, struct rt_spi_message *message) { /* 在這里用GPIO模擬SCK、MOSI和MISO */ return message-length; } static struct rt_spi_ops soft_spi_ops { .configure RT_NULL, .xfer soft_spi_xfer, };唯一的區(qū)別是configure多半不需要實現(xiàn)因為根本沒有外設寄存器可配置。發(fā)送時自行檢查message-send_buf是否為空決定是否從MOSI移出數(shù)據(jù)檢查message-recv_buf是否為空決定是否從MISO采樣。這里的性能瓶頸在于GPIO翻轉速度比較慢通常只能做到幾百kHz到1MHz左右但接一些不追求高速的外設傳感器、EEPROM、LCD初始化配置完全夠用。6.3 驅動健壯性消息合法性校驗與失敗重試我見過的不少驅動在ops-xfer里基本不做入?yún)⑿ｒ?。偶爾嘴瓢傳了個空指針或者長度算錯整個系統(tǒng)就掛掉了。在RT-Thread消息結構里send_buf和recv_buf同時為RT_NULL時沒有任何數(shù)據(jù)可傳輸應該直接返回錯誤長度為零也同理。if (message-length 0) { return 0; } if (message-send_buf RT_NULL message-recv_buf RT_NULL) { return 0; }這些看似無用的校驗在實際項目中可以省掉很多半夜調bug的痛苦。還要考慮通信失敗后的處理策略。SPI本身沒有ACK機制寫命令發(fā)出后是否成功一般取決于從設備的內部狀態(tài)。所以在設備驅動里加狀態(tài)確認通常很有必要——比如SD卡命令后要讀響應Flash寫命令后要輪詢狀態(tài)寄存器LCD顯存寫完可以讀回驗證。這些協(xié)議級的可靠性措施不能只依賴底層框架。6.4 性能優(yōu)化單次傳輸長度與合并傳輸SPI吞吐率往往取決于事務的拆分粒度。一次rt_spi_transfer_message傳入的消息越少、單條消息越長線程切換和總線占用開銷越小。舉例來說如果要把一個Flash固件分區(qū)全部讀回做校驗最直接的方式是循環(huán)調用rt_spi_read每次讀4KB。這個循環(huán)每執(zhí)行一次都要獲取總線、釋放總線。更好的做法是一次申請一個大緩沖區(qū)用一條長的消息把整個分區(qū)連續(xù)讀回。這樣SPI總線只被占用一次DMA也能把整塊數(shù)據(jù)搬完。但大緩沖區(qū)又涉及內存分配問題——你不可能無限制地申請大塊連續(xù)RAM。此時可以把消息鏈表用起來分配多塊較小的緩沖區(qū)通過next指針串成一個鏈表每塊緩沖區(qū)對應一條消息。它們在核心層可以被連續(xù)傳輸片選保持低位而內存壓力則被簡化到每塊緩沖區(qū)都比較小。這個技巧在讀寫大容量NAND Flash或長時間連續(xù)采樣時非常管用。7. 經(jīng)驗總結與未來擴展RT-Thread的SPI驅動框架最大的價值不是幫你少寫幾行寄存器操作而是幫你建立了一套“總線資源調度”的思維模型。縱觀整個框架核心層像個交通警察負責分配通行權BSP驅動是路口信號燈控制實際信號設備驅動是每輛車的駕駛員按既定路線行駛。應用層只需要說“我要到某個地方去”完全不用關心中間經(jīng)過哪些路口。實際操作中我個人的體會是剛上手時先不要急著看源碼和結構體。拿一塊Flash或傳感器用框架自帶接口先調通一版回環(huán)再回頭讀核心代碼理解會快很多。源碼本身寫得相對直白但如果沒有實際調試經(jīng)驗打底光看代碼容易陷入“每個字都認識整體不知道在講什么”的狀態(tài)。后續(xù)如果你的項目涉及更高性能需求可以留意RT-Thread在SPI框架里的兩部分擴展方向使用RT_SPI_CPHA/CPOL之外的自定義位配合外設的特殊時序要求做精細化控制。將DMA和SPI框架更深地綁定比如為struct rt_spi_message擴展發(fā)送完成回調這樣才能精確掌握DMA完成時機做更高層次的協(xié)議狀態(tài)機。另外如果同一個項目中需要兼容SPI Flash、SPI屏幕、SPI傳感器這幾種不同特性的外設建議在設備驅動的外層再抽象一層統(tǒng)一接口。這樣應用層永遠只面對一個“讀寫寄存器”或“讀一頁數(shù)據(jù)”的操作而底層可能用SPI、I2C甚至UART來實現(xiàn)你會驚喜地發(fā)現(xiàn)代碼復用率可以變得非常高。這算是從“會用SPI框架”邁向“設計良好驅動層”比較有價值的一步。 RT-Thread SPI驅動框架解析：從分層原理到調試實戰(zhàn)
RT-Thread系列學習筆記寫到第五篇這次踩進了SPI驅動框架。剛開始接觸這套框架時我一度被里面各種結構體和回調函數(shù)繞暈總覺得一個簡單的SPI讀寫為什么要包這么多層。直到在某次項目里需要同時掛載Flash、SD卡和一塊LCD屏才發(fā)現(xiàn)這套框架幫你省掉的不僅是重復造輪子還有大量排查片選沖突、時鐘極性錯誤、DMA緩沖對齊這類頭疼問題的時間。這篇文章不打算貼大段源碼——RT-Thread的源碼注釋已經(jīng)寫得夠清楚了我主要想拆解SPI框架這些層級到底為了什么而存在以及你在實際調驅動、寫應用時該在哪個位置下手哪些是常年踩坑的雷區(qū)。1. SPI驅動整體框架拆解為什么RT-Thread要把SPI分這么多層1.1 從一段最樸素的應用代碼說起先看一個常見的使用場景往一塊SPI NOR Flash里寫入一頁數(shù)據(jù)?；赗T-Thread的SPI設備驅動接口典型代碼如下#include rtthread.h #include rtdevice.h #include spi_flash.h static struct rt_spi_device *flash_dev; static int spi_flash_init(void) { struct rt_spi_device *spi_dev (struct rt_spi_device *)rt_malloc(sizeof(struct rt_spi_device)); rt_hw_spi_device_attach(spi1, spi10, GPIOA, GPIO_PIN_4); flash_dev (struct rt_spi_device *)rt_device_find(spi10); if (!flash_dev) { return -RT_ERROR; } return RT_EOK; } INIT_APP_EXPORT(spi_flash_init);從應用視角看你在“spi1”這個總線上注冊了一個名為“spi10”的設備之后通過rt_device_find(spi10)找到它對它執(zhí)行rt_device_read、rt_device_write、rt_device_control就完成了一次SPI通信。但如果你真的只把rt_device_write當SPI收發(fā)用很快會撞上邏輯分析儀顯示出的詭異波形——為什么有的數(shù)據(jù)命令不對為什么CS片選信號在一條消息里被反復拉低拉高這些都是沒理解框架分層導致的。1.2 RT-Thread SPI框架的三層分工RT-Thread的SPI驅動模型本質是一套“總線驅動 核心調度 會話管理”的抽象架構。它可以按下面三個層次來理解第一層物理SPI控制器驅動BSP層。這類驅動直接面向芯片上的SPI外設寄存器負責處理CR1、CR2、DR、SR這些外設寄存器配置引腳、時鐘極性、分頻系數(shù)。RT-Thread里最典型的實現(xiàn)就是drv_spi.c這種BSP文件它最終要做的事情是填充一個struct rt_spi_ops結構體把這個結構體注冊到總線上。第二層SPI核心層。這是整個框架的“調度中心”代碼路徑在components/drivers/spi/spi_core.c。它不直接操作任何芯片寄存器只處理設備注冊、總線申請、片選管理、消息鏈表遍歷等邏輯。你需要重點理解的就兩個接口rt_spi_transfer_message和rt_spi_take_bus。第三層SPI設備會話層。這一層處理“針對某個具體設備發(fā)一次完整事務”的邏輯典型代表是spi_msd.cSD卡、spi_flash.cNOR Flash、spi_wifi.cESP8266等模塊。它們把協(xié)議解析、命令拼裝、等待響應這些邏輯封裝成可復用的設備驅動。這三層對應到整套框架處理流程上就是下面這種關系應用層調用 rt_device_write(spi_dev, 0, buf, len) - 核心層 rt_spi_transfer_message(...) - 構造 rt_spi_message 鏈表 - 申請總線所有權 - 拉低片選 - 調 ops-transfer 執(zhí)行物理收發(fā) - 釋放片選/釋放總線這套分層模型中你平時直接接觸最多的是第一層和第三層。第一層是移植時需要你動手改的第三層是你拿到一款新外設時通常要自己寫的但二者之間的核心層才是保證SPI不出亂子的關鍵。1.3 這套分層替應用層解決了什么難題有人會問單片機裸機時直接往寄存器里扔數(shù)據(jù)也一樣能用為什么要引入這么多層我給你列一個實際會踩到的場景板子上有一片SPI Flash和一張SPI接口的SD卡兩者掛在同一條SPI總線的不同片選引腳上。裸機開發(fā)時你需要在應用層自己維護“當前總線屬于誰”這個狀態(tài)。讀Flash時要把片選切到Flash讀完切回來再操作SD卡前又得確保上一次會話徹底結束。如果應用層的兩個線程同時操作Flash和SD卡第一個線程讀Flash讀到一半第二個線程把片選切到了SD卡——波形直接亂掉數(shù)據(jù)全錯。RT-Thread核心層引入了一個“虛擬所有權”概念rt_spi_take_bus會先獲得總線所有權其他設備的消息只能排隊等待拿到總線所有權后rt_spi_take_cs只會拉低目標設備的片選。這樣的設計天然保證了總線上同時只存在一個“說話者”?；谶@個機制你在應用層根本不用關心總線沖突上層代碼只需要用標準的rt_device_write把請求丟出去剩下的會話調度由核心層處理。2. 關鍵數(shù)據(jù)結構與接口解析這些結構體背后鎖定了什么資源2.1 struct spi_device一個外設在框架中的存在形態(tài)這個結構體定義在rtdef.h中的struct rt_spi_device但更關鍵的是它內部的配置指針struct rt_spi_device { struct rt_device parent; struct rt_spi_bus *bus; struct rt_spi_configuration *config; void *user_data; };這里最值得關注的是bus和config兩個成員。bus指向這個設備掛在哪條總線上這意味著一個SPI設備的“身份”由它所屬的總線決定而不是由硬件片選引腳決定。這樣的設計讓“總線分離”變得非常簡單——同一條SPI總線上可以掛多個設備它們共用同一套物理外設只是各自維護自己的配置參數(shù)。config則指向一個rt_spi_configuration里面保存了該設備的參數(shù)模式、位寬、最大頻率、保留字節(jié)。這個指針在設備注冊時會被綁定。它解決問題的方式很巧妙同一條總線上掛Flash和SD卡時Flash可能需要Mode 0SD卡可能需要Mode 3兩者頻率也不一樣。每次切換設備時核心層會比較新設備所需的配置與當前總線上實際配置是否一致若不一致則調用ops-configure重新配置硬件。這套機制讓你不需要在切換設備時手動去改寄存器——框架全做了。2.2 struct rt_spi_configuration四個字段四個坑struct rt_spi_configuration { rt_uint8_t mode; rt_uint8_t data_width; rt_uint16_t reserved; rt_uint32_t max_hz; };mode這個字段是最容易看錯、又最隱蔽的。它其實不是只存一個數(shù)字而是把多項參數(shù)按位組合在一起常見的取值包括#define RT_SPI_CPHA (10) /* clock phase */ #define RT_SPI_CPOL (11) /* clock polarity */ #define RT_SPI_MSB (02) /* MSB First */ #define RT_SPI_LSB (12) /* LSB First */ #define RT_SPI_3WIRE (13) /* SI/SO pin shared */ #define RT_SPI_MASTER (04) /* master role */ #define RT_SPI_SLAVE (14) /* slave role */所以一個SPI設備最常用的“模式0”實際上對應RT_SPI_CPHA | RT_SPI_CPOL這一組合也就是讓時鐘空閑時為低、數(shù)據(jù)在第一個上升沿采樣。另一個容易讓人栽跟頭的坑是RT_SPI_MSB和RT_SPI_LSB它的值為0意味著你如果直接把模式變量和0做“或”運算MSB其實是默認選擇不會改變數(shù)值。這可能讓很多人誤以為“我沒有設置MSB/LSB”實際上框架已經(jīng)把MSB作為默認值了。這一點在與某些特殊外設對接時很重要——如果對端期望LSB先傳必須顯式把RT_SPI_LSB寫進mode里。max_hz則是設備的最高通信速率。注意它不是實際頻率而是一個上限值?？偩€驅動在初始化時會根據(jù)這個值去計算分頻系數(shù)實際頻率不高于它即可。我曾經(jīng)遇到一個奇怪現(xiàn)象一塊LCD屏明明支持36MHz時鐘但接到某個板子上跑到18MHz就花屏最后定位發(fā)現(xiàn)是PCB走線太長、干擾嚴重。從框架層面看只需調低max_hz就能解決問題——這個字段的設計本身就是給你這種場景做限速用的。data_width一般填88位極少數(shù)設備用16位或32位模式。RT-Thread官方目前對非8位模式的支持在部分BSP里還不夠完善所以如果你要接一個12位或16位并行的屏最好先確認當前BSP的SPI驅動是否支持非8位模式否則就需要在ops-transfer里面自己拼字節(jié)。2.3 struct rt_spi_ops底層驅動的“能力表”struct rt_spi_ops { rt_err_t (*configure)(struct rt_spi_device *device, struct rt_spi_configuration *configuration); rt_uint32_t (*xfer)(struct rt_spi_device *device, struct rt_spi_message *message); };這套回調接口非常簡單只有兩個函數(shù)指針。configure負責根據(jù)配置重新初始化SPI外設設置時鐘極性、數(shù)據(jù)位寬、預分頻。xfer負責真正發(fā)出一幀數(shù)據(jù)返回實際發(fā)送的字節(jié)數(shù)。我見過不少驅動移植者在這兩個函數(shù)上踩坑其中比較典型的情況是只實現(xiàn)了xferconfigure里什么都不做。你在調試時可能發(fā)現(xiàn)第一幀數(shù)據(jù)正常、第二幀數(shù)據(jù)就亂了。原因很簡單——如果configure不生效RT-Thread核心層在比較新舊配置不同后卻得不到硬件層面的真正重新配置。例如總線上掛著Flash和SD卡。Flash要求模式0SD卡要求模式3。程序先操作Flash一切正常再操作SD卡時核心層發(fā)現(xiàn)mode變了于是調ops-configure但你的configure是空函數(shù)底層SPI外設寄存器還保持著模式0的配置。于是SD卡收到波形完全錯誤。這種情況是最難排查的因為單純看代碼邏輯似乎沒有問題只能靠邏輯分析儀抓波形才能發(fā)現(xiàn)。2.4 struct rt_spi_message一次會話中的最小事務單元struct rt_spi_message { const void *send_buf; void *recv_buf; rt_size_t length; struct rt_spi_message *next; unsigned int cs_take : 1; unsigned int cs_release : 1; unsigned int reserved : 30; };這是整個SPI框架中最重要的數(shù)據(jù)結構。它的設計思想是一次rt_spi_transfer_message調用可以攜帶一串消息linked list of messages這串消息作為一個整體被傳輸中途不會釋放片選。send_buf和recv_buf分別指向發(fā)送緩沖區(qū)和接收緩沖區(qū)。當只發(fā)不收時recv_buf可以填RT_NULL驅動程序會自動丟棄讀到的數(shù)據(jù)。當只收不發(fā)時send_buf填RT_NULL驅動會發(fā)送全0或全1的填充字節(jié)具體看BSP實現(xiàn)。最容易被忽略的是cs_take和cs_release這兩個位域。它們控制這次消息是否需要拉低片選和釋放片選。你可能會想為什么不每次都把片選拉低再釋放因為有些外設的操作是一個“復合事務”——例如W25Q系列Flash的讀操作需要先發(fā)命令字節(jié)地址字節(jié)然后連續(xù)讀數(shù)據(jù)。如果每發(fā)一個字節(jié)就拉一次片選Flash根本不會進入讀狀態(tài)讀回來的永遠是亂碼。正確做法是struct rt_spi_message msg1 { .send_buf cmd, .recv_buf RT_NULL, .length 1, .cs_take 1, .cs_release 0 }; struct rt_spi_message msg2 { .send_buf addr, .recv_buf RT_NULL, .length 3, .cs_take 0, .cs_release 0 }; struct rt_spi_message msg3 { .send_buf RT_NULL, .recv_buf buf, .length len, .cs_take 0, .cs_release 1 }; msg1.next msg2; msg2.next msg3; msg3.next RT_NULL; rt_spi_transfer_message(spi_dev, msg1);這樣整個過程片選只拉低一次命令、地址、數(shù)據(jù)作為一個整體被發(fā)出去。理解了這個機制芯片手冊上凡是“CS must stay low during the entire instruction sequence”的約束你都能在框架中找到對應的實現(xiàn)方式。3. 消息傳輸流程與片選控制從線程安全到復合時序的細節(jié)把控3.1 rt_spi_transfer_message 的完整執(zhí)行鏈路rt_spi_transfer_message大概是你在核心層唯一需要仔細讀一遍的函數(shù)我建議你打開源碼把它的邏輯走一遍調用rt_spi_take_bus等待并獲取總線所有權。遍歷消息鏈表中的每一個rt_spi_message。若cs_take為1則調rt_spi_take_cs拉低片選。調用ops-xfer執(zhí)行物理收發(fā)。若cs_release為1則調rt_spi_release_cs釋放片選。全部消息處理完畢后調用rt_spi_release_bus釋放總線。注意核心層不會在消息之間自動拉低或釋放片選它完全依賴cs_take和cs_release兩個標志位。如果你在一個消息鏈表里設置了第一條cs_take1、最后一條cs_release1中間幾條都不設置那么片選在整個鏈表中從頭到尾都是低電平。這套機制還會自動處理配置切換。在遍歷消息鏈表之前核心層會比較當前總線上綁定設備的配置與待處理設備的配置是否一致。如果不一致它會調用ops-configure先重新配置再開始發(fā)送。所以你在同一條總線上交替訪問Flash和SD卡時可以不必擔心模式混用。3.2 為什么先拿總線再拉片選防搶戰(zhàn)的多線程思維這個順序不是拍腦袋定的它解決的是一個非常具體的并發(fā)問題。假設總線上同時掛了兩張SPI Flash分別用PA4和PA5做片選。線程A正在操作Flash1拉了PA4準備發(fā)一長串數(shù)據(jù)。此時線程B被調度它需要操作Flash2它拉了PA5也在發(fā)數(shù)據(jù)。但底層SPI外設只有一個兩個線程的數(shù)據(jù)會交疊混發(fā)雙方的結果全錯。RT-Thread的設計是SPI總線上有一個“所有者”概念bus-owner字段。rt_spi_take_bus會用互斥鎖保護這個字段誰拿到所有權誰才能操作物理外設rt_spi_take_cs則確保只有當前所有者才能拉片選。線程B在拿不到所有權時會被掛起休眠直到線程A發(fā)送完畢、釋放總線。所以我的建議是在應用中永遠不要直接寫片選引腳也不要直接調用底層BSP的xfer函數(shù)。一切訪問都走rt_spi_transfer_message或設備驅動接口不然多線程環(huán)境下的SPI總線一定會在你最忙的時候出亂子。3.3 硬件片選與軟件片選的本質差異及選擇關于SPI片選RT-Thread的BSP通常支持兩種方案硬件片選由芯片SPI外設內部的NSS邏輯自動控制。你只需配置GPIO復用功能發(fā)送數(shù)據(jù)時外設自動拉低片選發(fā)完自動拉高。軟件片選由普通GPIO手動拉高拉低通常在rt_spi_take_cs和rt_spi_release_cs里實現(xiàn)。兩種方案在RT-Thread里差別很明顯對比項硬件片選軟件片選CPU負擔低外設自動控制高每個事務都要GPIO寫入時序精度高由硬件保證時序關系低受中斷和調度影響復合事務較難實現(xiàn)連續(xù)片選往往需要特殊寄存器配置方便CS的拉低和拉高完全由軟件控制多設備支持可能需要多個NSS引腳部分MCU只有一個NSS任意GPIO均可擴展靈活誤操作風險某些時序下可能提前釋放片選完全可控只要代碼沒寫錯實戰(zhàn)中只要不是追求極限速率我通常偏向軟件片選。原因很簡單靈活度高遇到復合事務也好處理。尤其你還要用RT-Thread這類RTOS中斷優(yōu)先級變化可能導致響應稍有波動但軟件片選通過操作GPIO寄存器來控制實際誤差在微秒級以內對絕大多數(shù)外設完全夠用。不過要注意一點用軟件片選時必須確保GPIO配置為推挽輸出且初始狀態(tài)為高電平。這聽起來是基礎常識但很多新人在用STM32CubeMX自動生成初始化代碼后又手動改了引腳復用功能導致初始化順序不對片選腳一直輸出低電平結果總線上所有設備都處于選通狀態(tài)出現(xiàn)兩臺設備同時搶應答的靈異現(xiàn)象。3.4 DMA配合SPI時的消息構造技巧SPI外設加DMA是提升吞吐率的常見組合。RT-Thread消息結構體的send_buf和recv_buf本身不限制緩沖區(qū)來源所以在使用DMA時一個容易忽略的約束是緩沖區(qū)對齊和內存屬性。如果你的MCU帶D-Cache且緩沖區(qū)定義在可緩存內存區(qū)域發(fā)送和接收時可能出現(xiàn)緩存一致性問題CPU往DMA緩沖區(qū)寫了命令字但DMA讀到的還是Cache里的舊數(shù)據(jù)。這是嵌入式開發(fā)中比較隱蔽的坑常見征兆是單獨調試SPI正常加進RT-Thread后第一次讀數(shù)據(jù)正常后續(xù)讀出來的全是上一次的殘影。解決思路有下面幾種為DMA緩沖區(qū)單獨分配在非緩存內存比如STM32的__attribute__((section(.noncached)))。收發(fā)前后手動調用rt_hw_cpu_dcache_ops做cache清理和無效化。使用RT-Thread提供的rt_dma_alloc等接口統(tǒng)一從DMA安全內存池分配緩沖區(qū)。另外DMA模式下recv_buf不能隨便傳RT_NULL。若你只想發(fā)送且不關心接收請把recv_buf指向一個真實的接收緩沖區(qū)哪怕這個緩沖區(qū)不大避免DMA寫空指針導致HardFault。4. 從設備模式SPI Slave驅動要點方向反過來的玩法4.1 RT-Thread如何描述一個SPI從設備SPI這個總線有個特點它天生就是一主多從的結構。但有些應用場景下你的設備需要被別人當外設訪問——比如板子作為某個主控的協(xié)處理器主控通過SPI向你的板子下發(fā)命令。這種場景下你需要使用RT-Thread的SPI從設備框架。RT-Thread提供了一組從設備模式相關接口rt_err_t rt_spi_slave_register(struct rt_spi_bus *bus, const char *name, rt_spi_slave_cb_t cb, void *user_data); rt_err_t rt_spi_slave_config(struct rt_spi_device *device, struct rt_spi_configuration *config); rt_err_t rt_spi_slave_send(struct rt_spi_device *device, const void *buf, rt_size_t len);從設備模式下你不能主動發(fā)起傳輸只能提前準備好接收緩沖區(qū)等待主控來“拉”數(shù)據(jù)。這與主設備模式在編程模型上是完全不同的。RT-Thread的從設備框架用rt_spi_slave_send把數(shù)據(jù)準備好然后等待外部主控發(fā)起SPI時鐘數(shù)據(jù)才被真正移出。4.2 從設備回調機制與數(shù)據(jù)就緒通知當你作為從設備時寄存器層面的收發(fā)邏輯往往依賴硬件中斷。每一個SPI字節(jié)到達都會觸發(fā)一次接收中斷由BSP驅動把數(shù)據(jù)讀入FIFO或DMA緩沖區(qū)。RT-Thread從設備框架提供回調函數(shù)通常是某次完整事務結束時核心層調用回調通知應用層“數(shù)據(jù)已經(jīng)準備好了”。static rt_err_t spi_slave_callback(struct rt_spi_slave_device *device, const void *send_buf, void *recv_buf, rt_size_t len, void *user_data) { /* 在這里處理收到的數(shù)據(jù) */ return RT_EOK; }實際開發(fā)中這個回調函數(shù)里盡量只做“搬運”工作——比如把recv_buf拷貝到應用緩沖區(qū)或者設置一個事件標志喚醒應用線程。不要在這里做耗時處理比如解析JSON或寫Flash這會直接影響下一次SPI事務的響應速度。主控端可能只等了幾個微秒就再次發(fā)起傳輸你回調還沒跑完數(shù)據(jù)就丟了。4.3 主從設備同總線復用時的注意事項如果你在一個芯片上既想當SPI主設備讀外設又想當SPI從設備被外部主控訪問這是可以做到的但要注意引腳模式的切換。例如一個典型的處理方式是平時配置成SPI主模式外部主控通過一個GPIO電平變化觸發(fā)你切換到從模式。你在切換模式時需要重新初始化整個SPI外設并把引腳復用從主設備模式切到從設備模式。這個過程中框架層面的ops-configure就會反復被調用所以你的configure實現(xiàn)必須足夠健壯能處理運行時的反復切換。我在一次產(chǎn)測工具開發(fā)中就是讓板子既能自動掃描總線上兩塊Flash又能把整塊板子虛擬成一個SPI從設備供產(chǎn)測上位機讀寫。當時的實現(xiàn)方式是默認進入從設備模式收到產(chǎn)測上位機的“切換主模式”命令后重新執(zhí)行ops-configure把外設切成主模式之后就可以正常枚舉Flash了。這個功能完全建立在RT-Thread這套可重入的configure機制上——如果你在configure里只做一次性初始化、不做運行時重置那這套方案就完全失效了。5. 常見問題排查與調試技巧用邏輯分析儀和時間線思維抓SPI問題5.1 典型報錯與故障速查表下面整理了幾種我在使用RT-Thread SPI框架時遇到的問題。許多問題都不在框架本身而是外部因素但癥狀往往先從框架層表現(xiàn)出來。癥狀可能原因解決方案rt_spi_take_bus超時返回錯誤另一個線程長時間占用總線或中斷里占用了總線檢查是否在中斷里直接調用了SPI設備接口可臨時增大獲取總線超時時間讀回數(shù)據(jù)全為0xFFSPI模式配置錯誤CPOL/CPHA不匹配設備不在位片選沒拉低先用邏輯分析儀抓波形再核對設備手冊要求的模式讀回數(shù)據(jù)全為0x00極性配置或從設備未準備發(fā)送DMA緩沖區(qū)未正確初始化查看是否有數(shù)據(jù)從MOSI發(fā)出來發(fā)送數(shù)據(jù)對但命令無響應復合事務中片選被反復拉低檢查消息鏈表里cs_take和cs_release是否只在首尾設置第一次讀寫正常之后全錯上電后設備初始化時序未對齊Flash需要等待WIP清除在設備驅動中加狀態(tài)輪詢核對設備上電時序同總線多設備互相干擾軟件片選GPIO初始狀態(tài)為低或某設備發(fā)送時未正確拉高其他設備片選初始化階段把所有片選腳置高確認消息里cs_release確實觸發(fā)DMA模式讀到舊數(shù)據(jù)D-Cache未刷出或未無效化分配非緩存內存收發(fā)前后做cache維護5.2 一次SPI Flash驅動“寫進去讀不出”的完整排查我分享一個真實案例某塊開發(fā)板SPI Flash能讀到JEDEC ID和狀態(tài)寄存器說明讀命令和時序都正常但就是寫入后讀出來全是“0xFF”。排查過程是這樣的第一步檢查Flash是否真的處于寫使能狀態(tài)。用邏輯分析儀抓寫使能0x06命令時序波形顯示片選正常、時鐘正常但命令發(fā)出后沒有等待狀態(tài)寄存器中的WIP位清零。這會導致后續(xù)頁編程命令進來時Flash還在忙于上一次操作直接忽略新命令。第二步修改驅動代碼在寫使能后輪詢狀態(tài)寄存器確保WIP清零后再發(fā)送頁編程命令。這里建議用消息鏈表把“寫命令地址數(shù)據(jù)”串起來保持片選在整個寫周期低位。結果還是失敗。第三步仔細對比波形后發(fā)現(xiàn)頁編程命令后Flash返回的狀態(tài)值一直是0x00但數(shù)據(jù)引腳在讀取狀態(tài)時變成了高阻態(tài)。排查到這一步方向轉向硬件電氣特性板子上Flash的DO引腳與SD卡分線器共用而分線器的上拉電阻選擇了10k——不夠強。SPI速度較高時線路電容導致信號建立不完整。更換更小阻值的上拉電阻后問題徹底解決。這輪排查的經(jīng)驗是SPI問題優(yōu)先抓波形再改代碼。邏輯分析儀能看到片選、時鐘、數(shù)據(jù)三者的相對時序比打日志高效得多。尤其在RT-Thread這類多線程環(huán)境下打日志會引入額外調度延遲可能掩蓋真實時序問題。5.3 調試SPI消息鏈表的有效手段構造測試消息如果你懷疑是RT-Thread核心層在處理消息鏈表時出了問題這兩種情形比較少見但值得確認可以直接在應用層構造一組短消息做最小復現(xiàn)。static struct rt_spi_message test_msg; static rt_uint8_t send_data[4] {0xAA, 0x55, 0xAA, 0x55}; static rt_uint8_t recv_data[4] {0}; void spi_debug_loopback(void) { test_msg.send_buf send_data; test_msg.recv_buf recv_data; test_msg.length sizeof(send_data); test_msg.cs_take 1; test_msg.cs_release 1; test_msg.next RT_NULL; rt_spi_transfer_message(spi_dev, test_msg); }如果數(shù)據(jù)在主控側自發(fā)自收后能正確回讀說明物理鏈路和核心調度基本沒問題。接下來再逐步拆成多條消息驗證cs_take/cs_release的組合是否正確。這種“分而治之”的方式很快能定位到具體是哪一類消息組合導致片選異常。5.4 借助RT-Thread FinSH命令快速驗證SPI設備RT-Thread的FinSH控制臺很適合做SPI驅動基調。比如你已經(jīng)注冊好了“spi10”這個設備可以直接在FinSH里執(zhí)行msh spi loop spi10 0x9F 3這個命令會往spi10發(fā)送一字節(jié)0x9F并讀回3字節(jié)。如果讀回的值符合你預期就說明整條設備鏈路已經(jīng)打通如果讀不到就能排除大量上層邏輯集中精力檢查物理連接和初始化順序。在BSP里往往也提供list_device、list_spi這類命令能快速查看哪些SPI設備注冊成功、當前配置如何。這是我最常用的初始調試手段先確認設備注冊再測回環(huán)再做協(xié)議調試。6. 基于框架寫好自己的設備驅動從零到可復用的實踐路徑6.1 驅動代碼應該放在哪一層很多新手拿到一個SPI外設第一反應是在應用層堆一個讀寫函數(shù)到處調用。這在臨時驗證功能時可行但從可維護性角度不推薦。建議的做法是把設備驅動做成一個獨立文件然后通過設備注冊機制掛到設備框架里。以某個SPI DAC為例正確的組織方式是寫一個spi_dac.c實現(xiàn)dac_write_value(struct rt_spi_device *dev, rt_uint16_t value)這樣的基礎接口。對外暴露rt_device_write風格的讀寫接口讓上層應用不感知SPI的存在。在初始化線程里調用rt_hw_spi_device_attach掛載設備再調用注冊函數(shù)完成設備對象注冊。這樣后續(xù)如果換用I2C版本的DAC只需要替換底層驅動文件應用層代碼一行都不用改。設備框架的意義就在于此。6.2 不自帶SPI控制器的芯片怎么接SPI外設討論一個延伸問題有些MCU沒有硬件SPI外設或用完硬件SPI后仍有多余外設要接這時候可以用GPIO模擬SPI。RT-Thread的框架能不能支持這種答案是能但需要在ops-xfer內部自己翻轉GPIO。這種模擬SPI的驅動實現(xiàn)本質上和硬件SPI驅動的接口形式一致static rt_uint32_t soft_spi_xfer(struct rt_spi_device *device, struct rt_spi_message *message) { /* 在這里用GPIO模擬SCK、MOSI和MISO */ return message-length; } static struct rt_spi_ops soft_spi_ops { .configure RT_NULL, .xfer soft_spi_xfer, };唯一的區(qū)別是configure多半不需要實現(xiàn)因為根本沒有外設寄存器可配置。發(fā)送時自行檢查message-send_buf是否為空決定是否從MOSI移出數(shù)據(jù)檢查message-recv_buf是否為空決定是否從MISO采樣。這里的性能瓶頸在于GPIO翻轉速度比較慢通常只能做到幾百kHz到1MHz左右但接一些不追求高速的外設傳感器、EEPROM、LCD初始化配置完全夠用。6.3 驅動健壯性消息合法性校驗與失敗重試我見過的不少驅動在ops-xfer里基本不做入?yún)⑿ｒ?。偶爾嘴瓢傳了個空指針或者長度算錯整個系統(tǒng)就掛掉了。在RT-Thread消息結構里send_buf和recv_buf同時為RT_NULL時沒有任何數(shù)據(jù)可傳輸應該直接返回錯誤長度為零也同理。if (message-length 0) { return 0; } if (message-send_buf RT_NULL message-recv_buf RT_NULL) { return 0; }這些看似無用的校驗在實際項目中可以省掉很多半夜調bug的痛苦。還要考慮通信失敗后的處理策略。SPI本身沒有ACK機制寫命令發(fā)出后是否成功一般取決于從設備的內部狀態(tài)。所以在設備驅動里加狀態(tài)確認通常很有必要——比如SD卡命令后要讀響應Flash寫命令后要輪詢狀態(tài)寄存器LCD顯存寫完可以讀回驗證。這些協(xié)議級的可靠性措施不能只依賴底層框架。6.4 性能優(yōu)化單次傳輸長度與合并傳輸SPI吞吐率往往取決于事務的拆分粒度。一次rt_spi_transfer_message傳入的消息越少、單條消息越長線程切換和總線占用開銷越小。舉例來說如果要把一個Flash固件分區(qū)全部讀回做校驗最直接的方式是循環(huán)調用rt_spi_read每次讀4KB。這個循環(huán)每執(zhí)行一次都要獲取總線、釋放總線。更好的做法是一次申請一個大緩沖區(qū)用一條長的消息把整個分區(qū)連續(xù)讀回。這樣SPI總線只被占用一次DMA也能把整塊數(shù)據(jù)搬完。但大緩沖區(qū)又涉及內存分配問題——你不可能無限制地申請大塊連續(xù)RAM。此時可以把消息鏈表用起來分配多塊較小的緩沖區(qū)通過next指針串成一個鏈表每塊緩沖區(qū)對應一條消息。它們在核心層可以被連續(xù)傳輸片選保持低位而內存壓力則被簡化到每塊緩沖區(qū)都比較小。這個技巧在讀寫大容量NAND Flash或長時間連續(xù)采樣時非常管用。7. 經(jīng)驗總結與未來擴展RT-Thread的SPI驅動框架最大的價值不是幫你少寫幾行寄存器操作而是幫你建立了一套“總線資源調度”的思維模型。縱觀整個框架核心層像個交通警察負責分配通行權BSP驅動是路口信號燈控制實際信號設備驅動是每輛車的駕駛員按既定路線行駛。應用層只需要說“我要到某個地方去”完全不用關心中間經(jīng)過哪些路口。實際操作中我個人的體會是剛上手時先不要急著看源碼和結構體。拿一塊Flash或傳感器用框架自帶接口先調通一版回環(huán)再回頭讀核心代碼理解會快很多。源碼本身寫得相對直白但如果沒有實際調試經(jīng)驗打底光看代碼容易陷入“每個字都認識整體不知道在講什么”的狀態(tài)。后續(xù)如果你的項目涉及更高性能需求可以留意RT-Thread在SPI框架里的兩部分擴展方向使用RT_SPI_CPHA/CPOL之外的自定義位配合外設的特殊時序要求做精細化控制。將DMA和SPI框架更深地綁定比如為struct rt_spi_message擴展發(fā)送完成回調這樣才能精確掌握DMA完成時機做更高層次的協(xié)議狀態(tài)機。另外如果同一個項目中需要兼容SPI Flash、SPI屏幕、SPI傳感器這幾種不同特性的外設建議在設備驅動的外層再抽象一層統(tǒng)一接口。這樣應用層永遠只面對一個“讀寫寄存器”或“讀一頁數(shù)據(jù)”的操作而底層可能用SPI、I2C甚至UART來實現(xiàn)你會驚喜地發(fā)現(xiàn)代碼復用率可以變得非常高。這算是從“會用SPI框架”邁向“設計良好驅動層”比較有價值的一步。