[ILUG] Serial port

[Brian Foster]

  | Date: Tue, 4 Apr 2006 21:11:40 +0100
  | From: "Frank Duignan" <frank.duignan at gmail.com>
  | 
  | I've generally found sending a break character (0xff) is good at sorting
  | out this sort of first byte synchronization issue i.e transmit 0xff before
  | sending your real data.  The other end should dump the break if its uart
  | is worth its salt

 NO.  _if_ the peer's UART is "worth its salt",
 it will not be confused by a (series of) 0xFF
 or 0x00 octets, as that is not a true BREAK.
 IIRC, a true BREAK is all lines clamped low for
 at least ¼ second.  that should not be confused
 with a valid octet by any UART "worth its salt",

 nowadays, to send a true BREAK, use tcsendbreak(3).

 _however_, I do agree that some(/many?) UARTs are
 fooled by this trick (and I have used it myself).

 I suspect Pádraig's earlier guess, that CLOCAL is
 not set, is perhaps more relevant?

 then there's the problem of what really happens if
 the peer decides there is an incoming BREAK.  some,
 such as Solaris (viz a very recent thread), throw the
 system into the boot monitor, which is sometimes a
 disaster.  others, as Frank suggest, more-or-less
 resynch, which is perhaps what is wanted/needed here.
 (there are other possibilities.)   but it is worth a
 try, albeit it does not "work" will all equipment at
 all times.

cheers (hoping I haven't made too many mistakes,
as I just had a very nice French dinner with, of
course, a very nice French vin!....),
	-bl(*hic*)f-
-- 
Experienced (20+ yrs) kernel/software Eng: | Brian Foster   Montpellier,
 • Unix, embedded, &tc;  • Linux;  • doc;  | blf at utvinternet.ie   FRANCE
 • IDL, automated testing, process, &tc.   |  Stop E$$o (ExxonMobile)!
Résumé (CV) http://www.blf.utvinternet.ie  |     http://www.stopesso.com