Hello,
I work with the FreeRTOS port and I am wondering if there's a good way to generate an interrupt on one core that is executed in the context of another core. What I mean is, essentially what I'd like to do is if an event happens on one core, I'd like it to generate an interrupt in the FreeRTOS core so FreeRTOS can handle the event rather than handling it on the xc core. Essentially this would mimic the behaviour of a microcontroller with a peripheral interrupt. As an example, consider a core running an xc task uart_rx. What I would like is, if the uart_rx core receives a byte, it would generate an interrupt in the FreeRTOS core that would retrieve the byte and handle it somehow, e.g. place it into a FreeRTOS queue that would cause a waiting task to become enabled. I know this sounds overly complicated, this is just a simple example of what I want -- to enable the FreeRTOS core to work more like a standard microcontroller running an RTOS that can respond to events that might be generated elsewhere on the chip.
generate interrupt from one core to another
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
-
- XCore Addict
- Posts: 246
- Joined: Mon Jan 08, 2018 4:14 pm
Hi Akp,
I ve just seen a lot of development going on for an RTOS stack for xmos and its integration in freertos for the vocal fusion here:
https://github.com/xmos/lib_rtos_support
lot of stuff in there and reviewing the port, I feel what you want is possible already in this library; let us know
I ve just seen a lot of development going on for an RTOS stack for xmos and its integration in freertos for the vocal fusion here:
https://github.com/xmos/lib_rtos_support
lot of stuff in there and reviewing the port, I feel what you want is possible already in this library; let us know
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
Thank you for posting the link, I will take a look.
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
I see. The RTOS core(s) are set to interrupt on chanend. The peripheral core sets a global pending interrupt flag (to tell the RTOS core which peripheral core(s) have pending interrupts) and the peripheral issues an "end" control token to interrupt the RTOS core which handles interrupts from that peripheral. The RTOS core is interrupted and calls all the registered ISRs for the pending interrupts. So essentially there is a single interrupt per core that determines which ISRs to call every time it's fired. Makes sense. We only need one chanend for the RTOS core and one for each peripheral. Hardware lock ensures only one peripheral core issues the "end" control token to the RTOS core until the number of pending interrupts goes from 0 to 1. I think I could make this work when we need it (e.g. to bring some functionality into the RTOS core that's currently done on another core to free a core). Thank you.
I note that it looks to me the peripheral cores must be on the same tile as the RTOS core (due to shared global variables). That's not a problem I don't think.
I note that it looks to me the peripheral cores must be on the same tile as the RTOS core (due to shared global variables). That's not a problem I don't think.