I haven’t been able to find any specific reference in the doco to this.
If a delay() is in progress, will an interrupt stop the delay and start the function?
In my situation, we are ‘activating a pump ignition sequence’.
We need the start, hold, start, hold sequence to follow exactly the timing we put in and not have an interrupt stop the sequence. I’m unsure if when an interrupt function runs, if it returns to the ‘top’ of the loop() function, or resumes the loop() in the same spot it left off.
After an Interrupt code picks back up where it left off, anything else would surely be chaos.
Given all your are doing is turning something on and off, Could you not also do this with a Timer toggling a boolean state or the recommended millis().
If you have defined an interrupt it is precisely because you want it to interrupt your application to act on that trigger. Any code triggered by an interrupt should be very short, like setting a flag, at which point you return to your sequence with minimal consequence.
My limited understanding of the Particle system would suggest the only Particle defined interrupts that could interfere are probably linked to the Setup and Reset buttons.
It may be better to keep loop() looping, managing the events with a state machine-like approach.
If you have the skills, you you may want to try to create a little class that inherits from Timer that includes at least two member functions. 1) starts the pump start sequence and 2) returns true if the sequence is active.
That’s one approach, but I’m spiraling out here… sorry.
1 second might seem short but its an age to a microcontroller switching threads every 1ms. Now if you were instead talking much smaller intervals, then you might need to be worried e.g the example shown here https://docs.particle.io/reference/firmware/photon/#single_threaded_block-
The only things you really need worry about are the synchronous calls that could cause blocking behaviour listed shortly before that example. But that’s easy enough, if the ignition sequence is in progress don’t call any Particle methods until it is done.
Humm, I thought about this and wondered if that meant I needed to keep the latch state in memory - if we had power outages or used the bypass switch I’d end up with some complex logic… the alternative being I guess to use another relay to reset the latching - but that increases the pin count (already running low) and also makes it really hard for the onsite installer/electrician to wire it up.
Unless I’m missing something about the latching relay ponders
I was thinking, disregard the SMS’s in memory as they may contradict each other.
e.g. One user turns the pump on, another user tries, someone tries to turn it off, someone tries to check the state. I’d end up with scrambled up perspectives of ‘state’ of the pumping unit.
Maybe the answer lies in your suggestion of ‘i’m busy’ … argh - that brings me back to the complex world of trying to read SMS messages. I have another thread going for that one! haha