ThreadX Queue Message Size Limit

[lcdevans]

Hello,

I'm using ThreadX on an STM32 platform. I'm confused about the queue message size limit of 64 bytes/16 words.

I have read a previous Issue ticket #122 where the user asked about it, and was directed to another link for an explanation (https://learn.microsoft.com/en-us/answers/questions/292596/about-the-limite-of-the-message-size-of-queue). I have read both threads and am still confused about this.

The reason that seems to be given in the links above is that copies of larger sizes are too inefficient. Surely that should be up to the user's discretion? The answers given to #122 seem to indicate there is no technical reason the maximum message size can't simply be bigger.

I understand there are workarounds, such as redefining TX_16_ULONG, editing the source file, disabling error checking, sending multiple messages, etc, but it is frustrating to have to add such complications to a project to get around what appears to be an arbitrary restriction. Similar platforms, such as FreeRTOS, have a much higher queue message size limit.

Can you provide any information about why this limit of 64 bytes exists? Is there a technical reason other than copy size performance? Could you consider allowing larger sizes out-of-the-box?

Thanks for your time.

[fdesbiens]

Hi @lcdevans.

Thank you for your question. I will find someone on the team who could provide context around this limit. Stay tuned.

[fdesbiens]

@rahmanih Please feel free to comment.

[billlamiework]

One technical reason for this limit is that ThreadX messages are passed by value, i.e., copied from source to destination. The copy occurs with interrupts disabled, so the limit is 16 32-bit words. An application that doesn't care about the additional interrupt latency can override the TX_16_ULONG constant or directly all the internal _tx_queue_create API that does not have the error checking.

[rahmanih]

One technical reason for this limit is that ThreadX messages are passed by value, i.e., copied from source to destination. The copy occurs with interrupts disabled, so the limit is 16 32-bit words. An application that doesn't care about the additional interrupt latency can override the TX_16_ULONG constant or directly all the internal _tx_queue_create API that does not have the error checking.

we may add a flag like TX_QUEUE_DISABLE_MSG_SIZE_CHECKING undefined by default, and use it in the txe_queue_create()?

#ifndef TX_QUEUE_DISABLE_MSG_SIZE_CHECKING
        /* Check for an invalid message size - greater than 16.  */
        else if (message_size > TX_16_ULONG)
        {

            /* Invalid message size specified.  */
            status =  TX_SIZE_ERROR;
        }
#endif

regards
Haithem.

[billlamiework]

Yes, Haithem, this is a good approach that provides the desired flexibility!

[lcdevans]

Thank you for the replies, a flag like that is what I was hoping would be possible.