Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT


Integration of FreeRTOS and Random Event Mechanisms

Posted by groufosse on May 29, 2014

Hi, 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.

Integration of FreeRTOS and Random Event Mechanisms

Posted by heinbali01 on 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 portENDSWITCHINGISR( 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?

Regards, Hein

Integration of FreeRTOS and Random Event Mechanisms

Posted by groufosse on 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!

[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS