I am having a strange problem with a Diecimila board resetting when it receives serial communication. The problem only grows more bizzare in that it only show up if the board has been sitting there idle for ~5 minutes. if it sits there idle even longer, it will not even open up for serial communication and the program hangs. I have two boards, and pulling one and letting it "rest" for 10 minutes seems to fix the problem, but i need to be able to talk to the boards 24/7 without swapping them out. I'm not trying to do anything too crazy (sending a number) and I am able to get it working perfectly so long as it is within the first 5 minutes of plugging it in. This is a really strange problem, and i have no idea how to attack it.
I am using the arduino-serial.c provided by todbot's blog (http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/) and have it compiled and tested successfully under cygwin on and intel imac running windows xp pro sp2. (did have to comment out one line for it to work).
Thanks for helping as i am fairly fresh to he arduino scene!
I have no idea :)
but what are you talking to the arduino with? Is it possible that your client is closing the port after some period of time?
I’m just using a very general command to send a number to the com port. The command is almost verbatim once of the basic commands to make sure that the device is able to receive information from the command line that is on the tutorial (link in original post). The exact command that I use is “./test -p /dev/com3 -d 2000 -s 3” (minus quotes) The -p designates which port to send the information to. The -d sets a delay (as the Diecimila resets on serial opened, so this allows it time to finish resetting and get ready to receive information). and the -s is the information to send. I’m running a simple pde that listens for a number (and changes the ascii character received into a number) waits that many seconds, then turns an led (connected to pin 13 and ground) on for that number of seconds, hen turns the led off. When I open the line for communication the board resets (as it is supposed to) and the led flickers once. Then, two seconds later, the board receives the number (rx light turns on) but it appears to reset once again (led flickers again) and then nothing happens.
However whenever I use the serial monitor in the arduino program, it works fine, even when the command line does not, although it seems after about 10 minutes or so (after the command line is incapable of talking to the arduino) it too loses the ability to talk to the arduino completely (as it it will not even transmit and I get all sorts of fun red error listings in he text box) whereas the command line just seems o reset. This happens on both boards.
Also, letting the board rest does not always guarantee that it will work when I plug it in, seems to be more random than I initially believed.
As roypardi says What are you using to talk to the Arduino?
That is what is your hardware setup, PC Mac Windows what?
What language is you computer based end running?
If the serial monitor improves things it does sound like something is shutting down the port. USB ports shut down when there is no activity on them for a second or so.
I am using a modified version of http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/ to talk to the arduino via the command line.
I am running on an intel mac using WinXP SP2. (dual core intel proc with 2 gigs of ram).
I tested everything out on monday, and all day it ran flawlessly (stuck it in new usb port as I thought that might be the problem). It seemed to be fixed, but I came in today and it is continuing to show the issue. Using the serial monitor does help, but it is not 100% effective either (though perhaps 90%). So I have no idea why it was working so well on monday, or why it is messing up again today.
I am running on an intel mac using WinXP SP2.
Recoiling with horror . What an awful thing to do with a lovely Mac.
Yes it sounds like the port is being shut down by that nasty Mr. Gates. Test this by looking at the reset line with an oscilloscope. You could try disconnecting the USB chip from the reset line or using processing running under a Mac OS.