Improving auto-reset...

[William "Chops" Westfield]

Previously, there has been discussion about providing full SPI connectivity between the 16u2 and the main ATmega. Which is … complicated.

However, something that would be relatively easy to do is to get rid of the current capacitively coupled auto-reset in favor of a tri-stated direct connection from the 16u2 to the RESET pin of the atmega. Initially, it would be triggered by the same "dtr" software CDC logic that currently uses, except it would generate a momentary low pulse (and return to tri-state) instead of the low pulse and return to high. The capacitor, and the diode, would be eliminated. And THAT would allow a debugWire "pod" to be connected to an arduino via the ISP connector (currently, the cap interferes with debugwire operation.)

Eventually, if Atmel opens up debugWire a bit, then the 16u2 could implement some debugging capability.

BillW/WestfW

[Matthijs Kooijman]

Hi Bill,

> However, something that would be relatively easy to do is to get rid
> of the current capacitively coupled auto-reset in favor of a
> tri-stated direct connection from the 16u2 to the RESET pin of the
> atmega. Initially, it would be triggered by the same "dtr" software
> CDC logic that currently uses, except it would generate a momentary
> low pulse (and return to tri-state) instead of the low pulse and
> return to high. The capacitor, and the diode, would be eliminated.
> And THAT would allow a debugWire "pod" to be connected to an arduino
> via the ISP connector (currently, the cap interferes with debugwire
> operation.)

That actually makes a lot of sense - why muck around with a hardware
solution when you can just fix this in the firmware? Saves a few
components and makes stuff simpler.

Gr.

Matthijs

[Brian Cook]

> Initially, it would be triggered by the same "dtr" software CDC logic that currently uses, except it would generate a momentary low pulse (and return to tri-state) instead of the low pulse and return to high.

Would it still be possible to disable auto-reset with an external capacitor?

- Brian

[Nevada Smith]

Am Donnerstag, 6. November 2014 10:37:06 UTC+1 schrieb Bill Westfield:

Previously, there has been discussion about providing full SPI connectivity between the 16u2 and the main ATmega.  Which is … complicated.

Thats totally wrong. Its already there with a selectable autoreset off pin and ISP and also HID. Just noone cared about this like v2 (for now)
https://github.com/NicoHood/Hoodloader

[henry rodgers]

Hi, my name is Henry

Yes, you would be able to do that.

[Bill Perry]

Rather than have to play some goofy games with the DTR processing,
I believe that  it would be much easier to simply change the 16u2 code to use RTS instead.
I have brought this up before but didn't seem to get any interest.
The code to toggle RTS for autoreset is already in avrdude in the "arduino" protocol that the IDE uses.
So all that is needed is to change the 16u2 code to look at the CDC RTS status bit in the message vs
the DTR bit.
So down in Arduino-usbserial.c
this line:

bool CurrentDTRState = (CDCInterfaceInfo->State.ControlLineStates.HostToDevice & CDC_CONTROL_LINE_OUT_DTR);

would need to be changed to look for the CDC RTS status bit instead.

Id recommend changing the bool variable name as well to reflect RTS otherwise it would be confusing.

This would be a much smaller and easier change and would not increase the size of the f/w image.

This change also should work on boards with and without the autoreset h/w circuit
so you don't end up in a situation where the code has to be perfectly matched up correctly the main PCB h/w.
Which also means it can be tested and used on existing boards.

