Go Down

Topic: Autoreset Circuit on Uno (Read 2 times) previous topic - next topic

doov

Great.  Thanks a lot for the info guys.  Much appreciated.

bperrybap



Hi There,

I'm mildly confused as to how the autoreset circuit works on the arduino uno.  I assume DTR goes low when the serial transmission from the PC begins.  That discharges the 100 nF cap which pulls the reset line low.  With a time constant determined by the 10k pullup to 5V and the 100 nF cap the cap will recharge and the reset line will be high.  I assume that the bootloader takes over right after the reset line goes high at which point it slurps up whatever it gets over the serial line as program code and then resets the processors instruction pointer.  Is that correct?  Is there any indication when programming is complete?  How long is DTR pulled low for (I don't have a scope :().  Thanks!

D


Yes that is basically how it works. The IDE (via AVRDUDE) just pulses the DTR signal on then off to cause the AVR to reset

Not exactly.
The DTR signal is not pulsed. It is a level.
DTR is set by the OS when the serial port is opened *before* the application gets control of the serial port.
By default DTR is high.The OS sets DTR low (not the application) when the first open occurs
and then back to high when the last close occurs.
DTR is used as a single to know if there is anything attached to the serial interface.
High - nothing is there. Low something is there listening.
The capacitor is a h/w kludge that turns the falling edge of the DTR signal into a pulse
to reset the AVR.

Some operating system have the ability to change this DTR behavior but normally
that is the way DTR works.

RTS on the other hand is normally used for hardware flow control but the application
can control its level after the the application has opened the serial port.
The IDE or avrdude can pulse RTS - which they do to perform an auto reset,
because some hardware uses RTS vs DTR.

Some Arduino boards use DTR some use RTS.

Summary:
OS changes DTR from high to low when application opens port *before* application
has control of port. Capacitor is used to change falling edge to pulse.
RTS is used for h/w flow control but can be controlled by application after port is opened.

The IDE and avrdude upload can work with boards that use DTR or RTS for autoreset.

I prefer RTS over DTR for autoreset because with RTS you only get an autoreset when
code is being uploaded to the board.
But with DTR you get an autoreset every time the port is opened by an
application which means you can't open the serial port to talk to the arduino without reseting it.


--- bill

pico


I prefer RTS over DTR for autoreset because with RTS you only get an autoreset when
code is being uploaded to the board.
But with DTR you get an autoreset every time the port is opened by an
application which means you can't open the serial port to talk to the arduino without reseting it.


An interesting twist on the brain-deadedness of using DTR rather than RTS is a phenonemon I discovered only recently: On some Windows systems, connecting or disconnecting another device on _a different USB port_ can cause the DTR reset to occur on a USB connected Arduino!  Coding Badly suggested this may be due to a background "helper" application that probes the USB ports whenever a system change is reported by the OS, although on my system in question I haven't been able to identify the culprit.

Sheesh. Why did the change from using RTS to DTR occur anyway? Was there actually a rationale, or was it just one of the random "design" decisions passed on without explanation or prior discussion from On High?
WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

oric_dan

#8
Nov 19, 2012, 05:26 am Last Edit: Nov 19, 2012, 05:29 am by oric_dan(333) Reason: 1
RTS and DTR are a little more bizarre than I thought. I have both an FTDI cable [uses RTS] and
an FTDI Friend [uses DTR]. Don't have the scope handy, but using the DMM, where S-M means Serial
Monitor,

FTDI Cable: RTS=0V [steady] when S-M=off, RTS=5V [steady], when S-M=on.

FTDI Friend: DTR=5V [steady] when S-M=off, DTR=0V [steady], when S-M=on.

So, don't leave out the 100nF cap whatever you do.

Quote
Quote from: doov on Today at 05:29:49 PM
I'd like to use that to enable a bluetooth modem which sits on the uart.  If it's enabled during programming then it screws with avrdude (presumably because it's driving the tx line at the same time that avrdude is trying to drive the same line.).  Thanks!

You should probably wire it so it can be switched on/off via the Arduino and power it on in your setup() function.


Yeah, you cannot really have BT or XBee connected to the Arduino RX line at the same time as the standard
USB port, because the 2 signals conflict, so some XBee shields at least have a switch.

dc42


I'd like to use that to enable a bluetooth modem which sits on the uart.  If it's enabled during programming then it screws with avrdude (presumably because it's driving the tx line at the same time that avrdude is trying to drive the same line.).  Thanks!


If you use an Arduino Leonardo instead of a Uno (if that is what you are using), then uploading a program to it does not use the serial port, and the problem will not occur.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Go Up