企业官网建设流程全解析

很多做嵌入式Linux的朋友，都是从“点灯”这一步开始接触驱动开发的。我当年拿到一块新板子，第一件事就是翻原理图、找LED对应的GPIO引脚，然后想着怎么在Linux里把它点亮。结果上来就踩了一个大坑——在裸机上点灯，你只需要把某个寄存器的某一位写成1；到了Linux驱动里，同样的操作却要牵扯设备树、pinctrl、GPIO子系统、platform驱动、miscdevice，概念一个接一个，很容易写着写着就不知道自己在干嘛。

这篇内容就围绕“基于GPIO子系统的LED驱动”完整过一遍：从硬件原理图如何翻译成设备树，到驱动主文件怎么写，再到用户态一条ioctl命令如何一路打通到底层引脚。适合两类读者：一类是刚学驱动、看过裸机但还没建立内核资源管理概念的人；另一类是驱动能insmod但LED就是不亮、正在四处排查的人。看完你会对“驱动到底在驱动什么”这件事有一个更清晰的答案。

1. 裸机思维和Linux驱动思维的分水岭：引脚不是你的私有财产

1.1 裸机点灯：一连串寄存器操作的背后

先回忆一下裸机点灯的动作。拿到原理图，找到LED接在哪个GPIO上，然后翻芯片手册做三件事：配置引脚复用为GPIO功能、配置方向为输出、往数据寄存器写0或1。整个过程就是“物理地址+位操作”，很直接，也很自由。

这套思维迁移到Linux里，第一个诱惑就是：既然GPIO寄存器的物理地址是固定的，那我直接在驱动里ioremap一段物理地址，然后对着寄存器赋值不就行了？很多初学驱动的人第一版代码都是这么写的，我也一样。代码确实能编译，甚至在某些板子上真能把灯点亮。但问题在于，这只在“没有其他驱动跟你抢引脚”的时候成立。

现代SoC里，一颗引脚功能非常复杂：它可能同时连着UART的TXD、I2C的SCL、PWM的输出、定时器的捕获引脚，以及普通GPIO。引脚最终表现成哪种功能，由IOMUX或PAD配置寄存器的某几个bit决定。如果你的驱动绕过内核的资源管理，直接去改复用寄存器，会出现什么情况？内核里的其他驱动、中断子系统、电源管理模块都对这颗引脚的真实状态一无所知。假如系统里另一段代码也认为这颗引脚归它管，两边同时写同一个寄存器，灯就会莫名其妙闪或者完全不响应。

GPIO子系统不是简单的“寄存器封装库”，它是内核提供的一套引脚资源管理协议。它的核心价值不是帮你少写两行寄存器操作，而是让每一个驱动都能回答三个问题：这颗引脚现在归谁用、当前方向是什么、输出或输入状态怎么变化。对应到代码层面，就是gpiochip、gpio_desc、gpiod_*这一整套抽象。

1.2 初学阶段最常见的三个认知误区

我见过很多人在这一阶段反复绕圈，基本都卡在这三个误区里。

第一个误区：把GPIO子系统当成寄存器操作的“高级封装”，以为学它只是为了少写几行代码。实际上，GPIO子系统的核心是两级结构：底层是gpiochip，也就是芯片里的GPIO控制器驱动，负责具体的寄存器读写；上层是consumer API，也就是gpiod_get、gpiod_set_value这一组函数，供普通驱动调用。你写LED驱动时，永远站在consumer的位置，不需要关心物理寄存器地址，只需要告诉内核“我需要哪个引脚、用来干什么”。这套接口的真正目的，是让资源申请、方向配置、状态读写、释放清理全部走统一路径，避免驱动之间互相踩脚。

第二个误区：以为设备树里写的数字就是“GPIO全局编号”。老版本的gpio_request接口里确实需要一个整数编号，很多人因此以为设备树里的<&gpio3 14 GPIO_ACTIVE_LOW>就是在说“全局320号GPIO”。这是把DTB中的描述和内核运行时编号搞混了。实际上，设备树里写的是三部分：phandle引用（指向哪个gpio控制器）、偏移（控制器内部的第几路）、标志位（是否低有效等）。内核在运行时解析这个描述，动态分配一个gpio_desc，整个过程中不存在“全局GPIO号”这个概念。用新接口gpiod_get拿到的也是struct gpio_desc*，而不是int。

