rt-thread 驱动篇（三） serialX 压力测试-电子发烧友网

前言

本周笔者花了好多天的时间，计划从多个方面对串口驱动做个比较。下面就从以下几个角度做个对比测试。
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 已经够多了“ 。算是目前的一个小遗憾吧。