bug with serial port?

The Diecimila does in fact reset every time you open a serial connection to it. There are a few ways to get around it. The easiest might be to remove the capacitor that allows the automatic reset (although if you do, you'll also need to replace the bootloader with the NG one or you'll have a hard time uploading new sketches). It's the last thing (closest to the ATmega168) in the column of components that includes the L led and the RX and TX leds, I think.

Or you could use some sort of proxy (i.e. another simple Processing sketch) that keeps the serial port open all the time and forwards data to the other sketch over a local network connection (or some other means).

There's another trick, but it will probably require you to modify the Processing serial library and or the RXTX library that it uses. If you unset HUPCL when you have the port open, the next time you open it, the board won't reset.

I experienced the same problem relating to this issue.

I just got my decimila and tried using the example program 'physicalpixel' ; I was only able to get the processing program to interact with the arduino by adding a delay of about 12 seconds along the lines suggested in the previous replies.

Could you explain why it is necessary to do this, since I presume that the previous versions of the board did not require it?

You may want to amend the example programs as I am sure a lot of folks like myself will try the communications examples, such as physicalpixel and be a bit disappointed when they dont work.

I think you may have gotten a Diecimila that was accidently burned with the wrong bootloader (the NG one). The Dieicmila resets when you open a serial connection to it, however, the new bootloader quickly times out and starts your sketch, even with no delay in Processing. I should probably add in code to include the delay, but commented out, so that other people with these boards with the wrong bootloader can uncomment those lines to get the example to work. You might also want to burn the correct bootloader onto your board. For example, uC Hobby has instructions for doing so with a parallel programmer: https://web.archive.org/web/20200610013744/https://www.uchobby.com/index.php/2007/09/12/how-to-update-the-arduino/, or you can use an AVRISP mkII and the burn bootloader command in the Arduino environment.

Hi, I am not sure how to burn an up to date bootloader with the environment. Where would I find the latest bootloader and instructions on how to do that? is there any way to check to see if I do indeed have the NG bootloader by accident?

thanks for your help! I love the arduino and the way that you can simply interface to it.

I just realized that the solution you suggested would involve me getting a parallel or other programmer for the chip. Unfortunately i can't afford that. Could I return the board and have your distributor (MAKE magazine store) replace it with one with the correct bootloader?

There is a difference in the Diecimila, in that opening a serial connection to the board will reset it.

When doing a "tail -f /dev/ttyUSB0" the first time after connecting the diecimila to the computer, it will reset and its program will run from the start; breaking out of tail (ctrl-c) and restarting it will not do that (inbetween readings are lost though). I am just too lazy right now to check what happens when the computer is rebooted while the diecimila grafts.

PS: stty reports that HUPCL is set to off on the port. Trying above procedure with the arduino-IDE serial monitor will perform the reset all of the time.

Interesting. hungerbug, are you on a Mac? Did you unset HUPCL explicitly with stty? Does the board rest if you connect to it with Processing? I'd love to find a good way for people to prevent the board from resetting every time the port is opened.

hello mellis,

this is with a recent linux system:

  • no I did not set -hupcl explicitly, that seems to be the way the device gets created by udev
  • when reading the serial port with a processing sketch, the arduino resets every time.
    also, if I set [+]hupcl with stty, running the sketch will again set it to -hupcl!

what was it, you did to rxtx to make the autobootloader work on the 10k?

Actually, the FTDI drivers on both Mac and Linux automatically set (bring low) the DTR line when you open the serial port, which resets the board. Since we've got DTR connected to reset by a capacitor, you only get the reset when the lines drops (not when it's being held low), so if you unset HUPCL (leaving the line low when you close the port), the board won't reset the next time you open the port. On Windows you can open the port without setting DTR, but I'm not sure which programs do so.

