[ECOS] semi-blocking serial read

[Grant Edwards <grante@visi.com>]

My serial.c driver code has diverged somewhat from the standard
serial.c.  Most of the things I've done have either evolved in
parallel in the official one (like a non-blocking mode) or are
things that other people don't want.

One unique thing that mine does have that is both general and
(IMO) pretty useful is semi-blocking reads.

A semi-blocking read will block until _some_ amount of data is
available and return after transferring whatever is available.

This is primarily useful for UARTs with FIFOs such that receive
data comes in "chunks".  A semi-blocking read waits for the
next "chunk".  This allows you to process incoming data with
the lowest possible latency without doing a non-blocking read
in a busy-wait loop.

The change is pretty trivial.  In serial_read() you do
something like this:

     1	        while (size < *len) {
     2	            if (cbuf->nb > 0) {
     3	#ifdef CYGPKG_IO_SERIAL_FLOW_CONTROL
     4	                if ( (cbuf->nb <= cbuf->low_water) && 
     5	                     (chan->flow_desc.flags & CYG_SERIAL_FLOW_IN_THROTTLED) )
     6	                    restart_rx( chan, false );
     7	#endif
     8	                *buf++ = cbuf->data[cbuf->get];
     9	                if (++cbuf->get == cbuf->len) cbuf->get = 0;
    10	                cbuf->nb--;
    11	                size++;
    12	            } else {
    13	#ifdef CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING
--- 14                  if (!cbuf->blocking) {
+++ 14	                if (cbuf->nonblocking || (cbuf->semiblocking && size))) {
    15	                    *len = size;        // characters actually read
    16	                    res = -EAGAIN;
    17	                    break;
    18	                }
    19	#endif // CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING


The cbuf struct needs to change a little to accomodate the two
flags "nonblocking" and "semiblocking", but I think you see
what I mean.

I don't use serial.c and probably won't get around to
submitting a patch for some time, but I thought I'd toss the
idea out in case anybody else could use something like it.

-- 
Grant Edwards
grante@visi.com