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 bitportBASE_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.