rt-thread 驱动篇（七）GPIO驱动-电子发烧友网

前言

一提 GPIO 可能会让很多人觉得不屑，这么简单的东西有什么可说的，也就是一个拉低拉高，谁不会呢。

今天我们不讲推挽开漏、不提上拉下拉。大家来头脑风暴一下 GPIO 相关的几个问题。笔者说的不一定对，仅代表个人的一点儿小想法。

提出两个问题

有两个问题，需要考虑一下：
1. pin 设备驱动框架存在的必要性。
2. gpio 底层驱动使用官方提供的 api 还是直接寄存器操作？

在单片机里，pin 引脚操作往往很简单，写一个寄存器就成。但是在一个操作系统里，为了方便移植、便于阅读，对 pin 进行封装，在不同芯片上使用同一套 api 也还是有必要的。而这也正是一个操作系统的职责之一。

第二个问题，留着大家自己想吧。

pin 驱动框架

我们大家都知道，在我们使用 pin 的时候，没有谁先用 `rt_device_find` 查找 pin 设备，然后使用用 `rt_device_open` `rt_device_read` `rt_device_write` 去控制芯片引脚。而都是直接调用的 `rt_pin_xxx` c 函数簇。

pin 驱动框架，先把所有的 gpio 看作一个设备进行注册，然后提供了三个 `rt_pin_mode` `rt_pin_read` `rt_pin_write` c 函数，而不是 `rt_device_xxx` api 去访问某个 pin。
`rt_pin_mode` `rt_pin_read` `rt_pin_write` 这一套函数，可以不用考虑当前使用的是什么芯片，不用考虑芯片厂商提供的外设驱动库 api 是怎么写的。但是，真的是这样吗？

可以把驱动框架删掉，`rt_pin_xxx` 函数直接对接底层驱动吗？

当笔者阅读模拟 iic 驱动源码时，看到在控制 SCL SDA 高低电平切换时使用的 `rt_pin_write` 操作，一时间脑子一阵晕眩。为什么？我们先捋顺一下拉低 SDA 的函数调用过程。

以 `SDA_L` 为例
1. `SDA_L` 宏是 `ops->set_sda(ops->data, val)` 通过操作符指针调用底层接口，
2. `set_sda` 调用 `rt_pin_write`
3. `rt_pin_write` 通过 pin 设备执行 `_hw_pin.ops->pin_write` 调用的 pin 底层接口
4. 在 stm32 平台上 `_hw_pin.ops->pin_write` 等于调用 `stm32_pin_write` 函数
5. `stm32_pin_write` 调用 `HAL_GPIO_WritePin`
6. `HAL_GPIO_WritePin` 函数写寄存器。

弯弯绕绕，想控制 pin 引脚电平变化还真是煞费苦心了。

可以压缩上述调用过程吗？
`SDA_L` 宏直接定义调用 `stm32_pin_write` ，`stm32_pin_write` 内部直接操作寄存器。

soft iic 驱动

软件模拟 iic 驱动需要软件代码控制 SCL SDA 两根线时序，如前所述，拉低 SDA 线的过程被繁冗化了。

裸机能达到的 iic 时钟速度，在使用 rt-thread 的模拟 iic 时根本达不到，在多级指针和函数调用过程中，效率被极大降低了。

有没有一种策略，使 `SDA_L` 宏直接定义成 `stm32_pin_write` 或者 `gd32_pin_write` 等等。

笔者尝试把 i2c-bit-ops.c 文件和 drv_soft_i2c.c 两个文件进行合并，省掉了一级 `struct rt_i2c_bit_ops`，然后 `SDA_L` 也不使用 `rt_pin_write` 又跳过了多次指针调用。目前感觉良好。

GET_PIN

有哪位能告诉大家， `rt_pin_write(17, PIN_HIGH)` 这句代码有明确的语义吗？

