Follow-up Comment #6, patch #7559 (project avrdude):
Actually, if you look at my patch and then look at ser_win32.c, my patch makes
the logic work the same on both platforms. Windows has always been
bulletproof (and I can't tell you how much it bothers me that it wasn't on
Linux). Once I made that change, it became just as reliable under Linux for
me (Uno).
Now that being said, what I haven't mentioned is that is not the problem I was
trying to fix. I have a board with a FT232 and basically nothing is working
under Linux (works just fine in Windows). My patch at least gets the board
reset after attempted programming, which was a step forward.
With your patches, the close doesn't reset the device and start the code. I
think unless you intend to remove serial_set_dtr_rts function, the logic has
to be reversed as I did otherwise places like serial_close will still be
reversed.
You're right though, the code is just confusing. For example is_on is
unfortunately named because it implies current state rather than desired
state.
Btw, multiple times now you have said that your device resets on a DTR
transition to LOW: "Reset pulses can only occur at a HIGH-LOW transition".
Unless I misunderstand you (and I do not have a logic analyzer), my Uno goes
into reset when DTR is pulled low, and then boots once DTR is released
(verifed by LED). So long as I have DTR/reset pulled low, it does not boot.
Is that what you see with your device?
So here is the end result with your patch:
Uno - works fine
Zigduino/FT232 - neither programs (this was also problem with my patch) or
boots when closing the device (appears that reset is held LOW)
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/patch/?7559>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
_______________________________________________
avrdude-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
