No subject


Tue Jul 29 02:03:00 CEST 2008


care  about  guaranteeing  any  deterministic  behaviour in case both
input channels transfer data at the same time. If such a simultaneous
transaction happens, your input data stream (for  both  channels)  is
likely to get corrupted (without any error indication).

I interpret the fact that your code does not care about  this  as  an
indication  that  such situations are very untypical for your mode of
usage - but then why do we need to provide code that focuses on  such
a case?

So my question is: does it really make sense to continue polling  the
network console while a serial data transfer is in progress? [*]

I do not think so.

[*] Of course the same is true for the other direction  -  but  there
    situation  is  much easier becahuse (a) the serial driver is very
    fast and (b) the nc code already handles multi-byte data packets.


My suggestion is to make the multiplexing more intelligent instead of
making the serial driver more complex. The nice thing  with  this  is
that  you  probably  still get the same results (actually even better
ones as the artificial 128 byte line lengt limit can be avoided), and
the changes are only in the new code, i. e. users  who  do  not  need
such I/O multiplexing will not be affected.

I think it should be fairly simple to implement something similar  to
the VTIME feature for non-canonical reads in the Unix serial drivers
(see "man tcsetattr"):

- In idle mode, all configured input devices are polled in a
  round-robin manner (as it is done now).

- As soon as a character is received on the serial line, a  timestamp
  is  taken. As you calculated, one character at 115 kbps takes about
  100 us on the wire. Within a window of (for  exmaple)  500  us  (or
  about 5 character times) now polling of all other I/O ports will be
  skipped.

This should give you raw serial driver  performacne  while  a  serial
data  transfer  is running, while keeping functionality for all other
use cases.

What do you think?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In general, they do what you want, unless you want consistency.
                                    - Larry Wall in the perl man page


More information about the U-Boot mailing list