El 27/03/16 a las 17:42, Dan Smith via chirp_devel escribió:
def _rawrecv(radio, amount):
- """Raw read from the radio device, new approach, this time a byte at
- a time as the original driver, the receive data has to be atomic"""
"""Raw read from the radio device, less intensive way"""
data = ""
try:
tdiff = 0start = time.time()maxtime = amount * 0.020while len(data) < amount and tdiff < maxtime:d = radio.pipe.read(1)if len(d) == 1:data += d# Delta timetdiff = time.time() - start# DEBUGif debug is True:LOG.debug("time diff %.04f maxtime %.04f, data: %d" %(tdiff, maxtime, len(data)))
# Getting the data with a dynamic timeout in the serial deppending on# the amount of data we needtimeout = amount * 0.06This really doesn't make any sense: the value of timeout doesn't need to be greater if you're reading more data. The select() call that pyserial is making doesn't know how much data you're asking for, it only reports whether there is*any* data to be read from the descriptor. Further, pyserial cuts down the timeout each time through the read loop, if it has to go again. That means that if you're a little late on the first read loop, your timeout is cut down even further in the second and subsequent loops. Eventually that will end up cutting your timeout down to very small (i.e. less than a byte interval) value, which will make this unreliable. It might be good to review the implementation of pyserial's read code:
https://github.com/pyserial/pyserial/blob/master/serial/serialposix.py#L470-...
This is why you need to be processing incoming data into a queue if you're having trouble with the timing bits. Relying on the timeouts like you are is only going to work in lucky situations where you start your read with enough timeout remaining to process the full block.
Good to know about the shrinking of the timeout by using this. I will review the pyserial code now to better understand the issue.
Can you point me to a example of the queue schema you mention here?
73