Quality RTOS & Embedded Software

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


xQueueCreate problem on Atmega128

Posted by dcraw on December 8, 2007
I have FreeRTOS running on my Atmega128 and for the most part it appears to be running fine. But if I try to create a queue of 30,000 bytes xQueueCreate(30000, sizeof(uint8_t)); the returned xQueueHandle is always non-zero. Is there another API function I should check first to see if there is enough heap available, or is this a bug?

RE: xQueueCreate problem on Atmega128

Posted by dcraw on December 8, 2007
I just realized that queues on the Atmega128 are limited to 255. Is there an easy way to create a queue with more than 255 items?

RE: xQueueCreate problem on Atmega128

Posted by Jay on December 8, 2007
Can you explain why you would need a queue so big? Are you caching an image?


RE: xQueueCreate problem on Atmega128

Posted by dcraw on December 8, 2007
I am using the FreeRTOS queue to hold incoming serial bytes. The RX ISR adds to the queue every time it receives a byte. We have a requirement to hold at least 1500 bytes in the queue as the remote transmitter sends out huge chunks of data periodically. My application does not need preemption so I was considering using coroutines for everything to save memory. Actually, I don't even need to use FreeRTOS for my application, but I was hoping it would help structure and separate the different threads of my code.

I guess I could create my own global array of 1500 bytes and implement my own RX buffer. Then I would create a FreeRTOS queue of zero length and use that to essentially semaphore my coroutine when a new byte arrives.


RE: xQueueCreate problem on Atmega128

Posted by sotd on December 8, 2007
As far as I know the Mega128 had 4K bytes of RAM so you would never be able to create a buffer of 30K even if queues could be that big.

To get over the 255 you can either just change the type used in the functions or define portBASE_TYPE to be a 16bit type. The latter would be inefficient in some cases.

RE: xQueueCreate problem on Atmega128

Posted by dcraw on December 8, 2007
If I did increase portBASE_TYPE to a 16 bit type would it affect stability? Do any atomic operations on the Atmega128 depend on working with 8 bit types. Does portBASE_TYPE need to be a signed value?

RE: xQueueCreate problem on Atmega128

Posted by boozle on December 10, 2007
Given the large blocks to be received, and the likely need to prevent overflow, I would create a standard interrupt driven serial handler which manages its own buffers.

This interrupt handler should run at a higher priority than the clock tick and have no interaction with the RTOS. The RTOS should not totally disable interrupts in its critical regions, except for the time required to mask off all interrupts associated with the RTOS, after which the serial interrupt will be re-enabled. I know the 8051 interrupt system hardware is structured to enable this type of operation but others may not.

Set up like this the serial interrupt code can then break into the RTOS at any time, run to completion, return from interrupt leaving the stack unchanged as viewed by the RTOS. A standard task can then monitor the buffer status extracting and inserting blocks of characters.

In a similar situation I have used multiple RX buffers which are acquired and released via a state machine associated with each buffer, Rx buffer states are:(created & free), (receiving characters), (full & ready for processing)), (being processed), then back to (created & free)

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

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

Latest News

Version 10.1.0 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

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

Xilinx Microblaze and Zynq partner