實戰(zhàn)：從設備樹到I2C驅動與內(nèi)核調試)
1. 嵌入式驅動開發(fā)到底在做什么很多人第一次聽到“嵌入式驅動開發(fā)”這個詞腦子里浮現(xiàn)的畫面大概是一個人對著電路板焊臺冒著煙示波器上跳著波形然后屏幕上刷刷刷地滾著看不懂的寄存器地址。這個印象不算錯但只對了一半。嵌入式驅動開發(fā)的核心工作說白了就是讓操作系統(tǒng)能夠認識并控制硬件。CPU、內(nèi)存、GPIO、I2C、SPI、UART、USB、LCD、觸摸屏、WiFi模組、傳感器……這些硬件在操作系統(tǒng)眼里原本都是“陌生人”驅動就是給它們辦的身份證和操作手冊。我做了十多年嵌入式從8位單片機裸機跑到Cortex-A系列Linux驅動最大的感受是驅動開發(fā)不是“寫代碼”而是“翻譯”。你要把硬件手冊里那些時序圖、寄存器定義、電氣特性翻譯成內(nèi)核能理解的抽象接口。比如一個按鍵硬件上就是一個GPIO電平變化但內(nèi)核需要知道“這個GPIO對應哪個按鍵”“按下時是什么電平”“要不要消抖”“上報什么鍵值”。這一整套翻譯過程就是驅動開發(fā)。那這個方向適合誰呢如果你已經(jīng)會寫C語言能看懂簡單的電路圖用過STM32或者ESP32做過裸機項目那你就具備了入門的基礎。如果你還懂一點Linux用戶態(tài)編程知道文件操作、進程線程、設備節(jié)點這些概念那上手會更快。但如果你連指針和結構體都還寫不利索建議先把C語言基礎打牢否則看內(nèi)核源碼會很痛苦。驅動開發(fā)的價值在于它是硬件和軟件之間的唯一橋梁。沒有驅動再好的芯片也只是一塊硅片沒有驅動再牛的應用也跑不起來。而且這個方向的壁壘相對較高經(jīng)驗積累越深越吃香不是那種學三個月就能被替代的崗位。從智能家居、工業(yè)控制、汽車電子到機器人、醫(yī)療設備只要涉及硬件控制就離不開驅動開發(fā)。2. 驅動開發(fā)的核心知識體系拆解2.1 從裸機到Linux驅動的思維轉變很多從單片機轉過來的朋友第一個坎就是思維方式的轉變。裸機開發(fā)是“我直接操作寄存器”Linux驅動開發(fā)是“我告訴內(nèi)核怎么操作寄存器”。這個差別看起來小實際上影響巨大。裸機時代你寫一個按鍵掃描大概是這樣while(1) { if (GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) 0) { Delay_ms(20); if (GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) 0) { // 按鍵按下 while(GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) 0); // 按鍵釋放 } } }這種阻塞式掃描在裸機里沒問題因為整個系統(tǒng)就你一個任務。但在Linux里你絕對不能這么干。內(nèi)核里一個驅動阻塞了整個系統(tǒng)可能就卡死了。所以Linux驅動開發(fā)的核心思維是注冊、回調、異步、分層。你需要把按鍵注冊成一個輸入設備內(nèi)核的輸入子系統(tǒng)會幫你處理事件上報、消抖、重復按鍵等邏輯。你只需要在中斷處理函數(shù)里告訴內(nèi)核“這個鍵按下了”剩下的交給內(nèi)核。這就是分層的價值。2.2 字符設備、塊設備、網(wǎng)絡設備三大類Linux把設備分成三大類這個分類是理解驅動開發(fā)的骨架。字符設備是最常見的一類特點是按字節(jié)流訪問不支持隨機訪問。按鍵、串口、I2C、SPI、GPIO、LED、蜂鳴器這些基本都是字符設備。你打開/dev/ttyS0讀一個字節(jié)就是一個字節(jié)不能跳到第100個字節(jié)去讀。塊設備是按塊訪問的通常512字節(jié)或4KB為一個塊支持隨機訪問。硬盤、SSD、SD卡、NAND Flash、eMMC這些都是塊設備。塊設備的驅動比字符設備復雜得多因為要處理緩存、調度、合并請求等。網(wǎng)絡設備比較特殊它不走/dev節(jié)點而是通過socket接口訪問。WiFi、以太網(wǎng)、藍牙、CAN總線這些都屬于網(wǎng)絡設備。網(wǎng)絡設備的驅動要注冊net_device結構體實現(xiàn)ndo_start_xmit等回調函數(shù)。我剛開始學的時候總想把所有設備都往字符設備上套結果寫WiFi驅動的時候發(fā)現(xiàn)完全不是那么回事。后來才明白分類不是為了限制你而是為了給你提供合適的框架。選對了類別內(nèi)核會幫你做很多事選錯了你就得自己造輪子。2.3 設備樹硬件描述的標準化設備樹是嵌入式Linux驅動開發(fā)繞不開的話題。在設備樹出現(xiàn)之前硬件信息是硬編碼在驅動里的換個板子就要改驅動代碼非常麻煩。設備樹把硬件描述從驅動代碼里剝離出來用一套獨立的語法描述硬件資源。一個典型的設備樹節(jié)點長這樣i2c1 { status okay; clock-frequency 100000; eeprom50 { compatible atmel,24c02; reg 0x50; pagesize 16; }; };這段代碼的意思是I2C1控制器使能時鐘頻率100kHz掛了一個AT24C02 EEPROM地址是0x50頁大小16字節(jié)。驅動代碼里只需要匹配compatible屬性就能拿到這些硬件信息。設備樹的好處是一個驅動可以支持多個硬件配置。同樣的I2C EEPROM驅動換一個地址、換一個I2C控制器只需要改設備樹驅動代碼一行不用動。這在產(chǎn)品線豐富的公司里價值巨大。但設備樹也有坑。我踩過最深的坑是引腳復用配置。很多SoC的引腳是多功能的同一個引腳可以做UART、I2C、GPIO、PWM。設備樹里要正確配置pinctrl否則驅動加載了但引腳沒配對硬件就是不動。這個問題的排查方法后面會詳細講。2.4 并發(fā)與同步驅動開發(fā)的必修課Linux內(nèi)核是多任務、可搶占的驅動代碼可能同時被多個進程、多個中斷、多個CPU核心訪問。如果你不處理并發(fā)就會出現(xiàn)數(shù)據(jù)競爭、死鎖、內(nèi)存泄漏。內(nèi)核提供了多種同步機制機制適用場景特點自旋鎖短時間鎖定中斷上下文忙等待不能睡眠互斥鎖長時間鎖定進程上下文可以睡眠有優(yōu)先級繼承信號量資源計數(shù)可以睡眠適合生產(chǎn)者消費者完成量等待某個事件完成適合同步多個任務RCU讀多寫少讀端無鎖寫端延遲釋放原子操作簡單計數(shù)無鎖性能高我見過太多新手驅動里直接用一個全局變量做標志位不加任何保護結果跑壓力測試的時候隨機崩潰。并發(fā)問題最惡心的地方在于它不一定每次都出現(xiàn)可能跑一萬次才崩一次但產(chǎn)品出貨后就是災難。注意在中斷處理函數(shù)里絕對不能使用可能睡眠的鎖如互斥鎖、信號量否則會導致內(nèi)核崩潰。中斷上下文只能用自旋鎖或原子操作。3. 一個完整驅動項目的實操過程3.1 項目背景與需求分析假設我們要做一個嵌入式環(huán)境監(jiān)控項目需求是通過I2C接口讀取溫濕度傳感器比如SHT30通過GPIO控制一個風扇通過串口上報數(shù)據(jù)同時支持用戶態(tài)程序通過sysfs接口讀取當前溫濕度。這個項目雖然不大但涵蓋了驅動開發(fā)的幾個核心點I2C設備驅動、GPIO控制、字符設備接口、sysfs屬性、中斷處理風扇堵轉檢測。我拿這個項目當例子把完整流程走一遍。首先明確硬件連接SHT30掛在I2C1上地址0x44風扇控制引腳是GPIO1_15高電平轉動風扇堵轉檢測引腳是GPIO1_16下降沿觸發(fā)中斷調試串口是UART2波特率115200。3.2 設備樹配置與引腳復用設備樹是第一步也是最容易出錯的一步。先看I2C1的配置i2c1 { status okay; clock-frequency 100000; pinctrl-names default; pinctrl-0 i2c1_pins; sht30: sht3044 { compatible sensirion,sht30; reg 0x44; status okay; }; };然后是GPIO和中斷的配置gpio1 { fan_ctrl { gpio-hog; gpios 15 GPIO_ACTIVE_HIGH; output-low; line-name fan-ctrl; }; }; gpio1 { fan_detect: fan-detect { gpios 16 GPIO_ACTIVE_LOW; interrupt-parent gpio1; interrupts 16 IRQ_TYPE_EDGE_FALLING; debounce-interval 50; }; };這里有幾個關鍵點。gpio-hog表示內(nèi)核啟動時就把這個GPIO初始化為低電平防止風扇上電就轉。debounce-interval是硬件消抖50ms這個參數(shù)要根據(jù)實際風扇的抖動情況調整。我試過不設消抖結果風扇一轉就報一堆中斷CPU占用率飆升。引腳復用配置在pinctrl節(jié)點里pinctrl { i2c1_pins: i2c1-pins { pins { pinmux PINMUX_GPIO1_IO00__FUNC_I2C1_SCL, PINMUX_GPIO1_IO01__FUNC_I2C1_SDA; bias-pull-up; drive-strength 2; }; }; };bias-pull-up是I2C總線的上拉drive-strength是驅動能力。I2C總線如果沒有上拉波形會很難看通信不穩(wěn)定。我一般會在硬件上放4.7k的上拉電阻設備樹里再開內(nèi)部上拉作為備份。3.3 I2C驅動代碼實現(xiàn)I2C設備驅動的框架比較固定核心是probe函數(shù)和remove函數(shù)。先看結構體定義struct sht30_data { struct i2c_client *client; struct mutex lock; struct device *dev; int temperature; int humidity; };probe函數(shù)里要做幾件事分配數(shù)據(jù)結構、初始化鎖、注冊sysfs屬性、可能還要初始化硬件。static int sht30_probe(struct i2c_client *client, const struct i2c_device_id *id) { struct sht30_data *data; int ret; data devm_kzalloc(client-dev, sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; >static int sht30_read_data(struct sht30_data *data) { u8 cmd[2] {0x2C, 0x06}; u8 buf[6]; int ret; u16 temp_raw, humi_raw; mutex_lock(data-lock); ret i2c_master_send(data-client, cmd, 2); if (ret ! 2) { mutex_unlock(data-lock); return -EIO; } msleep(20); ret i2c_master_recv(data-client, buf, 6); if (ret ! 6) { mutex_unlock(data-lock); return -EIO; } temp_raw (buf[0] 8) | buf[1]; humi_raw (buf[3] 8) | buf[4]; >static ssize_t temperature_show(struct device *dev, struct device_attribute *attr, char *buf) { struct sht30_data *data dev_get_drvdata(dev); sht30_read_data(data); return sprintf(buf, %d\n,>cat /sys/bus/i2c/devices/1-0044/temperature cat /sys/bus/i2c/devices/1-0044/humiditysysfs的優(yōu)點是簡單直接缺點是每次讀都要觸發(fā)一次I2C傳輸頻繁讀取會影響性能。如果數(shù)據(jù)更新頻率高建議用字符設備或者input子系統(tǒng)。3.5 GPIO控制與中斷處理風扇控制用GPIO子系統(tǒng)struct gpio_desc *fan_gpio; fan_gpio devm_gpiod_get(dev, fan-ctrl, GPIOD_OUT_LOW); if (IS_ERR(fan_gpio)) { dev_err(dev, failed to get fan gpio\n); return PTR_ERR(fan_gpio); } gpiod_set_value(fan_gpio, 1);GPIOD_OUT_LOW表示初始輸出低電平風扇不轉。gpiod_set_value設置高電平風扇轉動。中斷處理static irqreturn_t fan_detect_isr(int irq, void *dev_id) { struct sht30_data *data dev_id; /* 上報堵轉事件 */ sysfs_notify(data-dev-kobj, NULL, fan_status); return IRQ_HANDLED; } ret devm_request_irq(dev, gpio_to_irq(fan_detect_gpio), fan_detect_isr, IRQF_TRIGGER_FALLING, fan-detect, data);中斷處理函數(shù)要盡量短不能做耗時操作。這里只是通知sysfs實際處理交給用戶態(tài)。sysfs_notify會喚醒阻塞在poll上的用戶態(tài)程序。3.6 編譯、加載與調試驅動編譯成模塊obj-m sht30.o KDIR : /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) all: $(MAKE) -C $(KDIR) M$(PWD) modules clean: $(MAKE) -C $(KDIR) M$(PWD) clean加載模塊insmod sht30.ko dmesg | tail -20如果probe成功dmesg會打印“sht30 probed successfully”。如果失敗根據(jù)錯誤碼排查。常見錯誤碼-ENODEV表示設備樹匹配失敗-EIO表示I2C通信失敗-EPROBE_DEFER表示依賴的資源還沒準備好。調試I2C通信可以用i2cdetect和i2cgeti2cdetect -y 1 i2cget -y 1 0x44 0x2C wi2cdetect能列出總線上所有設備地址如果0x44沒出現(xiàn)說明硬件連接或者引腳復用有問題。4. 常見問題與排查技巧實錄4.1 驅動加載失敗排查流程驅動加載失敗是最常見的問題我整理了一個排查流程現(xiàn)象可能原因排查方法insmod報錯“Invalid parameters”模塊參數(shù)錯誤檢查module_param定義probe函數(shù)沒被調用設備樹compatible不匹配對比驅動of_match_table和設備樹probe返回-ENODEV設備樹節(jié)點status不是okay檢查設備樹status屬性probe返回-EIOI2C/SPI通信失敗用i2cdetect/spidev_test驗證probe返回-EPROBE_DEFER依賴的驅動還沒加載檢查驅動加載順序內(nèi)核崩潰空指針或內(nèi)存越界看oops信息定位函數(shù)和行號我遇到最多的是-EPROBE_DEFER。比如I2C驅動依賴pinctrl驅動如果pinctrl還沒加載I2C驅動就會返回-EPROBE_DEFER內(nèi)核會稍后重試。這個機制是好的但如果你不知道會以為驅動有問題。解決方法是在設備樹里正確配置依賴關系或者調整驅動加載順序。4.2 I2C通信失敗的那些坑I2C通信失敗的原因很多我按概率排序第一是上拉電阻缺失。I2C總線必須有上拉通常4.7k到10k。有些開發(fā)板省了上拉電阻靠SoC內(nèi)部上拉但內(nèi)部上拉通常比較弱幾十k高速通信時波形上升沿太慢導致通信失敗。用示波器看SCL和SDA波形如果上升沿明顯變緩就是上拉不夠。第二是地址錯誤。7位地址和8位地址容易搞混。設備手冊上寫的0x44通常是7位地址但有些驅動代碼里用的是8位地址0x88。Linux I2C子系統(tǒng)用的是7位地址所以設備樹里寫0x44是對的。第三是時鐘頻率過高。100kHz是標準模式400kHz是快速模式1MHz是快速模式。但實際能跑多快取決于總線電容和上拉電阻。線越長、設備越多電容越大頻率就要降。我一般先用100kHz調通再逐步提高。第四是引腳復用沖突。同一個引腳被多個驅動申請后申請的會失敗。用cat /sys/kernel/debug/pinctrl/pinctrl-handles可以查看引腳占用情況。4.3 中斷丟失與消抖處理按鍵和堵轉檢測這類中斷最常見的問題是抖動導致多次觸發(fā)。機械開關的抖動時間通常是5ms到20ms風扇堵轉檢測的抖動可能更長。處理方法有三種硬件消抖RC電路、驅動消抖定時器、輸入子系統(tǒng)消抖。我推薦用輸入子系統(tǒng)的debounce-interval簡單可靠。如果自己寫驅動可以用定時器static void fan_detect_timer(struct timer_list *t) { struct sht30_data *data from_timer(data, t, detect_timer); int val gpiod_get_value(data-fan_detect_gpio); if (val 0) { /* 確認堵轉 */ sysfs_notify(data-dev-kobj, NULL, fan_status); } } static irqreturn_t fan_detect_isr(int irq, void *dev_id) { struct sht30_data *data dev_id; mod_timer(data-detect_timer, jiffies msecs_to_jiffies(50)); return IRQ_HANDLED; }中斷里只修改定時器50ms后定時器回調里再讀GPIO確認。這樣能過濾掉大部分抖動。注意定時器回調運行在軟中斷上下文不能睡眠不能用互斥鎖。如果需要睡眠操作用工作隊列workqueue代替。4.4 內(nèi)存泄漏與資源管理驅動里的內(nèi)存泄漏很隱蔽因為驅動通常長時間運行泄漏一點看不出來跑幾天幾個月才崩潰。我踩過的坑包括kmalloc后忘記kfree、request_irq后忘記free_irq、class_create后忘記class_destroy?，F(xiàn)在我都用devm_系列接口讓內(nèi)核自動管理資源devm_kzalloc代替kmallocdevm_request_irq代替request_irqdevm_gpiod_get代替gpio_requestdevm_ioremap代替ioremapdevm_接口的釋放順序是自動的而且跟設備生命周期綁定設備卸載時自動釋放不會漏。但要注意devm_分配的內(nèi)存不能在設備卸載后使用否則就是use-after-free。4.5 性能優(yōu)化與實時性考慮驅動性能優(yōu)化主要看兩個指標吞吐量和延遲。對于環(huán)境監(jiān)控這種應用吞吐量要求不高但延遲要穩(wěn)定。我做過測試同樣的I2C讀取用msleep和用usleep_range延遲差異很大。msleep的精度是10ms左右usleep_range可以到微秒級。SHT30轉換時間15ms用usleep_range(15000, 16000)比msleep(20)更精確整體讀取時間能縮短5ms左右。中斷處理延遲也很關鍵。如果中斷處理函數(shù)太長會影響系統(tǒng)實時性。我的原則是中斷處理函數(shù)只做最緊急的事其他都丟給工作隊列或線程化中斷。Linux支持request_threaded_irq把中斷處理分成上半部和下半部上半部快速返回下半部在進程上下文執(zhí)行可以睡眠。5. 驅動開發(fā)的進階方向與學習路線5.1 從字符設備到子系統(tǒng)框架學會寫字符設備驅動只是入門真正的進階是理解內(nèi)核子系統(tǒng)。輸入子系統(tǒng)、IIO子系統(tǒng)、V4L2子系統(tǒng)、ALSA子系統(tǒng)、網(wǎng)絡子系統(tǒng)、MMC子系統(tǒng)……每個子系統(tǒng)都是一套完整的框架幫你處理一類設備的共性邏輯。以IIO子系統(tǒng)為例溫濕度傳感器、加速度計、陀螺儀、ADC這些都屬于IIO。用IIO框架寫驅動你只需要實現(xiàn)read_raw回調剩下的緩沖區(qū)管理、觸發(fā)處理、sysfs接口、字符設備接口IIO都幫你做好了。代碼量能減少一半以上。我建議的學習路線是先寫一個簡單的字符設備驅動理解file_operations、cdev、設備號這些概念然后寫一個GPIO驅動理解gpiolib然后寫一個I2C驅動理解i2c_client和i2c_driver然后寫一個input驅動理解輸入子系統(tǒng)最后選一個復雜的子系統(tǒng)深入比如V4L2或者ALSA。5.2 設備樹與硬件描述的深入理解設備樹看起來簡單但坑很多。我見過有人把設備樹寫成這樣i2c40012000 { compatible vendor,i2c; reg 0x40012000 0x1000; clocks clk 10; status okay; };看起來沒問題但clocks的時鐘ID寫錯了導致I2C控制器時鐘頻率不對通信時好時壞。設備樹的調試沒有捷徑就是對著SoC手冊一個一個核對。還有一個常見問題是設備樹覆蓋overlay。產(chǎn)品開發(fā)中核心板設備樹是固定的底板設備樹用overlay動態(tài)加載。overlay的語法和普通設備樹略有不同而且加載順序有講究。我建議overlay只用于可插拔模塊核心硬件還是寫死在主設備樹里減少不確定性。5.3 內(nèi)核調試工具與方法驅動調試不能只靠printk雖然printk確實是最常用的。我常用的調試工具包括dev_dbg動態(tài)調試通過echo file sht30.c p /sys/kernel/debug/dynamic_debug/control開啟ftrace函數(shù)跟蹤看驅動函數(shù)的調用流程和耗時perf性能分析找熱點函數(shù)kprobe動態(tài)插樁不修改代碼就能查看變量值crash分析內(nèi)核崩潰轉儲文件ftrace是我用得最多的。比如懷疑probe函數(shù)耗時太長可以這樣echo function_graph /sys/kernel/debug/tracing/current_tracer echo sht30_probe /sys/kernel/debug/tracing/set_graph_function cat /sys/kernel/debug/tracing/trace_pipe它會打印出probe函數(shù)里每個子函數(shù)的調用時間和返回值一目了然。5.4 嵌入式AI與驅動開發(fā)的結合現(xiàn)在嵌入式AI很火但很多人忽略了一點AI模型跑在NPU或GPU上也需要驅動。NPU驅動要處理內(nèi)存分配、任務調度、中斷處理、電源管理這些跟傳統(tǒng)驅動開發(fā)一脈相承但復雜度更高。如果你有驅動開發(fā)經(jīng)驗轉向AI加速器驅動是一個很好的方向。你需要理解DMA、IOMMU、內(nèi)存一致性、緩存維護這些概念。比如NPU和CPU共享內(nèi)存時要處理cache一致性問題否則NPU算完的數(shù)據(jù)CPU讀到的還是舊值。解決方法是用dma_alloc_coherent分配一致性內(nèi)存或者手動調用dma_sync_single_for_cpu。這個方向的崗位需求在增長但門檻也高。我建議先把傳統(tǒng)驅動做扎實再往AI加速器方向延伸。5.5 面試準備與八股文整理嵌入式驅動開發(fā)的面試八股文主要集中在幾個方面內(nèi)核同步機制、內(nèi)存管理、中斷處理、設備模型、設備樹、總線驅動模型。我整理了一些高頻問題自旋鎖和互斥鎖的區(qū)別分別在什么場景下使用中斷上半部和下半部的區(qū)別工作隊列和tasklet的區(qū)別設備樹compatible屬性的匹配規(guī)則platform驅動和字符設備驅動的區(qū)別probe函數(shù)的調用時機和返回值含義內(nèi)核內(nèi)存分配函數(shù)kmalloc、vmalloc、kmem_cache_alloc的區(qū)別這些問題看起來是八股但背后都是實際開發(fā)中會遇到的問題。我面試別人的時候不會只問概念而是會追問“你在項目里怎么用的”“遇到過什么問題”“怎么解決的”。所以準備面試最好的方法不是背八股而是真正做過項目踩過坑總結過經(jīng)驗。6. 我個人的一些實操心得驅動開發(fā)這個方向入門曲線陡但一旦跨過去后面的路會越走越寬。我剛開始寫驅動的時候一個I2C驅動調了三天最后發(fā)現(xiàn)是設備樹里I2C控制器狀態(tài)沒寫okay。這種問題現(xiàn)在看起來很低級但當時就是找不到。我的經(jīng)驗是驅動調試要有耐心要相信硬件沒問題問題一定在軟件配置。大部分驅動問題都是配置問題不是代碼邏輯問題。設備樹、時鐘、引腳復用、電源域這四個地方檢查一遍能解決80%的問題。另外多看內(nèi)核源碼里的同類驅動。內(nèi)核源碼里drivers目錄下有幾千個驅動你遇到的問題別人大概率也遇到過。找到類似的驅動對比自己的代碼往往能快速定位問題。比如寫I2C驅動就看drivers/i2c/下的其他驅動寫input驅動就看drivers/input/下的。最后保持對硬件的敬畏。軟件可以隨便改硬件改一次就是打板、焊接、調試成本高得多。所以驅動開發(fā)要盡量把硬件抽象做好讓硬件變化不影響上層軟件。設備樹就是干這個的用好設備樹你的驅動才能適應不同的硬件配置。這個方向后續(xù)還可以往內(nèi)核社區(qū)貢獻代碼把驅動提交到主線。雖然過程比較漫長要經(jīng)過多輪review但能學到很多規(guī)范和經(jīng)驗。我提交過幾個小驅動到主線reviewer的嚴格程度超出想象但改完之后代碼質量確實提升了一個檔次。 嵌入式驅動開發(fā)實戰(zhàn)：從設備樹到I2C驅動與內(nèi)核調試
1. 嵌入式驅動開發(fā)到底在做什么很多人第一次聽到“嵌入式驅動開發(fā)”這個詞腦子里浮現(xiàn)的畫面大概是一個人對著電路板焊臺冒著煙示波器上跳著波形然后屏幕上刷刷刷地滾著看不懂的寄存器地址。這個印象不算錯但只對了一半。嵌入式驅動開發(fā)的核心工作說白了就是讓操作系統(tǒng)能夠認識并控制硬件。CPU、內(nèi)存、GPIO、I2C、SPI、UART、USB、LCD、觸摸屏、WiFi模組、傳感器……這些硬件在操作系統(tǒng)眼里原本都是“陌生人”驅動就是給它們辦的身份證和操作手冊。我做了十多年嵌入式從8位單片機裸機跑到Cortex-A系列Linux驅動最大的感受是驅動開發(fā)不是“寫代碼”而是“翻譯”。你要把硬件手冊里那些時序圖、寄存器定義、電氣特性翻譯成內(nèi)核能理解的抽象接口。比如一個按鍵硬件上就是一個GPIO電平變化但內(nèi)核需要知道“這個GPIO對應哪個按鍵”“按下時是什么電平”“要不要消抖”“上報什么鍵值”。這一整套翻譯過程就是驅動開發(fā)。那這個方向適合誰呢如果你已經(jīng)會寫C語言能看懂簡單的電路圖用過STM32或者ESP32做過裸機項目那你就具備了入門的基礎。如果你還懂一點Linux用戶態(tài)編程知道文件操作、進程線程、設備節(jié)點這些概念那上手會更快。但如果你連指針和結構體都還寫不利索建議先把C語言基礎打牢否則看內(nèi)核源碼會很痛苦。驅動開發(fā)的價值在于它是硬件和軟件之間的唯一橋梁。沒有驅動再好的芯片也只是一塊硅片沒有驅動再牛的應用也跑不起來。而且這個方向的壁壘相對較高經(jīng)驗積累越深越吃香不是那種學三個月就能被替代的崗位。從智能家居、工業(yè)控制、汽車電子到機器人、醫(yī)療設備只要涉及硬件控制就離不開驅動開發(fā)。2. 驅動開發(fā)的核心知識體系拆解2.1 從裸機到Linux驅動的思維轉變很多從單片機轉過來的朋友第一個坎就是思維方式的轉變。裸機開發(fā)是“我直接操作寄存器”Linux驅動開發(fā)是“我告訴內(nèi)核怎么操作寄存器”。這個差別看起來小實際上影響巨大。裸機時代你寫一個按鍵掃描大概是這樣while(1) { if (GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) 0) { Delay_ms(20); if (GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) 0) { // 按鍵按下 while(GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) 0); // 按鍵釋放 } } }這種阻塞式掃描在裸機里沒問題因為整個系統(tǒng)就你一個任務。但在Linux里你絕對不能這么干。內(nèi)核里一個驅動阻塞了整個系統(tǒng)可能就卡死了。所以Linux驅動開發(fā)的核心思維是注冊、回調、異步、分層。你需要把按鍵注冊成一個輸入設備內(nèi)核的輸入子系統(tǒng)會幫你處理事件上報、消抖、重復按鍵等邏輯。你只需要在中斷處理函數(shù)里告訴內(nèi)核“這個鍵按下了”剩下的交給內(nèi)核。這就是分層的價值。2.2 字符設備、塊設備、網(wǎng)絡設備三大類Linux把設備分成三大類這個分類是理解驅動開發(fā)的骨架。字符設備是最常見的一類特點是按字節(jié)流訪問不支持隨機訪問。按鍵、串口、I2C、SPI、GPIO、LED、蜂鳴器這些基本都是字符設備。你打開/dev/ttyS0讀一個字節(jié)就是一個字節(jié)不能跳到第100個字節(jié)去讀。塊設備是按塊訪問的通常512字節(jié)或4KB為一個塊支持隨機訪問。硬盤、SSD、SD卡、NAND Flash、eMMC這些都是塊設備。塊設備的驅動比字符設備復雜得多因為要處理緩存、調度、合并請求等。網(wǎng)絡設備比較特殊它不走/dev節(jié)點而是通過socket接口訪問。WiFi、以太網(wǎng)、藍牙、CAN總線這些都屬于網(wǎng)絡設備。網(wǎng)絡設備的驅動要注冊net_device結構體實現(xiàn)ndo_start_xmit等回調函數(shù)。我剛開始學的時候總想把所有設備都往字符設備上套結果寫WiFi驅動的時候發(fā)現(xiàn)完全不是那么回事。后來才明白分類不是為了限制你而是為了給你提供合適的框架。選對了類別內(nèi)核會幫你做很多事選錯了你就得自己造輪子。2.3 設備樹硬件描述的標準化設備樹是嵌入式Linux驅動開發(fā)繞不開的話題。在設備樹出現(xiàn)之前硬件信息是硬編碼在驅動里的換個板子就要改驅動代碼非常麻煩。設備樹把硬件描述從驅動代碼里剝離出來用一套獨立的語法描述硬件資源。一個典型的設備樹節(jié)點長這樣i2c1 { status okay; clock-frequency 100000; eeprom50 { compatible atmel,24c02; reg 0x50; pagesize 16; }; };這段代碼的意思是I2C1控制器使能時鐘頻率100kHz掛了一個AT24C02 EEPROM地址是0x50頁大小16字節(jié)。驅動代碼里只需要匹配compatible屬性就能拿到這些硬件信息。設備樹的好處是一個驅動可以支持多個硬件配置。同樣的I2C EEPROM驅動換一個地址、換一個I2C控制器只需要改設備樹驅動代碼一行不用動。這在產(chǎn)品線豐富的公司里價值巨大。但設備樹也有坑。我踩過最深的坑是引腳復用配置。很多SoC的引腳是多功能的同一個引腳可以做UART、I2C、GPIO、PWM。設備樹里要正確配置pinctrl否則驅動加載了但引腳沒配對硬件就是不動。這個問題的排查方法后面會詳細講。2.4 并發(fā)與同步驅動開發(fā)的必修課Linux內(nèi)核是多任務、可搶占的驅動代碼可能同時被多個進程、多個中斷、多個CPU核心訪問。如果你不處理并發(fā)就會出現(xiàn)數(shù)據(jù)競爭、死鎖、內(nèi)存泄漏。內(nèi)核提供了多種同步機制機制適用場景特點自旋鎖短時間鎖定中斷上下文忙等待不能睡眠互斥鎖長時間鎖定進程上下文可以睡眠有優(yōu)先級繼承信號量資源計數(shù)可以睡眠適合生產(chǎn)者消費者完成量等待某個事件完成適合同步多個任務RCU讀多寫少讀端無鎖寫端延遲釋放原子操作簡單計數(shù)無鎖性能高我見過太多新手驅動里直接用一個全局變量做標志位不加任何保護結果跑壓力測試的時候隨機崩潰。并發(fā)問題最惡心的地方在于它不一定每次都出現(xiàn)可能跑一萬次才崩一次但產(chǎn)品出貨后就是災難。注意在中斷處理函數(shù)里絕對不能使用可能睡眠的鎖如互斥鎖、信號量否則會導致內(nèi)核崩潰。中斷上下文只能用自旋鎖或原子操作。3. 一個完整驅動項目的實操過程3.1 項目背景與需求分析假設我們要做一個嵌入式環(huán)境監(jiān)控項目需求是通過I2C接口讀取溫濕度傳感器比如SHT30通過GPIO控制一個風扇通過串口上報數(shù)據(jù)同時支持用戶態(tài)程序通過sysfs接口讀取當前溫濕度。這個項目雖然不大但涵蓋了驅動開發(fā)的幾個核心點I2C設備驅動、GPIO控制、字符設備接口、sysfs屬性、中斷處理風扇堵轉檢測。我拿這個項目當例子把完整流程走一遍。首先明確硬件連接SHT30掛在I2C1上地址0x44風扇控制引腳是GPIO1_15高電平轉動風扇堵轉檢測引腳是GPIO1_16下降沿觸發(fā)中斷調試串口是UART2波特率115200。3.2 設備樹配置與引腳復用設備樹是第一步也是最容易出錯的一步。先看I2C1的配置i2c1 { status okay; clock-frequency 100000; pinctrl-names default; pinctrl-0 i2c1_pins; sht30: sht3044 { compatible sensirion,sht30; reg 0x44; status okay; }; };然后是GPIO和中斷的配置gpio1 { fan_ctrl { gpio-hog; gpios 15 GPIO_ACTIVE_HIGH; output-low; line-name fan-ctrl; }; }; gpio1 { fan_detect: fan-detect { gpios 16 GPIO_ACTIVE_LOW; interrupt-parent gpio1; interrupts 16 IRQ_TYPE_EDGE_FALLING; debounce-interval 50; }; };這里有幾個關鍵點。gpio-hog表示內(nèi)核啟動時就把這個GPIO初始化為低電平防止風扇上電就轉。debounce-interval是硬件消抖50ms這個參數(shù)要根據(jù)實際風扇的抖動情況調整。我試過不設消抖結果風扇一轉就報一堆中斷CPU占用率飆升。引腳復用配置在pinctrl節(jié)點里pinctrl { i2c1_pins: i2c1-pins { pins { pinmux PINMUX_GPIO1_IO00__FUNC_I2C1_SCL, PINMUX_GPIO1_IO01__FUNC_I2C1_SDA; bias-pull-up; drive-strength 2; }; }; };bias-pull-up是I2C總線的上拉drive-strength是驅動能力。I2C總線如果沒有上拉波形會很難看通信不穩(wěn)定。我一般會在硬件上放4.7k的上拉電阻設備樹里再開內(nèi)部上拉作為備份。3.3 I2C驅動代碼實現(xiàn)I2C設備驅動的框架比較固定核心是probe函數(shù)和remove函數(shù)。先看結構體定義struct sht30_data { struct i2c_client *client; struct mutex lock; struct device *dev; int temperature; int humidity; };probe函數(shù)里要做幾件事分配數(shù)據(jù)結構、初始化鎖、注冊sysfs屬性、可能還要初始化硬件。static int sht30_probe(struct i2c_client *client, const struct i2c_device_id *id) { struct sht30_data *data; int ret; data devm_kzalloc(client-dev, sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; >static int sht30_read_data(struct sht30_data *data) { u8 cmd[2] {0x2C, 0x06}; u8 buf[6]; int ret; u16 temp_raw, humi_raw; mutex_lock(data-lock); ret i2c_master_send(data-client, cmd, 2); if (ret ! 2) { mutex_unlock(data-lock); return -EIO; } msleep(20); ret i2c_master_recv(data-client, buf, 6); if (ret ! 6) { mutex_unlock(data-lock); return -EIO; } temp_raw (buf[0] 8) | buf[1]; humi_raw (buf[3] 8) | buf[4]; >static ssize_t temperature_show(struct device *dev, struct device_attribute *attr, char *buf) { struct sht30_data *data dev_get_drvdata(dev); sht30_read_data(data); return sprintf(buf, %d\n,>cat /sys/bus/i2c/devices/1-0044/temperature cat /sys/bus/i2c/devices/1-0044/humiditysysfs的優(yōu)點是簡單直接缺點是每次讀都要觸發(fā)一次I2C傳輸頻繁讀取會影響性能。如果數(shù)據(jù)更新頻率高建議用字符設備或者input子系統(tǒng)。3.5 GPIO控制與中斷處理風扇控制用GPIO子系統(tǒng)struct gpio_desc *fan_gpio; fan_gpio devm_gpiod_get(dev, fan-ctrl, GPIOD_OUT_LOW); if (IS_ERR(fan_gpio)) { dev_err(dev, failed to get fan gpio\n); return PTR_ERR(fan_gpio); } gpiod_set_value(fan_gpio, 1);GPIOD_OUT_LOW表示初始輸出低電平風扇不轉。gpiod_set_value設置高電平風扇轉動。中斷處理static irqreturn_t fan_detect_isr(int irq, void *dev_id) { struct sht30_data *data dev_id; /* 上報堵轉事件 */ sysfs_notify(data-dev-kobj, NULL, fan_status); return IRQ_HANDLED; } ret devm_request_irq(dev, gpio_to_irq(fan_detect_gpio), fan_detect_isr, IRQF_TRIGGER_FALLING, fan-detect, data);中斷處理函數(shù)要盡量短不能做耗時操作。這里只是通知sysfs實際處理交給用戶態(tài)。sysfs_notify會喚醒阻塞在poll上的用戶態(tài)程序。3.6 編譯、加載與調試驅動編譯成模塊obj-m sht30.o KDIR : /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) all: $(MAKE) -C $(KDIR) M$(PWD) modules clean: $(MAKE) -C $(KDIR) M$(PWD) clean加載模塊insmod sht30.ko dmesg | tail -20如果probe成功dmesg會打印“sht30 probed successfully”。如果失敗根據(jù)錯誤碼排查。常見錯誤碼-ENODEV表示設備樹匹配失敗-EIO表示I2C通信失敗-EPROBE_DEFER表示依賴的資源還沒準備好。調試I2C通信可以用i2cdetect和i2cgeti2cdetect -y 1 i2cget -y 1 0x44 0x2C wi2cdetect能列出總線上所有設備地址如果0x44沒出現(xiàn)說明硬件連接或者引腳復用有問題。4. 常見問題與排查技巧實錄4.1 驅動加載失敗排查流程驅動加載失敗是最常見的問題我整理了一個排查流程現(xiàn)象可能原因排查方法insmod報錯“Invalid parameters”模塊參數(shù)錯誤檢查module_param定義probe函數(shù)沒被調用設備樹compatible不匹配對比驅動of_match_table和設備樹probe返回-ENODEV設備樹節(jié)點status不是okay檢查設備樹status屬性probe返回-EIOI2C/SPI通信失敗用i2cdetect/spidev_test驗證probe返回-EPROBE_DEFER依賴的驅動還沒加載檢查驅動加載順序內(nèi)核崩潰空指針或內(nèi)存越界看oops信息定位函數(shù)和行號我遇到最多的是-EPROBE_DEFER。比如I2C驅動依賴pinctrl驅動如果pinctrl還沒加載I2C驅動就會返回-EPROBE_DEFER內(nèi)核會稍后重試。這個機制是好的但如果你不知道會以為驅動有問題。解決方法是在設備樹里正確配置依賴關系或者調整驅動加載順序。4.2 I2C通信失敗的那些坑I2C通信失敗的原因很多我按概率排序第一是上拉電阻缺失。I2C總線必須有上拉通常4.7k到10k。有些開發(fā)板省了上拉電阻靠SoC內(nèi)部上拉但內(nèi)部上拉通常比較弱幾十k高速通信時波形上升沿太慢導致通信失敗。用示波器看SCL和SDA波形如果上升沿明顯變緩就是上拉不夠。第二是地址錯誤。7位地址和8位地址容易搞混。設備手冊上寫的0x44通常是7位地址但有些驅動代碼里用的是8位地址0x88。Linux I2C子系統(tǒng)用的是7位地址所以設備樹里寫0x44是對的。第三是時鐘頻率過高。100kHz是標準模式400kHz是快速模式1MHz是快速模式。但實際能跑多快取決于總線電容和上拉電阻。線越長、設備越多電容越大頻率就要降。我一般先用100kHz調通再逐步提高。第四是引腳復用沖突。同一個引腳被多個驅動申請后申請的會失敗。用cat /sys/kernel/debug/pinctrl/pinctrl-handles可以查看引腳占用情況。4.3 中斷丟失與消抖處理按鍵和堵轉檢測這類中斷最常見的問題是抖動導致多次觸發(fā)。機械開關的抖動時間通常是5ms到20ms風扇堵轉檢測的抖動可能更長。處理方法有三種硬件消抖RC電路、驅動消抖定時器、輸入子系統(tǒng)消抖。我推薦用輸入子系統(tǒng)的debounce-interval簡單可靠。如果自己寫驅動可以用定時器static void fan_detect_timer(struct timer_list *t) { struct sht30_data *data from_timer(data, t, detect_timer); int val gpiod_get_value(data-fan_detect_gpio); if (val 0) { /* 確認堵轉 */ sysfs_notify(data-dev-kobj, NULL, fan_status); } } static irqreturn_t fan_detect_isr(int irq, void *dev_id) { struct sht30_data *data dev_id; mod_timer(data-detect_timer, jiffies msecs_to_jiffies(50)); return IRQ_HANDLED; }中斷里只修改定時器50ms后定時器回調里再讀GPIO確認。這樣能過濾掉大部分抖動。注意定時器回調運行在軟中斷上下文不能睡眠不能用互斥鎖。如果需要睡眠操作用工作隊列workqueue代替。4.4 內(nèi)存泄漏與資源管理驅動里的內(nèi)存泄漏很隱蔽因為驅動通常長時間運行泄漏一點看不出來跑幾天幾個月才崩潰。我踩過的坑包括kmalloc后忘記kfree、request_irq后忘記free_irq、class_create后忘記class_destroy?，F(xiàn)在我都用devm_系列接口讓內(nèi)核自動管理資源devm_kzalloc代替kmallocdevm_request_irq代替request_irqdevm_gpiod_get代替gpio_requestdevm_ioremap代替ioremapdevm_接口的釋放順序是自動的而且跟設備生命周期綁定設備卸載時自動釋放不會漏。但要注意devm_分配的內(nèi)存不能在設備卸載后使用否則就是use-after-free。4.5 性能優(yōu)化與實時性考慮驅動性能優(yōu)化主要看兩個指標吞吐量和延遲。對于環(huán)境監(jiān)控這種應用吞吐量要求不高但延遲要穩(wěn)定。我做過測試同樣的I2C讀取用msleep和用usleep_range延遲差異很大。msleep的精度是10ms左右usleep_range可以到微秒級。SHT30轉換時間15ms用usleep_range(15000, 16000)比msleep(20)更精確整體讀取時間能縮短5ms左右。中斷處理延遲也很關鍵。如果中斷處理函數(shù)太長會影響系統(tǒng)實時性。我的原則是中斷處理函數(shù)只做最緊急的事其他都丟給工作隊列或線程化中斷。Linux支持request_threaded_irq把中斷處理分成上半部和下半部上半部快速返回下半部在進程上下文執(zhí)行可以睡眠。5. 驅動開發(fā)的進階方向與學習路線5.1 從字符設備到子系統(tǒng)框架學會寫字符設備驅動只是入門真正的進階是理解內(nèi)核子系統(tǒng)。輸入子系統(tǒng)、IIO子系統(tǒng)、V4L2子系統(tǒng)、ALSA子系統(tǒng)、網(wǎng)絡子系統(tǒng)、MMC子系統(tǒng)……每個子系統(tǒng)都是一套完整的框架幫你處理一類設備的共性邏輯。以IIO子系統(tǒng)為例溫濕度傳感器、加速度計、陀螺儀、ADC這些都屬于IIO。用IIO框架寫驅動你只需要實現(xiàn)read_raw回調剩下的緩沖區(qū)管理、觸發(fā)處理、sysfs接口、字符設備接口IIO都幫你做好了。代碼量能減少一半以上。我建議的學習路線是先寫一個簡單的字符設備驅動理解file_operations、cdev、設備號這些概念然后寫一個GPIO驅動理解gpiolib然后寫一個I2C驅動理解i2c_client和i2c_driver然后寫一個input驅動理解輸入子系統(tǒng)最后選一個復雜的子系統(tǒng)深入比如V4L2或者ALSA。5.2 設備樹與硬件描述的深入理解設備樹看起來簡單但坑很多。我見過有人把設備樹寫成這樣i2c40012000 { compatible vendor,i2c; reg 0x40012000 0x1000; clocks clk 10; status okay; };看起來沒問題但clocks的時鐘ID寫錯了導致I2C控制器時鐘頻率不對通信時好時壞。設備樹的調試沒有捷徑就是對著SoC手冊一個一個核對。還有一個常見問題是設備樹覆蓋overlay。產(chǎn)品開發(fā)中核心板設備樹是固定的底板設備樹用overlay動態(tài)加載。overlay的語法和普通設備樹略有不同而且加載順序有講究。我建議overlay只用于可插拔模塊核心硬件還是寫死在主設備樹里減少不確定性。5.3 內(nèi)核調試工具與方法驅動調試不能只靠printk雖然printk確實是最常用的。我常用的調試工具包括dev_dbg動態(tài)調試通過echo file sht30.c p /sys/kernel/debug/dynamic_debug/control開啟ftrace函數(shù)跟蹤看驅動函數(shù)的調用流程和耗時perf性能分析找熱點函數(shù)kprobe動態(tài)插樁不修改代碼就能查看變量值crash分析內(nèi)核崩潰轉儲文件ftrace是我用得最多的。比如懷疑probe函數(shù)耗時太長可以這樣echo function_graph /sys/kernel/debug/tracing/current_tracer echo sht30_probe /sys/kernel/debug/tracing/set_graph_function cat /sys/kernel/debug/tracing/trace_pipe它會打印出probe函數(shù)里每個子函數(shù)的調用時間和返回值一目了然。5.4 嵌入式AI與驅動開發(fā)的結合現(xiàn)在嵌入式AI很火但很多人忽略了一點AI模型跑在NPU或GPU上也需要驅動。NPU驅動要處理內(nèi)存分配、任務調度、中斷處理、電源管理這些跟傳統(tǒng)驅動開發(fā)一脈相承但復雜度更高。如果你有驅動開發(fā)經(jīng)驗轉向AI加速器驅動是一個很好的方向。你需要理解DMA、IOMMU、內(nèi)存一致性、緩存維護這些概念。比如NPU和CPU共享內(nèi)存時要處理cache一致性問題否則NPU算完的數(shù)據(jù)CPU讀到的還是舊值。解決方法是用dma_alloc_coherent分配一致性內(nèi)存或者手動調用dma_sync_single_for_cpu。這個方向的崗位需求在增長但門檻也高。我建議先把傳統(tǒng)驅動做扎實再往AI加速器方向延伸。5.5 面試準備與八股文整理嵌入式驅動開發(fā)的面試八股文主要集中在幾個方面內(nèi)核同步機制、內(nèi)存管理、中斷處理、設備模型、設備樹、總線驅動模型。我整理了一些高頻問題自旋鎖和互斥鎖的區(qū)別分別在什么場景下使用中斷上半部和下半部的區(qū)別工作隊列和tasklet的區(qū)別設備樹compatible屬性的匹配規(guī)則platform驅動和字符設備驅動的區(qū)別probe函數(shù)的調用時機和返回值含義內(nèi)核內(nèi)存分配函數(shù)kmalloc、vmalloc、kmem_cache_alloc的區(qū)別這些問題看起來是八股但背后都是實際開發(fā)中會遇到的問題。我面試別人的時候不會只問概念而是會追問“你在項目里怎么用的”“遇到過什么問題”“怎么解決的”。所以準備面試最好的方法不是背八股而是真正做過項目踩過坑總結過經(jīng)驗。6. 我個人的一些實操心得驅動開發(fā)這個方向入門曲線陡但一旦跨過去后面的路會越走越寬。我剛開始寫驅動的時候一個I2C驅動調了三天最后發(fā)現(xiàn)是設備樹里I2C控制器狀態(tài)沒寫okay。這種問題現(xiàn)在看起來很低級但當時就是找不到。我的經(jīng)驗是驅動調試要有耐心要相信硬件沒問題問題一定在軟件配置。大部分驅動問題都是配置問題不是代碼邏輯問題。設備樹、時鐘、引腳復用、電源域這四個地方檢查一遍能解決80%的問題。另外多看內(nèi)核源碼里的同類驅動。內(nèi)核源碼里drivers目錄下有幾千個驅動你遇到的問題別人大概率也遇到過。找到類似的驅動對比自己的代碼往往能快速定位問題。比如寫I2C驅動就看drivers/i2c/下的其他驅動寫input驅動就看drivers/input/下的。最后保持對硬件的敬畏。軟件可以隨便改硬件改一次就是打板、焊接、調試成本高得多。所以驅動開發(fā)要盡量把硬件抽象做好讓硬件變化不影響上層軟件。設備樹就是干這個的用好設備樹你的驅動才能適應不同的硬件配置。這個方向后續(xù)還可以往內(nèi)核社區(qū)貢獻代碼把驅動提交到主線。雖然過程比較漫長要經(jīng)過多輪review但能學到很多規(guī)范和經(jīng)驗。我提交過幾個小驅動到主線reviewer的嚴格程度超出想象但改完之后代碼質量確實提升了一個檔次。