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

lostless

This is my mauseberry custom script that seems to be working. Im starting to actually understand this scripting stuff. Thanks to @meleu and @cyperghost and tad bit of me piecing this together form their scripts.
so edit the /etc/switch.sh file after installing the mauseberry driver.

#!/bin/bash

#this is the GPIO pin connected to the lead on switch labeled OUT
GPIOpin1=23

#this is the GPIO pin connected to the lead on switch labeled IN
GPIOpin2=24

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
while [ 1 = 1 ]; do
power=$(cat /sys/class/gpio/gpio$GPIOpin1/value)
if [ $power = 0 ]; then
sleep 1
else

# End Emulationstation if condition of running binary is true 
# Thanks @meleu and @cyperghost for 99.9999999999999% of this
# Edited by @lostless
 

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
fi
done

If anyone has ideas on how to improve this. Im all ears.

meleu

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

If anyone has ideas on how to improve this.

yes. Use a proper indentation! ;-)

lostless

@meleu oh forgive for my archaic organizational skill. Be kind I’m new to this. At least I got this far. Lol 😂

caver01

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

If anyone has ideas on how to improve this. Im all ears.

I highly recommend shifting this more complicated script over to a simplified python script (which uses efficient GPIO edge detection instead of a BASH sleep/wait loop) in conjunction with @meleu's shutdown service (with updated kill process code as needed).

~~This solution~~ @meleu's service idea takes everything that has been learned about killing emus and closing ES to save metadata and makes it into a generic script that runs no matter what is doing the shutdown. In other words, it is no longer tied to a "mausberry" script. Anything can call a shutdown and the service will trigger the proper kill commands. Then, with the complex stuff out of the way, your mausberry script can either revert to the original BASH script, or can be switched to python for more efficiency/less burden on the CPU. Performance gains are probably minimal.

This has a certain elegance, as it is switch-agnostic.

meleu

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

@meleu oh forgive for my archaic organizational skill. Be kind I’m new to this. At least I got this far. Lol 😂

Hey bro, no need to apologize. I'm glad if I can inspire people to code. That was just an idea for improvement, as you requested. ;-)

lostless

@meleu I was hoping the sarcasm came though. I guess with English as your second language, it gets lost in translation. I’m not apologizing and I very much appreciate you and your desire to teach peoel. You have probably taught me more than any one else here. So keep it up.

meleu

@lostless
By the way, that emulator kill script is still not as strong as I want to make it to be. If more changes come to how runcommand invoke the emulators the script can fail to kill the emu... I'll try to make it stronger and then post the solution on that thread @caver01 linked.

Cheers!

jmcfsu13

@lostless I had said before that you didnt need to add the 3v and you disagreed lol. but after you did I did research and although it is not required it is recomended. The pullup in the pie software isnt reliable according to the interwebs and to be safe you should keep your circuit how it was

lostless

@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?

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

0_1507987607571_9BA0CE2D-0924-4710-B776-38D29AEA4DAF.jpeg
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:

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)

Wait 150 cycles – this provides the required set-up time for the control signal

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.

Wait 150 cycles – this provides the required hold time for the control signal

Write to GPPUD to remove the control signal

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.