rt-thread 驱动篇之 serialX 阻塞超时返回

发布于 2023-08-21 08:41:08 浏览：1371 订阅该版

[tocm]

## 前言

尽管仍然很多痴男怨女在 v1 v2 身上跌倒、跌倒、继续跌倒，仍然阻止不了他们飞蛾扑火式的被 v1 v2 的缺陷所吸引而殉情。

它一如既往的保持着优良的特性，也有可能是很多人没发现，主要是接受它的人很少。不过，这不影响今天它带来新的特性。

### 阻塞超时

我们一直强调，它有与之前非同一般的两个概念“阻塞”“非阻塞”。虽然 v2 热火朝天的提出了这两个概念，但是实现的效果却不尽人意。

在之前的正式文档里，我没胆量承认一个事实，那就是，**阻塞读在无数据可读的时候将永远阻塞下去**。某些应用场景并不希望这样，我们希望等待某设备响应，若干时间后无响应超时，我们返回继续做其它工作，而不是被无响应的设备永久占用。

给某些论坛提问里的解答时，我提到过几次 serialX 可以通过以下技术手段应对这种场景。

#### 方法一

使用非阻塞模式打开，超时读过程伪代码可能如下这样：
```
while(timeout > 0) {
    read
    sleep 1
    timeout -= 1
}
if (timeout == 0) {
// timeout here
} else {
// no timeout
}
```

#### 方法二

使用完成中断 indicate 回调函数发消息，这也是官方提供的读串口设备的“标准”方式
```
static void serial_thread_entry(void *parameter)
{
    char ch;

while (1)
    {
        /* 从串口读取一个字节的数据，没有读取到则等待接收信号量 */
        while (rt_device_read(serial, -1, &ch, 1) != 1)
        {
            /* 阻塞等待接收信号量，等到信号量后再次读取数据 */
            rt_sem_take(&rx_sem, timeout);
        }
        ...
    }
}
```

> 注：此段代码改编自官方文档

大多数人第一次使用 rtt 的串口设备也是用这段代码测试的。但是，serialX 不提倡大家使用 indicate 回调函数。

serialX 有它自己的特性，它有它自己的优美性，那就是尽可能不给应用层代码带来麻烦，不要写太复杂难懂的逻辑，不要给应用层引入莫名未知的后果。

我们希望在不影响不改变之前的使用的前提下，`rt_device_read` 能够在预定的时间内超时返回退出，并不是用于阻塞下去，同时 `rt_device_read` 返回 `-RT_ETIMEOUT` 错误码。应用层可以根据 `rt_device_read` 返回值
- == 0 无数据
- > 0 有数据
- < 0 有错误（`-RT_ETIMEOUT` 超时）
分别处理不同情况。

#### serialX 的实现

首先，`rtdef.h` 添加定义，用于设备超时配置
```
#define RT_DEVICE_CTRL_TIMEOUT          0x30            /**< timeout for blocking */
```

其次，`struct rt_serial_device` 添加 `rt_tick_t timeout_tick;` 变量，设备超时时间 tick 。

然后，`rt_serial_control` 函数添加超时配置宏选项处理
```
    case RT_DEVICE_CTRL_TIMEOUT:
        rt_tick_t timeout_tick = (rt_tick_t)args;
        serial->timeout_tick = timeout_tick;
    break;
```

最后，在 `serialX.c` 文件中所有涉及到阻塞的地方（包括读写，不包含 flush）修改 `rt_completion_wait` 第二个参数为 `serial->timeout_tick`。并当 `rt_completion_wait` 返回 `-RT_ETIMEOUT` 时退出当前读写操作返回应用层。

> 注意：特别说明，我们希望一个设备以阻塞模式打开时，默认的阻塞超时时间是“永久”，所以，每次 `rt_device_open` 后 serialX 设定阻塞超时时间时间是 `RT_WAITING_FOREVER` 。如果需要指定某超时时间需要 `rt_device_control(serial_dev, RT_DEVICE_CTRL_TIMEOUT, &timeout);`

```
    rt_tick_t timeout = 50;

if (rt_device_open(scpi_uart_dev, RT_DEVICE_OFLAG_RDWR
                               | RT_DEVICE_FLAG_INT_RX
                               | RT_DEVICE_FLAG_INT_TX
                               | RT_DEVICE_OFLAG_BLOCKING) != RT_EOK)
    {
        rt_kprintf("Open device: %s failed\n", UART_DEV_NAME);
        return;
    }

rt_device_control(serial_dev, RT_DEVICE_CTRL_TIMEOUT, &timeout);

rt_ssize_t ret = rt_device_read(serial_dev, -1, &recvbuf[0], 128);
    if (ret == -RT_ETIMEOUT) {
        rt_device_close(serial_dev);
        return;
    } else {

}
```

这就是今天我们要讲的第三种方法，相比前两种，这种方法更优雅些，代码逻辑也清晰。

## 总结

欢迎大家入坑 serialX。

13 条评论

嚜軒公告 2023-08-21

努力中

CharlesX 2023-08-21

Make science fiction science

iron_cdw 2023-08-21

这家伙很懒，什么也没写！

StackYuan 2023-08-23

这家伙很懒，什么也没写！

出出啊 2023-08-23

恃人不如自恃，人之为己者不如己之自为也

Tamap 2023-09-08

这家伙不懒，签名都写了

出出啊 2023-09-08

恃人不如自恃，人之为己者不如己之自为也

林子哈 2023-11-04

这家伙很懒，什么也没写！

看了你写的源码，知道为啥很人多还是用V1和V2了，里面代码还是很多可以删减优化的，太多用户需要关心的宏，

如：RT_SERIAL_HARD_FIFO就应该在驱动适配的时候去设置就可以，RT_SERIAL_USE_EVENT没用直接删除，`struct rt_uart_ops`没必要定义那么多，
如    `int (*flush)(struct rt_serial_device *serial);`是不需要驱动适配的去关心的，在框架中自己实现就可以了，

还有
- `void (*enable_interrupt)(struct rt_serial_device *serial);`
- `void (*disable_interrupt)(struct rt_serial_device *serial);`
这两个实际源码不用就删除，原则，既然开源出来首先代码风格要相对简洁，然后增加的

```c
struct rt_device_ops
{
    /* common device interface */
    rt_err_t  (*init)   (rt_device_t dev);
    rt_err_t  (*open)   (rt_device_t dev, rt_uint16_t oflag);
    rt_err_t  (*close)  (rt_device_t dev);
    rt_ssize_t (*read)   (rt_device_t dev, rt_off_t pos, void *buffer, rt_size_t size);
    rt_ssize_t (*write)  (rt_device_t dev, rt_off_t pos, const void *buffer, rt_size_t size);
    rt_err_t  (*control)(rt_device_t dev, int cmd, void *args);
    rt_err_t  (*flush)  (rt_device_t dev);
};
```
其中`rt_err_t  (*flush)  (rt_device_t dev); `完全可以用`rt_err_t  (*control)(rt_device_t dev, int cmd, void *args);`替代，或者直接内部实现了，竟然是在rtt平台上面，就应该本着兼容性的原则添加你觉的造福大家的驱动，而且这个增加是没有必要的，特里独行有时不是好的。