Yet annother Retroflag NESPi case with Mausberry, Softshutdown, DUO-LED, Momentary switches

[cyperghost]

@lostless said in Yet annother Retroflag NESPi case with Mausberry, Softshutdown, DUO-LED, Momentary switches:

@jmcfsu13
I’m learning here. Most my knowledge is trial and error with research when I get stuck. But what do you mean by unreliable? What issues have others had? All that I can think of is possibly giving the gpio a more solid 3.3 v to work with?

unreliable means that the GPIO - if it is unpowered is in a floating state.
If you wait for signal on this GPIO to get high than this can be caused by radiation by your mobile, electrostatic stroke if you touch one of the Pie components....

The most relieable method (afaik) is to power the GPIO with 2.5-3.3V to get a high signal and wait for it's state changing to 0 by pressing the button ;)

[lostless]

@cyperghost from what I’ve experiened, GPIO is actually powered with 3.3v From inside the pi’s GPIO pin if pull up is turned on and it turns on an internal software resistor. It still needs to be pulled down to trigger the low. All that adding the other 3.3v is to lower the current though the GPIO pin as far as I can tell.

[Heyoeyo]

Very cool! Makes me want to get a proper case for mine.

Just to chime in on some of the questions/comments:

Pull-up resistors:

• If you configure a GPIO pin as an input and only connect a button, (no internal/external pull-up resistor) then the pin will be 'floating' until the button is pressed (i.e. it doesn't have a definite value). This means you'll get erratic signals on the pin, which will probably be misinterpreted by the pi as high-to-low and low-to-high transitions. So you might end up rebooting/shutting down your pi just by waving your hand near it.
• The internal pull-up should connect a resistor (internally) from the specified GPIO to 3.3v as @lostless says. It's the same as wiring your own external resistor, it's just there to save you the hassle because it's such a common thing to do. I believe the pi also has internal pull-down resistors if you feel like flipping the circuit upside down :p
• I don't know anything about the reliability of the internal pull-ups, but the situation @cyperghost is describing is exactly what you'd expect from a pin without pull-ups, so if they were enabled and it stills does that, I'd agree that they're unreliable! The main benefit of an external resistor is that it's something you can see and test, so it's definitely an option worth considering.
• Enabling the internal resistor and having an external resistor increases the current draw of the circuit (you're drawing current through 2 resistors in parallel instead of 1). This isn't much of an issue if you use a big enough external resistor and the benefit is that you get an added bit of redundancy in case one resistor fails.
• @lostless in the reset button wiring diagram you posted (with a 10k and 1k resistor), having that 1k resistor means the pin will only drop to 0.09V instead of fully grounding (0V) when the button is pushed. That's still well within the low-voltage threshold for the pi, so it's fine to keep it, but you can safely replace it with a direct connection if you want to simplify the circuit wiring (the 10k is providing protection from shorting the 3.3v supply. Meanwhile, connecting a GPIO-input pin directly to anything between 0-3.3V is harmless)

Reset python file:

• Just a minor thing, but I'd recommend moving the line:
  import os
  To the top of the file (with the other import commands). As is, the script is trying to import a library every time the reset button is pressed. Python might be smart enough to ignore it after the first call (I'm not familiar enough with python to know...) but it's overall just safer/cleaner to have it do this only once at the top of the script.

Mausberry custom script:
I'm not familiar with the Mausberry, so forgive me if I'm missing/misinterpreting something here!
The script you posted looks like it could be combined into the reset python script fairly easily. I'm not super familiar with bash, but the lines:

echo "$GPIOpin1" > /sys/class/gpio/export
echo "in" > /sys/class/gpio/gpio$GPIOpin1/direction
echo "$GPIOpin2" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio$GPIOpin2/direction
echo "1" > /sys/class/gpio/gpio$GPIOpin2/value

Seem to be configuring the pins, which I would interpret (in python) as:

GPIO.setup(GPIOpin1, GPIO.IN, pull_up_down = GPIO.PUD_DOWN)
GPIO.setup(GPIOpin2, GPIO.OUT, initial=GPIO.HIGH)

It doesn't look like the bash script uses the internal resistors (though maybe it does by default?). I've included the pull-down resistor, because of what happens in the while loop afterwards. You can remove the pull_up_down = GPIO.PUD_DOWN bit if you don't need it.

Then the while loop that follows (in the bash script) appears to be checking GPIOpin1 for a low-to-high transition to trigger a safe shutdown (I guess that has to do with the Mausberry?). You can do this in python with code similar to the reset button script:

# Define a function which will be called when the shutdown button is triggered
def interrupt_shutdownBtn(channel):
        os.system('/home/pi/maus_shutdown.sh')

# Enable shutdown button (GPIOpin1) interrupt to trigger on a rising edge (i.e. low-to-high transition)
GPIO.add_event_detect(GPIOpin1, GPIO.RISING, callback = interrupt_shutdownBtn, bouncetime = 1000)

And then you'd have to make a maus_shutdown.sh script like you did with the exit.sh script, by copying the rest of that bash script into a file:

espid="$(pgrep -f "/opt/retropie/supplementary/.*/emulationstation([^.]|$)")"
# Terminate any emulatorcall!
# This works just for RetroPie!
emucall="$(sed -n 4p /dev/shm/runcommand.info | tr -d '\\"' | tr '^$[]*.()|+?{}' '.' | sed 's/[^ ]*=[^ ]* //g')"
# If there's an emulator running, we need to kill it and go back to ES
if [[ -n "$emucall" ]]; then
    emupid="$(pgrep -f "$emucall" | tr '\n' ' ')"
    pkill -P "$(echo $emupid | tr ' ' ',')"
    kill "$emupid"
    wait "$emupid"
    sleep 5 # maybe it can be lesser
fi

if [ "$espid" ]; then
   touch /tmp/es-shutdown && chown pi:pi /tmp/es-shutdown
   kill $espid
   exit
fi
# End Emulationstation if condition of running binary is true (v1.56)

sudo poweroff

In fact, the first part of this is the exit.sh followed by some extra code to close emulationstation at the end (so you could split it up and re-use the exit script if you wanted, just be careful to move the espid=... part if you do).
Anyways, you should be able to combine the python bits into the existing reset script (though I haven't tested this!). Just make sure to copy each part into the appropriate section. So for example, the pin definitions go near the top (with resetBtn = 32), GPIO.setup lines go one after another, the interrupt functions should be written one after the other and the GPIO.add_event_detect lines should be together as well.

EDIT:
Changed one of the lines to use the pull-down resistor.

[lostless]

@heyoeyo well that was a read. LOL. So any way, I understand the electronics of whats going on and I figured out the pin does have its own 3.3V accidentally when i unplugged the 3.3V and the reset was still working. Pulled out my meter and, there you go 3.3V. As far as false positives, The wire run i'm running is very short to pin 32. I don't think it's going to pick up much noise plus it's running it to trigger on low. Noise would have a greater change to trigger a low to high. As far as the 10k to 3.3V being gone now, I'm willing to take the very minor risk of a possible failure of the software resistor.

Now as far as moving the import os to the top. done and It works still. Thank you for starting my understanding of python. After looking at yours I was looking at other scripts on how to program the button as a dual purpose to make the reset do 2 things based on how many times pressed. Ended up using yours, but it makes sense what i'm doing now.

[lostless]

Oh and all, final build. My own mini NES

[Heyoeyo]

@lostless said in Yet annother Retroflag NESPi case with Mausberry, Softshutdown, DUO-LED, Momentary switches:

@heyoeyo well that was a read. LOL

Haha, ya sorry about that! I kinda got carried away by the Mausberry thing :/

There's probably a few ways to have it respond to double pressing the reset button. One of the simplest (but not exactly prettiest) is by placing some extra code in the interrupt to watch for another button press (by polling it). You'd probably have to play around with the bouncetime setting on the interrupt as well as playing with delays while polling to get it to feel right, but it could definitely work.

Otherwise, glad to hear everything's working!

[cyperghost]

@heyoeyo said in Yet annother Retroflag NESPi case with Mausberry, Softshutdown, DUO-LED, Momentary switches:

I don't know anything about the reliability of the internal pull-ups, but the situation @cyperghost is describing is exactly what you'd expect from a pin without pull-ups, so if they were enabled and it stills does that, I'd agree that they're unreliable! The main benefit of an external resistor is that it's something you can see and test, so it's definitely an option worth considering.

I never used python for coding. But I never saw a tutorial yet, that says that there is no external or no external power feed needed.

Thank you for talking about the two resistors. AFAIK there is an internal resistors available (round about 50k) that splits voltage. So truely you need only one resistor outside ... it's value isn't really a great deal ... 500R up to 50kR.
But please correct me if I'm wrong....

Great explaination btw... thanks

[Heyoeyo]

@cyperghost said in Yet annother Retroflag NESPi case with Mausberry, Softshutdown, DUO-LED, Momentary switches:

So truely you need only one resistor outside ... it's value isn't really a great deal ... 500R up to 50kR.

If the internal pull-up resistor is enabled, you don't need any external resistors (just the switch connected from the GPIO to ground). However, if you're going to be sharing this with others (especially someone who might modify or try to copy the connections) then having the external resistor might be a nice courtesy since it makes the wiring much clearer.
Here's a set of possible connections from your button to the Raspberry Pi GPIO input:

If you use an external resistor, then anything around 10k is a good value to aim for (though as you say, going as low as 500 ohms will work, it will just draw more current when the button is pressed).

And just to be sure, here are some bad connections, maybe useful for anyone who wants to double check they haven't accidentally wired up this way:

[cyperghost]

@heyoeyo Wow... that was a good lesson. Thank you.

But can the internal resistor only enabled via python via PULLUP _ PULLDOWN-command as additional value to the GPIO setting? That's the only language that stays clear to enable/disable the commands.

[lostless]

@heyoeyo those diagrams confirm what I was suspecting. Thanks.

[Heyoeyo]

@cyperghost said in Yet annother Retroflag NESPi case with Mausberry, Softshutdown, DUO-LED, Momentary switches:

But can the internal resistor only enabled via python via PULLUP _ PULLDOWN-command as additional value to the GPIO setting? That's the only language that stays clear to enable/disable the commands.

It can definitely be done with languages other than python. I only know of the wiringPi C library, which provides the same kind of functionality, but there are probably other options as well.

It might also be possible to do it with bash, though I'm not familiar enough with it to know for sure. The actual (low-level) required steps are listed in the datasheet for the BCM chip the pi uses, which I've copied here for reference (from page 101):

The GPIO Pull-up/down Clock Registers control the actuation of internal pull-downs on
the respective GPIO pins. These registers must be used in conjunction with the GPPUD
register to effect GPIO Pull-up/down changes. The following sequence of events is
required:

1. Write to GPPUD to set the required control signal (i.e. Pull-up or Pull-Down or neither
   to remove the current Pull-up/down)
2. Wait 150 cycles – this provides the required set-up time for the control signal
3. Write to GPPUDCLK0/1 to clock the control signal into the GPIO pads you wish to
   modify – NOTE only the pads which receive a clock will be modified, all others will
   retain their previous state.
4. Wait 150 cycles – this provides the required hold time for the control signal
5. Write to GPPUD to remove the control signal
6. Write to GPPUDCLK0/1 to remove the clock

That's as technical a description as you'll find, but that's what python/wiringPi are doing 'under the hood'. As far as I can tell, it basically boils down to:

• Write a value to a register (special memory location): 0 Disables pullup/down, 1 enables pull-down, 2 enables pull-up
• Wait a short period of time
• Write another value to another register, which specifies the pin you are using (the value you set in the first register is mapped onto the pin selected by this register)
• Wait a short period of time (this is where the resistor is physically connected)
• Write something (say a value of 0) to both of the previous registers to reset them so they can be used for another pin

I'm not 100% sure of that last step though!
Anyways, this is only a little more complicated than setting the pins as regular inputs/outputs, which bash seems capable of doing based on what I've seen from the code that was posted. So it seems entirely possible that it's just a matter of writing an appropriate value into the correct file/folder to enable the internal resistors with bash.

[jmcfsu13]

so i finally had time to get mine wired. you guys have come a long way with the script. @cyperghost @lostless what are you now using for your completed shutdown and reset scripts?

[lostless]

@jmcfsu13 look further up. I’ve done a whole explanation of my power and reset button programming. I have my reset exit back to Es. And power exits retroarch and properly shuts down Es.

[jmcfsu13]

@lostless so you are still using the bash one? not the python?

[lostless]

@jmcfsu13 i am. If you want to try a python one and report back, give us the details of what you did

[caver01]

@lostless said in Yet annother Retroflag NESPi case with Mausberry, Softshutdown, DUO-LED, Momentary switches:

If you want to try a python one and report back, give us the details of what you did

I use a python script as shown in the first post on THIS THREAD. I simply replaced the call at startup in /etc/rc.local with a python /path-to-python-script &

This creates a more efficient shutdown, and @meleu's killes.sh script does all of the heavy lifting with respect to finding the emulator and ES processes and exiting.

[lostless]

@caver01 I was reading that thread, is there any rewireing of the mauseberry, as far as what pins to use or adding a transistor? And also does it solve the mauseberry not turning off if you shutdown via software?

[caver01]

@lostless said in Yet annother Retroflag NESPi case with Mausberry, Softshutdown, DUO-LED, Momentary switches:

@caver01 I was reading that thread, is there any rewireing of the mauseberry, as far as what pins to use

Of course, you would need to update the script to cover whatever pins you are using for IN/OUT, but the version I posted in that thread uses the recommended/example values from Mausberry (although it is using Broadcom pin numbering instead of GPIO numbers). Think of it as a direct replacement of the script from the Mausberry site.

or adding a transistor?

We can get into the transistor details, which comes to fruition in this post. That's the point at which I actually installed the transistor on another PIN and triggered it inside the more complex version of the BASH version (getting convoluted I know) of the mausberry script. Of course, I am now using python. The transistor trick (which could also be an opto-coupler MOSFET--Solid State Relay, or even just a diode as described above) does work, but it is not handled by this simplified python script. See below.

And also does it solve the mauseberry not turning off if you shutdown via software?

The key with the python solution is to replace the BASH "sleep loop" with a more efficient edge-detection method for watching GPIO. The python script achieves this quite easily, but of course, none of the extra stuff is included. It merely duplicates original mausberry shutdown.

For the ES and emulator exit, I have all of those commands conveniently separated from the trigger loop. The graceful exiting of emulators now resides in the killes.sh script coupled with the service. Another method could be to simply call the killes.sh script from the python script. That way, you still are letting the python edge detection handle the GPIO trigger, but keeping enhancements to the shutdown routine separate. I prefer the service, personally, as it is shutdown-agnostic (works with any shutdown request).

Finally, to finish the answer with respect to the transistor, my transistor trigger is now part of my killes.sh. So, when ever a shutdown is initiated, whether UI/software initiated or via the mausberry switch, the killes.sh gets called, closing down ES, emulators, and for me, tripping the transistor. That way, if the shutdown was triggered by the UI/software, the mausberry circuit still thinks the button was pressed.

There is one downside to this--no soft reboots. A reboot would still close the service, and trigger killes.sh which would tap the transistor and the mausberry circuit will cut power while the PI goes down. For me, no soft reboot (becomes shutdown instead) is a small price to pay for coverage of all other shutdown scenarios. My mausberry circuit no longer locks into a powered state, and I get the benefit of safe shutdown no matter how it was requested--all while doing python-based GPIO edge-detection for the switch.

[lostless]

@caver01 ok so the transistor just allows the mauseberry to shut down properly in any situation. But then python script is literally just a functionally identical script to the original, other then it being python?

[cyperghost]

@lostless

ok so the transistor just allows the mauseberry to shut down properly in any situation

Yes... the any situation is exacatly one situation. If you use sudo poweroff or sudo shutdown -h now and do a software poweroff, then the mausberry does not respond on any keypress (you can't power on your Raspberry) and you have to reset the MB circuit :(

But then python script is literally just a functionally identical script to the original, other then it being python?

It's the same. Only the detection of the GPIO event is different as @caver01 wrote.
It's better to use the shutdown service that @meleu introduced. It's a more solid solution except of the shutdown/reboot failure if you use the MB-circuit and the transistor/diode trick.

But you can easily solve it if you use this sniplet. I don't know any better solution so far :(