I'm using an Uno board and working on a sketch that in cycles a device on and off in (roughly) 1 min on and 1 min off cycles for a period of 8 hours. The device will output a fail signal if it detects a problem, and I have the sketch set up to uses an external interrupt on Pin 2 (int 0) to go to a loop that turns the device off, lights a "Fail" LED and does a Serial.print with a fail status and the time of failure.
The interrupt does call the handler, the pin changes seem to work, and it "halts" (via the "while(1);" loop), but I can't seem to get the fail message to the serial port.
Has anyone run into this before?
The code for that portion is posted below:
void failHold() {
detachInterrupt(0); Serial.println("FAIL"); Serial.print("Fail detected at "); Serial.print(millis()/1000, DEC); Serial.println("S. Correct problem and RESET."); Serial.println("");
digitalWrite(ampKeyPin, LOW); // unkey the amplifier
digitalWrite(txKeyPin, LOW); // unkey the transmitter
digitalWrite(keyLEDPin, LOW); // clear the Key LED
digitalWrite(failLEDPin, HIGH); // set FAIL indicator
while(1){};
}
Are you calling failHold() from an interrupt routine? That's really bad news, interrupt routines should complete and return ASAP (certainly shouldn't be calling into a library routine). While you are in an interrupt routine you are blocking other interrupts from running, such as the ones that are sending out bytes to the serial hardware....
You should be setting a flag in the interrupt routine for situations like this that loop() checks everytime through and call the failHold() from inside loop().
Yes...as far as I can tell the best way to do it is through an interrupt because I need it to immediately shut down the two devices.
Calling failHold() from inside the loop when the fail pin goes low would I believe allow the devices under test to keep running even after a failure is detected.
Currently loop() is using delay(mS) to establish the on and off periods, but by using a "check and see" approach to the timing, I can have it cycle through error checking, and keep a running clock on the monitor.
Thanks Mark - you've confirmed my suspicions about the serial port.
It's apparent what I must now do. I think it will give me better control and while a little less efficient, timing isn't critical so I think it will work out just fine.