串口

本文由RT-Thread官方论坛用户123原创公布：https://club.rt-thread.org/as...串口框架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;rt_uint32_t rx_bufsz :16; /* 批改之前版本的bufsz为接收缓冲区字节长度 */rt_uint32_t tx_bufsz :16; /* 减少成员变量发送缓冲区字节长度 */rt_uint32_t reserved :6;}; ...