第三个误区：以为GPIO子系统就是全部，不知道pinctrl的存在。GPIO子系统只管控制器和引脚状态，不管“引脚复用成GPIO功能”。从芯片硬件角度，一颗引脚要先配置成GPIO模式（这一步属于pinctrl子系统），然后才能被GPIO控制器接管。很多驱动明明gpiod_get成功、寄存器配置也写了，但引脚没反应，根因就是设备树里漏了pinctrl-0属性，或者复用配置写成了UART功能。我一直建议把GPIO子系统和pinctrl子系统当成一个组合来学，不要拆开。

2. 从原理图到设备树：接线事实怎么翻译成内核听得懂的<&gpioX N flags>

2.1 按原理图回答三个问题

写驱动之前，先回到硬件原理图。不管板子多复杂，控制一颗LED的关键信息就三个：它接在哪个GPIO控制器、哪一路、点亮时的电平。

第一个问题，LED的公共端接法决定有效电平。如果LED阳极串联电阻接电源，阴极接到GPIO引脚，那么GPIO输出低电平才能让电流流过，这就是“低有效”；反过来，阳极接GPIO、阴极接地，就是“高有效”。原理图这东西看起来不起眼，但决定着你设备树里写GPIO_ACTIVE_HIGH还是GPIO_ACTIVE_LOW，写错了整个驱动镜像反着来。

第二个问题，确认引脚有没有经过三极管或驱动芯片。部分硬件设计里，MCU引脚不直接驱动LED，而是通过一个NPN三极管。这时GPIO输出高电平让三极管导通，LED才亮，实际有效电平又是高有效，但不能简单看LED接法，还得看三极管的接法。我建议把所有中间器件都画到纸上写一遍逻辑，别省这一步。

第三个问题，确认这颗引脚是否被其他外设复用。很多板子的BSP里，UART、LCD、网卡、SD卡默认占用了一堆引脚。如果你选中的LED引脚正好被某个外设默认配置占用了，即使你驱动代码没问题，dmesg里也会出现pin busy之类提示。所以先查板级设备树里有没有其他节点引用了相同引脚，这一步能少走很多弯路。

2.2 设备树节点：自定义compatible加led-gpios属性

学习阶段我强烈建议自己写一个“自定义节点”，不要一上来就套内核的gpio-leds标准框架。自定义节点能逼着你理解compatible匹配、phandle引用、GPIO描述这三个关键概念，而标准框架把这些细节都藏起来了。

一个最小设备树节点长这样：

/ { myled { compatible = "myboard,led"; pinctrl-names = "default"; pinctrl-0 = <&led_pins>; led-gpios = <&gpio3 14 GPIO_ACTIVE_LOW>; status = "okay"; }; };

逐行拆开看。compatible字段用来和驱动里的of_device_id匹配，内核看到这个节点后，会为它创建一个platform_device，然后去找compatible相同的platform_driver。名字本身没有特殊含义，但必须有，而且驱动和设备树要严格一致。

led-gpios是GPIO consumer属性的标准写法。属性名的规则是“名字-gpios”，这里con_id就是led。属性值分三段：第一段是phandle，指向某个gpio控制器节点，比如<&gpio3>；第二段是控制器内部的偏移量，也就是第14路；第三段是GPIO标志位。GPIO_ACTIVE_LOW这个宏定义在include/dt-bindings/gpio/gpio.h里，值是1，含义是“这颗LED是低电平点亮”。这段描述的意义在于，把“哪颗引脚”和“怎么算有效”告诉内核，之后你调用gpiod_set_value(desc, 1)时，内核知道要往物理引脚上输出低电平。

2.3 pinctrl：这颗引脚的“第二张身份证”，漏了就白配

GPIO节点只告诉内核“引脚归哪个控制器”，但没告诉硬件“引脚要从其他功能切换成GPIO功能”。这一步由pinctrl子系统完成。在设备树里，它表现为pinctrl-0属性。

&pinctrl { led_pins: ledgrp { pinctrl-single,pins = < 0x001A0 0x00000218 >; }; };

