CSerialport用于多串口烧录MCU时丢失数据的分析与解决办法

        最近在做用于GD32MCU 多串口烧录的一个项目。目标芯片就是GD32MCU，当然肯定也兼容STM32F1系列的所有芯片。
        整体的连接情况如下：主机(PC端)：多串口烧录上位机软件，从机(GD32MCU，进入system boot)，连接线采用USB转串口线。
因为对于MCU的量产烧录，很多厂家都有需求，并且量产脱机烧录或者在线编程器好像都很贵，具体价格没有了解过。所以目前来看，这个多串口软件还是能够解决很多人对于量产烧录的需求的。
        但是第一个版本release出去之后，反馈回来了一个消息就是，这个软件不好用，不好用的表现在于“挑线”，即对于有些USB转串口线，软件工作没问题，对于有些线，感觉会丢失数据，具体表现就是下载进度条卡住不走了。
        目前我接触到的比较多的USB转串口芯片是PL2303和CH340这两款，但是好像PL2303这个仿冒的比较多。。。这些暂时就不详细说了。所以我的第一判断是这个软件并不是“挑线”，而是挑转换芯片。这个问题又分成两类，一个是芯片中的固件处理有问题，另一个是PC端的驱动有问题。
之前我也怀疑是CSerialport这个类有问题，在网上查了很久，大体分为两种说法：1.对EV_RXCHAR这个事件的监测有问题，会漏掉。2.向串口写数据有问题，出现了本次的写入数据把上一次的数据覆盖。上了accessport这个串口监测软件后，发现数据没丢，也没漏写，只是有些命令的ACK收到以后，就不会再发下一条命令了，或者发了下一条正确指令没有ACK返回来。所以，我就开始怀疑串口转换芯片的固件和驱动有问题。

        今天先写到这，明天接着写。。。。。。

--------------------------------分割线------------------------分割线------------------------分割线-------------

        经过这段时间的测试，发现确实与串口转换芯片有关，因为在PL2303这根串口线几乎就没有成功下载过bin文件，而另外一根CH340就很稳定。既然发现了问题，下一步就是解决这个问题。

        但是从驱动到转换芯片的固件，都没有代码参考，所以，想要调试是不可能了。不过PL2303的线在ISP下载中还是很好用的，但是涉及了多串口下载以后，就出现了问题，初步猜测应该是驱动的响应没有处理好。所以在CSerialport类中WriteChar()函数进行了修改，每一次WriteFile()函数执行后，都增加一定时间的等待，该值由用户设置，在打开多串口的监视线程的函数中，应当设置该值，这样，用户就可以根据自身的串口线的不同，设置不同的等待值，好的线也许设置0等待即可，差的线也许等待的时间要久一些。至此，该问题解决。

        同时最近的串口编程还发现，在使用9针串口的DTR和RTS流控对MCU实现自动BOOT的开发过程中，正常来讲，这两根线的低电平应该是-3V ~ -15V，但是在CH340这个芯片转换出来的低电平始终是0V，目前还没搞明白原因。由于这个情况，使用CH340调试MCU自动BOOT功能，很久都没调通，换了根线又正常了，很是郁闷。。。。