I've had an exceptional amount of difficulty getting the serial monitor working reliably in the arduino software v22 under Ubuntu Linux. It sometimes works if the amount of data coming over is very low or very intermittent (e.g., once per second or slower). First, the background:
I have a new Arduino Uno. It appears to work normally.
I am powering the Arduino over USB (no external power.)
I am using the arduino IDE v22 under Ubuntu Linux ~9.
I'm using java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
I have added myself to the "dialout" group.
My Uno always appears as /dev/ttyACM0, as follows:
ls -l /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 2011-01-23 16:34 /dev/ttyACM0
dmesg:
[243199.131605] usb 4-1: new full speed USB device using uhci_hcd and address 29
[243199.342928] usb 4-1: configuration #1 chosen from 1 choice
[243199.345892] cdc_acm 4-1:1.0: ttyACM0: USB ACM device
I can load, compile, and upload most sketches without difficulty. However, if a sketch sends more than a trivial amount of data with Serial.print(), things go haywire. I will describe in detail below, since I've managed to find a few other posts describing similar symptoms but I didn't see any posts that got to the bottom of it. Hopefully I can help the experts drive this to ground and get it sorted for all of us. I am happy to do additional debugging on my side if it will help.
To set a baseline, I called up the Blink example (which does not use any Serial communications) and loaded it in to the Uno. After the sketch loads, the "L13" led blinks slowly at ~0.5Hz as expected. At this point, with the Uno connected to the laptop and the arduino software running, I can open the serial monitor window and close it as much as I like. I can change the settings and the settings are recalled the next time I open the window. I don't see anything in the serial monitor window, but because Blink does not send anything, I don't expect to. I can use the mouse to select menus in the IDE and make selections with good responsiveness. I can quit the Arduino IDE and start it back up again, and it quits and loads quickly. In fact, I can load my own complex sketches that don't write serial data back to the PC and everything works OK. I belabor all of these points only because they contrast with what happens when I load a sketch using heavy Serial output.
With the Uno loaded with Blink, I called up the example Examples/Basics/AnalogReadSerial and made one small change: I added a delay(1000); to the start of the loop (in order to observe and test some things which I will note below). I sent this slightly modified Blink sketch to the Uno. The sketch loads (Uno RX/TX lights flash, Uno resets) and starts running. The Uno's TX light blinks slowly, about once per second, (which is expected since I added the delay(1000) line to the loop). The interesting thing here is that the TX light stays on for about half a second each cycle, then turns off. I click on the serial monitor icon in the Arduino IDE, and after a second or so, the window comes up and I start to see the output of the sketch. ALSO, the TX light on the Uno has changed its behavior: It still comes on once per second, but it only stays on for a few ms. It's more of a brief flicker than a blink. When I see this behavior I know the Uno has achieved some sort of "happy" state for serial comms with the host. I can open and close the serial monitor with the sketch running on the Uno; whenever the serial monitor window is closed, the TX light duty cycle is about 50%; whenever the serial monitor window is open, the duty cycle is maybe 1%. I can open and close the serial monitor window as often as I like. I can use the menus in the IDE and they are very responsive; I can quit the Arduino IDE and re-start it very quickly.
Now, if I take the "delay(1000)" line OUT of the sketch and re-upload it in its stock form, the situation changes dramatically.
I open the AnalogReadSerial example again and press the Upload button in the Arduino IDE and the sketch loads. The sketch starts running as soon as it's done loading, as expected, and the Uno's TX light turns on solid. It does not turn off, ever. Now I click the serial monitor button, and after a few seconds, I get the following error: "processing.app.SerialException: Serial port '/dev/ttyACM0' already in use. Try quiting any programs that may be using it." Taking a cue from another thread, I do a "lsof | grep ttyACM0" at this point; the grep returns zero rows (no hits.) The /dev/ttyACM0 device is still present, but there is a new line in the dmesg dump:
[244277.807273] tty_port_close_start: tty->count = 1 port count = 0.
At this point, the IDE is very sluggish and unresponsive. Menus do not drop down for seconds at a time. I can quit the IDE, but it takes some time to actually respond to the close box click. (The Uno is still on this whole time, BTW.) When I start the IDE back up, it takes a long time for the GUI window to come forward. Before it does, on the command line from which I start the IDE, this message appears:
RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyACM0
Now when the IDE finally does come up and I hit the serial monitor button, I get a different error: "processing.app.SerialNotFoundException: Serial port '/dev/ttyACM0' not found. Did you select the right one from the Tools > Serial Port menu?" At this point I verify that the device still exists with an ls -l /dev/ttyACM0, and sure enough it is still listed and has not changed. I check dmesg to see if a different port has appeared, but there are no more USB connect messages. There are, however, a whole lot more of these:
[244552.082351] tty_port_close_start: tty->count = 1 port count = 0.
(After some poking around after this line of experimenting, I can report that this line appears a few seconds AFTER the serial monitor button is pressed and almost immediately before the "port not found" error message is printed. It also appears after a failed upload of any sketch when I try to replace the problematic one running in the Uno.)
Now I am in a tough spot. I can't just open the Blink example and upload it, because the IDE claims it can't find the serial port /dev/ttyACM0.
Furthermore, at this point the Arduino Uno RESET button does not appear to work quite right. When I press it, the "L13" LED blinks three times in rapid succession, but the TX light never goes out. If I hit the upload sketch button in the IDE and then hit the Uno's hardware reset button after just the right fraction of a second delay, I can successfully load a replacement sketch. There is a very small time window that if I am lucky, I can hit and have the Blink sketch reload into the Uno and things return to normal.
So, it seems that there is something going on in the USB interface on the Uno and its relationship with the host-side driver that makes connecting to the Uno impossible if the Uno is already trying to send a lot of serial data to the host.
I am working with an MSGEQ7 and seeing the data quickly is important to figuring out how my circuits are behaving, so the (delay(1000)) is not really a solution. Can anyone help?! I am happy to do investigations and testing on my side if someone can point me in the right direction. I have some java and c/c++ development experience.
Thanks!