Wow, you're right about the cap. According to the Arduino Mini 05 schematic, it doesn't have the cap built in. I thought ALL Arduinos had the cap. It's what makes them an Arduino. Make sure the cap is between the programmer and the arduino reset pin, some people mistakenly hook it up like a pullup or pulldown. I don't think you need the pullup resistor, there's already one on the board. Here's a link to a guide for using the mini - http://arduino.cc/en/Guide/ArduinoMini .
The board is kind of a pain to hookup. I know it doesn't deal with your original question, but for future ideas I would suggest moving to a Pro Mini. They can be had pretty cheap, they have the cap and pullup, they can be easily hooked directly with a FTDI connector, and I find them being used much more than the Mini 05 so there should be more help and support. I just don't hear people using or asking about the plain Mini as much. But that could be just me.
I can't find the info on how I should add the capacitor to allow the auto reset feature to work... I did solder wires to the FTDI, and I soldered a connector to the arduino mini to make it easy to connect the serial adapter, so where do I add the capacitor, and what value should it be? From what I've read it should be 100nF?
Avrdude was updated a few years ago to control RTS for autoreset.
If your FTDI board has RTS you can use it instead of DTR and avoid having to mess with
the capacitor.
This is because DTR is not pulsed but rather driven low by the OS when the port is opened.
The cap is used to turn the falling edge of the level signal into a pulse,
whereas the RTS signal is controlled by avrdude and is actually pulsed low and then goes back high.
I use RTS rather than DTR on all my serial adapters.
Using RTS vs DTR also means that you can open the serial port
with a serial monitor and not reset the Arduino board.
When using DTR, the Arduino is reset every time the serial port is opened.
bperrybap:
Avrdude was updated a few years ago to control RTS for autoreset.
If your FTDI board has RTS you can use it instead of DTR and avoid having to mess with
the capacitor.
This is because DTR is not pulsed but rather driven low by the OS when the port is opened.
The cap is used to turn the falling edge of the level signal into a pulse,
whereas the RTS signal is controlled by avrdude and is actually pulsed low and then goes back high.
I use RTS rather than DTR on all my serial adapters.
Using RTS vs DTR also means that you can open the serial port
with a serial monitor and not reset the Arduino board.
When using DTR, the Arduino is reset every time the serial port is opened.
--- bill
And CTS? only have a CTS and DTR...
I just can't get a clear picture of what DTR and CTS is... some say RTS is DTR, some say RTS is CTS, some just say RTS without mentioning any of the others....
Note: the descriptions below are from the perspective from the serial chip.
i.e. if an FTDI chip is used it will be from the perspective of that chip.
FTDI chips support CTS, RTS, and DTR. Whether they are all brought out to
a connector depends on the individual board. Also the FTDI chip is configurable
and some of these pins are re-configurable depending on the microcode loaded
into the part.
Anybody that says RTS the same as either CTS or DTR doesn't know what they are talking about.
They are 3 separate distinct signals.
CTS (clear to send) is an input. If h/w flow control is enabled, it can be used for h/w flow control.
A high level on this input pin says to stop transmitting. The internal level will usually default to low
on most chips if the pin is not connected to anything
which allows the transmission to occur even if h/w flow control is enabled.
When h/w flow control is not being used,
this input is often connected to ground to ensure that the chip will transmit even if h/w flow
control is enabled.
Whether h/w flow control is enabled is determined by the host driver and its configuration.
DTR (data terminal ready) is an output pin. It is used as an indicate the presence of a device.
This pin is driven low when the first open of the serial port is done and returned back to high when the last
close is done.
For auto reset to work on Arduino you need a signal that momemtarily toggles low and returns back
to high. The DTR signal does not do this. By adding the cap and a resistor you can turn the falling
edge of the DTR signal into a pulse that can be used for resetting the AVR.
The value of the resistor and the capacitor determine the width (timing) of that pulse.
RTS (Request to send) is an output. It is not CTS nor is it DTR. RTS is a separate and distinct signal.
It is the h/w flow control complement to CTS. The chip uses RTS to tell the other end (avr) when
it (the FTDI chip) is ready to receive data.
The UART inside the AVR (at least the m328) does not support h/w flow control
and so that is why h/w flow control is not used with arduino.
i.e. if the FTDI chip sets RTS to tell the AVR to stop transmitting, the AVR
will keep transmitting since it doesn't support h/w flow control.
So here is the summary with respect to an FTDI chip:
DTR is an output pin from the FTDI chip
which set and controlled by the OS and is controlled by the serial port being opened.
It goes low when the port is opened and goes back high when the port is closed.
The application does not have full control of this output pin.
CTS is an input signal to the FTDI chip that tells the chip when it is allowed
to send data if h/w flow control is enabled.
RTS is an output signal from the FTDI chip that tells the other end
when it can transmit data.
Applications like avrdude can get control of the RTS pin.
This is why using RTS is better than DTR for something like an Arduino
auto reset function which needs a pulse.
DTR is not under control of the application and cannot be pulsed, that is why
there is the cap circuitry. It converts the non pulsed signal to a pulse.
RTS can be under control of the application and can be pulsed and in fact
avrdude will pulse RTS when you use the -arduino protocol which the IDE
uses.
A real FTDI cable brings out RTS and not DTR.
The green wire on the 6 pin connector is RTS not DTR.
(see page 11 of the datasheet: 5v FTDI cable)
Arduino added the autoreset cap circuit hack and
switched to using DTR instead of RTS because they didn't want
to modify the avrdude code. By using this "hack" they could use the
existing avrdude and the stk500 protocol.
Eventually a separate "arduino" protocol was added (which the IDE now uses)
which is essentially the same as the stk500 protocol other than it toggles
RTS for auto reset. So now you can use RTS for autoreset which allows
using a standard FTDI serial cable.
Many of the low cost FTDI boards connect the DTR signal where
the real FTDI cable connected the RTS signal. This was useful several
years ago before avrdude was modified to add the "arduino" protocol which
has code to control the RTS signal.
Some of the FTDI boards bring out both RTS and DTR and you can jumper it
or add a wire to select which one you want to use.
RTS will work with or without the autoreset cap circuit, while DTR requires the cap autoreset
circuit.
If the board you have does not allow you to use RTS then you must add the appropriate
autoreset circuit to use DTR for auto reset.
For maximum compatibility, you can add the auto reset circuity (cap and resistor)
and then auto reset will work with either DTR or RTS.
One issue with using the auto reset circuit is that the capacitor does not allow using debug wire.
This means that you can't use debug wire for source level debugging.
This is another reason I prefer to use RTS over DTR. When using RTS you don't need the cap
and it can be removed which allows you to use h/w tools like the AVR dragon for
source level debugging.
To second what bill said, forget about CTS. Secondly, you also have to be careful that the Vcc voltage on the FTDI header doesn't clash with external power you may be applying to the board. I blew a USB port on my notebook that way once. So, if the Vcc pin is hot, then don't connect Vin to the board. [on my own boards, I leave the FTDI header Vcc pin unconnected, and "always" power via Vin, then no confusion].
The valid FTDI cables usually bring out RTS, and little adaptor boards like the FTDI Friend [from adafruit, I believe] bring out DTR. Both will work ok as long as the board has the pullup R on the Arduino Reset pin, and the inline cap to block DC voltages [eg, from DTR staying low]. I use both types of adaptor, and both work fine.
There are also 3rd party adaptors using CP1202/whatever chip that may not have either RTS or DTR signal on the 6th pin of the header, and there are also many 3rd party adaptors where the signals are all jumbled on the 6-pin header w.r.t. to the standard FTDI cable, so you have to be careful that the correct signals go to the correct places on the mini board.
Also, in the past, if using the FTDI cable that brings out RTS, you needed to enable the signal in Windows by going to "Control Panel > System > Device Manager > Ports > eg COM5 [ie, the port being used] > Port Settings > Advanced", and enabling "Set RTS On Close".
oric_dan:
To second what bill said, forget about CTS.
I would connect it to ground to ensure that the chip always transmits
since h/w flow control is not being used.
Also, in the past, if using the FTDI cable that brings out RTS, you needed to enable the signal in Windows by going to "Control Panel > System > Device Manager > Ports > eg COM5 [ie, the port being used] > Port Settings > Advanced", and enabling "Set RTS On Close".
Is that still true? I don't use windows but I would think that option would make RTS work like
DTR and now that avrdude has the "arduino" protocol to directly control and toggle RTS I would
think that this is no longer necessary and that it should work ok without having to mess with this setting.
Just my reasoning as I can't test it as I don't use Windows.
RTS will work with or without the autoreset cap circuit, while DTR requires the cap autoreset circuit.
This MIGHT be true if you never use anything other than AVRDude and the Arduino Serial monitor. Other programs may use RTS in other ways (including "hardware flow control"), which is one of the problems with using a user-program-controller signal, one of the reasons for using DTR for autoreset, and a good reason to keep the cap in the circuit even if you're using RTS. (Fundamentally, according to various specifications, DTR should only change at the beginning of a communications session, while RTS can be manipulated during sessions. OTOH, most such specifications are "loosely interpreted" by modern software.)
westfw:
This MIGHT be true if you never use anything other than AVRDude and the Arduino Serial monitor. Other programs may use RTS in other ways (including "hardware flow control"), which is one of the problems with using a user-program-controller signal, one of the reasons for using DTR for autoreset, and a good reason to keep the cap in the circuit even if you're using RTS. (Fundamentally, according to various specifications, DTR should only change at the beginning of a communications session, while RTS can be manipulated during sessions. OTOH, most such specifications are "loosely interpreted" by modern software.)
Not quite following you here.
From my dealing with various serial drivers in different OSes for just over 30 years,
I've seen support for controlling RTS in most host operating systems.
Some screw it up especially with respect to h/w flow
control but nearly all of them allow you to disable h/w flow control and have direct manual control
of the RTS signal from the application.
DTR on the other hand is quite different. And while various OS's also seem to screw up that signal
as well, most tend to handle it properly at port open/close time.
There are some newer OS's that let you muck with DTR but that seems to much rarer
and should not be counted on - which the arduino DTR auto reset does not.
Here are the benefits of why I choose RTS over DTR for auto reset:
RTS can auto-reset the AVR with or without DTR the auto-reset circuitry.
When using RTS, (without the DTR auto reset circuitry)
you can connect to an arduino using a serial monitor application and not reset the Arduino.
You can't do when using with DTR for auto-reset.
When using RTS, you don't need the auto reset circuit so the cap can be removed
which allows debugwire to be used. This allows source level debugging.
You can't do this when using DTR for auto-reset.
it is pretty cool to source level debug an arduino sketch inside a small 8 pin AVR chip
like the ATtiny85.
So from my experience and perspective, either DTR or RTS
can be used for uploading code with auto reset,
but RTS has some advantages over using DTR which I find very useful.
I don't have RTS so I wnat to know where to add (paralel or just directly in the circuit or whatever) the capacitor on the DTR pin, and which value it should have...
I'm sorry, but I'm starting to get frustrated here :S
Thanks... in the end we didn't use that drawing but another one AND IT FINALLY WORKS!!!!! The Mini 05 does reset nicely, and I can finally program it with the FTDI!
SparkyRih:
Thanks... in the end we didn't use that drawing but another one AND IT FINALLY WORKS!!!!! The Mini 05 does reset nicely, and I can finally program it with the FTDI!
I'm glad it works. Please share the drawing so other people can solve the same problem.
