CODEWITHSUNDEEP
embeddedavrfreertos
Travis Griggs
Travis Griggs

Reputation: 22252

Frustrating FreeRTOS xQueueCreate() limitation

I'm trying to use a queue to buffer characters from my UART ISR to a background task. I want the queue to be 512 bytes long. This is unfortunately impossible, because the type of the size argument is unsigned portBASE_TYPE which for the xmega256a3 is a single byte (char). Is there a reason the maximum size of a queue floats with portBASE_TYPE? Rather than uint16_t?

I'm curious if others have hit the same limitation, and what, if anything, they've done about it.

Upvotes: 2

Views: 3225

Answers (2)

Travis Griggs
Travis Griggs

Reputation: 22252

Richard Barry (FreeRTOS author) posted the following response on the FreeRTOS mailing list:

This is only the case on 8-bit architectures. It has been mentioned a few times (you can search the support archive on the FreeRTOS site), but not for years as most new projects are using 32-bit architectures. The simple thing to do is change the definition of portBASE_TYPE in portmacro.h, but it will make your code larger and less efficient.

As an aside, many of the FreeRTOS demos use queues to pass characters into and out of interrupts to provide a simple example of tasks and interrupts communicating, but unless the throughput is very low (a command console for example), it is not the recommended way of writing production code. Using circular buffers, preferably with a DMA, is much more efficient.

Upvotes: 4

Austin Phillips
Austin Phillips

Reputation: 15776

It's natural to use portBASE_TYPE for the majority of variables for efficiency reasons. The AVR is an 8 bit architecture and so will be more efficient dealing with 8 bit queue arithmetic than 16 bits. For some applications this efficiency may be critical.

Using a uint16_t doesn't make sense on 32 bit architectures and you'll note that the portBASE_TYPE for ARM cores is a 32 bit value, so choosing a uint16_t as the default type of queue length would be an artificial restriction on these cores.

Here's some options:

  • Refactor your tasks to read from the queue more often. Unless other tasks are stealing too much processing time, it should be possible to lower your ISR queue length and buffer the data in your reading thread.
  • Recompile FreeRTOS with a different portBASE_TYPE. I haven't tried this but I don't see a reason why this wouldn't work unless there was some assembler code in FreeRTOS which expected an 8 bit portBASE_TYPE. I had a quick look and didn't see any obvious signs of the assembler code expecting 8 bit types.
  • Use your own queuing library that has the capability to store as much data as you need. Use other FreeRTOS primitives such as a semaphore to signal to your task that data has been added to your queue. Instead of your task blocking on a queue read, it would block on a semaphore. Upon the semaphore being signalled, you'd use your own queuing library to read queued data.

Upvotes: 3

Related Questions