串口框架V1和V2版本对比

本文由RT-Thread官方论坛用户123原创发布：https://club.rt-thread.org/ask/article/2915.html

串口框架V1和V2版本对比

V1版本串口框架（以及驱动）总结

这部分的总结，其实也是在之前写的串口V1版本的文章中有所提及的，这里大致再总结一下，如果初次查看的话，可能会造成一些困扰，那么就去请先去查看之前的三篇文章：串口(一)、 串口(二) 、串口(三)相信看完之后会更加清晰一些。另外如果有任何描述不当或者分析不对的地方，尽情评论区发言或者直接私信我。

• 发送模式不够完善：

  • 串口驱动中，发送中断模式未发挥出中断应有的特性，造成使用中断时，仍然需要浪费大量CPU时间，影响系统整体性能。

• DMA发送使用不当容易丢包：

  • 当写数据为轮询或者中断时，调用rt_device_write正确返回后即代表数据发送完成。而使用DMA时，调用rt_device_write返回后仅仅代表数据准备完毕，并不能代表数据发送完成，如果用户在正确返回后再次调用rt_device_write，将有可能出现上次数据未发送完成，数据又被修改的发送数据错误的问题。

• 不同模式时，影响应用层执行逻辑：

  • 结合第二点再引申下来这个问题：当使用中断和轮询时，发送模式为阻塞模式，使用DMA时，发送模式为非阻塞模式，且未对数据块进行保护。另外不仅仅是发送端的考虑，接收端也有可能会出现阻塞和非阻塞的模式选择问题。因此框架层应该更多关心阻塞非阻塞的操作模式，使得应用层执行流程能够统一。

V2版本的串口框架（以及驱动）主要改动点：

• 取消了硬件工作模式的判断，硬件工作模式由驱动层支持，使得框架层与 硬件工作模式 无关；
• 统一操作接口，应用层不再关心 硬件工作模式，
• 统一使用 阻塞/非阻塞 操作模式，不会因为模式的变更导致应用层逻辑代码行为不一致。
• 增加发送缓冲区功能，保证应用层数据的完整性，从而解决丢包率；
• 每一路的串口都有独立的发送缓冲区和接收缓冲区的宏定义，取代之前的所有串口默认使用RT_SERIAL_RB_BUFSZ这一个宏定义。
• 完善工作模式，分工明确，轮询、中断、DMA都能按照正确的工作模式执行。

ps: 这里我用了两个词汇用来区分模式：硬件工作模式和应用操作模式，这两个词汇可能不是官方用词，这里旨在用来区别描述上的混淆和困扰

硬件工作模式： 指串口的三种模式，代表的是使用轮询、中断、DMA进行操作串口时的工作模式。
应用操作模式： 指串口的实际操作模式，代表的是应用层使用串口时选择使用阻塞或非阻塞传输的操作模式。

V1和V2版本对比

V2版本的在使用上的改动点，上文已经描述过了，下面主要从代码层面以及用户使用上对比两个版本的差异。

结构体的成员变量的变更

serial_configure

修改V1版本的bufsz为rx_bufsz，指代的含义未变更，均指代接收缓冲区字节长度；增加发送缓冲区字节长度的成员变量tx_bufsz。具体如下代码段所示：

/* V1版本的成员变量 */
struct serial_configure
{
   
    rt_uint32_t baud_rate;

    rt_uint32_t data_bits               :4;
    rt_uint32_t stop_bits               :2;
    rt_uint32_t parity                  :2;
    rt_uint32_t bit_order               :1;
    rt_uint32_t invert                  :1;
    rt_uint32_t bufsz                   :16;
    rt_uint32_t reserved                :6;
};

/* V2版本的成员变量 */
struct serial_configure
{
   
    rt_uint32_t baud_rate;

    rt_uint32_t data_bits               :4;
    rt_uint32_t stop_bits               :2;
    rt_uint32_t parity                  :2;
    rt_uint32_t bit_order               :1;
    rt_uint32_t invert                  :1