Understanding Display Update and System Delay

Troubleshooting and Support
1

After managing to set up VS Code and compiling and testing some examples on the Daisy Field, I started reading the code found in DaisyExamples. I hope to get a basic understanding of coding for the Daisy Seed that way.

I noticed the following pattern:

int main(void)
{
    // ...

    hw.StartAudio(AudioCallback); // [1]

    while(true)
    {
        UpdateDisplay();
        System::Delay(10); // [2]
    }
}

[1] Am I understanding this correctly that there are basically 2 loops going on in this application? A DSP loop and a loop for everything else? If so, how do I decide what goes where?

[2] Whenever I see the display being updated, it is followed by a call to System::Delay(n);.

  • Is this a pause that puts the main() loop on hold?
  • Why is this needed?
  • What value should be chosen for n? Should this value be different, depending on the refresh rate of the display?
  • As an exercise, I want to write a game of Pong, playable on the Daisy Field display. Should I use the System::Delay(10); method to separate the rendering of my frames?
2

The audio callback isn’t really a loop, it gets triggered by a timer interrupt, runs to completion, then gets triggered again by the next interrupt. This ensures that the audio codec is reliably serviced.

The loop in main() is typically where less time-critical code would go, since it is constantly being put on hold by the timer interrupt which triggers the audio callback.

  • 10 ms delay in the loop causes UpdateDisplay to run at approximately 100 times maximum per second, which is more than fast enough for, for instance, a scope. The actual value is up to you. For text, it only needs update when you change something on screen.

To do an animated game, you’ll need to read buttons fast enough to be responsive, and render frames often enough to simulate smooth motion, and if you want sound, you’ll need to not overburden the AudioCallback(), which MUST ALWAYS complete in the time before next interrupt.

You can do all these using a combination of the AudioCallback() and a less time-critical loop in main().

1 Like
3

Yes - time critical stuff that must be done in time to output the next audio sample-block in the DSP ‘audio callback’, everything else in ‘main’.

4

Also, things that might take a long time (like refreshing the display or printing to the debug log) definitely shouldn’t be called in the audio thread to avoid crashing the Seed / causing audio dropouts.