thewon86

没看出来哪儿简化了。看看 serialX 里的处理，那个才叫简化 `dma_cnt = RT_SERIAL_DMA_BUFSZ - __HAL_DMA_GET_COUNTER(&(uart->dma_rx.handle));` 三种中断，同一个公式搞定。

你说的 “USB虚拟串口” 是 cdc_vcom.c 文件实现的功能吗？ 看看这个文件源码就知道了，这个东西跟串口驱动没一点儿关系，借用了 `rt_hw_serial_isr` 这个函数和 `struct rt_uart_ops` 这个结构体，很奇葩的想法。

> > 你说的 “USB虚拟串口” 是 cdc_vcom.c 文件实现的功能吗？ 看看这个文件源码就知道了，这个东西跟串口驱动没一点儿关系，借用了 `rt_hw_serial_isr` 这个函数和 `struct rt_uart_ops` 这个结构体，很奇葩的想法。 > > 对，是cdc_vcom.c，这个用到了rt_hw_serial_isr，而且和serial有些耦合，所以导致串口架构会影响USB虚拟串口，这个地方做的是有些问题，，，不知道serialX，有没有对cdc_vcom.c做适配 上面说了，vcom 和 串口没半毛钱关系，没兴趣去做适配。 自己重写 vcom 驱动吧，把 serial 相关的东西全删掉。

> I see . Thank you.

> https://thewon.gitee.io/2022/0902/erpc-transport-winsock2/

There is the same issue [ReadFile](https://thewon.gitee.io/2022/0906/erpc-note/#%E4%BF%AE%E6%94%B9%E4%B8%80%E4%B8%AA-bug)

https://club.rt-thread.org/ask/article/bfd92159ba11aef6.html 这里的开关中断换成只开关当前串口外设的中断就不会影响到其它串口了。

> 这个串口DMA接收实现(stm32)就是个大坑!!!!! > > 现在的逻辑是: DMA一直接收, 根本不管buffer有没有溢出, 这将导致: 如果buffer溢出(buffer里面的值可能已经修改了几伦, 然而len值已经不能反应buffer内的真实数据量), 上层(应用层)根本感知不到buffer已经溢出(buffer中的数据已经覆盖再覆盖了, len已经背离真实情况), 上层怎么处理都恢复不了正常状态, 除非关闭再打开串口(清除底层buffer的len, 让len恢复正常). > > 正常的逻辑不应该是: DMA根据buffer的余量接收, 如果buffer满了, 就不应该接收, 等上层处理完了(buffer有余量了), 在接收数据啊. 还可以保证新的数据全部就收，丢弃最旧的数据，反正应用层已经处理不过来了，总需要丢掉一些数据。 放弃 v2 吧，论坛上还有个人多read了数据的，提问了不止三次了，没人敢解答，v2 的问题没人帮你解决得了的

> > > 这个串口DMA接收实现(stm32)就是个大坑!!!!! > > > 现在的逻辑是: DMA一直接收, 根本不管buffer有没有溢出, 这将导致: 如果buffer溢出(buffer里面的值可能已经修改了几伦, 然而len值已经不能反应buffer内的真实数据量), 上层(应用层)根本感知不到buffer已经溢出(buffer中的数据已经覆盖再覆盖了, len已经背离真实情况), 上层怎么处理都恢复不了正常状态, 除非关闭再打开串口(清除底层buffer的len, 让len恢复正常). > > > 正常的逻辑不应该是: DMA根据buffer的余量接收, 如果buffer满了, 就不应该接收, 等上层处理完了(buffer有余量了), 在接收数据啊. > > >...

``` let cursor = ftp.simple_retr("84402.ISO").unwrap(); let mut bin = fs::File::create("84402.ISO").unwrap(); let wr = bin.write(&cursor.into_inner()).unwrap(); println!("{}", wr); ``` or ``` ftp.retr("84402.ISO", |stream| { let mut buf = Vec::new(); // stream.read_to_end(&mut buf).map_err(|e|...