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

lostless

@cyperghost thx. Not my first project. 😜

caver01

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

My route is much easier as it just used a Si-diode connected to mausberry-switch-ground.

Are you saying you figured out a way to get the Mausberry circuit to cut power after a software-initiated shutdown using just a diode? Can you explain what you did with that diode given the fact that my circuit looks like this:

cyperghost

@caver01 If the SW brown is the ground of the switch then just connect any GPIO wire to it. This shutdowns the mausberry.

  GPIO                               MAUSBERRY
from Pie          DIODE            switch ground
   O---------------->|----------------O

I measured a voltage of 3-4V between the switch poles.
The mausberry don't cares of the voltage source.
Is it from the switch or feed from the diode ;)
The diode is just for protection of the Pie against voltage feed-backs.
But the transistor also works....

caver01

@cyperghost
I see. So you are merely simulating the voltage that would go there if the switch were triggered by supplying that voltage from the GPIO. That makes sense, and definitely easier than connecting a solid state relay or transistor across both switch poles.

cyperghost

@caver01 Exactly. As the Mausberry mains provides the same ground to all connected devices I see no problem with different ground potentials also. So this should work in general. But it would be nice if you report back.

cyperghost

@caver01
I tested with a bare mausberry switch - No Rasperry connected, no LED just the power plug via micro USB.

You measure between LED(+) and GROUND Reset Pad >> 0V
Now you connect SWITCH(+) and SWITCH(-) with one cable just for a second to simulate a momentary push button
You measure between LED(+) and GROUND Reset Pad >> 2,5V
The LED(+) simualtes a GPIO output voltage + diode = 3,3V-0,7V=2,5V
Now connect LED(+) to SWITCH(-) (just 1 seconds) and measure between LED(+) and GROUND Reset Pad >> 0V

So this seems to work in general
I used a 1N4002 Diode ... This shuts against 100V and I can provide 1A through ;)
A bit overgrowen but I don't know any cheaper parts...

EDIT:
I measured voltage between the switch-pads!
These are 5,0V and if you press the power switch the GPIO will receive back-draws and may get damaged .... So use the diode to protect the Pi - I don't know any cheaper life insurance (and this is a working one)

lostless

@cyperghost @day Word of warning. I think i just burned out my GPIO by my setup and redoing my image without the GPIO script installed in a pull up mode. Even though i had a 10K resistor to lower current, the pin was not set up at that time.. GPIO on any pin is not functioning. Im rethinking hooking up in pulldown mode just to avoid this.

found out that the 3.3 volt line is not needed. if a gpio pin is set as pullup, it gives you 3.3 volts on the pin and all you have to do i ground it. i have another issues where the gpio just stopped triggering. on my other card, its triggering just fine

cyperghost

@lostless But I think you have to stick to Python. Can you post code please?

lostless

@cyperghost i will when i figure out whats wrong with my code and why it stopped working. could be something simple as permission issues.

lostless

@cyperghost @day
ok, come to find out, you don't need to feed the gpio 3V. setting it as a pullup automatically sets it to 3.3V, I guess? its working! so new image of final.
now for the scripting. i want to thank @Heyoeyo for this and helping me understand a tad bit of python. Im using pin 32 so thats been made. change the pin to whatever one you're using. The file is in the home folder called reset.py

import RPi.GPIO as GPIO
import time
import os 

# Define which pin u're using for the reset button (change this to whatever pin you use)
resetBtn = 32


# Use 'board' pin numbering (i.e. the zig-zaging numbering scheme)
GPIO.setmode(GPIO.BOARD)
# See:   https://pinout.xyz/   for the pin layout

# Set the resetBtn pin to an input and enable the pull-up resistor
GPIO.setup(resetBtn, GPIO.IN, pull_up_down = GPIO.PUD_UP)

# Define a function which will be called when your reset button is pressed
def interrupt_resetBtn(channel):

        # Print indication to console
        print "You pressed the reset button!"

        # Code for detecting/ending an
        # emulator would go here
        os.system('/home/pi/exit.sh')


# Enable reset button interrupt to trigger on a falling edge (i.e. high-to-low transition)
GPIO.add_event_detect(resetBtn, GPIO.FALLING, callback = interrupt_resetBtn, bouncetime = 1000)

# --------------------------------------------------------------------

# Now just wait forever for the user to press a button
# The sleep time doesn't really matter, make it long enough so it isn't wasting cpu cycles
while 1:
        time.sleep(5)

so this just calls for a shell script called exit.sh i made in the home folder. thanks to @meleu for this. (What would do without him?)

# 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

this needs to be made executable, if you called the file exit.sh

sudo chmod +x /home/pi/exit.sh

now add to /etc/rc.local

python /home/pi/reset.py &

right before
exit 0
reboot andnow the reset can be used to exit back to es. if you want to make reset do something else, remove the

        import os
        os.system('/home/pi/exit.sh')

and put in the code you want it to do.

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 ;)