Quality RTOS & Embedded Software

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


Best Practise to create a queue

Posted by benduvenage on September 4, 2015

Hi All

I have created project with 8 Tasks. I will have these taskes communicate with each other via a few queues. What will the best place be (best practise) to put the queue declarations.?

Kind regards B

Best Practise to create a queue

Posted by heinbali01 on September 4, 2015


Many good answers to your question are possible.

What I like personally is a very small main() function: it initialises the minimal hardware and it starts 1 task, my main task.

When that task starts it is sure to be the only task (except the idle task ) so it can safely do everything: create queues, buffers, semaphores, and also initialise peripherals. Only when that has been done successfully, the main task will start/create all other tasks and services.

The reason to do most of the initialisation from a task ( and not from main() ) is that many functions may depend on a running scheduler.

So symbolically:

~~~~~ void main() { initialisehardware(); xTaskCreate (vMainTask, "mainTask", STACKMAINTASK, NULL, PRIOMAINTASK, NULL); vTaskStartScheduler(); } void vMainTask( void *pvParameters ) { initialiseresources(); // queues, semaphores etc initialiseperipherals(); // drivers for peripherals starttcpip(); startother_tasks(); for( ;; ) { // Do the main work } } ~~~~~

Regards, Hein

Best Practise to create a queue

Posted by benduvenage on September 4, 2015


Best Practise to create a queue

Posted by richard_damon on September 5, 2015

I personally prefer a different method. My main functions calls an init function for every "Module" in the system that creates the task, queue, semaphores excetera and does any simple hardware initilization (that which can be done without use of interrupts and such), and THEN starts the scheduler.

Any initilzations that need FreeRTOS to be up (then need interrupts etc.) will be at the begining of an appropriate task. (This is especially true of 'remote' devices that need a comm link to talk to).

The problem I see of holding off creating things until FreeRTOS has started is you have a much larger surface of things that you need to make sure are setup before use, and all the hidden dependencies between things. Queue are the communication link between tasks or tasks and interrupts, so you need to be sure they are setup before either user of the thing accesses them. If you do it pre scheduler, this isn't normally an issue as the tasks aren't running nor are the interrupts, so nothings should be trying to access them. Setting things up pre-scheduler says I can simply setup the queue in the module that receives from it or that setups what is protected by a semaphore/mutex, and it generally doesn't matter what order they are setup.

If you setup after the schedule has started you have to figure out what CAN be setup first (becuase it doesn't start up accessing something it doesn't setup), which may mean moving the initilization of a queue away from the 'natural' owner of it. You also need to be much more careful with things that use interrupts to make sure an iterrupt can't occur until everything it accesses has been setup.

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

Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.

Free TCP/IP and file system demos for the RTOS

Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists