[avrdude-dev] [patch #7559] 'arduino' programmer type DTR transition fix

[Robert Spitzenpfeil]

Follow-up Comment #3, patch #7559 (project avrdude):

In the piece of code you've referred to it seems to be 'inverse logic'. That
is if it gets a '1' it clears some bits. Yes.

As far as what happens on the physical DTR signal of my serial port: no. At
least on FTDI chip based adapters.

I've made a few traces with my logic analyzer.

1) unpatched avrdude 5.10
2) my patch
3) your patch
4) both patches

It shows that the unaltered 'ser_posix.c' code actually drives the physical
signal LOW, when the ser_set_dtr_rts() function gets a '0' as argument.

I think that the code should represent what happens in the real world and not
in some register.

Further description of the attached image:

For each test run the arduino board was disconnected and reconnected to USB.
This makes sure the serial port is in the same state.

1) 

Avrdude is run for the first time and everything works. The AVR chips actually
gets 2 reset pulses, which doesn't seem to matter.

Then avrdude is run 3 times in a row. Each run times out, as it can't get an
answer from the bootloader. As you can see in the trace, the reset pulse is
created very late. This is caused by the fact that the DTR line is not
switched in the right way. Reset pulses can only occur at a HIGH-LOW
transition.

The next time avrdude is run and interrupted with CTRL+C. This leaves the DTR
line high.

The next and last run of avrdude works again, just like the very first time.

2)

With my proposed patch it works and the DTR line is always left in a usable
state for next runs of avrdude. Actually it is independent of the initial
state of DTR.


3)

With your patch (inversed DTR register writes), the upload works every time as
well, BUT ser_set_dtr_rts() now does the inverse thing of what it is told to
do. If it gets a '0' it writes a '1' to DTR and vice versa. I don't like that,
as this is confusing. Maybe there should be a comment in 'ser_posix.c' why the
register writes are inversed to produce the desired output on the physical
signal line.

4)

With both patches applied it still works, but it is basically as confusing as
3).

(file #23662)
    _______________________________________________________

Additional Item Attachment:

File name: g3215.png                      Size:157 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?7559>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/