Make reset signal route to either DTR or CTS

[PropGit]

Make the reset signal route to either the DTR pin or the CTS pin.

DTR functionality already works and should remain as-is. Ensure that it works perfectly for DTR after being switched from CTS to DTR.

CTS functionality is new.

• By default, CTS is an input and is pulled-high.
• If the reset signal is directed to CTS, the CTS pin must remain as an input (which will generate the high signal externally) and must only be set to output low when a reset is requested, then is set back to input. Never drive CTS as an output high!

[dbetz]

Why can't I drive CTS? I think that is how I tested it and it seemed to work. I know it is normally an input but does it have to be? In any case, the current firmware drives it just like DTR. To treat it differently will require different code. Right now the only thing that is different is the PIN number.

[PropGit]

@AndyLindsay and I had a reason that I'm either not remembering correctly right now, or the reason isn't really valid. Hopefully he can clarify this.

Reasoning Out Loud:
DTR is normally driven; but it's also an output always.
CTS is normally an input; but we're asking that it be at least temporarily an output if used as a reset signal.

Circuitry that connects to CTS for normal purposes is driving CTS; though open-drain placed on a CTS pin (which is an input and pulled-high on-board) would work also.

If we use CTS as an open-drain output for the reset signal, it won't protect against shorts if it's accidentally configured that way and connected to a circuit that drives CTS both high and low.

I can't find reason not to make CTS constantly driven.

[PropGit]

Discussed with @AndyLindsay where he reminded me of the reason.

The CTS for reset signal is for SIP use of the module. If CTS is constantly driven (high and low; high normally) then it not only prevents other ways to reset the Propeller (ie: from the press of a Reset button they may have wired in as well), but it also causes a short-circuit in that same case (CTS driving high, Reset button (or external signal) driving same connection low). We don't want to have to force the user (and rely on them remembering) to add additional circuitry on their breadboard to protect against that... we can just do it in software by making the firmware toggle CTS between input and output low, only.

NOTE: DTR would be the same situation, except that we added protective circuitry on the PAB WX to protect against such electrical contention.

If it helps in code, the DTR pin can be treated the same way and all should still work (input, or driven output low; never driven output high.

[dbetz]

Okay, this isn't an easy fix. It also seems like it's only a partial fix. If I try to reset the Propeller by using CTS then having the WX pull it low while some external circuitry is pulling it high will still generate a short won't it?

[AndyLindsay]

It's kind of like I2C, multiple devices can either pull the line low or release it and let the pull-up resistor(s) make it high.

…

On Apr 10, 2017 2:27 PM, "David Betz" ***@***.***> wrote: Okay, this isn't an easy fix. It also seems like it's only a partial fix. If I try to reset the Propeller by using CTS then having the WX pull it low while some external circuitry is pulling it high will still generate a short won't it? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALCgdxA75yl9d4AkY3UY5WYeBHdB-4hwks5rup6wgaJpZM4M5QyP> .

[PropGit]

No. If it's "pulled" that means it's connected through a resistor to a certain voltage source. If it is "driven" that means it's connected directly to a certain voltage source.

If a line in pulled high, and then suddenly the line itself is driven low, the signal on the line will read "low" and the resistor will take the load of the difference between low and high and dissipate it as heat. No short, and a controlled amount of current is drawn.

If a line is driven high from some source, and then suddenly another part of the line is driven low from another source (with no resistor in-between), that will be a direct short; which pulls a lot of current since the line itself has very little resistance to dissipate the difference.

[PropGit]

If the WX is driving CTS low and some other circuit on the breadboard is driving it high... that will indeed be a problem; but we always tell people never to drive the RESn line high.

[AndyLindsay]

It just occurred to me that the SIP module might convert output-high into open drain high on CTS. Let me test this first.

…

On Apr 10, 2017 2:33 PM, "Andy Lindsay" ***@***.***> wrote: It's kind of like I2C, multiple devices can either pull the line low or release it and let the pull-up resistor(s) make it high. On Apr 10, 2017 2:27 PM, "David Betz" ***@***.***> wrote: > Okay, this isn't an easy fix. It also seems like it's only a partial fix. > If I try to reset the Propeller by using CTS then having the WX pull it low > while some external circuitry is pulling it high will still generate a > short won't it? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#21 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ALCgdxA75yl9d4AkY3UY5WYeBHdB-4hwks5rup6wgaJpZM4M5QyP> > . >

[AndyLindsay]

I just tested it, and although it might actually work in some systems when the Wi-Fi module's ESP module is sending output-high due to the Wi-Fi module's (5 V or 3.3 V) to 3.3 V conversion circuits, the correct approach will be to put /CTS in a (high) resting state by making it an INPUT. Then, to start a negative pulse to a Propeller microcontroller's RESn line, /CTS should be driven OTUPUT-LOW. To end the reset pulse, /CTS should be made INPUT again to return the RESn line to its high resting state.

…

On Mon, Apr 10, 2017 at 2:40 PM, Parallax Git Administrator < ***@***.***> wrote: If the WX is driving CTS low and some other circuit on the breadboard is driving it high... that will indeed be a problem; but we always tell people never to drive the RESn line high. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALCgd7Q3g7FMwbO6WXx6Ka9MG7mlNUoFks5ruqGzgaJpZM4M5QyP> .

[PropGit]

Follow-up: On the PAB WX, the WX socket /DTR line is pulled up with a 100 k ohm resistor, to prevent the high-impedance input on the programming-source-selector circuit from falsely detecting a reset.

[dbetz]

So what is your final conclusion? How should I implement DTR and CTS reset?

[PropGit]

I think both DTR and CTS functionality can be like this:

• pin remains an input by default
• when a reset pulse is requested
  • set pin's output state to low (this is important to do before the direction change)
  • set pin's direction to output
  • pause for designated reset pulse time
  • set pin's direction to input