Using RTS instead of DTR also gives you the option of connecting the arduino without reseting the board.
(assuming the IDE doesn't do something goofy and toggle RTS when it starts the serial monitor)
This can be valuable feature as you can talk to the avr without having to reset it.
I use this capability quite often as I use real FTDI cables (which use RTS)
or re-wire the USB to serial adapter to use RTS instead of DTR.

--- bill

[Bill Perry]

Another alternative that requires quite a bit more s/w and additional h/w changes to the main board
would be to move the ISP programming into the 16u2.
i.e. the 16u2 becomes the target of the stk500 protocol rather than the on board AVR.
This would seem a much better use for the 16u2 rather than just as a simple USB to serial chip.

It requires a dual mode of operation that flips between being a usb to serial interface and a AVR ISP programmer.
And it would also require that the 16u2 be wired up to the AVR ISP pins.

I think the mode flipping could be worked out to use the existing transitions on some combination of
DTR and RTS signals to ensure that no changes are needed to the IDE or to avrdude.

On the positive side, it eliminates the bootloader from the AVR since it would always be being
programmed by ISP, either by the 16u2 or through an external programmer using the ISP pins.
This would allows users to simply stuff in blank parts into their arduino boards and uploading "just works".

--- bill

[Nevada Smith]

This is already possible with HoodLoader2 and HIDProject Arduino as ISP fix:

https://github.com/NicoHood/HoodLoader2
https://github.com/NicoHood/HID
https://github.com/NicoHood/HID/wiki/Arduino-as-ISP

Its nothing new. Its just that noone listens carefully on the dev list. Also USB HID is fully functional with HoodLoader2 and HID project.
This way it also makes more sense, since you can change the functionality of your 16u2 at any time. You still have to wire the ISP connections though.

To understand your Idea bill I simply write what I understood:
With the (already configured) Arduino protocol avrdude also triggers RTS on reprogramming, so RTS would also work.
But the difference is that the Serial monitor only triggers DTR so we do not have an autoreset here by default?

I could add this to my bootloader, but I am not sure if it makes sense. People are used to the reset (like me). It might be useful sometimes, but then you could add the USB-Serial Demo of the HID Project and use this fix there. And people wont get confused. Also It is nearly impossible to change those old bootloaders/firmwares on newer boards. They just wont do that. But they could add a checkbox in the serial monitor though, yes. Or they could add HL2 by default (since it may be used for advanced stuff but doesnt have to be. But they wont do that too since they dont even merge the better USB Core).

Bill, I will test that RTS and possible add it to my USB-Serial example. There you have your no autoreset firmware. You could also add a setting if the pin next to the gnd is bridged or not to en/disable autoreset by hardware again (without reuploading the sketch) for example. Then you have both versions, selectable with a small gnd bridge.

Please note that HL2.0.3 currently has a uploading verification bug on some usb hubs which is now fixed in the new 2.0.4 dev branch. At the data of writing this, the new version is not compiled yet.

Let me know what you think.
~Nico

[Bill Perry]

On 2015-02-21 14:09, Nevada Smith wrote:
>
> To understand your Idea bill I simply write what I understood:
> With the (already configured) Arduino protocol avrdude also triggers RTS on reprogramming, so RTS would also work.
> But the difference is that the Serial monitor only triggers DTR so we do not have an autoreset here by default?

Yes. The OS controls the state of DTR and so DTR drops *before* the application runs.
Since the 16u2 code is looking at DTR the output signal from the 16u2 going to AVR reset follows
the state of the CDC DTR level.
The signal level drop is converted to a pulse by the autoreset hardware (the capacitor).

Since RTS is left alone, using RTS instead allows an application to open the serial port and not trigger a reset
unless it really wants it by explicitly dropping/toggling the RTS signal.
So if the 16u2 code simply looked at the RTS signal level instead, the output signal that is driving
the AVR reset would toggle to reset the AVR only when an application explicitly asked for it to be toggled
vs every single time the serial port is opened regardless of whether the reset is actually desired.

>
> I could add this to my bootloader, but I am not sure if it makes sense. People are used to the reset (like me). It might be useful sometimes, but then you could add the USB-Serial Demo of the HID

I think it is a total pain in the ass that a reset occurs every single time the serial port is opened
which is why I switched to using RTS.
When RTS is used you could get the best of all worlds.
Autoreset happens during an upload. No reset happens when the serial port is opened.
And it would be possible to add a button in the Arduino IDE GUI to reset the board should you want
to do that.
With DTR you can't offer the option to talk to a live board without resetting it.

In the case of wanting to run debug wire, the code in the 16u2 code could be changed to assert the AVR reset
when RTS is asserted low but then change the 16u2 "reset" pin back to an input when the RTS is high.

--- bill

[Nevada Smith]

I just tested it and changed the sketch to RTS. I get not in sync errors. Seems that just nothing is happening on the rts state. Did you set any special setting in the boards.txt?

[Nevada Smith]

I got your replys via mail but now they've disappeared.

However you should have a look at the links I posted. Yes it is a sketch, because with Hoodloader2 you can use the 16u2 nearly the same as Arduino leonardo as well. Just have a closer look.

Any why do you discuss about a board you dont even own?

[Tom Igoe]

Not sure which one of us you’re talking to here?

Tom

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Nevada Smith]

To bill. PCINT was in another thread ;)