这里的写法因SoC厂商而异，有的用fsl,pins，有的用pinctrl-single,pins，但本质都一样：指定某个物理引脚，并配置它的复用模式、上下拉、驱动强度。第一项0x001A0是引脚偏移，第二项0x00000218是pad配置值。这两项不是通用的，必须查你手头芯片的pinctrl手册，照抄别人的设备树很容易出错。

我遇到过不少朋友，驱动代码写得有模有样，设备树节点也写了led-gpios，就是没写pinctrl-0，结果引脚一直保持复位后的默认状态，怎么点都不亮。加上pinctrl配置后，dmesg里能明显看到引脚复用信息变化，问题立刻解决。记住一句话：gpiochip管理“之后”的事，pinctrl管理“之前”的事，两者缺一不可。

3. 驱动代码设计：一个不到200行的platform_driver加miscdevice实现

3.1 为什么用platform_driver，而不是直接register_chrdev

设备树里有了myled节点，内核在启动阶段就会把这个节点变成platform_device，挂在platform总线上。所以驱动里对应选择platform_driver，通过compatible匹配，匹配成功后内核回调probe函数。这是“驱动和设备如何见上面”的标准流程。

有些人不理解，说“我直接register_chrdev，自己创建设备节点不行吗？”技术上当然可以，很多课程早期的杂项设备示例也是这么做的。但问题是这样的驱动不知道自己在为哪个硬件服务：它没有设备树节点，没有匹配关系，probe阶段拿不到任何硬件信息。如果一个系统里有多个外部接线的LED，驱动就无法区分哪个是哪个。数据结构的分离是有道理的：设备树描述硬件，驱动操作硬件，platform总线负责把两者配对。只有建立在配对关系上的代码，才谈得上“可扩展、可维护”。

这里选择platform_driver的另一个好处是probe时机。GPIO控制器本身也是一个驱动，它可能在你的LED驱动之后才加载完。如果设备树里的gpio3还没就绪，devm_gpiod_get会返回-EPROBE_DEFER，内核会自动记住这个依赖，等GPIO控制器驱动注册后再重新probe你的驱动。这种自动重试机制，是裸写register_chrdev做不到的。

3.2 完整驱动代码与逐段解释

直接给一份能用的精简实现。头文件、ioctl命令定义、platform匹配、probe、fops、module入口，全套放一起：

#include <linux/module.h> #include <linux/platform_device.h> #include <linux/of.h> #include <linux/gpio/consumer.h> #include <linux/miscdevice.h> #include <linux/uaccess.h> #include <linux/fs.h> #include <linux/ioctl.h> #define LED_MAGIC 'E' #define LED_ON _IOW(LED_MAGIC, 1, int) #define LED_OFF _IOW(LED_MAGIC, 2, int) static struct gpio_desc *led_desc; static int led_open(struct inode *inode, struct file *filp) { return 0; } static ssize_t led_read(struct file *filp, char __user *buf, size_t count, loff_t *ppos) { char val; if (count < 1) return 0; val = gpiod_get_value(led_desc) ? '1' : '0'; if (copy_to_user(buf, &val, 1)) return -EFAULT; return 1; } static long led_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) { if (_IOC_TYPE(cmd) != LED_MAGIC) return -ENOTTY; switch (cmd) { case LED_ON: gpiod_set_value(led_desc, 1); break; case LED_OFF: gpiod_set_value(led_desc, 0); break; default: return -EINVAL; } return 0; } static const struct file_operations led_fops = { .owner = THIS_MODULE, .open = led_open, .read = led_read, .unlocked_ioctl = led_ioctl, }; static struct miscdevice led_miscdev = { .minor = MISC_DYNAMIC_MINOR, .name = "myled", .fops = &led_fops, }; static int led_probe(struct platform_device *pdev) { int ret; led_desc = devm_gpiod_get(&pdev->dev, "led", GPIOD_OUT_LOW); if (IS_ERR(led_desc)) { dev_err(&pdev->dev, "failed to get led gpio: %ld\n", PTR_ERR(led_desc)); return PTR_ERR(led_desc); } ret = misc_register(&led_miscdev); if (ret < 0) { dev_err(&pdev->dev, "misc register failed: %d\n", ret); return ret; } dev_info(&pdev->dev, "LED driver probed\n"); return 0; } static int led_remove(struct platform_device *pdev) { misc_deregister(&led_miscdev); return 0; } static const struct of_device_id led_of_match[] = { { .compatible = "myboard,led" }, { } }; MODULE_DEVICE_TABLE(of, led_of_match); static struct platform_driver led_driver = { .probe = led_probe, .remove = led_remove, .driver = { .name = "myled", .of_match_table = led_of_match, }, }; module_platform_driver(led_driver); MODULE_LICENSE("GPL");

