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 <[email protected]> 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. _______________________________________________ Triangle, NC Embedded Computing mailing list To post message: [email protected] List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org TriEmbed web site: http://TriEmbed.org To unsubscribe, click link and send a blank message: mailto:[email protected]?subject=unsubscribe
