Something like the CD4532 priority encoder (50 cents) could be attached added to one of the above circuits. There is one output that goes low (or high) when any of its inputs are made high, and that could be tied to one of the above push-on push-off circuits. And 3 more outputs give the binary code of the highest priority input. You can't use that to detect two buttons at the same time. The nice thing about CD series CMOS is that it is very flexible about the power supply up to 18V and nanoamps quiescent current.
The Maxim 73xx series (~$2) are port expanders, input, output and combo. An interrupt output that is activated when any of the inputs is pressed. There are up to 16 inputs, depending on family member, and configurable pullup resistors. The current state (or latched transition states) can be read via I2C (or other options). Enough configuration registers to keep you hopping. Standby current, near 1 microamp. E.g. MAX7319, 8 inputs, latches transitions. Again for push-on-off, I guess the interrupt would have to be connected to one of the circuits earlier in the thread, but the
The problem with using the CD4532 is that the power system would start up at the press of any of the buttons, but then after the prop started up, it would read nothing on the CD4532 since by then you would have lifted your finger. I do like the up to 18V input though, allowing the chip to be connected directly to the VIN.
I haven't looked to much into the Maxim 73xx, but it doesn't seem to come in a DIP which is annoying, but not a deal breaker. Also, I would need to connect this on the output side of a Voltage regulator. I might replace my current linear regulators with switching ones, in which case I can do this, but hopefully there is another way.
Add a capacitor in parallel with the pulldown resistor, enough to hold the logic level long enough for the Prop to start up and read it. If you do that though, also add 100Ω or so resistor in series with the switch to avoid sparking when the switch bounces.
The regulated voltage is definitely a problem for fancy logic like the MAX73xx. Maybe a low current regulator like the MCP1702. The MAX7319 does latch the input transitions, so that would give the Prop time to start up.
One of the issues you will run into when starting a Propeller with a momentary-contact switch is the relatively long time that it takes to come out of reset. In some cases, having to hold the button down for the program to take over and hold the power on can be an advantage. But, if you're as impatient as I am, you just want to click the button briefly to get things rolling. In that spirit, consider the following circuit (bereft of the needed caps surrounding the regulator):
In the off state, it should draw little or no current. Pressing the button raises the base voltage above 0.7V with enough current to turn the NPN on, driving its collector low, and turning on the pMOSFET, which feeds the 3.3V regulator. The output of the regulator, through the 100K resistor, is enough to hold the NPN in its "on" state, keeping the pMOSFET conducting after the button is released.
Now, here's where it gets interesting. With the switch open, and with the circuit powered up, the voltage on the Prop Pin node will be around 1.0V, which registers as a logic "low" to the Propeller. When the button is pressed, this voltage will raise to about 3.0V without affecting the power-up condition, and which the Propeller sees as a logic "high'. So the button can also be used as an input to the Propeller! Further still, should the Propeller decide to turn itself off, it has only to pull the pin low to turn off the NPN and power everything down (which it can safely do, even while the button is being pressed)..
Disclaimer: I have not built this circuit to test it ('couldn't find a pMOSFET to try it with). But I've simulated enough of it in Spice to obtain the DC voltages reported above.
-Phil
I have been playing with this circuit on the breadboard for a bit now. It works great when I'm not trying to drive it with the Prop. When I'm attempting to drive the pin low to shut down, the Prop seems to stop executing the program (it gets stuck). I suspect that the rail voltage is browning out and resetting the Propeller before it is low enough for Phil's circuit to "latch" to the off state. Unfortunately I don't have an oscilloscope to catch what is going on behind the sceens so I'm just guessing here
I'm going to try playing with some resistor values and see what happens. Should I consider driving the "prop pin" connection on Phil's circuit with a Schmitt trigger to add a bit of hysteresis?
I suspect that the rail voltage is browning out and resetting the Propeller before it is low enough for Phil's circuit to "latch" to the off state.
That seems to be a familiar refrain in this thread.
Try modifying the regulator circuit thus:
The diode in the ground circuit of the regulator will force it to regulate to 3.9V, and the series diode will drop that back to 3.3V. (Be sure to check it before powering your Propeller!) What this addition does is to provide additional time for the Prop to hold the NPN base low before the electrolytic cap discharges and causes a brownout reset. By that time, the regulator output will be close to zero. If it isn't, a bleeder resistor on its input cap will help get it there more quickly. But I think the NPN base current should be adequate to do the job.
I'm still having the same issues, perhaps I'm using excessively large caps, its also possible that I've made a wiring error. I cleared off my breadboard to give some of the other circuits a try, I will revisit this one though.
I put together the SCR based circuit that Tracy posted in post #11. So far it seems to be working perfectly, it powers up with a very brief press of the button, and powers down reliably when the prop goes into RCSLOW.
When using CLKSET to set the clock to RCSLOW, what is the correct frequency to input for the frequency argument of the command? I just used 20_000 since the nominal freq. given in the Propeller manual is 20Khz, but it is subject to quite a bit of variability. I take it that this value is only used for any frequency based calculations in later parts of the program such as waitcnt(clkfreq*2+cnt) etc.?
The SCR circuit was doing the job, but I want to be able to re-use the push button for input. So I added a couple resistors and a diode to drop the voltage to Prop friendly levels without affecting the SCR.
Here is my modified version of Tracy's design:
And here is the code I'm using to test it out:
'blink led 5 times then go into low power state
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
PUB TestBlink
dira[16]~~
repeat 5
outa[16]~~
waitcnt(clkfreq+cnt)
outa[16]~
waitcnt(clkfreq+cnt)
CLKSET(rcslow,20_000)
For my circuit to work, the electrolytic cap on the 3.3V bus has to be much larger than the regulator's filter cap.
-Phil
Duhh that makes sense doesn't it. In addition, I just realized that I had left the "power indicator" led plugged in and therefore pulling 11+ mA out of the rail. I think the led alone is likely the cause of my issues here. I'm going to take another swing at this circuit in a little bit.
One more thing: if you're using a micropower regulator, the ground current may not be adequate to bias the offset diode correctly. To correct this, you can add a resistor between the output of the regulator to its ground lead (i.e. to the diode's anode).
One more thing: if you're using a micropower regulator, the ground current may not be adequate to bias the offset diode correctly. To correct this, you can add a resistor between the output of the regulator to its ground lead (i.e. to the diode's anode).
-Phil
Good to know Phil. At the moment I'm using a LM2937, so it should not be an issue for now.
Comments
The Maxim 73xx series (~$2) are port expanders, input, output and combo. An interrupt output that is activated when any of the inputs is pressed. There are up to 16 inputs, depending on family member, and configurable pullup resistors. The current state (or latched transition states) can be read via I2C (or other options). Enough configuration registers to keep you hopping. Standby current, near 1 microamp. E.g. MAX7319, 8 inputs, latches transitions. Again for push-on-off, I guess the interrupt would have to be connected to one of the circuits earlier in the thread, but the
I haven't looked to much into the Maxim 73xx, but it doesn't seem to come in a DIP which is annoying, but not a deal breaker. Also, I would need to connect this on the output side of a Voltage regulator. I might replace my current linear regulators with switching ones, in which case I can do this, but hopefully there is another way.
Thanks,
Marcus
The regulated voltage is definitely a problem for fancy logic like the MAX73xx. Maybe a low current regulator like the MCP1702. The MAX7319 does latch the input transitions, so that would give the Prop time to start up.
I have been playing with this circuit on the breadboard for a bit now. It works great when I'm not trying to drive it with the Prop. When I'm attempting to drive the pin low to shut down, the Prop seems to stop executing the program (it gets stuck). I suspect that the rail voltage is browning out and resetting the Propeller before it is low enough for Phil's circuit to "latch" to the off state. Unfortunately I don't have an oscilloscope to catch what is going on behind the sceens so I'm just guessing here
I'm going to try playing with some resistor values and see what happens. Should I consider driving the "prop pin" connection on Phil's circuit with a Schmitt trigger to add a bit of hysteresis?
Perhaps some sort of brownout detector?
Thanks,
Levi
Try modifying the regulator circuit thus:
The diode in the ground circuit of the regulator will force it to regulate to 3.9V, and the series diode will drop that back to 3.3V. (Be sure to check it before powering your Propeller!) What this addition does is to provide additional time for the Prop to hold the NPN base low before the electrolytic cap discharges and causes a brownout reset. By that time, the regulator output will be close to zero. If it isn't, a bleeder resistor on its input cap will help get it there more quickly. But I think the NPN base current should be adequate to do the job.
-Phil
I'm still having the same issues, perhaps I'm using excessively large caps, its also possible that I've made a wiring error. I cleared off my breadboard to give some of the other circuits a try, I will revisit this one though.
I put together the SCR based circuit that Tracy posted in post #11. So far it seems to be working perfectly, it powers up with a very brief press of the button, and powers down reliably when the prop goes into RCSLOW.
When using CLKSET to set the clock to RCSLOW, what is the correct frequency to input for the frequency argument of the command? I just used 20_000 since the nominal freq. given in the Propeller manual is 20Khz, but it is subject to quite a bit of variability. I take it that this value is only used for any frequency based calculations in later parts of the program such as waitcnt(clkfreq*2+cnt) etc.?
The SCR circuit was doing the job, but I want to be able to re-use the push button for input. So I added a couple resistors and a diode to drop the voltage to Prop friendly levels without affecting the SCR.
Here is my modified version of Tracy's design:
And here is the code I'm using to test it out:
'blink led 5 times then go into low power state CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 PUB TestBlink dira[16]~~ repeat 5 outa[16]~~ waitcnt(clkfreq+cnt) outa[16]~ waitcnt(clkfreq+cnt) CLKSET(rcslow,20_000)Best Regards,
Levi
For my circuit to work, the electrolytic cap on the 3.3V bus has to be much larger than the regulator's filter cap.
-Phil
Duhh that makes sense doesn't it.
Thanks for the slap to the back of the head Phil.
Best Regards,
Levi
One more thing: if you're using a micropower regulator, the ground current may not be adequate to bias the offset diode correctly. To correct this, you can add a resistor between the output of the regulator to its ground lead (i.e. to the diode's anode).
-Phil
Good to know Phil. At the moment I'm using a LM2937, so it should not be an issue for now.
Thanks,
Levi