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