Is it necessary for serial monitor and serial plotter to reset my Arduino?

Projects Programming
1

I've noticed whenever I have a program that sends output to the serial monitor, that the program always resets (starts from the beginning) every time that I open the serial monitor.

Up until now this hasn't been a problem, but today I wrote a very simple monitor program for my uno that could accept some simple commands (from serial monitor) and respond by doing some correspondingly simple things. Just stuff like displaying the time, displaying the temperature, examining IO registers etc.

One of the commands that I wanted to add was to make it plot temperature. Very simple, just prompt the user for a timebase and then start Serial.printing the temperature at those regular intervals after this plot mode was enabled.

The idea was for me to switch from serial monitor to serial plotter after that command was given, and then just let it log and graph temperature. The problem of course is that closing the serial monitor and starting the serial plotter always resets my program. So it resets to the default state of NOT plotting temperature and the point is moot.

So now I'm wondering if it's necessary for serial monitor (and plotter) to always reset the Arduino when activated (as in something about the hardware that makes it have to be this way), or is it just something that seemed like a good idea at the time (when the IDE was written)?

2

You can make it not reset by using a different terminal program than Serial Monitor, which won't send the reset pulse. The other option is to disable the auto reset. There are some instructions here:
http://playground.arduino.cc/Main/DisablingAutoResetOnSerialConnection

If you use an ATmega32U4 based board like Leonardo, Pro Micro, etc. then it doesn't reset. This can actually cause problems because you will miss any serial prints made between the start of the program and the opening of the Serial Monitor. That's why you'll see many programs have the line:

while (!Serial) {}

so that they'll hang until the Serial Monitor is opened.

3

pert:
You can make it not reset by using a different terminal program than Serial Monitor, which won't send the reset pulse.

Ok thanks. That's really what I was wondering, is the reset an essential part of establishing the serial communication or was it just added for convenience. So the reset pulse is something that requires a specific control sequence to be sent (or something like that). Is that correct? So in this case it should be possible to make my own (or get third party) serial monitor that doesn't do this.

The other option is to disable the auto reset. There are some instructions here:
Arduino Playground - HomePage

Ok that's really useful to now. Thanks pert. :slight_smile:

So I think I'll try the capacitor from reset to ground trick, as it seems fairly obvious from the schematic how that will work (capacitive voltage divider on the "serial" reset pulse).

One question though. Wouldn't (hardware) disabling serial reset also disable it from getting back to the boot loader when I want to upload a new sketch?

4

BTW. Forgot to mention other option I was considering.

As a workaround I was toying with the idea writing some program state information to the EEPROM. Then I could just let it reset itself when changing between serial monitor and serial plotter, but pick up the correct initial program state to start it in anyway.

5

pert:
You can make it not reset by using a different terminal program than Serial Monitor, which won't send the reset pulse.

This is incorrect. autoreset is being trigger by DTR.
The DTR signal is controlled by the OS not the application.
When the application opens the serial port, the OS drops DTR and holds it low for as long as the serial port is open.. This happens before the application can do anything to stop it.
Applications can contrl RTS and some, but not all, operating systems do allow applications to control DTR, once the port is open.
However, the application has to open the serial port to be able to manipulate any of the modem control signals, so by the time the open() function, which is used to get control the serial port, returns, it is too late. DTR has already been set to be low, which triggers the auto reset in the Arduino h/w

When auto reset uses RTS instead, then the auto reset does not automatically happen when the serial port open is done.
In fact the original FTDI USB to serial cable used RTS and not DTR. It was nice in that when the original FTDI serial port cable was used, auto reset would not happen when the serial port was opened.

What never made any sense to me was that when the Arduino design abandoned the FTDI chip in favor of 16U2 they should have changed the code to use RTS instead of using DTR. That would have allowed the open to work without reseting the board.
avrdude has code to explicitly toggle RTS when the "arduino" protocol is used so auto reset would still work for uploads for cables that used RTS instead of DTR.
The older IDE opened the serial port, toggled RTS, and closed the serial port before it ran avrdude, so that even before the "arduino" protocol existed, you could use RTS instead of DTR.
Using RTS instead of DTR the best of all worlds.

The whole reason DTR was used rather than RTS was they went for a h/w solution to a s/w problem.
When auto reset was originally added it was done as a h/w only modification to the board.
Because the OS drops DTR to low when the serial port opens, when using DTR for auto-reset nothing has to be done to support it in any of the s/w applications - like avrdude.
However, the DTR remains active - low - all the time the serial port is open.
This is the reason a cap was put in series with the auto reset signal. This changes the DTR level based signal to a pulse so that the AVR can start running again.
When using RTS instead, the application can do a real pulse and there is no need for a cap.

