Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 6 of 6

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

  1. #1
    Member
    Join Date
    Oct 2015
    Location
    Roma (IT, UE)
    Posts
    67

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

    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 by XFer; 10-13-2018 at 10:45 PM.

  2. #2
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    1,895
    As far as I know, a serial port doing Midi would run on 31250 baud...

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,354
    Quote Originally Posted by XFer View Post
    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?
    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.

  4. #4
    Member
    Join Date
    Oct 2015
    Location
    Roma (IT, UE)
    Posts
    67
    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).

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,354
    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.

  6. #6
    Member
    Join Date
    Oct 2015
    Location
    Roma (IT, UE)
    Posts
    67
    Great explanation!
    Thanks a lot.

    Fernando

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •