embedded - 令人沮丧的FreeRTOS xQueueCreate()限制

我正在尝试使用queue将字符从UART ISR缓冲到后台任务。我希望队列长为512字节。不幸的是，这是不可能的，因为size参数的类型是unsigned portBASE_TYPE，对于xmega256a3来说，它是单个字节(char)。队列的最大大小是否因portBASE_TYPE而浮动？而不是uint16_t？

我很好奇其他人是否遇到了相同的限制，以及他们对此做了什么(如果有的话)。

最佳答案

出于效率考虑，对大多数变量使用portBASE_TYPE是很自然的。 AVR是8位体系结构，因此处理8位队列算术将比16位更有效。对于某些应用，此效率可能至关重要。

在32位体系结构上使用uint16_t没有意义，您会注意到ARM内核的portBASE_TYPE是32位值，因此选择uint16_t作为默认的队列长度类型将是对这些内核的人为限制。

这里有一些选择:

重构您的任务以更频繁地从队列中读取。除非其他任务浪费了太多的处理时间，否则应该可以缩短ISR队列长度并在读取线程中缓冲数据。

使用不同的portBASE_TYPE重新编译FreeRTOS。我还没有尝试过，但是我不明白为什么除非FreeRTOS中有一些汇编代码(期望8位portBASE_TYPE)，否则无法正常工作。我快速浏览了一下，没有看到期望8位类型的汇编代码的任何明显迹象。

使用您自己的队列库，该库可以存储所需数量的数据。使用其他FreeRTOS原语(例如信号量)向您的任务发出信号，表明已将数据添加到队列中。它不会在读取队列时阻塞您的任务，而是会在信号量上阻塞。发出信号量后，您将使用自己的排队库读取排队的数据。

关于embedded - 令人沮丧的FreeRTOS xQueueCreate()限制，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/14449235/