Help correcting bad habits

I've completed my first big project and it works very well. However, I've picked up some habits I'd really like to change.

Here's the scenario - the Arduino is connected to the usb cable and the program is running. Now to make a change, I make the program changes, save the program, close the IDE, unplug the usb cable and then plug it in again and start the IDE, load the previously saved program, compile it and upload and all is well. I go through this clumsy process because if I try to compile and upload while the program is running, I get errors due to the com port being busy, since I usually have Serial.println functions running to help me with debugging. I made a change to have the serial print functions run for 10 seconds in order to see the TX light go off (hoping to avoid com port busy problems) but that doesn't work either.

I would very much like to understand how to make the test/change process quicker and less cumbersome.

Can you just close the serial monitor instead without disconnecting everything?
Or does your sketch sit there and churn out data thru its serial port?

Even if the program is constantly barfing data out to the serial port, it really… really shouldn’t affect your ability to upload!

See, the Arduino boards use a part of the serial connection called “DTR” (data terminal ready), a signal line used on old modems but not used for data transfer. It “blips” that signal before it tries to upload the program. That signal is connected to “Reset” on the Arduino, so whenever the computer “blips” DTR, it’s the same as hitting the reset button on the board. It does that whenever it goes to try uploading a program, every time. And it always works, pretty much with zero exceptions, because the timing of the bootloader is synced with the timing of the uploader, one knows what to expect from the other.

So no matter what your program may be doing, it can’t touch DTR since it’s not even connected to the chip (except at the Reset pin). You can have a program running serial at 140kbps burping out streams of garbage data, and the uploader blips DTR to say “SHUT UP!”, the chip resets and receives the program. Even if you have the serial monitor open, the Arduino IDE is smart enough to close it before trying to upload (automatically).

The only thing that could be getting in the way is some outside program running on your PC, tying up your serial ports. Maybe you have some modem software running? Anything that could possibly be getting in the way of the COM port. Failing that, try going to Device Manager and changing the port number assignment for that USB COM port, maybe that mystery program will leave the new port number alone :wink:

Crossroads - I can close the monitor but it doesn't make any difference.

What steps do you go through for changing code on an Arduino?

I should add that I'm running the IDE in an XP partition in VMWARE. I did this because my base system is Win7 x64 and there seem to be known problems with compiling and uploading in this environment.

If I need to, I can just create a base XP system and boot to it (no VMWARE). However, I'd really like to not do that.

Oh, GOD! Man, you're making things about 100 times more complicated than it needs to be... haha.

I run Windows 7 Home (hey, I'm a domain admin but don't need it on my personal PC) x64, with SP1. Yes, Windows 7 x64. Arduino IDE 0022.

Here's how I put some new code on my Arduino Duemilanove via USB: - fire up Arduino IDE - jot down some scribble code - plug in Arduino with USB cable - hit Upload - Done!

That's all you've gotta do. No matter what your program may be burping out over serial... just hit "Upload" and it's done. VMware can be really flaky with USB, so it's just adding another layer of complication on there...

There are no known problems (that I know of) with building on Windows 7. I've never, never touched XP with my Arduino and all the low-level bit-banging hacking I've done with it. I mean, have you had any issues, or even... tried it? :~

If you insist on uploading the code while your arduino is using the serial, what error message do you receive?

Have you tried manually pushing the arduino reset button to fix the uploading problem?

I have windows vista, was running -0021 (before I got myself all hosed up doing sanguino stuff).
I would compile my code, and upload - if the serial monitor was open, it shut by itself, and the upload would start after the standard # of seconds with the normal bootloader.
Pretty much as falconfour desribes the sequence.

if u'r having this much trouble then why use the pins that screws you up ? pick another pin or program an analog pin to digital if u need more digitals.

It should just work. As mentioned earlier, it's more likely that some other software is tying up your COM port.

I’ve heard of a case where a sketch that sends serial data continuously would flood the USB buffers with input. Even if the Arduino is reset those buffers are still full and prevent the output attempts from getting any buffer space.

This is unusual.

The fix is to hold the Arduino in Reset while temporarily disconnecting the USB cable. Then start the upload and release the Reset button only when you get the “Binary sketch size:” message. This flushes the buffers (by unplugging the cable) and keeps the sketch from running before the upload (by holding the Reset button).

Sounds like sound advice! Nice tip, will have to remember this one.

johnwasser - your idea fixes my problems - thanks.

another option is put a decent sized "delay" into setup(). push reset when you hit upload and the board will be in the delay when the code starts to hit.

UnstableBoy: another option is put a decent sized "delay" into setup(). push reset when you hit upload and the board will be in the delay when the code starts to hit.

I don't see how that would flush the USB buffers.

I've heard of a case where a sketch that sends serial data continuously would flood the USB buffers with input. Even if the Arduino is reset those buffers are still full and prevent the output attempts from getting any buffer space.

That was a problem that came up with the release of the Uno board. It was a bug in (I think) the 8u2 serial converter on the board. It did get fixed/updated/resolved at some time later in the manufacture run. I don't own a Uno so I didn't keep track of the bug details but it was a problem not ever seen on arduino board models using the FTDI serial converter chip prior to the Uno's release.

Lefty