Close

ESP8266 Issues Responding to interrupts

A project log for Galaga meets IoT

ESP8266 captures high scores as they occur on a Galaga PCB from the Golden Age of Arcade

justin.richardsjustin.richards 11/13/2016 at 05:015 Comments

I have been so close to a working solution but always come back to issues with ESP8266 latency delay when responding to the first interrupt.

Interrupt service becomes when of an issue it seems when examining any of the variables that modified during the interrupt routine.

I incorrectly arrived at a conclusion that the ESP8266 is fast enough to respond to each new write to the 2114 in a timely manner. It kind of is but if your main loop is referring to any of the variable set in the INT then it is no longer reliable.

Have decided to go back to the original idea of once the INT is triggered, read and record the state of the IO as fast as possible then post process the changes by looking for the toggle bit . It uses 1 extra pin but I think it is the only way.

So it is back to the drawing board.

Discussions

justin.richards wrote 11/14/2016 at 01:29 point

Thanks for the pointers folks.

Issues relating to the mainline checking on variables set by the interrupt had been in the back of my mind but dismissed it as it mostly works. Just sometimes misses the first instance.

But after reading the article, I am thinking that is exactly the issue. C compiler optimisation.

Will be back to my test bench in about 2 weeks to experiment with volatile etc.

Thanks again

  Are you sure? yes | no

Leonard wrote 11/13/2016 at 13:29 point

Interrupts can be tricky. Interrupts interrupt currently running code, such as your main loop, and that can be at any point in time. Some variable checking may be required to have the interrupt code see it is adjusting something that it actually should adjust. Or in your main code, have a check to see if the variable you need, may have already been changed by the interrupt. If things in code are borked, you could even have a situation where your code reboots the controller, and sometimes that may go so fast you may sometimes not even notice.

If you are doing this with c, read about the use of the keyword 'volatile'. It tells the compiler to not optimize.

E.g. http://www.barrgroup.com/Embedded-Systems/How-To/C-Volatile-Keyword

  Are you sure? yes | no

esot.eric wrote 11/13/2016 at 17:04 point

That's probably one of the best explanations of "volatile" I've seen. Thanks! There are a few other pitfalls it doesn't mention, I've thrown up some ideas over at: (again, related to programming in C)

https://hackaday.io/project/5624-potentiallyusefulfrustratingobscure-cgccmake/log/49037-interrupts-volatiles-and-atomics-and-maybe-threads

  Are you sure? yes | no

Leonard wrote 11/14/2016 at 10:48 point

Hey, thanks for that writeup, that is helpful.

  Are you sure? yes | no

esot.eric wrote 11/13/2016 at 06:53 point

not sure I understand your setup well enough to make a determination of any sort but "if your main loop is referring to any of the variable set in the INT then it is no longer reliable." sounds quite a bit like a pretty common mutual-exclusion problem that arises often with interrupts...

  Are you sure? yes | no