I'm running this on a Teensy 3.2 right now.
Code:
void setup() {
Serial1.begin(26300, SERIAL_8N1);
}
void loop() {
Serial1.write(0xA5);
Serial1.flush();
}
Here is the result on my oscilloscope.
First and most importantly, Serial1 does indeed work properly for this code. I know you are skeptical, but it does indeed work. However, there are some issues common to *ALL* hardware serial communication, which you may not know.
Obviously you need to use good quality equipment for troubleshooting. A cheap clone logic analyzer running at a sample rate less than 5X the baud rate is always going to give you trouble. I know good quality oscilloscopes are expensive. You probably can get ok results from cheap gear, but it's difficult and unreliable since you don't have a good scope for comparison.
No matter how good your equipment, there is a fundamental an issue with parsing continuous serial data if the receiver is out of sync. 8N1 format uses 1 start bit (low), 8 data, and 1 stop bit (high). When Teensy or *any* other device sends continuously, the next start bit begins immediately after the prior stop bit. If you connect to such a signal in the middle of such data, where the start bit is missed, how would you ever know which low bits are the start bits and which are data bits?
You can't know. Your logic analyzer can't parse that. Neither can my oscilloscope. Neither could the UART in any chip.
Here is the exact same scope setup, if I disconnect and reattach the scope probe while the data is running:
You can easily see this is the
exact same waveform. But the scope is showing unknown data with framing errors (the red marks) because it expected to see a stop bit (high) but an actual data bit was low. This process repeats over and over. It never manages to correctly parse the data stream. It's the exact same Teensy running the exact same code as above (I didn't reprogram it, just left it running). The only difference is I momentarily disconnected the scope probe, and when I clipped it back on there was a 8 in 10 chance of connecting during the 8 data bits, which of course happened here.
This is a
problem common to all 8N1 serial communication. If the receiver doesn't begin parsing at the start bit (which is only a 1 in 10 chance doing hot plug of an active 100% usage data stream), it will mistake the first low data bit as a start bit. It's doing exactly what it should. You're never supposed to begin without a start bit. Ordinary 8N1 serial was never designed to be hot-plugged like USB. You're supposed to get wrong data if you begin parsing the stream after a start bit.
Of course, 8N1 serial parsing does recover if there are ever any idle times of 9 bits or longer. But if you always keep transmitting without any gaps between each stop bit and the next start bit, and out-of-sync receiver will never recover. This is simply how 8N1 serial works. The lack of recovery in parsing a continuous stream is one of the many weaknesses of this old and simple protocol.
I know Serial1 works reliably on Teensy 3.x. I've been through this over and over, and of course it's been used successfully by many thousands of people on Teensy 3.x over the last 5 years. If you're still not convinced, and I certainly can understand skepticism, hopefully this long-winded explanation of how 8N1 receiver parsing works can help you avoid more pitfalls as you continue to test. Teensy is extremely reliable, far moreso than that clone logic analyzer, but all testing needs to be done with an awareness of how the protocol really works, so you don't end up reaching a false conclusion things are broken with a test that no UART could ever pass because is violates the protocol.
Then again, while it's unlikely, I am willing to accept any reproducible bug report. Real bugs are
sometimes discovered, even after many years of widespread use. The documentation is never perfect and can always use improvement.
