[TriEmbed] ESP8266 Programming tip

[John Vaughters]

Scott,

I probably have plenty to learn from that statement. I am not sure I fully understand playing nice with interrupts. The delay() usage was just me being lazy and hoping it worked from code copied. Definitely no lessons needed there. It was just known bad practice skimping for time. It did work, but I like the new method better. The only relation I have for the interrupts is the limited multi-threading code I have written, which needs care to not overstep. There seems to be some correlation with interrupts, but not sure I have wrapped my head around it yet. Not sure I will anytime soon either, but I will most certainly remember the general concept on taking care when using interrupts if I ever need to. So thanks for the description. I don't think this affects my current situation unless my assumptions are wrong. I am fairly sure the lib is not using interrupts. So far it seems stable.

Thanks,

John Vaughters




On Tuesday, January 26, 2021, 4:49:09 PM EST, Scott Hall via TriEmbed <triembed at triembed.org> wrote: 






>Interrupts are the way to.  I have been advocating and professing using asynchronous coding techniques over synchronous techniques ever since the late 1980s.  Interrupt routines are to get the values of an interface quickly and set a handshake variable to a slower processing routine.  You never use timers in the routine, let the timer create the interrupt for timing, and never use delays or cycle-wasting functions or loops in the routine.  In the main operational loop, check the handshake and process the values as needed -- but always in an interruptible way (always process to the buffer pointer minus one to keep from catching a value that is currently being written by the interrupt routine).  This is actually standard best practice, and makes for far more responsive processes.