Thank you mellis; What I think I understand, please correct me if Im wrong:

  • HUPCL=hangup on close?
  • When I interrupt tail-ing of the port, it will not be shut down properly, so subsequent opens will not change DTR, voilà no reset.
  • This is consistent with the following: After killing tail, reading the port by a processing sketch also will not reset the arduino. (above I said, it always does, but I just did shorten the story.)
  • also consistent: doing a tail after the processing sketch will again reset the board.
  • also consistent: if I "kill" the processing sketch, not "esc" out of it, it behaves the same as tail or "ttylog".

actually the linux kernel ftdi driver should not mess with DTR on close, if not instructed to do so: http://www.gelato.unsw.edu.au/lxr/source/drivers/usb/serial/ftdi_sio.c#L1333

PS: my interest in this discussion: it was nice to be able to connect a computer to an arduino diecimila from time to time only to monitor, what its doing.

Yes, HUPCL is hang-up on close. Thanks for the information. I'd like to find a way do something similar on other OS's, although some superficial tests made it seem like it's not as easy to prevent the board from resetting on the Mac. I could be wrong, though.

I'm having a lot of trouble with this issue using my Mac to send data to my Arduino Diecimila. hupcl seems to be set on the port no matter how many times I try to unset it with stty and my board always resets (taking about 11 seconds) whenever I open a connection to the serial port (using echo or screen or telnetting to serproxy).

This makes it apparently impossible to create a stand-alone command that will send data to the Arduino. Is there anything I can do? Is the only solution to write a program that will open the port, keep it open and then accept data from other programs?

I am able to change the value of hupcl while the port is open. So if I open the port by telnetting to serproxy and then in a separate terminal window set -hupcl then as long as I don't close the telnet session, I'm able to echo data to the serial port and it won't reset the board. Closing the telnet connection closes the port from serproxy and hupcl is set again and all future connections to the serial port reset the board.

It's good to know that this works, but it certainly doesn't seem like an ideal solution.

There are a couple of possibilities. One is to set (unset?) HUPCL from within the program that sends the single command to the board - after you've opened the port. If you do this each time, opening the port will never reset the board. Another is, as you said, create a single program that proxies the actual communication with the board (you could use serproxy for this).

Also, if the delay is 11 seconds, it sounds like your board has the wrong bootloader. Some of the Diecimila boards were unfortunately shipped with the NG bootloader. If you burn the Diecimila bootloader, you'll only need a delay of a second or two, which might be short enough to just build into the individual commands (depending on what you're trying to do).

Maybe I can workaround this reset problem by using the digital pins 0,1? The setup is as follows: an arduino board that runs standalone on an external power supply. With each iteration the code dumps some values on the serial port, so a monitoring computer can be attached - this should not interrupt the running program in any way, though, so I rather not mess with DTR, which is a pain on the USB connection.

I imagine, the arduino digital pins 0,1/RX,TX map to pins 3,2 of a 9pin computer port. How do I connect computer pin 5/ground on the arduino?

Peter

I did now wire arduino TX pin1 to db9 RX pin2 and arduino GND to db9 GND pin5. on the computer nothing received on the serial port. the arduino tx led does not flash neither. computer and arduino use the same datarate. the arduino has its own power adaptor.

What am I doing wrong?

You need to do some voltage conversion between the Arduino RX and TX pins and a regular serial cable / RS232 / DB9 connection. You might want to start a new thread about it.

They added the capability of having the Arduino software environment reset the Arduino processor, so that you would not have to do the little dance of pushin the reset button and hitting the download button within a relatively small time period. It also makes it possible for the timer period to be reduced that the AVR waits. deciding whether it should run the existing sketch or the bootload code. Unfortunately, the USB interface chip that the
Arudino uses emulates a serial port, and the initialization that most software does when you "open" the serial port causes the same reset action on the arduino side.

Not sure this is relevant, but was able to prevent this reset by setting the DTR within a perl script I was using. Hopefully this will help somebody with a similar problem talking to the Arduino with perl.

-Dave

#!/usr/bin/perl

use strict;
use Device::SerialPort;

my $port = Device::SerialPort->new("/dev/ttyUSB0");
$port->databits(8);
$port->baudrate(9600);
$port->parity("none");
$port->stopbits(1);
$port->dtr_active(0);

sleep(1);

...