I admit it . . . I'm new to Arduinos. But they're really fun.
BACKGROUND:
Let's say My Uno (powered by a 9v wall wart) monitors light output from Your Uno's RGB LCD (your Uno is powered by a 12v wall wart). My Uno sees that the regularly-timed RGB LCD changes that are normally produced by Your Uno are not happening (i.e., Your Uno has hung). My Uno needs to reset Your Uno by sending a low pulse to Your Uno's RESET pin.
MY QUESTIONS:
(1) I assume the grounds of the 2 Unos need to be connected. Is that right?
(2) Does it matter which ground pins I connect between the two boards? My guess is that I need to connect the GND pin just to the right of the POWER area's 5v pin on My Uno to Your Uno's same pin. But there's also the GND pin next to POWER area's Vin pin on each board, and the GND pin next to AREF pin at the top of each of the boards in the DIGITAL area. So many choices!
MY PLAN: My Uno will hold its own output to Your Uno's RESET pin HIGH until a reset needs to occur on Your Uno. At that time, My Uno will send a short LOW pulse to Your Uno's RESET pin, then I'll bring My Uno's output to Your Uno's RESET pin back to HIGH. I'm pretty sure that's right, so I should NOT use a pullup resistor between Your Uno's Reset pin and 5v. Correct? (I think My Uno's constant-HIGH-until-reset-is-needed value into Your Uno's RESET pin should eliminate the need for such a pullup resistor.) Or maybe I'm goofed up in my thinking.
ANOTHER QUESTION:
(3) Should I use a resistor between My Uno and Your Uno's RESET pin? If so, what value?
Please let me know if my ideas are correct or if they're wrong.
You need to connect the grounds. On an uno, all grounds are the same so it doesn't matter which one you use.
Can't advise on the resistor.
And now the point; you should write the code in such a way that it does not stop working; a reset is hardly ever the solution. If that fails, you can consider the use of the watchdog that is build into the 338P microcontroller.
1 - yes, or use an optoisolator if that's not a good thing.
2 - all the gnd pins are connected internally, use whichever is convenient.
3 - would be a good idea; something between 220 and 1k should be fine. It will form a voltage divider with the 10k pullup and internal pullup on the reset pin, so you need a fairly low value to guarantee a valid reset condition.
4 - have you considered using the watchdog timer to reset the one with the LCD on it if it gets hung? Like, this is the exact situation it is designed for, and it doesn't involve a second arduino.
5 (as noted above) Write your code correctly so it doesn't hang!
Thanks for the responses. Believe me when I say I've tried changing my code to avoid the hanging. The hanging is sporadic, occurring as soon as a couple of hours from a reset, or as long as a few weeks after a reset. Often, it stops right in the middle of a write to the LCD, but other times the writes are successful. I have read about the use of STRING and even about using the Serial.print when the Uno isn't connected to the USB. I don't have any of that in my code (I've commented all the serial port writes, and this sketch never used STRING logic).
If you can see what it might be in my code that's causing the sporadic hang problem, please let me know what you think. I'm not a confident C (or C++) programmer by any stretch of the imagination, so your insights would be greatly appreciated. I've attached (at least, I hope the attachment will work) my code for the solar water heating controller that often freezes (pun intended).
I have no experience with the OneWire library so can't judge; maybe your code hangs on the sensors.requestTemperatures or something in another library.
Code wise, this looks like a job for the watchdog. Set it up in setup() and kick it in the beginning of loop(); not sure what the maximum time is (I think it's 8 seconds), your 5 and 10 second delays might interfere with it (you can rewrite your code to make use of millis() and a statemachine for the delay part).
Only two comments (in sequence of importance)
1)
Get rid of the goto. One hardly ever needs goto and your code definitely does not need it; replace it by a simple return and get rid of the label.
2)
My approach for below
if (firstTime == 1)
{
firstTime = 0;
}
else
would be
if (firstTime == 1)
{
firstTime = 0;
collector_temp2 = collector_temp;
tank_temp2 = tank_temp;
outside_temp2 = outside_temp;
// nothing else to do
return;
}
if ((tank_temp < -40 || collector_temp < -40) ||
It could also be a power issue or EM interferance.
But have you tried enabling the watchdog timer? You turn it on with a timeout up to 8 seconds, and have your code call the wdt_reset() function to reset the watchdog more frequently than that (typically like, every pass through loop). And if the code doesn't do that for long enough that the watchdog times out, it resets the board. It's meant as a solution for exactly this kind of problem.
Thanks very much for your responses, sterretje and DrAzzy. What each of you says makes sense. I had actually looked at the internal Watchdog function a few days ago, but must have been tired when I read the "how to" pages from several different websites - because it didn't make much sense to me. But yesterday, I read some other folks' ideas about how it works and how to implement it, and now I think the internal function really is better than what I was planning. Not that my idea wouldn't work, but using a 2nd Arduino is a bit clunky.
I also thought about power glitches causing the problem. That might be what happens, but nothing else in our house seems to exhibit problems. UNOs might just be more sensitive, or maybe the wall wart I'm using (brand new, though) is not up to snuff. (?)
If my code is hanging on something in one of the libraries I'm using, will at this point in my new hobby, it's above my pay grade to figure that out. Watchdog should cover it, though, no matter what's responsible. I even read one posting on the web where someone was using the same sensors I'm using, and that person found that water had seeped into one of the sensors, causing a 600 ohm connection between two of the leads where there shouldn't have been any connection - and THAT caused the Arduino to hang. (My installation is brand new, though, and I've been very careful about sealing things so that doesn't happen.)
As for the GOTO command and the LABEL - I know that GOTOs are frowned on, and I know that coding can be changed to eliminate GOTOs 99.99% of the time. But I'm not a C (C++) coder yet, and I didn't know about the C "return" command - I just hadn't cruised through the reference page looking for a solution to the GOTO. What you say makes good sense.