Hi everyone,
I have made my first serial comm program on arduino last weekend. I realized that each time I establish link on the USB serial port by opening serial port file and activating the transmission lines, the arduino resets itself. I know this because each time I open that comm port I receive the string that arduino is supposed to send when it starts up. Is what's happening really what I think? :-/ Does establishing serial comm reset the arduino?
The Arduino board is a prototyping and development platform.
The board resets the controller chip when there is a wiggle on the DTR line of the serial connection. This lets the bootloader run again, which gives the Arduino IDE a chance to upload a new sketch that replaces the old sketch. If no such upload happens, the old sketch is started again from the beginning.
In most applications, this is welcome behavior. When you connect with a terminal application or the Arduino monitor, you probably want setup() to run again so the Serial.begin(9600) takes effect, and you can see the first message your sketch prints out.
You can also design your sketch to use EEPROM to adjust the state of processing if you want it to "resume where it left off." EEPROM data does not get erased on each reset, so your sketch can read those values to decide what to do first.
In the very few situations where this is completely unacceptable, then you should fully debug your sketch on the Arduino board, and then transfer the programmed ATmega controller to a "barebones" circuit that does not watch the DTR line for a reset.
Thank you halley. That feature is indeed welcome in my case. By transferring the controller do you mean taking that large chip and planting it on an empty board? I thought the bootloader is stored in the flash with the sketch on the chip but I must be mistaken.
Yes, the big chip that is in a socket on most board variants.
There are three kinds of memory: PROGMEM (flash) contains the bootloader AND the sketch itself. The bootloader accepts the data that is your uploaded sketch, and the bootloader will ensure that it doesn't overwrite itself. Your sketch cannot change the PROGMEM contents. RAM is for your variables and this will be wiped out on every reset. EEPROM is like flash, but it's entirely at your sketch's control, and will not be wiped on a reset or power cycle. All three are in the "big chip" so you can easily transplant it all in one step.
Yes, It's actually two signal lines on the RS-232 that are activated when a port is opened, DTR and RTS. The process of opening a comm port (at least on windows) cause DTR/RTS to be turned on. There might be away to defeat this action in the device driver, but I'm not sure. Nor do I know how the Linux and Mac behave when opening a comm port.
The auto reset feature of newer Arduino boards wire a capacitor to either of these two signal lines (after they have been converted to a TTL signal level) and wires it to the Arduino reset pin, which causes the Arduino to reset and start the bootloader.
Removing this capacitor link will stop this behaviour/feature and some Arduino designs have a removable jumper to enable or disable this feature. If you disable the link then you will have to remember to hit the reset button on the Arduino when attempting to download a new sketch or reinstall the jumper.
So basically it's simple to get around this auto reset behavior by just removing the cap the connects to the Arduino reset pin.
Lefty
So basically it's simple to get around this auto reset behavior by just removing the cap the connects to the Arduino reset pin.
I completely agree, but I usually don't advocate patching or cutting a purchased board that otherwise works perfectly, so I didn't mention that. The ones with jumpers are the best option if you need to control the behavior, but you don't want to wire a whole circuit and come up with a corny name like "My Own Private Iduino" for it.
Thanks guys. That was very helpful.
Yes, It's actually two signal lines on the RS-232 that are activated when a port is opened, DTR and RTS. The process of opening a comm port (at least on windows) cause DTR/RTS to be turned on. There might be away to defeat this action in the device driver, but I'm not sure. Nor do I know how the Linux and Mac behave when opening a comm port.
I've same problem with my Mac and it is a pain 
Hoping someone finds a trick to solve this issue !
I didn't try it myself practically, but you can plug a 110 Ohm (or 100 Ohm) resistor between the reset pin and the +5V pin to temporarily disable the Auto-Reset feature.
MikeT
Truth is I don't have this issue in Linux, so I'm "blaming" the driver for lowering DTR line when we disconnect (I believe this is what causes it).
So ideally I'd want DTR line to stay up when we close the device, but I think this is driver related. And we have not source code for te official FTDI driver.
I remember seeing serial comm aplications (minicom I believe) that allow DTR line to be kept up, so you can switch to another application without it disturbing the modem. I am not sure how to do it though.
Álvaro
Whether you have this problem in Linux depends on your computer. It resets on one of mine, not on the other.
I have a kludge to get around the problem. I use bash scripting to get stuff out of my arduino once a minute using crontab. It resets on my present computer without this kludge.
Somewhat complicated :It starts with this which is linked from the playground.
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
As it is posted it resets my board with my present computer, but I have emailed the author who supplied me with instructions to modify the source code so that it leaves DTR alone when it exits.
This is the modified source code :
http://pluggy.is-a-geek.com/arduino/arduino-serial.c
It resets the first time it is run but afterwards it doesn't. It needs to be compiled with gcc - instructions in the source code. It can be used as is to communicate with the arduino, but heres the trick, it stops plain old bash scripting resetting the board if it is just run once. I have it set in /etc/rc.local and from then on my bash scripting works every time with this code :
#!/bin/bash
stty -F /dev/ttyUSB0 cs8 115200 ignbrk -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke noflsh -ixon -crtscts -clocal # sets up serial
date > /root/arduinonew # saves date to file
cat /dev/ttyUSB0|head -n 8|tail -n 4 >> /root/arduinonew # appends arduino output to file
As it is, it reads 8 lines of output from the arduino and saves the last 4 lines to a file /root/arduinonew along with the date and time. I then parse this file to get all I want out. Reading more than it needs, stops any problems with it joining the communication half way through. The arduino sends the stuff out over and over every couple of seconds. The script runs once a minute.
toptions.c_cflag &= ~HUPCL; // disable hang up on close (toggling DTR) This is the modified bit
Ok. You're clearing HUPCL. makes sense.
However RXTXcomm (java), which is also used by Arduino IDE, does not. Actually here's a comment on the code:
/* FIXME: HUPCL: generate modem disconnect when all has closed or
exited */
So, I can fix this easily in my C++ application, but I cannot fix this in my Java application. Stuck.
I'll speak with RXTX guys about this.
PS: One thing that can be done is clear this bit early before starting any application. Should work, I'll have selfonlypath test it as soon as possible.
One thing that can be done is clear this bit early before starting any application. Should work, I'll have selfonlypath test it as soon as possible.
stty -f /dev/tty.usbserial.* (Replace * with correct name)
stty -f /dev/tty.usbserial.* -hupcl
Unfortunately , it does not work on my iMac where arduino still reset upon lauching or quitting a java application connected via USB
Clarification:
only the 2nd command actually clears HUPCL. The 1st one was to just take a look at flags.
Yesterday I had same problem in linux, clearing the HUPCL flag by hand on my serial/tty configuration worked like a charm.
Álvaro