几个关键点逐个说。probe函数里第一步调用devm_gpiod_get，第一个参数是设备结构体，第二个参数con_id填“led”，它会自动去设备树里找“led-gpios”这个属性。第三个参数GPIOD_OUT_LOW表示拿到GPIO后立即把它设为输出，初始逻辑状态是低。这一步非常实用，LED在驱动加载瞬间就处于可控的灭灯状态，避免复位时乱闪。

devm前缀的意思是设备资源管理。驱动不需要自己调用gpiod_put，设备被移除或驱动出错时，内核会自动释放GPIO请求。这种写法能避免泄漏，也是现代内核推荐的风格。IS_ERR判断不能省，设备树缺属性、GPIO控制器没就绪、引脚被占用时，都会在这里返回错误。

3.3 open/ioctl/read：用户态接口只暴露“开”和“关”

miscdevice在这里起到的作用很单纯：注册一个主设备号为10、次设备号动态分配的字符设备，自动在/dev下生成myled节点。相比自己调用alloc_chrdev_region、cdev_init、class_create、device_create那一大串，miscdev把样板代码压缩到了最小。教学场景、简单外设控制场景用miscdevice完全够用，也更聚焦在GPIO本身。

三个fops函数都非常小。open函数可以什么都不做，直接返回0。一个LED本来就没什么状态要初始化，强行在里面塞一堆逻辑反而是过度设计。read函数返回当前逻辑状态，用户态读一个字符就能知道灯是亮是灭。注意gpiod_get_value返回的是“逻辑状态”，它内部已经考虑了active-low翻转，驱动这边不需要自己再判断硬件接法。

ioctl函数里，我没有使用已经废弃的.ioctl成员，而是用.unlocked_ioctl。这是当前内核的标准做法，Linux在2.6系列以后就不再使用内核大锁来串行化ioctl了，驱动自己负责并发安全。LED操作本身就是简单的寄存器赋值，天然原子，不用担心锁的问题。一组LED_ON、LED_OFF命令就足够覆盖点灯需求，如果你还想支持闪烁，可以扩展一个周期参数，但初版驱动越简单，越容易验证基础链路。

4. 一次点亮请求的内核之旅：从ioctl到引脚输出寄存器

4.1 用户态到驱动的边界：VFS把ioctl送进file_operations

假设用户态程序执行了ioctl(fd, LED_ON, 0)，这条命令会先进入内核的sys_ioctl，然后根据fd找到对应的struct file，再从file指向的file_operations里找到unlocked_ioctl这个函数指针，调用进led_ioctl。整个过程就是一次普通的VFS派发，misc设备节点和普通文件在路径上没有任何区别。

这也解释了为什么驱动里的ioctl命令要自己定义魔法数、命令号。内核并不知道你的LED_ON是什么意思，它只负责把cmd这个整数原样传给驱动。驱动拿到cmd后，按约定解析，发现是开灯，于是调用gpiod_set_value(led_desc, 1)。注意，这里传的是“逻辑值1”，至于物理引脚上输出的是高还是低，由GPIO描述符内部的active-low标志决定，驱动完全不用管。

4.2 gpiod_set_value内部做了什么

gpiod_set_value的消费流程大概分几步：先通过desc->gflags检查GPIO是否有效、方向是否输出、是否支持睡眠操作，然后把desc转发给对应gpiochip的.set方法，最后执行底层寄存器赋值。这个过程中，内核还会做一次active-low翻转：如果desc标记了FLAG_ACTIVE_LOW，逻辑高对应的物理电平就是低。

我们设备树里写的是GPIO_ACTIVE_LOW，所以gpiod_set_value(desc, 1)最终让引脚输出物理低电平，正好点亮LED。这套逻辑对驱动作者极其友好：你描述硬件时声明“这灯是低有效”，之后在代码里就永远只说“我要点亮它”，不用反复去记反相。

4.3 为什么我劝你别往回用gpio_set_value老接口

