Page tree
Skip to end of metadata
Go to start of metadata

The VMIN and VTIME values interact to determine the criterion for when read should return; their precise meanings depend on which of them are nonzero. There are four possible cases.
This web page explains it as:

  • VMIN = 0 and VTIME = 0

    This is a completely non-blocking read - the call is satisfied immediately directly from the driver's input queue. If data are available, it's transferred to the caller's buffer up to nbytes and returned. Otherwise zero is immediately returned to indicate "no data". We'll note that this is "polling" of the serial port, and it's almost always a bad idea. If done repeatedly, it can consume enormous amounts of processor time and is highly inefficient. Don't use this mode unless you really, really know what you're doing.

  • VMIN = 0 and VTIME > 0

    This is a pure timed read. If data are available in the input queue, it's transferred to the caller's buffer up to a maximum of nbytes, and returned immediately to the caller. Otherwise the driver blocks until data arrives, or when VTIME tenths expire from the start of the call. If the timer expires without data, zero is returned. A single byte is sufficient to satisfy this read call, but if more is available in the input queue, it's returned to the caller. Note that this is an overall timer, not an intercharacter one.

  • VMIN > 0 and VTIME > 0

    A read() is satisfied when either VMIN characters have been transferred to the caller's buffer, or when VTIME tenths expire between characters. Since this timer is not started until the first character arrives, this call can block indefinitely if the serial line is idle. This is the most common mode of operation, and we consider VTIME to be an intercharacter timeout, not an overall one. This call should never return zero bytes read.

(In my experience, the VMIN>0 and VTIME>0 mode doesn't quite work as advertised. The timer seems to be a very short interval, much less than a 1/10th second. I haven't seen it work on ARM with 2.6, and Linux 3.13 on x86. At a fast baudrate (115200), with VMIN=1 and VTIME=1, a read() sometimes returns 10 or more bytes. But more often it's just a partial read of a few bytes regardless of the VTIME value. Maybe this brokenness is preferred/desired? A minimum 0.1 sec message separation is simply too long (and not practical) at modern fast baudrates.)

  • VMIN > 0 and VTIME = 0

    This is a counted read that is satisfied only when at least VMIN characters have been transferred to the caller's buffer - there is no timing component involved. This read can be satisfied from the driver's input queue (where the call could return immediately), or by waiting for new data to arrive: in this respect the call could block indefinitely. We believe that it's undefined behavior if nbytes is less then VMIN.


http://www.unixwiz.net/techtips/termios-vmin-vtime.html

  • No labels