FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [December 2011 Threads]
Hi all,
In my FreeRTOS project, I want to post several messages to queues (from task) without the possibility of a task switching until after the group of sends. I have implemented it using vTaskSuspendAll, but this appears not to work.
Here is pseudo-code of the section (which is called from a task not ISR):
vTaskSuspendAll();
for (i = loop through routing table)
{
if (route exists)
{
os_err = xQueueSendToBack( queue, &blockToSend_p, 0 );
num_routes++;
}
}
blockToSend_p->num_references = num_routes;
xTaskResumeAll();
At xTaskResumeAll I have a situation that the highest prio task shown as READY in StateViewer is *not* the one that is scheduled next.
I am aware that the FreeRTOS documentation for vTaskSuspendAll/xTaskResumeAll specifies not to use certain RTOS calls including xQueueSendToBack while suspended; however my understanding is that one may not make calls with potential to block. Using delay 0 in 'send' ensures the call does not block. What should I concluded from the unexpected sheduling behaviour?
A. I've used the wrong design.
B. It's the right design, but a stack overflow is breaking the RTOS.
I tried placing a taskYeild() after xTaskResumeAll() but it did not fix my crashes.
Should I consider using xQueueSendToBackFromISR from task in order get queue-but-don't-reschedule behaviour?
My setup: STM32F103, FreeRTOS 7.0.2, IAR EWARM 5.30 with StateViewer plugin.
Many thanks for your suggestions.
Owen
I'm not sure if xQueueSendToBack() can be used when the scheduler is suspended, it might even depend on the port being used, but if it says not to do it then it is probably best not to.
As an alternative, try temporarily raising the priority of the task doing the sends to be above any of the tasks doing the receives, then when all the sends are complete, drop the priority back down again and the receive tasks can then run.
Thank you for that suggestion.
I had
#define configUSE_PREEMPTION0
and this may have been the issue, but the build has other bugs that are not yet resolved.
So I will report back a solution when the other bugs are fixed.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.