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] [July 2016 Threads] Synchronization of FreeRTOS with ISR’s of higher kernel’s priorityPosted by rirititi on July 8, 2016 I’m currently studying the possibility of migrating some of our projects from Nucleus to FreeRTOS on an LPC43xx µC.
One of my main concerns is the limitation of use on ISR with higher priority than the FreeRTOS kernel. I need to keep an ISR uninterruptible / non-disabled with higher priority than the kernel one’s (due to hard real time constraints).
I have read the documentation of FreeRTOS and read some post related to my concern on the forum (for example https://sourceforge.net/p/freertos/discussion/382005/thread/670bab1e/#b281 ) without finding a way to communicate between that ISR and FreeRTOS.
Is there an issue to that problem? Can I use a mechanism to synchronize FreeRTOS tasks with that ISR? Can I raise another lower priority ISR or any other mean (synchronization flag…) that could allow me to reenter in the FreeRTOS world?
Thank you for any help.
Synchronization of FreeRTOS with ISR’s of higher kernel’s priorityPosted by rtel on July 8, 2016 I'm afraid I don't fully understand your question.
On ARM Cortex-M devices, FreeRTOS has a configuration setting called
configMAXSYSCALLINTERRUPT_PRIORITY which the application writer can
set to a value of their choosing (although the hardware itself prevents
it being set to 0). Interrupts at or below that priority are can use
the interrupt safe API, but are effected by kernel critical sections.
Interrupts above that priority are never disabled [unless you
application code disables them] but cannot use the interrupt safe
FreeRTOS API.
Is your question how to use the FreeRTOS API from an interrupt above
configMAXSYSCALLINTERRUPT_PRIORITY?
If that is your question, the answer is quite a simple "you can't". If
you could, then configMAXSYSCALLINTERRUPT_PRIORITY would not exist.
If you could describe your particular use case (for example, what is the
interrupt doing, what are its timing constraints, etc.) then perhaps we
could suggest an option for you.
Synchronization of FreeRTOS with ISR’s of higher kernel’s priorityPosted by richard_damon on July 8, 2016 An interrupt with a priority above configMAXSYSCALLINTERRUPT_PRIORITY can't use the API because it is not disabled when FreeRTOS is manipulating internal structures that need to be able to be updated atomically. Either you need to place your ISR priority under the limit, and make sure your code uses similar restraint as the kernal (it only blocks the interrupts for very short periods), or if you absolutely can't tolerate even very short deays, that ISR needs to trigger a lower priority interrupt (otherwise unused) that make the communication to FreeRTOS.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|