rt-thread 驱动篇（二） serialX 理论实现
前言 “serialx” 我起的名字，起个名字想破头。
在前一篇文章里，大致提出了我的串口驱动框架理论。里面做了一些对串口驱动特性的幻想。也在 nuc970 芯片下通过了中断模式的实践验证。但是，因为 nuc970 的 uart 自带 fifo 。用它测试效果好，并不能真正说明驱动框架通过验证了。
然后，紧接着笔者在 stm32f429 完成了中断和 dma 两种模式。今天，我把一些测试结果和移植说明发出来，征求全网公测。
测试配置：dma 二级缓存 32 个字节，串口收发缓存各 512 字节。
注：本串口驱动工作特性请参阅前一篇文章rt-thread 驱动篇（一） serialx 框架理论
stm32 中断模式测试 以下是三组连续发收测试：
1. 定时间隔20ms，发送250字节数据，持续发送2600w，接收发送数据量相等
2. 定时间隔50ms，发送250字节数据，持续发送600w，接收发送数据量相等
3. 定时间隔80ms，发送1000字节数据，持续发送600w，接收发送数据量相等
注：刚刚跟我们小伙伴求证了一下，串口调试助手的定时间隔是固定周期。如果是这样的，以上测试是有意义的，如果不是，那就没达到串口带宽上限。
stm32 dma模式测试 1. 读写测试，串口调试助手定时 10ms ，发送40字节数据，持续发送129w
2. 串口调试助手定时 50ms ，发送500字节数据，持续发送527w
3. 串口调试助手定时 40ms ，发送500字节数据，持续发送261w
4. 串口调试助手定时 40ms ，发送1000字节数据，持续发送262w
串口调试助手上发送和接收数量不相等，接着我在代码中添加了个断点，单独发送了一个字节 ‘z’ 。
代码中接收和发送数量相等，都等于串口调试助手的接收量。这个缺少的部分是串口调试助手发送失败数量，还是串口驱动接收丢失了？
接下来，修改成中断接收发送模式，其它不做修改进行相同的测试，也是有数量差。进一步检查串口驱动里，接收缓存有溢出现象。应用层没来得及把数据取走，就删掉了最旧的数据。
接口详解及移植说明 rtdef.h 添加几个宏定义 添加阻塞打开相关标志
#define rt_device_oflag_blocking 0x000 /**< blocking io mode */#define rt_device_oflag_nonblocking 0x004 /**< non-blocking io mode */...#define rt_device_ctrl_blocking 0x05 /** ps: 谢谢 @hellobye 的及时纠正，`rt_completion` 不存在本小节描述的漏洞。各位看官可以直接跳过本小节了。
串口驱动里有几个阻塞点，进入阻塞都使用的 `rt_completion` ，如下代码：
serial->ops->enable_interrupt(serial);ret = rt_completion_wait(&(serial->completion_rx), rt_waiting_forever);// 或者 serial->completion_tx 首先开中断，调用 `rt_completion_wait` 等待完成量进入阻塞。这样是有个漏洞的，当开中断后有个串口中断，中断处理函数里调用 `rt_completion_done` 是没有任何反应的，`rt_completion_done` 直接返回退出。
进而回到原线程才执行 `rt_completion_wait`。之后，如果有第二次接收（或发送）中断发生时才会结束上一次的阻塞。但是，第二次什么时候出现也就是个未知数了。即便前一次可能已经收全了全部想要的数据，但是会不定期阻塞下去。
解决方法有两个：一、不用永久阻塞，换成 10ms 或者几 ms 等待；二、用二值信号量替代。
但是！！！我没有用上述方法中的任何一个进行改进，原因是：
第一种方法无疑要引入一个循环，`rt_completion_wait` 超时返回的时候循环继续阻塞。还有就是等待时间没有理论支持。最重要的是用循环方式补漏洞的方式不美观。
没使用二值信号量的原因是，rt-thread 的信号量实现没有真正的“二值”，如果中断已经多次 release 了，然后应用层才来一次 take，之后还可能成功 take 多次（虽然应该是要阻塞的，但是实际不阻塞，反而会循环 take 多次）。
结束语 现笔者将打码开放出来 gitee 仓库 [serialx]( https://gitee.com/thewon/serialx )，求全论坛公测。期待各位大佬提出各种测试方案对它蹂躏。
有问题可以在仓库里提 [issue]( https://gitee.com/thewon/serialx/issues ) ,或者到 rt-thread 官方论坛上进行讨论。
用好连接器 搞清这三个电压真的很重要
锌空电池的结构和工作原理图解分析
MOS管的死区损耗计算
被动元器件电阻国产替代机遇凸显， 国内品牌紧抓机遇
华为P10/P10 plus首轮预售，换个姿势保准让你抢到！
rt-thread 驱动篇（二） serialX 理论实现
BLE光交箱智能门锁-解决方案
Surface商用版的Windows 11 22H2更新功能
2020年7-9月机器人行业新品一览
为什么要用机器人清洗外墙
GPIO输入输出实验
去中心化Token互换协议R1协议介绍
紫光DRAM芯片目前产品产量很小，市场份额不大
劲爆，原来红米note4X真有骁龙653版本，性能强悍跑分9W
5g在智慧城市中的应用（5g的智慧城市如何实现）
短期内工业机器人整体市场将呈稳健增长态势
立体透明oled显示屏怎么用
大联大品佳集团推出基于NXP产品的200W LED Power方案
Model S自己发动连撞五车，特斯拉自动驾驶又出事
MediaTek 推出天玑 8200-Ultra，携手小米联合定义影像特长芯
在前一篇文章里，大致提出了我的串口驱动框架理论。里面做了一些对串口驱动特性的幻想。也在 nuc970 芯片下通过了中断模式的实践验证。但是，因为 nuc970 的 uart 自带 fifo 。用它测试效果好，并不能真正说明驱动框架通过验证了。
然后，紧接着笔者在 stm32f429 完成了中断和 dma 两种模式。今天，我把一些测试结果和移植说明发出来，征求全网公测。
测试配置：dma 二级缓存 32 个字节，串口收发缓存各 512 字节。
注：本串口驱动工作特性请参阅前一篇文章rt-thread 驱动篇（一） serialx 框架理论
stm32 中断模式测试 以下是三组连续发收测试：
1. 定时间隔20ms，发送250字节数据，持续发送2600w，接收发送数据量相等
2. 定时间隔50ms，发送250字节数据，持续发送600w，接收发送数据量相等
3. 定时间隔80ms，发送1000字节数据，持续发送600w，接收发送数据量相等
注：刚刚跟我们小伙伴求证了一下，串口调试助手的定时间隔是固定周期。如果是这样的，以上测试是有意义的，如果不是，那就没达到串口带宽上限。
stm32 dma模式测试 1. 读写测试，串口调试助手定时 10ms ，发送40字节数据，持续发送129w
2. 串口调试助手定时 50ms ，发送500字节数据，持续发送527w
3. 串口调试助手定时 40ms ，发送500字节数据，持续发送261w
4. 串口调试助手定时 40ms ，发送1000字节数据，持续发送262w
串口调试助手上发送和接收数量不相等，接着我在代码中添加了个断点，单独发送了一个字节 ‘z’ 。
代码中接收和发送数量相等，都等于串口调试助手的接收量。这个缺少的部分是串口调试助手发送失败数量，还是串口驱动接收丢失了？
接下来，修改成中断接收发送模式，其它不做修改进行相同的测试，也是有数量差。进一步检查串口驱动里，接收缓存有溢出现象。应用层没来得及把数据取走，就删掉了最旧的数据。
接口详解及移植说明 rtdef.h 添加几个宏定义 添加阻塞打开相关标志
#define rt_device_oflag_blocking 0x000 /**< blocking io mode */#define rt_device_oflag_nonblocking 0x004 /**< non-blocking io mode */...#define rt_device_ctrl_blocking 0x05 /** ps: 谢谢 @hellobye 的及时纠正，`rt_completion` 不存在本小节描述的漏洞。各位看官可以直接跳过本小节了。
串口驱动里有几个阻塞点，进入阻塞都使用的 `rt_completion` ，如下代码：
serial->ops->enable_interrupt(serial);ret = rt_completion_wait(&(serial->completion_rx), rt_waiting_forever);// 或者 serial->completion_tx 首先开中断，调用 `rt_completion_wait` 等待完成量进入阻塞。这样是有个漏洞的，当开中断后有个串口中断，中断处理函数里调用 `rt_completion_done` 是没有任何反应的，`rt_completion_done` 直接返回退出。
进而回到原线程才执行 `rt_completion_wait`。之后，如果有第二次接收（或发送）中断发生时才会结束上一次的阻塞。但是，第二次什么时候出现也就是个未知数了。即便前一次可能已经收全了全部想要的数据，但是会不定期阻塞下去。
解决方法有两个：一、不用永久阻塞，换成 10ms 或者几 ms 等待；二、用二值信号量替代。
但是！！！我没有用上述方法中的任何一个进行改进，原因是：
第一种方法无疑要引入一个循环，`rt_completion_wait` 超时返回的时候循环继续阻塞。还有就是等待时间没有理论支持。最重要的是用循环方式补漏洞的方式不美观。
没使用二值信号量的原因是，rt-thread 的信号量实现没有真正的“二值”，如果中断已经多次 release 了，然后应用层才来一次 take，之后还可能成功 take 多次（虽然应该是要阻塞的，但是实际不阻塞，反而会循环 take 多次）。
结束语 现笔者将打码开放出来 gitee 仓库 [serialx]( https://gitee.com/thewon/serialx )，求全论坛公测。期待各位大佬提出各种测试方案对它蹂躏。
有问题可以在仓库里提 [issue]( https://gitee.com/thewon/serialx/issues ) ,或者到 rt-thread 官方论坛上进行讨论。
用好连接器 搞清这三个电压真的很重要
锌空电池的结构和工作原理图解分析
MOS管的死区损耗计算
被动元器件电阻国产替代机遇凸显， 国内品牌紧抓机遇
华为P10/P10 plus首轮预售，换个姿势保准让你抢到！
rt-thread 驱动篇（二） serialX 理论实现
BLE光交箱智能门锁-解决方案
Surface商用版的Windows 11 22H2更新功能
2020年7-9月机器人行业新品一览
为什么要用机器人清洗外墙
GPIO输入输出实验
去中心化Token互换协议R1协议介绍
紫光DRAM芯片目前产品产量很小，市场份额不大
劲爆，原来红米note4X真有骁龙653版本，性能强悍跑分9W
5g在智慧城市中的应用（5g的智慧城市如何实现）
短期内工业机器人整体市场将呈稳健增长态势
立体透明oled显示屏怎么用
大联大品佳集团推出基于NXP产品的200W LED Power方案
Model S自己发动连撞五车，特斯拉自动驾驶又出事
MediaTek 推出天玑 8200-Ultra，携手小米联合定义影像特长芯