retrolefty:
Avrdude and IDE now already create the needed pulse by driving CTS low then high again.
I thought for legacy reasons that AVRDUDE and/or IDE pulsed both DTR and RTS comm signal lines so that either could be used to trigger the auto-reset circuit, but not CTS?
Lefty
oops. 
It is RTS not CTS. Total goof on my part. (CTS is on receiving end)
BUT.... DTR is not pulsed. It merely changes state (drops) on the first open and then changes
back (back to high) on the last close of the serial port. The transition is handled by the OS
not the application.
But in the larger picture, I don't understand why DTR is still being used for auto-reset
now that there is RTS toggle support for auto-reset as
turning a falling edge into a pulse is what complicates things so much.
Plus s/w like the IDE and AVRdude have no control over this DTR transition, it happens
before they have control over the serial port because it happens in the OS driver when
when the serial port is opened/closed.
If things were just switched over to using RTS instead of DTR things get much simpler
AND you don't get an auto-reset when you simply open the port.
You have to explicitly toggle RTS after the serial port is opened to get the auto-rest.
I use this on my boards and it is very nice. I get the auto-reset when the IDE
wants to upload a sketch but I don't get it when the serial port is opened
for communication.
IMO, RTS is the way to go. It allows control of the auto-reset.
I understand why DTR was initially used as it was a h/w hack that worked
before the IDE/Avrdude software was modified to control RTS. But now that the s/w
toggles RTS, why use DTR anymore?
--- bill