Teensy 3.6 at high baud rate
- Thread starter Shockwave
- Start date
- Status
PaulStoffregen
Well-known member
Yes, baud rates up to several megabits/sec work.
Serial1 and Serial2 have FIFOs which really help interrupt reduce overhead at higher speeds.
Serial1 and Serial2 have FIFOs which really help interrupt reduce overhead at higher speeds.
MichaelMeissner
Senior Member+
In addition to using the 2 serial ports with FIFOs (Serial1 and Serial2), if your device supports it, you might want to enable hardware flow control using CTS (pins 18 or 20 for Serial1 and pin 23 for Serial2) on the Teensy connected to the RTS pin of the device, and connecting any digital pin to be used as RTS to your device's CTS pin:
Also note, if your device is far enough away, it may be useful switching to something like RS-485, which provides check-summing, etc.
Also note, if your device is far enough away, it may be useful switching to something like RS-485, which provides check-summing, etc.
I saw the max rate as I was reading the PJRC website. For the serial ports the table read what acceptable baud rates were. So I took that to mean you could not go beyond that.
Fortunately I was able to write a test program which spit out a buffer of ten 0x55 bytes to the port, then measured the end of the final stop bit with a scope. that's 100 bits in all and it came in at 109.5us, giving a baud rate of 913242. Which is only .07% off. So I'm happy the devices will be able to communicate over 422 with this bitrate.
Fortunately I was able to write a test program which spit out a buffer of ten 0x55 bytes to the port, then measured the end of the final stop bit with a scope. that's 100 bits in all and it came in at 109.5us, giving a baud rate of 913242. Which is only .07% off. So I'm happy the devices will be able to communicate over 422 with this bitrate.
Whatever table you were looking at is probably not applicable to the Teensy 3 series 
I'm glad that ten bytes came out OK for you, although the correct measurement cycle for asynchronous serial is within each byte -- leading (falling) edge of start bit to leading (rising) edge of stop bit. The reason for this is that a stretched stop bit is totally acceptable on an asynchronous serial interface, and shouldn't count "against" the timing of the interface.
I'm glad that ten bytes came out OK for you, although the correct measurement cycle for asynchronous serial is within each byte -- leading (falling) edge of start bit to leading (rising) edge of stop bit. The reason for this is that a stretched stop bit is totally acceptable on an asynchronous serial interface, and shouldn't count "against" the timing of the interface.
PaulStoffregen
Well-known member
- Status