LV15-01-点亮LED-01-基础知识

发表于 分类于 ， ， 本文字数： 4.2k 阅读时长 ≈ 15 分钟

本文主要是点亮LED——基础知识的相关笔记，若笔记中有错误或者不合适的地方，欢迎批评指正😃。

点击查看使用工具及版本
PC端开发环境 Windows Windows11
Ubuntu Ubuntu20.04.6的64位版本（一开始使用的是16.04版本，后来进行了升级）
VMware® Workstation 17 Pro 17.0.0 build-20800274
终端软件 MobaXterm(Professional Edition v23.0 Build 5042 (license))
Win32DiskImager Win32DiskImager v1.0
Linux开发板环境 Linux开发板 正点原子 i.MX6ULL Linux 阿尔法开发板
uboot NXP官方提供的uboot，NXP提供的版本为uboot-imx-rel_imx_4.1.15_2.1.0_ga(使用的uboot版本为U-Boot 2016.03)
linux内核 linux-4.15(NXP官方提供)
点击查看本文参考资料
分类 网址 说明
官方网站 https://www.arm.com/ ARM官方网站，在这里我们可以找到Cotex-Mx以及ARMVx的一些文档
https://www.nxp.com.cn/ NXP官方网站
https://www.nxpic.org.cn/NXP 官方社区
https://u-boot.readthedocs.io/en/latest/u-boot官网
https://www.kernel.org/linux内核官网
点击查看相关文件下载
分类 网址 说明
NXP https://github.com/nxp-imx NXP imx开发资源GitHub组织，里边会有u-boot和linux内核的仓库
https://elixir.bootlin.com/linux/latest/source 在线阅读linux kernel源码
nxp-imx/linux-imx/releases/tag/rel_imx_4.1.15_2.1.0_ga NXP linux内核仓库tags中的rel_imx_4.1.15_2.1.0_ga
nxp-imx/uboot-imx/releases/tag/rel_imx_4.1.15_2.1.0_ga NXP u-boot仓库tags中的rel_imx_4.1.15_2.1.0_ga
I.MX6ULL i.MX 6ULL Applications Processors for Industrial Products I.MX6ULL 芯片手册（datasheet，可以在线查看）
i.MX 6ULL Applications ProcessorReference Manual I.MX6ULL 参考手册（下载后才能查看，需要登录NXP官网）

一、应用层操控硬件的两种方式

在 Linux 系统下，一切皆文件。应用层如何操控底层硬件，同样也是通过文件 I/O 的方式来实现，前面我们学习设备文件，包括字符设备文件和块设备文件，为啥叫设备文件？其实设备文件便是各种硬件设备向应用层提供的一个接口，应用层通过对设备文件的 I/O 操作来操控硬件设备，譬如 LCD 显示屏、串口、按键、摄像头等等，所以设备文件其实是与硬件设备相互对应的。

设备文件通常在/dev/目录下，我们也把/dev 目录下的文件称为设备节点。设备节点并不是操控硬件设备的唯一途径，除此之外，我们还可以通过 sysfs 文件系统对硬件设备进行操控， 接下来将进行学习！

1. sysfs 文件系统

简单的说， sysfs 是一个基于内存的文件系统， 同 devfs、 proc 文件系统一样，称为虚拟文件系统； 它的作用是将内核信息以文件的方式提供给应用层使用。 前面中我们学习过 proc 文件系统， 应用层可以通过proc 文件系统得到系统信息和进程相关信息，与 proc 文件系统类似， sysfs 文件系统的主要功能便是对系统设备进行管理，它可以产生一个包含所有系统硬件层次的视图。

sysfs 文件系统把连接在系统上的设备和总线组织成为一个分级的文件、 展示设备驱动模型中各组件的层次关系。 sysfs 提供了一种机制，可以显式的描述内核对象、对象属性及对象间关系， 用来导出内核对象(kernel object，譬如一个硬件设备)的数据、属性到用户空间，以文件目录结构的形式为用户空间提供对这些数据、属性的访问支持。下表描述了内核对象、对象属性及对象间关系在用户空间 sysfs 中的的表现：

内核中的组成要素 sysfs 中的表现
内核对象（例如一个硬件设备） 目录
对象属性（例如设备属性） 文件
对象关系 链接文件

