ESP8266 Community Forum

- Tue Dec 09, 2014 6:41 pm #4443 Would it be possible for tmr.stop() with no parameter to stop all the timers?

When uploading a file, I want to stop all the timers so nothing goes off during the upload.

I could stop all of them one by one, and will do so in the interim, but it would be convenient and useful in other cases to stop all active timers at once, for instance if there is an interrupt.

It would also provide backwards compatibility for code written before build 12.09.

Speaking of which, since we don't have access to the source, can you provide some info on the interrupts.

Can 2 (or 7) interrupts be handled simultaneously? What is the priority for handling them? When do interrupts work or not? From deep sleep? How do tmr.alarms fit in with interrupts? With deep sleep? I could experiment, but it might be better to have some of these issues in black and white to know what should happen. (Besides, I am lazy).

I am pretty sure that my rain gauge is not triggering the interrupt as reliably as it should and am wondering if there is a non-hardware reason that interrupts may be ignored or blocked in certain circumstances.

A second interrupt seems to work perfectly after power up but stops working after a few hours, despite everything otherwise looking OK. I wonder what might block an interrupt?

ESP8266 for dummies, LuaLoader and project updates: http://benlo.com/esp8266

- Tue Dec 16, 2014 3:06 pm #4966

Can 2 (or 7) interrupts be handled simultaneously?
What is the priority for handling them? When do interrupts work or not? From deep sleep?
How do tmr.alarms fit in with interrupts? With deep sleep?
I could experiment, but it might be better to have some of these issues in black and white to know what should happen.

Nice additon will be global/local interrupts handling - on/off.
How to avoid an interrupt after previous one (keypress debounce, encoder counting, etc...) - in the middle of execution interrupt driven code?

- Fri Dec 19, 2014 6:22 am #5144

Would it be possible for tmr.stop() with no parameter to stop all the timers?

When uploading a file, I want to stop all the timers so nothing goes off during the upload.

I could stop all of them one by one, and will do so in the interim, but it would be convenient and useful in other cases to stop all active timers at once, for instance if there is an interrupt.

It would also provide backwards compatibility for code written before build 12.09.

Speaking of which, since we don't have access to the source, can you provide some info on the interrupts.

Can 2 (or 7) interrupts be handled simultaneously? What is the priority for handling them? When do interrupts work or not? From deep sleep? How do tmr.alarms fit in with interrupts? With deep sleep? I could experiment, but it might be better to have some of these issues in black and white to know what should happen. (Besides, I am lazy).

I am pretty sure that my rain gauge is not triggering the interrupt as reliably as it should and am wondering if there is a non-hardware reason that interrupts may be ignored or blocked in certain circumstances.

A second interrupt seems to work perfectly after power up but stops working after a few hours, despite everything otherwise looking OK. I wonder what might block an interrupt?

tmr.alarm is not a hardware interrupt. it's a chain of Timer(soft I think, from SDK).
all timers alarm will handled one by one. not simultaneously.

- Fri Dec 19, 2014 7:49 am #5154

tmr.alarm is not a hardware interrupt. it's a chain of Timer(soft I think, from SDK).
all timers alarm will handled one by one. not simultaneously.

Thanks. I was guessing that was the case.

Any idea how it handles conflicts when one timer has not completed its task and a second timer fires? Is it purely a queue or stack?

Are lower number timers more likely to be accurately timed, then?

Just trying to pre-empt the kinds of difficult to debug problems that come up if you make the wrong assumptions...

ESP8266 for dummies, LuaLoader and project updates: http://benlo.com/esp8266