Integration of FreeRTOS and Random Event Mechanisms

groufosse wrote on Thursday, May 29, 2014:

This is an overall design approach question using FreeRTOS.
In the processor I am using (STM32F4 series) it can be set up with continuous DMA from the ADC and a callback is performed upon a specific sample buffer being obtained. But, with FreeRTOS’ deterministic, scheduled behavior, I’m trying to understand just how to integrate such functionality together. What type of task, and at what interval, could be implemented to handle this, keeping in mind these are interrupt driven functions (ADC,DMA) for the most part?

Thanks for your replies.

heinbali01 wrote on Thursday, May 29, 2014:

Hi there,

That sounds like an interesting project you’re about to develop!

ADC, I suppose that you want to make recordings of sound or do analogue measurements? Where do these data go to? Analyse them, write them to a disk or send them out on the Ethernet?

Many roads lead to Rome, but here is a nice one:

Define an interrupt for the ADC/DMA peripheral and do as little as possible from within that interrupt:

• Check for errors, make sure you confirm or clear them (see manual STM32F4)
• Provide a new buffer to the DMA so it can be filled (often there are two alternating buffers)
• Send a reference to the filled buffer (just a pointer) with xQueueSendFromISR() to the consumer
• If xQueueSendFromISR() sets ‘*pxHigherPriorityTaskWoken’, make sure that a task-switch takes place after returning ( see portEND_SWITCHING_ISR( xSwitchRequired ) ).
• And if there is no new data, a task switch probably isn’t necessary

The consumer is a normal FreeRTOS task. It receives all ADC data. After doing its work, you can make the task sleep using xQueueReceive().
If there is no other task with a higher prority, the time between leaving the interrupt and waking-up up the consumer will be less than a µs. That’s the deterministic behaviour.

( some people believe that their program will become more responsive if they handle the data ‘directly’ from within the interrupt )

Your consumer task may take it easy, as long as the queue has enough free space.

Now when you make something like a streaming audio player (or recorder), you might want to use more than one task:

  • A task which fetches the data (from a disk, USB, internet)
  • A task which decodes the data (from MP3 to raw)
  • An interrupt (as above) which checks DMA status and swaps buffers

And then you make sure that there is enough buffer space between these three. I tend to have 5 to 10 seconds of audio prepared to be sent out on DMA, just to avoid drops of sound.

Is this more or less what you were asking for?


groufosse wrote on Thursday, May 29, 2014:

Hello Hein,

Thank you for an elaborate and detailed answer. I believe it provides me with enough to get going. And yes, it is related to audio. As I implement it in the next while, I may have other questions and I hope you are available to answer. Thanks!