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




Loading

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?

Jay

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.

Doug

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 ]    [ 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