rt-thread 驱动篇之 serial v1 v2 和 X 10.00

发布于 2022-04-10 16:10:25 浏览：5037 订阅该版

[tocm]

## 前言

本周笔者花了好多天的时间，计划从多个方面对串口驱动做个比较。下面就从以下几个角度做个对比测试。
1. 工作模式对照
2. close open 测试
3. poll 发送测试
4. flush 支持测试
5. 非阻塞收发测试
6. 阻塞收发测试
7. 回环测试数据丢失率

其它未测试项：stream 支持，因为 v1 v2 只有 poll 模式支持， serialX 可以全模式支持，这一项未进行对比。

### 测试环境

- rt-thread 4.1.0
- STM32F429-ATK-APOLLO
- 串口收发缓存均设定 128 字节

#### 工作模式对照

| 版本 | poll收发 | 阻塞/非阻塞 | 驱动层缓存 | DMA支持 | STREM 支持 |
| :--: | :------: | :---------: | :--------: | :-----: | :--------: |
|  v1  |    Y     |      -      |     -      |    Y    |   仅poll   |
|  v2  |    Y     |      *      |     Y      |    Y    |   仅poll   |
|  X   |    Y     |      Y      |     Y      |    Y    |   全模式   |

> \* v2 对阻塞概念的认识，仅认为是降低 cpu 耗用。

#### close & open 测试

测试过程：

1. 先用 poll 模式打开，打开失败直接返回；成功输出 "POLL modeopen opened\n" 。
2. 输出 "CLOSE & REOPEN\n" 。关闭串口设备，再用中断收发模式打开，打开失败直接返回；成功输出 "INT mode opened\n" 。
3. 最后循环关闭打开 1百万次。打开失败直接返回。
4. 测试通过，使用 poll 模式打开串口设备，并输出 "REOPEN successfull\n"。准备进入下一项测试。

|   版本   |  v1  |  v2  |  X   |
| :------: | :--: | :--: | :--: |
| 测试结果 | 通过 | 通过 | 通过 |

#### poll 发送测试

用 poll 模式打开串口，发送若干数据。

|   版本   |  v1  |  v2  |  X   |
| :------: | :--: | :--: | :--: |
| 测试结果 | 通过 | 通过 | 通过 |

#### flush 支持测试

如果没有 flush ，驱动缓存的数据可能没有完全输出到外设，这个时候 close 设备可能出现丢失部分数据。

使用 flush 的目地就是保证驱动层缓存数据完全输出到外设，之后对设备的任何操作不会影响之前的数据。

|   版本   |   v1   |   v2   |  X   |
| :------: | :----: | :----: | :--: |
| 测试结果 | 不支持 | 不支持 | 通过 |

> 因为 v1 不支持非阻塞发送，也没有驱动层缓存，write 总是把最后一个字节写到串口移位寄存器后才返回。所以 v1 不会出现丢失数据的现象。

> v2 在这一环节的表现和 v1 是一样的，大家可以猜猜原因是啥。

**注：本部分为了测试 flush 特性有效性，因此 X 出现 close 的时候出现丢数现象。使用版在 close 设备的时候应该强制 flush 一下的。**

#### 非阻塞收发测试

使用中断非阻塞模式打开串口设备，发送 10k 左右数据量，同时测量一下时间。

| 数据量 |         v1         |         v2         |         X          |
| :----: | :----------------: | :----------------: | :----------------: |
| 102400 | 102400 / 9762ticks | 102400 / 8863ticks | 102400 / 8863ticks |
| 10240  |  10240 / 976ticks  |  10240 / 876ticks  |  10240 / 876ticks  |
|  128   |   128 / 12ticks    |   128 / 11ticks    |   128 / 11ticks    |

这部分测试大体上符合预期，因为有缓存，v2 和 X 先把数据放到缓存中就返回了。这样可以减少发送等待时间。

#### 阻塞收发测试

| 数据量 |         v1         |         v2         |         X          |
| :----: | :----------------: | :----------------: | :----------------: |
| 102400 | 102400 / 9762ticks | 102400 / 8902ticks | 102400 / 8866ticks |
| 10240  |  10240 / 976ticks  |  10240 / 890ticks  |  10240 / 884ticks  |
|  128   |   128 / 12ticks    |   128 / 11ticks    |   128 / 11ticks    |

