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

[dbetz]

I tried this and it didn't seem to work. In fact, I can't seem to set the state of the /CTS pin at all. If I force it to high it still reads 0v on my meter. Could I have fried my WX module?

Also, do I need to enable the internal pull-up resistor if we use the approach of leaving /CTS an input by default? I would guess not since I think the Propeller essentially has an internal pull-up on /RES.

[PropGit]

We shouldn't need to enable the internal pull-up if it's being connected to a Propeller's RESn pin.

[AndyLindsay]

Here is a /CTS test that uses the firmware and wifi library that are currently in circulation. Expected results and link to firmware + library are in the comments. /* Test /CTS with this firmware & wifi library https://www.parallax.com/downloads/parallax-wx-wi-fi- module-firmware-and-example-files Expected output: Test controlling Wi-Fi module I/O Set /CTS ouput-high pinState = 0 Check /CTS pinState = 1 Set /CTS ouput-low pinState = 0 Check /CTS pinState = 0 Check /CTS for pull-up when input should return high pinState = 1 */ #include "simpletools.h" #include "wifi.h" int pinState; int main() { wifi_start(31, 30, 115200, WX_ALL_COM); char *reply; print("Test controlling Wi-Fi module I/O\r"); print("Set /CTS ouput-high\r"); reply = wifi_command("SET:pin-gpio13,1\r"); pinState = (reply[3] == '1') ? 1 : 0; print("pinState = %d\r\r", pinState); pause(1000); print("Check /CTS\r"); reply = wifi_command("CHECK:pin-gpio13\r"); pinState = (reply[3] == '1') ? 1 : 0; print("pinState = %d\r\r", pinState); pause(1000); print("Set /CTS ouput-low\r"); reply = wifi_command("SET:pin-gpio13,0\r"); pinState = (reply[3] == '1') ? 1 : 0; print("pinState = %d\r\r", pinState); pause(1000); print("Check /CTS\r"); reply = wifi_command("CHECK:pin-gpio13\r"); pinState = (reply[3] == '1') ? 1 : 0; print("pinState = %d\r\r", pinState); pause(1000); print("Check /CTS for pull-up when \rinput should return high\r"); reply = wifi_command("CHECK:pin-gpio13\r"); pinState = (reply[3] == '1') ? 1 : 0; print("pinState = %d\r\r", pinState); pause(1000); }

…

On Mon, Apr 24, 2017 at 9:39 AM, Parallax Git Administrator < ***@***.***> wrote: We shouldn't need to enable the internal pull-up if it's being connected to a Propeller's RESn pin. — 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/ALCgd7NTvkc3CFAHBVlt64VNGDdQs359ks5rzNBOgaJpZM4M5QyP> .

[dbetz]

I tested using the /CTS pin for reset and it seems to be working with no additional pull-up resistor. I just connected /CTS to /RES on the Prop Mini.

…

On Apr 24, 2017, at 2:16 PM, Andy Lindsay ***@***.***> wrote: Here is a /CTS test that uses the firmware and wifi library that are currently in circulation. Expected results and link to firmware + library are in the comments. /* Test /CTS with this firmware & wifi library https://www.parallax.com/downloads/parallax-wx-wi-fi- module-firmware-and-example-files Expected output: Test controlling Wi-Fi module I/O Set /CTS ouput-high pinState = 0 Check /CTS pinState = 1 Set /CTS ouput-low pinState = 0 Check /CTS pinState = 0 Check /CTS for pull-up when input should return high pinState = 1 */ #include "simpletools.h" #include "wifi.h" int pinState; int main() { wifi_start(31, 30, 115200, WX_ALL_COM); char *reply; print("Test controlling Wi-Fi module I/O\r"); print("Set /CTS ouput-high\r"); reply = wifi_command("SET:pin-gpio13,1\r"); pinState = (reply[3] == '1') ? 1 : 0; print("pinState = %d\r\r", pinState); pause(1000); print("Check /CTS\r"); reply = wifi_command("CHECK:pin-gpio13\r"); pinState = (reply[3] == '1') ? 1 : 0; print("pinState = %d\r\r", pinState); pause(1000); print("Set /CTS ouput-low\r"); reply = wifi_command("SET:pin-gpio13,0\r"); pinState = (reply[3] == '1') ? 1 : 0; print("pinState = %d\r\r", pinState); pause(1000); print("Check /CTS\r"); reply = wifi_command("CHECK:pin-gpio13\r"); pinState = (reply[3] == '1') ? 1 : 0; print("pinState = %d\r\r", pinState); pause(1000); print("Check /CTS for pull-up when \rinput should return high\r"); reply = wifi_command("CHECK:pin-gpio13\r"); pinState = (reply[3] == '1') ? 1 : 0; print("pinState = %d\r\r", pinState); pause(1000); } On Mon, Apr 24, 2017 at 9:39 AM, Parallax Git Administrator < ***@***.***> wrote: > We shouldn't need to enable the internal pull-up if it's being connected > to a Propeller's RESn pin. > > — > 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/ALCgd7NTvkc3CFAHBVlt64VNGDdQs359ks5rzNBOgaJpZM4M5QyP> > . > — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAq-1qLNF8NuR7Cexb2fILEbP_aeNjAfks5rzOcGgaJpZM4M5QyP>.

[PropGit]

[RETRACTED! After posting this I suddenly realized this must be a caching problem, and sure enough, a reload of the setting page without cache solved the problem.]

I have two modules I simply call SIP and DIP.

While attempting to test PropLoader v1.0-33 with Wi-Fi Firmware v1.0 (2017-04-22 10:25:42 13-gb357dbb), I found that the setting to route the Reset signal is missing on my SIP module:

However, it is clearly there in setting on my DIP module (running the same firmware):

Also note that the Debug Log button on the left-side only appears from the Home page on the SIP module, but appears on every page on the DIP module.

I updated both my SIP and DIP module, one right after the other, using the same .ota file.

[PropGit]

Verified this works great with a direct connection - CTS to RESn, using PropLoader v1.0-33 (2017-04-22 08:49:27 g0d30b50) with Wi-Fi Firmware v1.0 (2017-04-22 10:25:42 13-gb357dbb).

For testing, I used an old Propeller Flip prototype (the one with P31 and P30 swapped) on a breadboard where I wired the Wi-Fi SIP to P31, P30, RESn, Gnd (and 3.3v from Flip to Wi-Fi module) and powered the board using the Gnd and 5 vdc connections from a nearby PAB WX. And, of course, I set the Reset Pin to "CTS (GPIO13)" in Wi-Fi Module's configuration page settings, then clicked Save to Flash (and also Save just for kicks).