rirititi wrote on Friday, July 08, 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.
rtel wrote on Friday, July 08, 2016:
I’m afraid I don’t fully understand your question.
On ARM Cortex-M devices, FreeRTOS has a configuration setting called
configMAX_SYSCALL_INTERRUPT_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
Is your question how to use the FreeRTOS API from an interrupt above
If that is your question, the answer is quite a simple “you can’t”. If
you could, then configMAX_SYSCALL_INTERRUPT_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.
richard_damon wrote on Friday, July 08, 2016:
An interrupt with a priority above configMAX_SYSCALL_INTERRUPT_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.
damodharbodduku wrote on Thursday, June 27, 2019:
I hope you have you have migrated Nucleus projects to Free RTOS.
We have Nucleus based Embedded applications in our Target (old board). We are planning to port and run these embedded applications in a new target which has Free RTOS. Is there any porting document or user guide …etc?
Have you faced any challenges in migration?