Does nay body else have the problem of the serial monitor on the host PC simply stopping displaying any more data returned from the Arduino. This happens to me after 4 to 16 hours while I'm looking for a bug that causes a hang. The arduino is putting out a circa 100 byte block of data every 10 mins.
At first I thought that the PC was running out of ram but the 4:1 variation in the time it takes to come to a halt make me doubt that.
That's not much data in total before it hangs. Are you sure that the arduino or your program hasn't crashed? Do you have some way to know that it is still putting out data? I have something running right now that reads 3 dallas 1-wire temp sensors and writes the info to the serial port. I'm putting out about 100 bytes every second and it has been running for many hours now using the built in port monitor to show it.
EDIT: You jinxed me, it just stopped outputting to the comm port display. I could see the tx LED on the arduino is stuck on like the buffer is full. The rest of my code was running fine still, happily updating the LCD so my uno wasn't frozen. I tried resetting the arduino and then closing and reopening the comm port display window, but no difference. I unplugged the USB cable causing the arduino to lose power, but I didn't close the IDE. I plugged it back after a few seconds and it all started working again without rebooting windows or closing the IDE.
The IDE is pretty flakey in my experience and could easily be causing the problem - to test whether that is the cause, you could use a different application to display the output from the COM port (there are plenty to choose from).
Yes the arduino is usuall still running when the monitor stops. Its reading a set of analog temperature sensors every second, averaging them over 15 seconds worth of readings then setting some switches and taking a snapshot recording of everything every 10 min onto an sd card. Also the data can be read back over the ethernet. Those pards still work most of the time.
I'm actually trying to debug somthing that realy stops the Arduino but that happens at 2 or 3 day intervals. I would like to put more Serial.print statements into the code to find the bug, at the moment I'm just printing things like FO/FC/FDNO for 'file open/file close/file did not open' etc to cut down the amount of ram on the PC that the text on the monitor takes up and to stop the sketch gatting too big, its 28K before I start filling it up outputs for debugging.
So any suggestions as to which serial monitor I can leave running for days would be welcome. I supose I don't even need yesterdays activity when everything is working ok Just the bit where the Ardunio comes to a halt.
On large sketches it's very easy to run out of SRAM space (not flash space as reported by the IDE) and that can lead to very illogical failures and not easy to diagnose. What many do is try storing a lot of the constant string print messages to flash memory instead SRAM default and see if the symptom changes.
Hi Lefty,
I learnt my computing on a LEO II using 5 hole punched tape for programming and input 50 years ago!! So its in my nature to automatically use all the memory optimisation that I can.
I'm not using the String class to avoid the known bug, just Char[] arrays. The text for the Client.print, File.print & Serial.print all use the F macro for fixed text and I'm using integer arithmatic in all but 2 sums. memfree() is reporting 650 bytes of sram free at the worst part of the programme on every cycle, as such I don't appear to have a memory leak so something else must be happening.
I don't want to tear the libraries apart and reverse engineer them unless I have to. I just want the project to run as an embeded system, trouble free for the next 25 years!!!
If you want to see if the issue is the serial monitor or the arduino code, defeat the auto reset of the arduino with a capacitor or resistor. That way you can use the serial monitor to check the arduino output without reseting the arduino.