I'm on Win7 64, Arduino Uno, visible in the Device Manger under "Ports" as "Comm. Port COM4". I have a simple, working sketch in which I send simple commands to the Uno via the serial port. Everything works. However, after sending two commands, COM4 becomes unavailable. At that point, issuing "mode com4" in cmd gives me "Device COM4 is not currently available". If I keep the Device Manager open while I issue the second command, I see that the listing is being refreshed as if hardware was being re-scanned. I can "fix" the issue by uninstalling COM4. At that point, in the Device Manager, with "Show hidden devices" on, I can see a gray "ghost" of COM4 that's still there. After removing the ghost COM4, scanning for new hardware, Win will find the Uno again and install it under Ports as "Comm. port (COM4)".
At that point I can issue two commands and then... I'm back to the problem. I tried reassigning the Uno to another port (COM7) in the Device Manager but I get the same problem. Any advice? I don't think the problem is with the sketch, but I've included it just in case.
char* val = "0";
void setup(){
for (int i=8;i<12;i++) {
pinMode(i, OUTPUT);
digitalWrite(i,LOW);
}
Serial.begin(9600);
}
void loop() {
int idx=0;
if (Serial.available()>0) {
while(Serial.available()>0) {
val[idx++] = Serial.read();
}
//Parse input here, set relevant variables, set port state
...
digitalWrite(port,state);
}
delay(500);
}
Other than a USB cable, what is connected to the Uno?
A 4-channel, 5V relay board, its inputs connected to the digital pins of the Uno. Two relays have wiring attached, two are blank. The relays work fine as long as I'm able to issue commands.
BTW, not sure if it matters, but during installation I pointed Win to the \drivers folder (not FTDI) per the install guide.
I was about to test it but then I realized the bug is in the sketch, after all. I declare "val" (where I read in the commands) as a single char, because originally my serial commands were 1-char long. But I then switched to 2-char long commands, without changing the val declaration. So now the second 2-char command runs over the declared length and (presumably) locks up the Uno. I changed the val declaration to "12345678" and I added "Serial.flush;" once I've read in the command. Everything works again. Thanks for helping me along.
One more question. I issue the serial commands from a Perl script. It seems that Arduino's Serial Port Monitor and my Perl script don't play along. That is, if I use the Serial Port Monitor, I can access the serial port as much as I want. But once I've quit out of the Monitor the port becomes inaccessible to my Perl script. I have to uninstall the port and re-scan for new hardware. Then it becomes accessible to the Perl script. But if I try to launch the Monitor after using my Perl script, the Arduino IDE locks up. It's not a big issue, because, in the end, I'll only be using the Perl script. I'm just curious why this is the case. I realize that a serial port cannot be used by software A and B at the same time, but it should be possible to access the port from software B, once software A has been closed.
emprolus:
I was about to test it but then I realized the bug is in the sketch, after all.
I suspect you are a bit too hasty to declare victory.
One more question. I issue the serial commands from a Perl script. It seems that Arduino's Serial Port Monitor and my Perl script don't play along. That is, if I use the Serial Port Monitor, I can access the serial port as much as I want. But once I've quit out of the Monitor the port becomes inaccessible to my Perl script.
The symptoms you have described, including the one above, indicate a hardware related problem. My suspicion is that your Uno + relay board are consuming more power than your USB port can safely provide.
I suggest you reconsider Reply #3. If I am correct and you do not reconsider, you could permanently damage your Uno or even your computer. If I'm wrong the price you pay is fairly small.
No, I wasn't dismissing your voltage concerns, I was just happy to have found the cause of the "2-command-limit" problem. I realize that there are two unrelated issues here: sketch bug + voltage. I ran the sketch without the relay board, and, as you've suggested, I could run the Monitor and the Perl script one after the other without port drop-outs. Which means that the relays use more juice than the Uno can provide. I now power the relays directly from a 5V 750mA wal-wart and all seems fine. Thanks.
BTW, as I was testing voltages, I plugged a 5V, 1.8A wal-wart into the DC jack of the Uno (the relay board was hooked into Uno's VCC and GND), hoping that the Uno will pass on more juice to the board. At this point Win stopped recognizing the Uno altogether, so I promptly unplugged the 1.8A wal-wart. I then realized that the Uno has a rather wimpy voltage regulator which can't cope with an external DC supply that strong. The regulator ends up throttling the current to, say 50-100mA max, while heating up to the point of potential damage. Like I said, I now power the relay board directly and it works, so hopefully I haven't fried Uno's regulator. Thanks again.