Although the example above is contrived, it's not uncommon to "stream" sensor readings.The device /dev/ttyACM0 is simply not accessible anymore (or only for fractions of a second once in awhile). This is not a problem with the FTDI based units.

I don't think it's the bootloader. To recover from my most recent test I swapped the ATmega328P from my Uno and put it into my Duemilanove. I switched the "Serial Port" to /dev/ttyUSB0 but had to leave the board type as "Uno" or uploading would not work -- I figured this was because the ATmega328P had optiboot on it.

After that, I was able to reprogram the chip easily even though it had the tight serial loop code / optiboot.

@Senso: pressing reset doesn't really help. I tried varying my button push timing systematically (then randomly) and coudn't come up with a reliable procedure that I could say with certainty was responsible for the success of the upload, though I did get it to work once (but not with the example program in the OP of this thread).

Yes, a fine option for programming the Uno, but as I've previously outlined in this thread, the problem does not appear to be with the bootloader (see reply #3). Additionally, not everyone has an ISP, so that is a bad option for democratizing the tool.

It appears that we need someone with Linux CDC / ACM kernel module experience, someone with LUFA / USB / 8u2 programming experience, or someone with an oscilloscope or logic analyzer to look into this and check out what's going on when the Arduino Uno is sending serial data that causes the /dev/ttyACM0 port to become inaccessible. Bad symptoms happen completely independently of the Arduino IDE -- an Arduino Uno sending serial data hooked up to an Ubuntu Linux 10.04 LTS or 10.10 Meerkat (kernel version 2.6.35) computer is a PITA to use even without the IDE at all -- simply attempting to open the port with a program like "minicom" fails most of the time.

I am no expert for Linux / Kernel issues. However I had significant issues with Ubuntu and the AVRISPmkII. The issue was caused by how Ubuntu handled USB. The issue disapeared after upgrade to 10.04. I did not upgrade to 10.10. So if you suspect the Kernel, then you have to tell which Kernel you are running.

I've got Ubuntu 10.04 and got the same issue. I plug out the board, plug it in while holding the reset button and restarting the IDE. Then I get the message:RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyACM0

And everything works fine until I open the Serial Monitor again. Sometimes I get this message:RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyACM0: File exists

Hi all,I have the same problem with my Arduino Uno / Ubuntu 10.04 LTS/64 bit (I can break the look with Win7, however).

Would it be a solution to add a switch to the setup and within the serial look check whether the switch is pressed. If the switch is pressed the serial loop is exited. This would be a software/cheap hardware solution to stop continuous data stream to the serial port. Then it should be possible to send another sketch to the Arduino.

Cheers

Karl-Heinz

PS: I am not a programmer, but an endless loop without any control does not look like good programming practice to me.

Just a proof, that it is possible to overcome the limitation of the current Arduino Uno to look when permanently sending serial data.

Turns on and off a light emitting diode(LED, i.e. red) connected to digital pin 13, when pressing a pushbutton attached to pin 2. Turns on and off a LED (i.e. green) connected to digital pin 12, when pressing a pushbutton attached to pin 3

Reads an analog input on pin 0, prints the result to the serial monitor

// constants won't change. They're used here to// set pin numbers:const int buttonPin = 2; // the number of the pushbutton pinconst int ledPin = 12; // the number of the LED pinconst int buttonPin2 = 3; // the number of the pushbutton pinconst int ledPin2 = 13; // the number of the LED pin

>>PS: I am not a programmer, but an endless loop without any control does not look like good programming practice to me.

Hi Karl-Heinz,

that is true. The reason this happened to me is that I uploaded an example from the example library: the DigitalReadSerial example in the Basics section. I did not look at the code in that much detail before I uploaded it, not expecting that a program in the Arduino IDE could brick my UNO.