2. sysfs 与/sys

sysfs 文件系统挂载在/sys 目录下，启动 ALPHA/Mini I.MX6U 开发板，进入 Linux 系统（开发板出厂系统） 之后，我们进入到/sys 目录下查看，如下所示：

image-20240902200341919

上图显示的便是 sysfs 文件系统中的目录，包括 block、 bus、 class、 dev、 devices、 firmware、 fs、 kernel、modules、 power 等，每个目录下又有许多文件或子目录，对这些目录的说明如所示：

image-20240902200954862

系统中所有的设备（对象）都会在/sys/devices 体现出来，是 sysfs 文件系统中最重要的目录结构；而/sys/bus、 /sys/class、 /sys/dev 分别将设备按照挂载的总线类型、功能分类以及设备号的形式将设备组织存放在这些目录中，这些目录下的文件都是链接到了/sys/devices 中。

设备的一些属性、数据通常会通过设备目录下的文件体现出来，也就是说设备的数据、属性会导出到用户空间，以文件形式为用户空间提供对这些数据、属性的访问支持， 可以把这些文件称为属性文件； 读这些属性文件就表示读取设备的属性信息，相反写属性文件就表示对设备的属性进行设置、以控制设备的状态。

3. 总结

应用层想要对底层硬件进行操控，通常可以通过两种方式：

  • dev/目录下的设备文件（设备节点） ；
  • /sys/目录下设备的属性文件。

具体使用哪种方式需要根据不同功能类型设备进行选择，有些设备只能通过设备节点进行操控，而有些设备只能通过 sysfs 方式进行操控；当然跟设备驱动具体的实现方式有关，通常情况下，一般简单地设备会使用 sysfs 方式操控，其设备驱动在实现时会将设备的一些属性导出到用户空间 sysfs 文件系统，以属性文件的形式为用户空间提供对这些数据、属性的访问支持，譬如 LED、 GPIO 等。但对于一些较复杂的设备通常会使用设备节点的方式， 譬如 LCD 等、触摸屏、摄像头等。

二、标准接口与非标准接口

Linux 内核中为了尽量降低驱动开发者难度以及接口标准化，就出现了设备驱动框架的概念； Linux 针对各种常见的设备进行分类，例如 LED 类设备、输入类设备、 FrameBuffer 类设备、 video 类设备、 PWM 设备等等，并为每一种类型的设备设计了一套成熟的、标准的、典型的驱动实现的框架， 这个就叫做设备驱动框架。

设备驱动框架为驱动开发和应用层提供了一套统一的接口规范， 例如对 LED 类设备来说， 内核提供了 LED 设备驱动框架，驱动工程师编写 LED 驱动时，使用 LED 驱动框架来开发自己的 LED 驱动程序，这样做的好处就在于，能够对上层应用层提供统一、标准化的接口、 同时又降低了驱动开发工程师的难度。

编写 LED 驱动程序并不仅仅只能使用内核设计的 LED 设备驱动框架，不用内核的 LED 驱动框架也是可以开发出 LED 驱动程序的，但如果这样写，使用这个驱动程序注册的 LED 那就不是标准设备了， 因为该驱动程序向应用层提供的接口并不是统一、 标准化接口。

除此之外，还有很多硬件外设，尤其是嵌入式系统中所使用到的这些硬件外设，它们可能并不属于 Linux 系统所规划的设备分类当中的任何一种设备类型，例如在 Linux 系统中，有一种设备类型叫杂散/杂项类设备（misc device），可以想一想为啥叫杂散类设备，说明这种设备既不属于这种设备类型、又不属于另一种设备类型，无奈只能把它归为杂项类。

因为一个计算机系统所能够连接、使用的外设实在太多了，不可能每一种外设都能够精准地分类到某一个设备类型中，通常把这些无法进行分类的外设就称为杂项设备，杂项设备驱动程序向应用层提供的接口通常都不是标准化接口、它是一种非标准接口，具体如何去操控这个设备通常只有驱动工程师知道。所以在嵌入式系统中，很多硬件外设的驱动程序都是定制的。

三、LED 硬件控制方式

1. sysfs控制LED

1.1 控制说明

