Teensy 3.6 @ 24 MHz: can Serial3 (no FIFO) keep up at 57600?

Status
Not open for further replies.
X

XFer

Well-known member
Hello,

I'm completing a battery-powered MIDI project with Teensy 3.6 acting as USB Host.
Since I have to save battery, I'm trying to keep clock speed at the minimum (with working USB), so 24 MHz.

Now, the problem is that I've wired the MIDI Out port to Teensy pin 8 (Serial3 tx), which has no hardware FIFO (my fault, forgot about that! :( ).
Do you think I risk to miss bytes, at this (relatively!) low CPU speed (24 MHz), without FIFO? I think Serial3 runs at 57600 to work as a MIDI port.

CPU doesn't have much load; just forwarding MIDI messages from USB device to MIDI port and little else.
I don't think I'm going to have issues: after all 24 MHz are still plenty, and Serial3 has software buffer anyway. But...?

Thanks for your insights. :)

EDIT: on second thought, I'm just transmitting, so having hardware FIFO or not should not matter much; only (software) serial buffer depth matters. Right? :)

Fernando
 
Last edited:
XFer said:
EDIT: on second thought, I'm just transmitting, so having hardware FIFO or not should not matter much; only (software) serial buffer depth matters. Right? :)
Click to expand...

Either way, for transmit-only communication the consequence of not keeping up will be small idle times and not managing to fully utilize all of the 31250 baud bandwidth. You won't lose anything, as can happen when you don't keep up with sustained fast incoming serial data.

Even at 57600 baud with 8N1 format data, that's only 5760 interrupts per second. As long as you're not using libraries like Adafruit_Neopixel which block interrupts for lengthy times, you'll probably be able to keep up.
 
Thanks Paul.
I think I'll rewire to Serial2 anyway, just to be safe... I seem to (vaguely) remember that Serial1 and Serial2 driver code was also more efficient (I want to minimize the risk of delays on note events without upping the CPU clock if possible).
 
Yes, Serial1 & Serial2 have FIFOs for lower interrupt overhead, and more efficient block write to the transmit buffer. For megabit speeds, these make a huge difference.

They'll also help at lower speeds, especially if you have other libs which spend significant time blocking interrupts. But if you're not using stuff which blocks the relatively high priority level interrupts used by serial, the benefit is minimal at slower baud rates. For example, if you use the audio library and you run fairly computationally heavy stuff like reverb effects or FFT analysis, that stuff all happens as a relatively low priority interrupt which does not interfere with the serial interrupts.

If you have other CPU heavy but "normal" code which doesn't disable interrupts, then the serial buffer sizes are what matters. You can increase those just as easily on Serial3 (by editing the code lib code) as you could any other port. But just to keep things in perspective, even if you run the audio library with reverb or FFT, those computationally heavy operations happen in about the amount of time only a couple MIDI messages take to send. In a worst case you could have an empty transmit buffer and then the audio lib takes up CPU time after after you've read a sensor and haven't yet put the MIDI message into the outgoing serial buffer. You'd see a delay of about 1 to 2 milliseconds in that sort of scenario. But if the buffer already had several MIDI messages queued, they would stream out the port during those computations and your new message would go right after them because you'd still manage to get it into the buffer before 2 messages could send.
 
Status
Not open for further replies.
Back
Top