函数调用中的第一个参数值 “17” 表示了什么？
可能啥也不代表。
首先，它肯定不是芯片引脚编号。
大多数芯片，GPIO 编码采用的类似如下方式：
- 以端口编码，一颗芯片上的 GPIO 可以分成若干个端口，用字母 A B C ... 命名（也有 1 2 3 编号命名的，比如 RA6M4）。我们称之为 PA PB PC ...
- 每个端口有8/16个 io 。分别编码 0-7 或者 0-15。有些芯片上的某个端口只有 15 个 io ，那就只有 0-14 有效。我们称之为 PA0 PA15

为了不使用魔数 “17” ，这种模棱两可，含义不明的写法，rt-thread 针对每种芯片要求定义一个 `GET_PIN` 宏，它可以从一种直观的引脚编号写法中返回一个数字。比如 `GET_PIN(G, 1)` 的结果是 97。

使用 `GET_PIN` `rt_pin_write(17, PIN_HIGH)` 可以写成 `rt_pin_write(GET_PIN(B, 1), PIN_HIGH)` ，这样是不是更直观了？

但是，有一种情况，不允许我们用 `GET_PIN` 。那就是在 menuconfig 或者 RT-Studio 的 Settings 里配置模拟 iic 两个引脚号的时候。它只支持输入数字，这个时候我们必须知道 `GET_PIN` 的数学含义，心算把 `GET_PIN(B, 1)` 转成 17 。

`GET_PIN` 的数学含义是确定的吗？是放之四海而皆准的吗？在每一款芯片上可以使用同一个数学公式演算吗？

**这个可以是，但实际却不是**。

另类的 AB32 RA6M4 N32

我们仍然以 17 这个编号为例，下面来看看 AB32 RA6M4 上面它分别代表哪个 GPIO 。

AB32 上应该是 PE4。
AB32 版 `GET_PIN` 是这样的:

#define __AB32_PORT(port)   GPIO##port
#define __AB32_GET_PIN_A(PIN)  PIN
#define __AB32_GET_PIN_B(PIN)  8 + PIN
#define __AB32_GET_PIN_E(PIN)  13 + PIN
#define __AB32_GET_PIN_F(PIN)  21 + PIN

几个端口不通用，各自为战

RA6M4 上不存在。因为 RA6M4 的 P100 对应的是 256 ；P015 对应的是 15 。没有 17 这个编号。
AB32 版 `GET_PIN` 未实现。

还有 N32，上面笔者说了句“它肯定不是芯片引脚编号”。但是，我又发现在 N32 的drv_gpio.c 中，定义成了芯片引脚号。打脸了...
N32 版 `GET_PIN` 也未实现。

还有其它芯片是上述三种情况之外的吗？欢迎大家讲出来。

明确的应用层语义

不失一般性，假设可能存在某芯片端口编号不是连续的，中间缺失端口B。同时端口 A 也只有 12 个 io。我们把所有的端口和 io 进行排序编号。PA0 是 0 号、PA1 是 1 号 ... PA11 是 11 号。那么，PC0 编号是多少？12吗？

假如有一同系列芯片，它是有端口 B 的。那么 PB0 编号该定义成多少合适呢？也是 12 吗？

> 或者，干脆我们就假定所有的芯片端口都是连续无缺失的，每个端口也是满满当当 16 个 io 。这样 PB0 总是 16，PC0 总是 32。

从理论上讲，所有的芯片 gpio 编号系统是可以用一个公式实现的，这个公式可以在 rt-thread 使用宝典（2022-0516更新）中找到。

RA6M4 上，应用程序层可以使用 17 表示 P101，因为它的端口编号从 0 开始；
N32 上，应用程序层可以使用 17 表示 PB01，因为它的端口编号从 A 开始；
STM32 上，应用程序层可以使用 17 表示 PB01，因为它的端口编号从 A 开始；
AB32 上，应用程序层可以使用 17 表示 PB01，因为它的端口编号从 A 开始

无论用的哪家芯片，无论是哪个系列芯片，无论是哪款型号，它有多少引脚。我们希望 17 这个值能对应一个明确的引脚名。不会因为某系列芯片中某子型号因为其中某个端口 io 数量少一个导致后面所有 io 的编号都变了。又或者同样的 PB01 在不同子型号不同封装下的编号也不一样。