Is the os_timer_setfn() hardware or software driven?

[kolban]

Imagine I register a function to be called in the future using os_timer_setfn(). After calling this, the ESP8266 does nothing further and simply waits for the timer to fire. My question is .... "Is this timer wait a busy wait or a sleep/hardware wait?". Does the ESP8266 maintain a list of timers and poll them looking for the next timer to fire or does it use "hardware" and put itself into a low power state waiting for the timer to fire using an internal interrupt driven clock?

Neil

[eriksl]

I think the api documentation is clear enough on this point (and otherwise I just assumed ). Works over here.

What it DOES is simply call your callback function at some time in the future, minimal x timespan from what you specified. In the meantime the cpu simply keeps running, setting a timer function is not blocking execution. So you can install multiple timers and that just works, no problem. It's very comparable to a timer compare interrupt on a "regular" microcontroller. If you're done with your business, just return from all of your functions and the SDK code will make sure the cpu does "nothing" (at least: not on your code) and it will only return to your code when the timer fires. Whether the SDK code will put the cpu in a somewhat lower power sleeping state or not, I cannot confirm, but I assume it does, so it may be beneficial.

I think the timer code inside the SDK is actually built around a list of timers, the (one) hardware timer is programmed to fire when the first next timer function should be called, when that happens, the timer is reprogrammed to fire for the next timer function to be called, etc. So it all revolves around one hardware timer. AFAIK there is only one timer in the esp8266 anyway, so it should be used shared nicely.

[kolban]

Howdy and thanks for the response. My core puzzle is that I am looking at porting a JavaScript runtime called Espurino to the ESP8266. In the JavaScript environment, there is a JavaScript function exposed called "setInterval(function, interval)" ... which calls the JavaScript function at each interval of msecs. As I look to see how the JavaScript library works, it maintains a list of timers to fire. It then has an "idle" loop which busy walks the list of timers and sees if any of them have expired ... and if so, it causes the invocation of the JavaScript function. This feels like it will busy consume the CPU in the ESP8266. Ignoring watchdogs and yielding just now, I wondered if there would be a better way leveraging the os_timer_setfn()? I wondered if that was more "efficient" than this busy loop mechanism? My thinking would have been that if the JavaScript runtime is going to do nothing until a timer is ready, instead of doing a busy poll on the timers, I would register an os_timer_setfn() and give control back to the ESP8266. However, this would only be more efficient if the internals of os_timer_setfn() aren't themselves simply doing a busy poll of the timer list set by calls to os_timer_setfn(). And that was the background to the question. I am trying to understand if there is something smarter (perhaps an internal timer interrupt in the CPU microcode) that makes this better.

Neil

[eriksl]

The os_timer_setfn actually does what you want, it's like the javascript implementation. I can't believe a javascript is simply sitting and waiting for the first alarm. It will also, on the operating system, program a timer, that goes off at the first javascript timer. No busy loops there. Also no busy loops in the esp8266 timer implementation. Where do you get that impression from?

[kolban]

Howdy,
My words probably aren't working for me today

By busy loop, what I mean is that code is actively checking to see if a timer is ready ... as opposed to hardware assist where no code is needed to check if a timer is ready ... instead, a hardware clock is ticking internally at microcode level and causes an interrupt when the timer expires.

As for the JavaScript runtime ... the one I am using is called Espruino and the relevant idle loop processing can be found starting at line 1439 here ... https://github.com/espruino/Espruino/bl ... eractive.c

This is as much an academic question as anything. Not a vital need on my part to understand this ... just curious.

Neil

[eriksl]

I am understanding exactly the same from your alternate description I think we have a asynchronisity in our understanding I will try again.

Suppose you have three logical timers (comparable to the "javascript" timer or the os_timer_fn timers), one should fire every 1ms, one every 2ms and one every 5 ms.

At the lowest level you can easily implement something like that using one "hardware" timer. From time offset 0 ms, the first timer to fire is timer 0 (every 1ms), at 1 ms. So it is programmed to be fire at offset 1 ms. In the meantime the cpu can go do anything it likes including going into a power saving mode. At time offset 1 ms, the hardware timer fires an interrupt and the low level code (in this case: the code from SDK) will recognise it's the first timer that should be called. When it has done so, it checks what timer should fire next. In this case it's both timer 0 and timer 1 at offset 2 ms. So the timer is programmed for 2 ms. At the interrupt the code for timer 0 is called and the code for timer 1 is called. This goes on for a while, until we reach 5 ms, where the timer 0 and timer 2 code should be called.

The crux of the story is that the cpu doesn't need to do anyhing (no busy loops, etc.) between moment in time "x" where the timer is started OR where the previous timer fired and moment in time "y" where the next timer should fire. The only difference between having only one hardware timer and having an infinite amount of hardware timers is that you need to program the single hardware timer every time it has fired. Usually this is very "light", just a few lines of code. So in the end it's not really that useful to have more than one timer, unless you do "complex" things like hardware pwms on different frequencies, compare&capture etc.