How properly, under RTOS, to set up the highest priority non-maskable interrupt vector?

[djixon]

API mechanism suggests cb function from ISR. So if I understand, you are proposing to make a cb from that software interrupt and then from it, call to GetTicker64() should be possible, because that cb function will be "at right" core?

[MicroController]

Yep.

Code: Select all

static void getTicker64_ipc(void* out) {
  *(uint64_t*)out = getTicker64();
}

...
uint64_t ticks;
esp_ipc_call_blocking(other_core_id, &getTicker64_ipc, &ticks);
...

[djixon]

Yup, not by creating software interrupt but just by calling that API blocking function until core is switched. Thank you MicroController for helping in that optimization. There is some limitation of that API about not using windowed mechanisms (so NO entry or retw must be performed) however I used that sipmle asm to get_another_cpu switch, and once it returns I performed call to GetTicker64() from new returned core. Here is v2.0

CPU_ticker64_v2.0.zip
https://uploadnow.io/f/6tG4PrM

[djixon]

Here is v3.0:
- removed constructor and added native init function with core ID
- removed usage of RAM, higher part of CCOUNT stored internaly into Xtensa core, in special register not used by Espressif (register index 244). I searched for opcode in all compiled libraries and searched through all source code in latest ESP_IDF and it simple is not used anywhere. If someone from ESP stuff can confirm that, it would be nice.
- made non-windowed versions of routines for direct ipc grabs from another core
- now both 64bit tickers (on dual cores) can run in parallel and even be nested
- added deinitialization routines, which free allocated interrupts
- added another auto calibration variable for cases of ipc-s
- without RAM usage for storage of upper part, ISR and other assembler routines extra optimized
- added example of ISR deinitialization
- performance improved

CPU_ticker64_v3.0
https://uploadnow.io/f/j8ZGhJZ