From: Michael Walle
...
> What comes directly to my mind is the handling of the break condition.
> Can't look into that at the moment. But if break conditions are
> translated into status-only packets, how are two consecutive breaks
> recognized. Ie. if the break condition flag is sticky (until a new
> character is received) you can't determine if its one or more. But maybe
> we are lucky and the chip will send some different pattern. If only
> there were some specs ;)
Well on a usual async line:
- Line idle is repeated zero.
- Break is repeated one.
- A byte is encoded as a start bit (1), 8 data bits, and a stop bit (0).
If the stop bit is absent (ie a 1) you get a character framing error.
So you can't actually get back to back break conditions without a
character with framing error happening first.
The real fubar are some hdlc chips (I won't mention the zilog scc) that
report 'abort/break' asynchronously from the data stream.
Correctly receiving <data><abort><flag><data><flag> and
<data><abort><data><flag>
is almost impossible.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
