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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