> v1 在非阻塞和阻塞两种模式下的表现是一样的，因为它没有阻塞概念。
>
> v2 耗时比 v1 少，这是在预料中的，但是，它还是比 X 多了几个 tick 。这也是上文中工作模式对照部分对它的阻塞/非阻塞特性加 \* 的原因。

特别测试，当每次写小于串口驱动层缓存大小的数据时，

| 数据量 |   v2    |   X    |
| :----: | :-----: | :----: |
|   16   | 1ticks  | 0ticks |
|   32   | 5ticks  | 0ticks |
|  128   | 11ticks | 0ticks |

为什么出现了和上面表格不一样的结果，因为这次测试，每次写之前有个 1s 延时，保证串口缓存是空的。**当串口缓存大小是 N 前提下，每次 write 小于等于 N 数量的数据应该可以直接写到缓存，并立马返回！**所以，对于 X 来说耗时就是 **0**。

这个很重要，**当我们用串口调试程序，需要打印一些信息的时候，又不希望因为串口输出数据影响到其它业务的时序，或者，最大限度地降低因串口输出数据而影响其它程序执行时序**。

#### 回环测试数据丢失率

使用阻塞模式打开串口设备。这次通过串口调试助手以 20ms 的定时间隔，发送 384 字节数据。

|  版本  |           v1           |           v2           |         X          |
| :----: | :--------------------: | :--------------------: | :----------------: |
| 丢失率 | 671144 / 556848/17.03% | 1208816/1070464/11.45% | 2390800/2390800/0% |

> v2 在这一步表现很差，第一次，笔者应用层缓存是 512 字节，想 `rt_device_read(uart, -1, recvbuf, 512);` 发现 read 不到任何数据，read 也不阻塞了，而是总能返回，单步进去看到，但接收的数据大于驱动缓存的时候，驱动拒绝处理，直接返回0！！！v2 的缺陷之一。
>
> 鉴于以上原因，之后改成 `rt_device_read(uart, -1, recvbuf, 128);` 应用缓存和驱动缓存大小相等。
>
> 手动单次发送，一次发送 344 字节数据（多于驱动缓冲大小），接收 256 字节，再次发送，接收 384 字节，第三次发送接收还是 256 字节，第四次又变成 384字节。

即便考虑到 v2 的上述缺陷，最多有 127 个字节数据被“滞留”串口驱动缓存里未及时返回。也弥补不了上述丢失率！

### 开启 DMA 的表现

很遗憾，v1 只支持 DMA 接收不支持 DMA 发送（估计以后也用不上 v1 了），由以上对比测试我们发现 v2 和 v1 很类似，在测试 v2 DMA 接收发送时也发现总体效果和使用中断没多少差异。

X 的表现如何呢？等待您的发现！

> 遗憾的是，笔者对 STM32 的 HAL 极其不熟悉，又极其不想用 HAL 。花了很长时间想自己通过寄存器配置实现，最终没成功，还是放弃了。
>
> HAL 有一个好处，那就是几乎可以适配 STM32 所有系列芯片。但是，HAL 不是为 OS 而生的 `#error "USE_RTOS should be 0 in the current HAL release"`，在 OS 上用终究有可能遇到失锁的问题。
>
> 使用 HAL 还有个小小的瑕疵，那就是 `is_dma_txing` 判断变得不友好，无奈之下，笔者在 `struct stm32_uart` 中添加了个 `rt_bool_t dmaTxing;` 变量 —— ”HAL 中 gState 和 RxState 已经够多了“ 。算是目前的一个小遗憾吧。

### 结束语

