OK, I'm closing it as "won't do" then.  The discussion can
be found both, here in the patch tracker as well as the
mailinglist archives, so hopefully, someone interested in
the details will be able to find it.

Personally I'd like to see something that is completely invariant to whether a real RS232 port/device is connected or a TTL serial adapter, so that it doesn't matter if signal levels are inverted or not. As I had to find out, there doesn't seem to be an easy way for the computer to know which is which.

It should always work. There should be comments that explain what is done and why.

My previously proposed addition of the 'toggle' function would provide just that, BUT a) I'm not capable of providing the necessary patches to 'ser_win32.c' b) it would also require changes to 'ser_posix.c' as well.

So what to do?

If the bootloader timeout is long enough (really don't know about all optiboot versions for sure), 'arduino.c' could be modified as such:

------

  // explanatory comments should go here...

  serial_set_dtr_rts(&pgm->fd, 0);
  usleep(50*1000);
  serial_set_dtr_rts(&pgm->fd, 1);
  usleep(50*1000);
  serial_set_dtr_rts(&pgm->fd, 0);
  usleep(50*1000);
  serial_set_dtr_rts(&pgm->fd, 1);
  usleep(50*1000);

------

This would provide at least one usable (5V/0V) transition for the reset capacitor to be pulled in the right direction, regardless what 'HIGH' actually means.

I could do some reliability testing on homebrew and a Diecimila board using various bootloaders, but only on linux.

Can someone summarize for me the action to take?

As I don't have an Arduino around, I'd only like to commit
something that makes everybody happy.

There are level shifter ICs... as you know very well. And e.g. the MAX232 doesn't translate more than RX/TX.

But maybe we should forget about RS-232. Nobody with a sane mind uses that anymore (industrial stuff excluded for now).

And whoever thought that using a negative voltage for logic 1 is a good thing should not come anywhere near me.

And another one...

Now what happens if someone should connect an AVR chip to a real RS-232 interface ?

As the levels for DTR seem to be inverse there, the transition for resetting the arduino will be wrong as well. (just like before patch #7100 for 5V systems).

Therefore I suggest to use something similar to comment #4 / file #23663. This will work independently of which way around the voltage levels actually are.

Those are real full-swing (e.g. +-12V) RS-232 voltages.  The voltage levels are inverted for TTL (0 to 5V) serial, so the data signals are 5V for a logic 1 and 0V for a logic 0 (whereas -12V is a logic 1 for the data signals of full-swing serial) and the control signals (apparently) become 0V for logic 1 and 5V for logic 0.

Have you checked the behavior on Windows?  There, I believe that a call to ser_set_dtr_rts(1) brings the lines low and 0 brings the line high.  So patch #7100 brought the two OS's (Windows and Posix) into alignment: i.e. interpreting a 1 to mean "set the corresponding bit in the control register", which, on both operating systems, sets the physical line low.  But someone should probably verify this, since it's been a while since I tested it and my notes are a bit obscure. 

If I'm right, then I believe the current behavior (in SVN) is correct: it's consistent between operating systems, uses the OS interpretation of the meaning of "set the line" (i.e. bringing it low), and correctly resets Arduino boards (which is, after all, the goal). 

Maybe we just need to clarify with better comments the behavior of the ser_set_dtr_rts() function (i.e. that a logical 1 means a low level on the physical line and vice-versa)?

Hmmm. Not on my system.

From my point of view it looks like that patch #7100 is just wrong. It makes the auto-reset functional, but that's about it.

When I use that patch and have a look at DTR with my logic analyzer, the signal is inverted. (FTDI adapter).

I've attached some code that you can play with. Even the ioctl() that reads back the status of DTR shows that it is set LOW after having written a '1' to the bit, and set HIGH after having written a '0' to the bit.

Maybe the bug is somewhere deeper in the food chain.

I think that when you call ser_set_dtr_rts(1) the DTR line should actually be set HIGH. With your patch that is not the case on my machine.

(file #23669)

"I do not know. There are several things I can't adequately explain with this board yet."

Looks like the supplier just reported a minor hardware defect.  I'll try to make the mod next weekend and let you know if it works better then.

Only the comments in 'ser_posix.c' are quite misleading. If clearing a bit in a register actually sets the signal line to high and vice versa. Almost like clearing an interrupt flag in an AVR by writing a 1 to the bit.

Someone else on a linux system should check this as well. Just to rule out that my system is weird.

Nevertheless nothing of this changes the fact that only a HIGH-->LOW transition can cause a reset pulse if there is a capacitor between DTR and the reset pin. All arduinos have that.

Toggling the line twice always creates at least one H->L transition.

Hmmm.

I don't want to turn this into a "which patch is better" discussion ;-)

The patch(es) that provide the best (and identical) results on all platforms should be used. Preferably with code that has the same logic and enough comments to understand it, if there are significant differences.

Now back to the reset business.

Why does your arduino require an additional reset after the bootloader is done? So far every bootloader I've used automatically starts the application after the upload is done. No additional external reset required here.

Regarding holding DTR low. This only keeps the AVR in reset state if DTR is wired directly to the reset pin.

To my knowledge all 'arduino'-type boards have a 100nF capacitor between the DTR line and the chip's reset pin. Therefore it is physically impossible that keeping DTR low holds the chip in reset. DC voltages are blocked by capacitors. That's why I keep repeating the HIGH-->LOW business all the time.

Anyhow. If getting this to work needs a 2nd reset on windows, then it should be inserted.

I will look into the ser_posix.c stuff some more and record traces.

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)

Another option would be to introduce

serial_toggle_dtr_rts();

and in 'arduino.c' use:

  serial_toggle_dtr_rts(&pgm->fd);
  usleep(50*1000);

  serial_toggle_dtr_rts(&pgm->fd);
  usleep(50*1000);

That way it would not matter (for the purpose of auto-reset) if the stuff in 'ser_posix.c' is inverted or not - as long as it is consistent! Also the initial state of DTR is irrelevant.

It would either produce HIGH_LOW_HIGH or LOW_HIGH_LOW, both sequences reset the chip.

I've attached the changes needed for this proposal. But it adds more changes.

The generated waveforms on DTR and reset are the same as with my initial patch (trace #2)

(file #23663)

Actually, I think you got better results by accident.  Isn't the logic in ser_posix.c ser_set_dtr_rts backwards?

Can you try the attached patch instead of your patch?

This fixed the problem with my Uno needing a manual reset to upload code under Linux.

(file #23660)

It came to my attention that I could only upload every 2nd try to my bootloaded AVR chip (or 'Arduino' if you like). The first pass would fail and I would abort avrdude (the chip was not reset). With the old code this left the DTR line in a usable state for the next run, which then succeeded reproducibly.

This patch reverses the sequence of setting/clearing DTR/RTS. In depth explanation including a small schematic are in the comment in the .diff file.