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

Thread: Library delays?

  1. #1
    Junior Member
    Join Date
    Dec 2013
    Location
    The Internet
    Posts
    1

    Question Library delays?

    Yo,
    Big ups to Paul for Teensy and Teensyduino! Awesome learning and prototyping platform.

    Quick question about libraries with delay()s contained within them:
    I'm developing a project with lots of controls. It's a MIDI controller, and I want to make sure few control changes are missed. The project includes LiquidCrystalFast to display various control parameters as they change. I was looking through the source for LiquidCrystalFast, and there are some delays here and there to allow data to be sent to the LCD controller successfully.

    Wouldn't this delay() the software every time the LCD must be updated, potentially resulting in missed control changes if controls are changed very quickly?

    If so, would it be a good idea to update the LCD less frequently to reduce delay()s and avoid missed control changes?
    Last edited by vas0line; 12-01-2013 at 08:06 PM.

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,327
    With USB MIDI, you can't miss incoming data. The USB has built-in flow control. The incoming data will go into buffers on Teensy, and when those are full the PC will stop sending and buffer on the PC side. Eventually, if it runs out of buffers, bad things can happen. Ableton will show bright orange warnings that it can't send. Other programs might just slow down, freeze, crash or otherwise behave badly. But you simply can't miss any incoming data.

    With normal serial MIDI (the big 5 pin DIN connector), you can miss incoming data. But the serial object has a 64 byte buffer. Since byte arrive at most about 3100/sec, that buffer lets you have small delays like the LiquidCrystal library, without much trouble.

    Of course, it's wise to always read all the incoming data and then update your display when there's nothing left in those buffers. That buys you the maximum possible time to do other stuff, since those buffers for incoming data will be empty.

    If you're really concerned about this stuff, Teensy 3.0 has much more buffering ability than Teensy 2.0. The USB stack uses a pool of memory for incoming package buffers, instead of a fixed 2 packets on Teensy 2.0. In serial1.c, you can edit the buffer size, and Teensy 3.0 has much more memory. Likewise, you can edit the size of the USB buffer pool is usb_desc.c. But usually you don't need to mess with that stuff. The defaults give you plenty of buffering to tolerate short delays like LiquidCrystal.

Tags for this Thread

Posting Permissions

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