Go Down

Topic: DueTimer question - can callback calls overlap? (Read 428 times) previous topic - next topic

clone45

Hello,

I'm working on an audio application that streams 44,100kHz audio from flash memory.  In the application, I'm using the DueTimer class.  My code looks something like:

Code: [Select]


void setup()
{
  Timer0.attachInterrupt(handler).setFrequency(44100).start();
}

void handler()
{
  // 1. Do some stuff..
  // 2. Play back audio..
}


I've found that if my handler() function tries to do too much stuff (namely, fetching too much information from the flash memory), that the audio plays back slower.

So, I tried this test:

Code: [Select]

void handler()
{
  if(lock == true) Serial.println("woops!");
  lock = true;
  // 1. Do some stuff..
  // 2. Play back audio..
  lock = false;
}


But alas, no "woops!" message appeared.  My theory is that the DueTimer library somehow ensures that the callback completes before being called again.  Is that true?  If that is true, is there some way to detect (besides listening to the audio) when the code within handler() is too slow?

Thanks,
Bret

Magician

Put a volatile uint32_t counter++ in your handler, than read and print out a number every 1 sec. Reset counter.

MarkT

You shouldn't call anything in an ISR that can hang waiting for interrupts, like Serial calls.
System deadlock can result unless the priorities happen to allow the setup to work.

Currently Serial on the Due doesn't use interrupts, but future releases are likely to change
that as this is already a requested feature.

If your ISR is taking lots of microseconds, consider making it take fewer microseconds...

To drive the DAC you can set it to be triggered from a timer and pull its data from
RAM using DMA, or simpler have the timer generate an interrupt for each sample
to feed the DAC.
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

Go Up