Currently 8-bit micros are limited to a queue size of 255. To increase the limit I was thinking about modifying the QueueDefinition structure. I would change uxMessagesWaiting and uxLength to be unsigned portSHORT instead of unsiged portBASE_TYPE. Can anyone think of potential pitfalls with this? Are there certain atomic operations which depend on uxMessagesWaiting being only 1 byte?
There should be no problem with having the larger data size. As I recall the very old versions of FreeRTOS.org, prior to the introduction or portBASE_TYPE, had this member as a 16bit type. Regards.
For some reason the queues don’t work after making this change. I only changed the type of uxMessagesWaiting and uxLength in the QueueDefinition structure to unsigned portSHORT. I left all of the function prototypes untouched (still passing portBASE_TYPE). After makeing these 2 small changes the code still compiles cleanly without warnings, but for some reason queue receive calls are never returning? Using an Atmega128
My fault. I was passing in an uninitialized queue to xQueueSend(). Changing the QueueDefinition structure was just enough to cause my prgram to really crash. But once I fixed my initialization problem everything was working fine with the larger queues.
Why not make the type automatically switch to 16 bit when the queue gets bigger than 255 ?
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.