But like I said, the side effect of using DTR for auto reset is you will get it whether you want it or not, whenever the serial port is opened.
Some version of Windows used to have some advanced settings that allowed controlling the DTR behavior at open time. While this violates the standard, it can be useful for certain situations where there are h/w issues that need a work around - like in this case.

--- bill

6

@pert, do you have an example of such a program?

I've tried realterm and putty and both generate a reset (on a Sparkfun RedBoard which uses a FT231SX chip). I have always assumed that it's the driver that causes this behaviour when the serial port is opened.

@stuart0, I think that the eeprom way is the better way.

//Edit
OK, bperrybap's reply confirms that a different terminal program will not work and that I don't have to look for a different terminal program :wink:

7

bperrybap:
This is incorrect.

Sorry about that. Thanks for correcting my misinformation. I was mislead by arduino ide - Why does starting the serial monitor restart the sketch? - Arduino Stack Exchange

The Arduino uses the RTS (Request To Send) (and I think DTR (Data Terminal Ready)) signals to auto-reset. If you get a serial terminal that allows you to change the flow control settings you can change this functionality.

The Arduino terminal doesn't give you a lot of options and that's the default. Others will allow you to configure a lot more. Setting the flow control to none will allow you to connect/disconnect from the serial without resetting your board. it's quite useful for debugging when you want to be able to just plug in the connector and see the output without having to start the sketch over.

I'm surprised that an incorrect answer on Stack Exchange got 24 upvotes and no correction. I rarely see an answer with so many upvotes on that site.

stuart0:
Wouldn't (hardware) disabling serial reset also disable it from getting back to the boot loader when I want to upload a new sketch?

Correct, the reset is needed to run the bootloader. If you disable the auto reset then you would need to manually reset the Arduino at the right moment so that the bootloader will be running when the IDE tries to upload to it.

8

I think that some of the issue & confusion is that I have seen many serial drivers f'up the handling of DTR and RTS over the past 3 decades.
DTR is not supposed to be used for h/w flow control.
It is supposed to indicate that something is present. So while it might stop serial data from flowing it isn't intended for that and typically does more than simply indicate ready to receive data.

But both Windows and Linux drivers have f'd this up in various releases in some drivers at various points in time.
Sometimes the drivers gets them backwards. Sometimes it just does them wrong.
I haven't messed with Windows in about 10 years but I saw on various versions of Windows (Vista and older) that there were some advanced configuration options that allowed configuration of DTR and RTS signals. They varied across releases but in some cases messing with a h/w flow control configuration modified DTR behavior (which is wrong) but might work in this case.

So it will depend on the OS and the driver you are using as to if you can modify the OS DTR behavior during open() and close().

--- bill

9

Great replies, thanks to everyone. :slight_smile:

So let me summarize to see if I've got this right.

  • The Arduino is reset by the DTR signal (as emulated by the USB to serial com converter chip), which is in turn initiated by the host computer when a serial link is established.

  • Specifically a brief reset pulse is generated each time the DTR goes from inactive to active.

  • This kind of acts like a non maskable interrupt to vector to the bootloader (I know reset does more hardware initialization than an actual interrupt, but it's kind of like an NMI in this application). A very clever trick to make sure that a user program can't hang and go deaf to the serial input (even if interrupts are disabled).

10

stuart0:

  • The Arduino is reset by the DTR signal (as emulated by the USB to serial com converter chip), which is in turn initiated by the host computer when a serial link is established.

  • Specifically a brief reset pulse is generated each time the DTR goes from inactive to active.

  • This kind of acts like a non maskable interrupt to vector to the bootloader (I know reset does more hardware initialization than an actual interrupt, but it's kind of like an NMI in this application). A very clever trick to make sure that a user program can't hang and go deaf to the serial input (even if interrupts are disabled).

Just for a bit of additional clarity.
The DTR signal is not a pulsed signal. It is a level signal. If the OS is in control of the signal, then it drops DTR low and DTR remains low for as long as serial port is open. That is why there is a capacitor in series between the the auto reset signal and the actual AVR reset signal on the Arduino board. When DTR is pulled low, the low drains the capacitor and the actual reset signal on the other side of the capacitor goes low. The pullup resistor on the AVR reset line re-charges the capacitor and in a few milliconds the reset line returns back to a high level.
It is an ugly way of generating a pulse for this application, as it creates a single pulse with a very long slew rate. (the signal rises back to high relatively slowly so it isn't a digital signal) This is typically not a good thing to do on a reset signal. Also the momentary rapid discharge of the capacitor can create noise spikes on the signal which is also not good. In fact some of the early boards could brick the AVR to the point of needed High voltage re-programming due to this circuit.

The IDE and avrdude will also toggle RTS when it wants to put the board into the bootloader in case a dongle/cable/board is using RTS instead of DTR.