最后，依旧公开测试代码，本次测试使用的代码可以在 [serialX](https://gitee.com/thewon/serialX) 仓库找到。近期，笔者也会将 serialX 提交到 rt-thread 主仓库。

提前预告，下次我们来聊聊 serialX 在做控制台串口时遇到的问题已经解决方案（包括使用中断 DMA 收发模式打开的串口设备）。

[rt-thread 驱动篇 之 serialX 全网公测](https://club.rt-thread.org/ask/article/3362.html)

aozima 打赏了 5.00 元 2022-04-10 17:01:30
andychen 打赏了 5.00 元 2022-04-11 10:48:59

15 条评论

crystal266 2022-04-10

嵌入式

mysterywolf 2022-04-11

https://github.com/mysterywolf

armink 2022-04-11

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

Acuity 2022-04-11

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

出出啊 2022-04-12

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

@123 “串口调试助手以 20ms 的定时间隔，发送 384 字节数据”
这就是测试条件，场景很复杂？请通篇看全所有说明

> 首先说一下，做升级首要还是兼容性，用户无感最重要，否则做的再好也是一堆诟病。比别人多长两只手，别人觉得是异类而非super man.

文章最后一句预警了兼容性问题，请通篇看全所有说明

> 你要知道为什么 stream 只支持poll，而且有且仅有支持poll。你觉得支持起来会很难么？为什么不支持上去，也没有人提pr说要支持呢？

为什么一直没支持，看我下一篇文章。没人提 pr 就没人提 issue ？去 github 上翻翻 issue 吧。

> “v2 对阻塞概念的认识，仅认为是降低 cpu 耗用。”这是你的原话，而代码上阻塞实现了INT阻塞和DMA阻塞，且有大量同步IPC在内部，实在不清楚你这句话怎么理解的。

您理解的阻塞是什么概念？poll 就是阻塞？用上中断和 ipc 就是非阻塞？驱动缓存干嘛用的？当驱动缓存足够用的时候，缓存不缓存，还要等待缓存所有数据清空再返回应用，这是非阻塞？这是阻塞！！！当使用 9600 波特率的时候，每发送一个字节需要耗时 1.1 ms！！！您觉得调试输出十个八个字符信息的时候，应用程序被耽误10ms的时间，而去掉调试信息就少这10多ms时间，这个是非阻塞？

> “v1 只支持 DMA 接收不支持 DMA 发送”，v1支持DMA发送和接收，你要看过代码肯定知道有对应的接口，只是驱动上没有支持而已，建议把框架和驱动分清楚，什么事情是框架管的，什么事情是驱动该管的。

框架和驱动是绝缘的？驱动是建立在框架基础之上的！驱动严重依赖框架的设计理念！框架没有的概念，驱动能变出花来？

> DMA的行为和中断差太多了，而且发送和接收使用的模式也不一样，一个是循环一个是单次触发，为了实现统一，框架上把两者行为统一了起来，无非就是byte和bytes的区别，剩下的由驱动的管理，当然有个标志定义的有些牵强，但也能用。

> flush 确实是没有支持的，当初考虑的是等着和POSIX一起完善上去就先delay了，不仅这个flush，还有更完善的POSIX、RTS CTS硬件流控都没弄好。

没有支持的不仅仅是 flush

> 最初设计我也是想着硬件无关性，只把阻塞非阻塞弄好就行了（类似linux设备树那样配置，其他用户不要关心了）。最后妥妥被现实打脸，只谈操作行为不谈硬件行为就是耍流氓，所以才有后边的模式和硬件来回配置的操作，这个后边是可以优化的更好的。

模式和硬件来回配置的操作是最要不得的，不然要什么框架和驱动的区别，一起搞好了。既然分开了还要高强度耦合，这不是掩耳盗铃吗？

> 任何平台都要有应用场景的前提，所以测试丢包率很高也可能是正常的，所以框架层我留了大量API进行对接，方便驱动做符合自己应用场景的适配，或者在应用程序上动手脚（但不建议）。

这段话说的最有道理，“测试丢包率很高也可能是正常”，测试通不过，怎么经得起实际应用的考验？怎么放心用在产品上？丢包的原因在哪儿没搞清楚，就先认为是正常的？！
“框架层我留了大量API进行对接，方便驱动做符合自己应用场景的适配”，您的意思是每个人使用 v2 的时候，都要根据自己是实际情况修改，改成适用自己应用场景的？那让大家用什么 v2 都自己从头写一套**框架和驱动**好了。

> 测试方法，说了很多遍，测试方法和应用场景有关：单串口下：
（1） 在允许丢包的情况下，各个模式的波特率最高达到多少，满足丢包率<5%,
（2） 在不允许丢包的情况下，各个模式的波特率最高达到多少，使得丢包率0%；
 多串口下测试并发情况类似，最少使用三个串口进行测试。

测试方法我也说的很详细，测试很简单。没有人看不懂我的测试过程吧。单串口，无应用，单单收发测试都有丢包，是什么原因引起的数据丢失？发送方？数据线？芯片串口外设？还是 rt-thread 内核不够实时？还是串口框架设计有缺陷？