解决方案 »

  1.   

    1、是否仍会不断触发DataReceived?是的,会。
    2、则此时执行BytesToRead为1还是2?都有可能(多测试几次就会总结出来)
      

  2.   


    那么对于仍会触发DataReceived问题,是不是多次触发嵌套执行,因为一次事件可能还没结束而在此触发?
      

  3.   

    Only one event handler can execute at a time.,线程阻塞调用。
    另外合理的设置ReceivedBytesThreshold的值,若接收的是定长的数据,则将ReceivedBytesThreshold设为接收数据的长度,若接收数据的结尾是固定的字符或字符串则可采用ReadTo的方法或在DataReceived事件中判断接收的字符是否满足条件。
      

  4.   

    首先,串口有个fifo的buffer的,所以数据过来不会马上覆盖。4楼读,触发不会嵌套,所以第二个问题的答案读到是1。
      

  5.   

    我当时有做过串口快速传大量数据,发现触发式会丢包,后来在某个线程里面循环不停的读,才解决了问题。SerialPort.read()这个方法读。
      

  6.   


    多谢!
    最近也发现用触发会丢包,而且如果在触发线程中sleep(x),得到的结果会随x的时间得到不同的结果,因此的不使用sheep时读到的结果取决于系统的反应时间。
    线程里面循环不停的读是个好方法,但增加了系统的开销,特别是在大量不连续的情况下。因此,是否可以用第一个数据触发,然后在触发线程中调用循环读取方法,再在一定条件下结束循环读取线程并结束触发事件??欢迎继续讨论。
      

  7.   

    我觉得在线程里循环读增加不了多少开销的,我用的时候也有留意过cpu,好像没什么变化(可能现在的电脑性能都太好了吧~)。
    不过如果你的情况是:要么没数据,要么一来就连续大量数据的话,用你的那种方法确实不错,定个协议,触发知道开始读然后就循环读,收到特定标志结束,然后把触发功能打开。不过开始的标志和结束的标志要定好。或者说在循环读的时候发现比较长一段时间没数据的话就结束线程并开启触发功能。
      

  8.   

    我的做法是这样:触发时读取,读取时不妨sleep(10),时间长短取决于你一次传输的数据量和实时要求。此时BytesToRead包含了新到的数量。
    可以将所有的串口数据添到一个 List<byte>里面,然后再根据你的协议,找数据头和结尾,也可以新开个线程处理。
    这样比较适合数据零零散散到达,而且可能长度不定的情况。
      

  9.   

    我的做法是这样:触发时读取,读取时不妨sleep(10),时间长短取决于你一次传输的数据量和实时要求。此时BytesToRead包含了新到的数量。
    可以将所有的串口数据添到一个 List<byte>里面,然后再根据你的协议,找数据头和结尾,也可以新开个线程处理。
    这样比较适合数据零零散散到达,而且可能长度不定的情况。
      

  10.   


    也是一个好方法,但sleep(x)的x确实很难定义在某些不确定的系统中,因为你不知道一次发过来的数据有多大。
    但却是提供了个好方法。