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


Quee with variable lenght

Posted by Carlo De Bonis on March 26, 2012
How to solve the following scenario with FreeRTOS?

I have 3 instances of a task that receives messages from the host. The message
is structured and contains an address that identifies the task that must
receive an decode the message. Each of these 3 tasks, depending on the type of
message received, provides a response of variable length.
Each of these 3 tasks sends a request to the task n. 4, GATEKEEPER type, that
provides to transmit the answers to the host.
How do you reconcile with the constraint that the Quee, when creating, has a
defined length?
Thank you

RE: Quee with variable lenght

Posted by Richard Damon on March 26, 2012
If I need to queue up messages of variable length (or messages of large size), what I do is put on the queue a pointer to the message, and have some method of handling these message buffers. That way the queue stores a fixed size message (the pointer).

The other option, if all the messages are fairly small, is to set the queue up for the largest message, and just live with a bit of wasted space inside the queue. The task receiving the message needs a buffer big enough for this largest message, but it would anyway as it doesn't know what sort of message it really is until it gets it.

RE: Quee with variable lenght

Posted by Carlo De Bonis on March 26, 2012
Your first solution (pointer with ixed lenght) requires managing a more memory than the one described in heap_x.c that is a block partitioned memory to be seen as a common resource shared by mutex semaphores
Thank you

RE: Quee with variable lenght

Posted by Richard Damon on March 26, 2012
The blocks could be allocated as needed with pvPortMalloc by the sending task and then release with pvPortFree by the receiving task. Depending on your usage patterns, you may need to worry about heap fragmentation here.

Since there are just a few different sizes, there could also just be an array (possibly of size 1 if you can count on the receiver to finish with the buffer before the sender needs another) for each size with a method to keep track of which ones are owned by the sending and which by the receiving task. This method could be as simple as making another queue which you push all the buffers addresses (of a give size) onto, and to get a buffer of that size, request one off. The receiving task then just pushes the addresses of the buffer when it is done.

RE: Quee with variable lenght

Posted by Carlo De Bonis on March 26, 2012
This answer is completely satisfactory and comprehensive
Thanks for the suggestions and the help provided.

[ 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