Implementing timers

[CurlyMoo]

@TD-er I was working on a proof-of-concept of timer events. And i must say, i am pretty impressed on what you implemented in ESPEasy. A efficiënt and light weight timer queue as i would quite ideally have expected it.

Any ideas about the efficiency difference between a timer queue running on xTaskCreatePinnedToCore and one based on a SIGALRM or even hardware interrupt timers:
https://github.com/khoih-prog/ESP8266TimerInterrupt/blob/master/examples/ISR_Timer_Complex/ISR_Timer_Complex.ino?

From what i see is that the current timer does periodic evaluations. So if i set a timer for 10 seconds, i still get 10x TIMER_1SEC evaluations. Whilst a timer queue implemented in the most ideal way, only evaluates for the minimal amount of time necessary. So if my first timer is 10 seconds and my second timer 5 minutes, i only want two evaluations. One after the 10 seconds and one after the 5 minutes (until a earlier timer enters).

[TD-er]

Everyting is run from the internal scheduler, even the PLUGIN_TEN_PER_SECOND calls (and everything else)
The main problem with this approach is that an action run from the main scheduler may contain some code that needs more time than available between scheduled actions.
This may lead to some delay in executing the next action.
For most scheduled actions, this does not really matter as long as it is executed often enough.
For example the 10/sec and 50/sec calls are used mainly to make sure data is read often enough to not miss anything important, but it doesn't matter if the time between calls isn't constant.

For the loop timer (see setlooptimer_ms command) I do reschedule it based on the set interval and the last set scheduled time.
This to make sure the timer does not drift over time. But there still isn't a guarantee it will execute every set N msec, or even that it may not skip a cycle.
If you plan on using the (ESP32 specific) hardware interrupt timers or run it at a different core, you will not have to worry about those issues, but there is a serious big drawback here.

• Interrupt driven callback functions must be in IRAM, including all functions you may want to call from those callback functions. (ICACHE_RAM_ATTR attribute)
• RTOS tasks need data synchronisation semaphores to protect against concurrency related data corruption.

The IRAM is slightly less of an issue on ESP32, but on ESP8266 you really have not a lot of it.
Current core versions do have some optimizations, but in the past it was in the order of 1 kB or less free for your own sketches after the Arduino library was loaded.
Still you must make sure to only call IRAM attributed functions and data (or volatile declared objects) when using interrupt callback functions.
Nice for really quick callback functions, but not for rules parsing.

Data locking/synchronization between (RTOS) tasks can become tricky if it has to be done between cores as not all memory can be accessed from both cores.
I've experimented a bit with it in the past and as you may have noticed it is now effectively disabled as it caused issues which have to be looked into.

Edit:
I think timer1 on ESP8266 is used for PWM signalling.