On Sat, Apr 25, 2015 at 4:04 PM, Martin Ling <martin-sig...@earth.li> wrote: > On Sat, Apr 25, 2015 at 02:38:54PM -0400, Cody P Schafer wrote: >> >> But for serial devices, I've got min = 1 & time = 0. >> The idea here is to get _any_ data as soon as it is available (with >> grabbing more than one byte possible but not requested). >> >> I'm not looking for any timeouts. I'm just trying to get bytes as soon >> as they are available in an efficient manner. > > Ah OK, I was figuring it was VTIME rather than VMIN that you had set, to > cause read() to return early. > > So we can drop the aspect of timeouts, there are indeed none involved > and your example with sp_wait() followed by a sp_nonblocking_read() call > is a direct equivalent. > > What makes this code more efficient though? If you have VMIN=1, VTIME=0 > then your code will be reading a byte at a time, because each read will > return as soon as there is one byte (VMIN=1), and the loop will execute > far quicker than the time it takes for a byte to come in on a serial line.
This assumes I'm using something that is normal serial hardware. Many devices that present as serial ports aren't really serial ports. USB devices are especially prone to this. Further, even if a real serial port is on the other end, nothing guarantees that device isn't implementing it's own version of waiting that I have no control over. As a result, the buffer will often contain more than 1 byte. > > So you can just call sp_blocking_read(buf, 1, 0) in a loop to get > exactly the same result. > >> 0.1 seconds doesn't appear common. >> Linux's default is VTIME=0, VMIN=1, which causes terminals to match >> the behavior of regular files. >> FreeBSD (from some source code grepping) appears to do the same. >> I don't have any other posix-like systems around, but I'd be impressed >> if they went with non-common behavior. > > OK. I just knew there were some non-zero default values around as I'd > been caught out by them before. I thought that included VTIME=1 i.e. 0.1 > seconds but apparently not. > >> While it's unfortunate that windows doesn't have similarly sane >> defaults (as >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365467%28v=vs.85%29.aspx >> appears to imply, search for COMMTIMEOUTS), that isn't necessarily an >> excuse not to provide those sane defaults via a cross platform >> library. >> >> The windows docs for COMMTIMEOUTS even imply it can get exactly the >> posix-like VTIME=0, VMIN=1 behavior ( >> https://msdn.microsoft.com/en-us/library/windows/desktop/aa363190(v=vs.85).aspx >> , see the "Remarks" section). >> >> Given all this, it still isn't clear why using events should be required. > > I *think* you're correct that those mentioned Windows settings would > reproduce the special case of VTIME=0, VMIN=1 behaviour. It wouldn't > work for any other value of VMIN though, so you'd still be reading a > byte at a time. > I'm not currently seeking any behavior other than VMIN=1. While I could see other values being convenient for protocol implementations, as you mention portability for that would be tricky (or deeper than adjusting port flags, one would have to actually compose a single lib operation on some platforms into more than 1 system call). The VMIN=1 case, on the other hand seems like it'd be rather possible. ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