ALPHA I.MX6U 开发板底板上有一颗可被用户控制的 LED 灯，如下所示：

image-20240902201340398

上图中箭头所指的 LED 便是开发板上唯一一个可以被用户所控制的 LED， 另外一颗 LED 则（名称为PWR）是底板上的电源指示灯。

对于 ALPHA I.MX6U 开发板出厂系统来说， 此 LED 设备使用的是 Linux 内核标准 LED 驱动框架注册而成， 在/dev 目录下并没有其对应的设备节点，其实现使用 sysfs 方式控制。 进入到/sys/class/leds 目录下，如下所示：

image-20240902201451385

上小节介绍了/sys/class 目录，系统中的所有设备根据其功能分类组织到了/sys/class 目录下，所以/sys/class/leds 目录下便存放了所有的 LED 类设备。从上图可以看到该目录下有一个 sys-led 文件夹， 这个便是底板上的用户 LED 设备文件夹，进入到该目录下，如下所示：

image-20240902201548602

这里我们主要关注便是 brightness、 max_brightness 以及 trigger 三个文件，这三个文件都是 LED 设备的属性文件：

  • brightness： 翻译过来就是亮度的意思， 该属性文件可读可写； 所以这个属性文件是用于设置 LED的亮度等级或者获取当前 LED 的亮度等级，譬如 brightness 等于 0 表示 LED 灭， brightness 为正整数表示 LED 亮，其值越大、 LED 越亮； 对于 PWM 控制的 LED 来说， 这通常是适用的，因为它存在亮度等级的问题，不同的亮度等级对应不同的占空比，自然 LED 的亮度也是不同的； 但对于 GPIO控制（控制 GPIO 输出高低电平）的 LED 来说，通常不存在亮度等级这样的说法，只有 LED 亮（brightness 等于 0）和 LED 灭（brightness 为非 0 值的正整数）两种状态，ALPHA I.MX6U 开发板上的这颗 LED 就是如此，所以自然就不存在亮度等级一说，只有亮和灭两种亮度等级。
  • max_brightness： 该属性文件只能被读取，不能写，用于获取 LED 设备的最大亮度等级。
  • trigger： 触发模式，该属性文件可读可写，读表示获取 LED 当前的触发模式，写表示设置 LED 的触发模式。 不同的触发模式其触发条件不同， LED 设备会根据不同的触发条件自动控制其亮、灭状态， 通过 cat 命令查看该属性文件，可获取 LED 支持的所有触发模式以及 LED 当前被设置的触发模式：
image-20240902201728489

方括号（[heartbeat]）括起来的表示当前 LED 对应的触发模式， none 表示无触发，常用的触发模式包括none（无触发）、 mmc0（当对 mmc0 设备发起读写操作的时候 LED 会闪烁）、 timer（LED 会有规律的一亮一灭，被定时器控制住）、 heartbeat（心跳呼吸模式， LED 模仿人的心跳呼吸那样亮灭变化）。

通常系统启动之后，会将板子上的一颗 LED 设置为 heartbeat 触发模式，将其作为系统正常运行的指示灯，例如 ALPHA I.MX6U 开发板系统启动之后，底板上的用户 LED 就会处于心跳呼吸模式，这个我们自己观察便可知道。

1.2 相关命令

1
2
3
4
5
cd /sys/class/leds/sys-led
echo timer > trigger # 将 LED 触发模式设置为 timer
echo none > trigger  # 将 LED 触发模式设置为 none
echo 1 > brightness  # 点亮 LED 
echo 0 > brightness  # 熄灭 LED

我们可以自己动手使用 echo 或 cat 命令进行测试、控制 LED 状态； 除了使用 echo 或 cat 命令之后，同样我们编写应用程序，使用 write()、read()函数对这些属性文件进行 I/O 操作以达到控制 LED 的效果。

Tips：命令 cat 读取以及 echo 写入到属性文件中的均是字符串，所以如果在应用程序中通过 write()向属性文件写入数据，同样也要是字符串形式；同理，使用 read()读取的数据也是字符串 ASCII 编码的。

2. I/O控制

这一部分就是通过open、close、read、write、ioctl等函数来操作LED驱动，进而控制LED灯。