I appreciate the help you're offering, and thanks, but I need to puzzle it out here. And it isn't worth it, as this is a
very unusual situation--very non-standard. It's not a Teensy problem, but almost certainly the Kinetis UART that's so much more capable than I need--and which sees this non-standard bus configuration as an error. It seems the best thing I could do is carefully look at the error bits and the flags set due to break detection and handle them so they don't interfere with the correct processing of what immediately follows. Which I think is what Chris O. was saying. It
would be convenient if break detection could be turned off, so I could be sure the issue has nothing to do with UART-vs-break.
I'm using an
RS485-to-USB converter that's high-speed, isolated, and has a Silicon Labs CP2104 UART-to-USB.
Here's a 'scope shot of the
A and
B signals, and
RX1, while a single ACK is sent: first the driver is initially disabled, then enabled for a about a bit-time, then a start-bit of 0 and data 0:1:1:0:0:0:0:0, a stop bit (1), then idle (1s) for a couple of character-times, then the driver is disabled.
As you might be able to see, it's 230,400 baud, and, after the line driver is enabled, there is about 1 bit-time of marking line before the beginning of the start bit. And, yes, the converter gets every character of every message all the time, while, simultaneously, the Teensy 3.5 misses most.
Of course you're right that it all depends on the start bit. But no start bit, no matter how clean, will be detected if, say, a false start bit precedes it by less than a character-time--if it arrives while the UART is in the middle of assembling a character or break.