网上老教程特别多，一搜遍地都是int gpio = 123; gpio_request(); gpio_set_value()那套，很多人顺手就抄进项目里了。如果你在5.x或更晚的内核上开发，我劝你别这么干。理由有三条。

老接口没有逻辑值与物理电平的自动转换。你设备的LED是低有效，老接口就得自己写电平翻转，非常容易写出“代码看着没错、灯就是反着亮”的bug。老接口基于全局整数编号，这个编号在不同内核版本、不同设备树状态下不稳定，可移植性差。最关键的是，老接口在新内核里处于deprecated状态，虽然还在，但文档里已经明确不推荐使用。新项目就应该从gpiod_*系列开始，这是内核社区给出的方向。

4.4 底层硬件瞬间：方向、输出寄存器和电平转换

驱动调完gpiod_set_value后，底层gpiochip的set回调会把值写到GPIO控制器的数据寄存器。比如某控制器第14路对应输出寄存器的bit14，代码执行到这里就是一次纯粹的位运算加一次寄存器写。单条写操作是原子的，所以不用担心并发问题。

但整个链路里还有一个容易忽略的环节：引脚的方向和pad配置。我们调用devm_gpiod_get时传了GPIOD_OUT_LOW，gpiolib在request阶段已经帮你把方向设为输出了。但如果某个驱动在运行时调用gpiod_direction_input改变方向，LED立刻就会变成无效状态。这类问题在单片机裸机时代几乎不可能出现，因为代码全都是你自己写的；到了Linux驱动环境，一个系统里有几十个驱动，它们之间的资源冲突排查难度会大很多。这也是我一直强调“用子系统、看上下文”的原因，你永远不知道还有谁在操作同一颗引脚。

5. 编译加载与实测：insmod之前和之后要做的事

5.1 Makefile的内核树变量，交叉编译常犯的错

驱动模块必须链接到内核源码树才能编译，不能独立编译。一个最简Makefile长这样：

KERN_DIR ?= /lib/modules/$(shell uname -r)/build obj-m += led_drv.o all: make -C $(KERN_DIR) M=$(PWD) modules clean: make -C $(KERN_DIR) M=$(PWD) clean

桌面Linux上，只要装了对应内核开发包，直接make就能编出.ko。嵌入式开发板则需要交叉编译。做法是在make时传ARCH和CROSS_COMPILE，比如：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

常见的坑是仅仅传了CROSS_COMPILE，但KERN_DIR指向的是x86开发机的内核源码树，这样编出来的模块是x86架构的，放到ARM板子上insmod时直接报“Invalid module format”或者内核版本不匹配。正确做法是KERN_DIR指向你开发板所对应内核版本的源码目录，并且这个目录已经配置过目标架构。判断方法也很简单：编完后用file命令查一下.ko文件格式，确认是ARM ELF还是x86 ELF。

5.2 一套可复用的验证流程

驱动编译好只是第一步，我建议每次按固定顺序验证，别跳步。

先把新设备树编进dtb，替换开发板的/boot下的dtb文件并重启。启动后先确认设备树节点是不是真的进入内核了，可以在/deb/ 下检查我不确定路径；正式做法是到/sys/firmware/devicetree/base下找同名节点，或者用设备树dump工具。节点存在了，再insmod led_drv.ko。insmod没有报错只代表模块加载成功，不代表probe成功，所以紧接着必须看dmesg。

如果一切正常，dmesg里会出现“LED driver probed”这一行，同时/dev/myled节点出现。这时用一个小测试程序验证：

#include <fcntl.h> #include <sys/ioctl.h> #include <stdio.h> #include <unistd.h> #include <linux/ioctl.h> #define LED_MAGIC 'E' #define LED_ON _IOW(LED_MAGIC, 1, int) #define LED_OFF _IOW(LED_MAGIC, 2, int) int main(int argc, char **argv) { int fd = open("/dev/myled", O_RDWR); if (fd < 0) { perror("open"); return 1; } if (argc > 1 && argv[1][0] == '1') ioctl(fd, LED_ON, 0); else ioctl(fd, LED_OFF, 0); close(fd); return 0; }

编译后先执行关灯、再执行开灯，观察LED状态变化。到这一步LED能正常开关，说明用户态、设备节点、驱动、GPIO子系统、pinctrl、硬件电路串联起来了。

