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] [April 2014 Threads] AVR32 UC3 port: vTaskDelay thread- and interrupt-safe?Posted by threis on April 30, 2014 Hi,
when i look at the function vTaskDelay() i wondered about the missing entering of a critical section at the beginning of the function. The function call of vTaskSuspendAll() just increment the variable uxSchedulerSuspended, which e.g. is polled at context switch. If an timer interrupt occurs during vTaskDelay() is processed, this function would interrupted before the calling task could inserted into the list of delayed tasks. If then the timer interrupt would processed and check if there are tasks ready to run, these tasks would removed from the delayed task list and put in the ready task list.
If now the cpu returned to processing of the function where the interrupt occured, this list of delayed tasks would corrupted. I think the call of vTaskDelay() must be thread- and interrupt-safe. What do you thing about? Do you agree with my conclusion or is there anything i didn't consider?
I'm using the AVR32 UC3 port.
Please excuse my english.
Thank you
AVR32 UC3 port: vTaskDelay thread- and interrupt-safe?Posted by rtel on April 30, 2014 FreeRTOS minimises its use of critical sections in order to remain as responsive to interrupts as possible. It uses the scheduler locking as a means of allowing interrupts to remain enabled. When the scheduler is locked the kernel's data structures are protected from interference from the timer (or any other interrupt that is written correctly). Instead such interrupts manipulate a set of 'pending' data structures. Any 'pending' updates are processed into the main kernel data structures when the scheduler is unlocked.
Note the UC3 port in the main FreeRTOS download is no longer supported as it only runs on ES chips (it works around silicon bugs that no longer exist in the chips). Atmel have their own port in the ASF, but we are understandably unable to support third party code directly.
Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|