the biggest problem is backwards compatibility - the IDE still needs to be able to communicate with EVERY existing arduino board out there, containing various bootloaders, firmware, and hardware configurations.
That is why any prosed fix to UNO should be 100% backward compatible with the currently shipping
0022 and 1.0RC host software.
The proposal I suggested, required no changes to any host software.
It is changes that are isolated to the UNO board hardwre and 8U2 software.
It makes the UNO work like boards that use the official FTDI data cable by changing its auto-reset
to use RTS vs DTR.
(official FTDI data cables, don't bring the DTR signal out on the connector, they use RTS instead)
And while the proposal I made may not be the final solution,
I still believe that there is a solution for UNO that would not require re-spinning the board.
I think the key is what to insert in place of the c5 capacitor that is currently in series with the
A diode? A resistor? Some sort of resistor probably makes the most sense since
it will prevent shorts to the RTS line from people either grounding or setting RESET to VCC.
the whole auto-reset is an admirable intention that has, over time, and with various 'tweaks' become an absolute nightmare. the problem has been compounded by attempts to stick to a single codebase across several OS platforms, each OS with it's own level of access to and support for the usb and/or serial hardware.
personally, i'd do away with the auto-reset completely. instead i'd use a far more robust manual reset system:
1. IDE pops up a window saying "PRESS and HOLD reset button..." with a counter going from 5 seconds down to 0
2. IDE then closes that window and pops up another window saying "RELEASE reset button NOW".
during the above two steps the IDE would send repeatedly a query command to the bootloader, monitoring for a bootloader response. when the correct response came back the IDE would know that a communications channel with the bootloader had been established. if no response is seen within 5 seconds of the second window being popped up, a 3rd window could be popped up saying "Unable to Communicate". all very simple.
if someone is bright enough to program an arduino, they should be bright enough to press and release a single button as instructed!
It sounds like you are assuming a particular method of uploading (a serial based bootloader).
and that the IDE has full control over the bootloader protocol.
If so, both of those assumptions are either incorrect or too limiting.
The IDE allows using many methods of uploading including ISP and proprietary methods like Teensy.
These alternate methods have no issues with auto-reset.
Even in the case of using a serial based bootloader, the IDE does not control the serial data
transfer. That is all handled by AVRDUDE.
So now you are talking about a much bigger change that involves not only coming up with a new
handshake and upload protocol but also potentially either moving all the upload functionality into the IDE
or adding additional functionality to AVRDUDE.
Also, take a close look where the reset button is located particularly on the official
arduino boards. How are you going to press that button when a shield in in place?
I believe that downloading from the IDE should "just work" rather than require people to hold
their mouth just right and have to push buttons on the Arduino board at just the right time
to initiate the download.
So, at this point, I believe it will be much easier to simply correct auto-reset issues that exist
once and for all in the Arduino hardware and software rather than dream up entirely new download mechanisms.
While auto-reset may have issues, IMHO, most are self inflicted by a lack of understanding of how DTR and RTS really work
and a lack of coordinating the host software to properly use the control lines.
I also believe that the majority of people are not experiencing auto-reset issues.
Yes there are many auto-reset issues with trying to use the Arduino as and ISP
but most users are not doing that and most of those issues can be traced back
not providing adequate auto-reset control on the board.
i.e. using DTR and not providing something as simple as a jumper to disable auto-reset.
There seems to be a bias to keep trying to solve the problem by throwing hardware at a problem
that needs to be solved by taking a different approach which probably involves software.
The key to having a reliable auto-reset is to have full control over the Arduino's reset line
by the host software.
While DTR can be used to control auto-reset, it is ugly and problematic because DTR is a level based signal and
the host application often does not have full control over the DTR line.
i.e. the OS usually controls and alters the DTR line state before the host application could ever take control.
IMHO, using RTS is the long term answer as it can be better controlled than DTR.
Since it can be toggled by the host software when needed/as needed,
there is no need to have hardware on the Arduino board attempt to make a pulse from a falling edge
level based signal.
The problem then reduces to how to keep the auto-reset signal from colliding with other
signal sources that drive the RESET line locally on the board.
All the Aduino IDE OS's currently supported allow controlling RTS from the host software.
The existing IDE and AVRDUDE both now have the ability to control the RTS line
and do toggle RTS for those Arduino board implementations that use RTS instead of DTR.
The current IDE toggles RTS which allows boards that use DTR or RTS to function even
when using older AVRDUDE that does not have the arduino programmer type that knows
how to toggle RTS.
So backward and forward compatibility is pretty well covered right now.
To me the ideal solution for auto-reset is to use RTS instead of DTR since applications
have much better control over RTS.
In addition, to accommodate those with very special needs for disabling autoreset, provide a jumper.
For a board like an official Arduino board like an UNO, if it were up to me, I'd put
a set of holes for a 2 pin header that has a trace between them. That way if a person
really wants to disable auto-reset for good, they can cut the trace.
If they want to use a jumper, they cut the trace and solder in a 2 pin header.
That way the less technical folks get a nice easy to use auto-reset from the IDE with no jumpers
and those with special needs can perform a simple "hack" to get what they need.
With a solution like that, you continue to get auto-reset for normal sketch downloading
and those that want to use the arduino as an isp can simply cut a trace, install a header/jumper
and disable auto-reset whenever they want/need to.
Also, when using RTS instead of DTR, you won't get the Arduino board reseting
when you open the serial port. You only get a reset during a download.