5.3 几个高频报错的定位思路

验证过程我最常被问到的问题集中在下面几个现象，整理成一张表方便排查：

强调一个细节：-EPROBE_DEFER不是失败，它其实是一种“我正在等别的驱动就绪”的信号。第一次probe时GPIO控制器可能在依赖顺序上还没加载完，内核发现GPIO芯片没就绪就会返回这个值，后续会自动重新probe。你别自己在驱动里把它当成错误直接卸载模块。

6. 点亮之后，你应该立刻做的三件事

6.1 对照内核的gpio-leds标准驱动重写一遍

自定义驱动跑通后，建议立刻对照标准驱动加深理解。Linux里已经有一个通用的gpio-leds驱动（drivers/leds/leds-gpio.c），它通过led-class框架提供/sys/class/leds接口。对应设备树写起来也很简单：

leds { compatible = "gpio-leds"; work-led { label = "work"; gpios = <&gpio3 14 GPIO_ACTIVE_LOW>; linux,default-trigger = "none"; }; };

内核看到compatible为gpio-leds，会加载标准驱动，在/sys/class/leds/work/下生成brightness节点。想点亮就是echo 1 > /sys/class/leds/work/brightness，想灭灯就是echo 0。这个框架的好处是：不用重新编译驱动，不用自己写ioctl，应用层直接操作sysfs就能控制状态，还有default-trigger机制，可以让LED在心跳、网络流量等事件下自动闪烁。

学习它的意义在于，你要看到“自己写驱动只是手段，不是目的”。一个新功能出现时，先想想内核里有没有现成框架，如果通用框架能满足需求，优先用通用框架。只有框架没有覆盖到你的硬件差异时，才值得从零写一个带设备树的自定义驱动。

6.2 把操作对象从“自己定义”变成“标准抽象”

自定义驱动里，你用自己的ioctl命令控制LED，设备和应用之间约定死的。gpio-leds则是把“开关”抽象成一个同步的brightness文件，谁都可以读写。从Linux哲学来看，后一种设计更“社区化”，因为它把外设能力收敛成了公共接口，上层可以用统一的工具去操作。

这一点在做真实项目时特别重要。一份完善的BSP里，可能同时存在几十个LED，分别用于电源指示、联网指示、告警指示、心跳闪烁。如果每个LED都写一个自定义字符驱动，应用层代码就会变成一片混乱的ioctl管脚。用led-class框架，应用层只需要按label找到目录写brightness，驱动的差异全部被隐藏。这也是我一直强调“先学自定义驱动、再跳回通用框架”的原因：你只有亲手写过一遍，才能理解标准框架替你解决了哪些问题。

6.3 GPIOD之后，按什么顺序学中断、pinctrl和模拟协议

GPIO子系统这边打通了，下一步的学习路线建议按下面顺序走。

第一站是中断子系统。按键是最典型的场景，你要学会gpiod_to_irq拿到中断号，然后用request_irq或request_threaded_irq注册回调，配合debounce处理按键抖动。这一步会让你理解GPIO不仅用于输出，还承担输入事件源的工作。

第二站是pinctrl的进阶。除了配置引脚复用，你还要理解sleep状态、偏置配置、驱动强度这些参数怎么影响高速信号和低功耗。实测时可以用万用表或示波器观察引脚电平，对比不同pad配置下的波形变化。

第三站是用GPIO模拟低速协议。I2C、SPI、1-Wire都能用GPIO软件模拟，学一遍bitbang实现，外设协议栈、时序、ack机制这些概念就全串起来了。你会发现之前学的GPIO API只是起点，真正值钱的是“拿GPIO去理解上层协议如何与硬件打交道”这种能力。

我自己的体会是，驱动开发学到最后，拼的不是你会背多少API，而是你对“硬件怎么工作”和“内核怎么管理资源”这两个问题理解到多深。LED驱动这条路虽然起点低，但带给你的思考模型，足够支撑后面走很远。

最后分享一个很土但有效的排查习惯：每次写完设备树改动，先重启，再确认设备树节点真的出现在运行时环境中，然后才去碰驱动代码。顺序反了的话，你会把设备树的错也算到驱动头上，越查越乱。这个习惯帮我省下的时间，远比它多花的那几分钟要多。