A group at the local STEM school has a project to build a gaming system. They are running EmulationStation on a Raspberry Pi which works very nicely. Everything is controlled by a joystick and pushbuttons. They are building into a wood console they cut on a CNC router.
They called me to help them integrate a coin acceptor into the game. The design and implementation of the coin acceptor was documented here
So we have a signal coming into the RPI that is HIGH when there is time left and LOW when the time runs out. They needed to somehow not allow gaming to start until the signal goes HIGH and terminate it when it goes LOW.
First we looked at EmulationStation. They are using an IPAC-4 controller to convert the controls into keyboard keystrokes. There are a few connections there for a coin acceptor; however, we could find no documentation on how to make those work with EmulationStation. Since we only had 4 hours left to complete the program we had to move on.
Since we could not find any other method of using a coin acceptor I will document our solution. It is not elegant, but it works.
We decided the best course of action was to trap the call to EmulationStation. We would not execute the gaming software until $$$ was input and the control signal went HIGH. Then when the signal went LOW we would reboot the RPI.
The kids don’t know anything about linux outside of getting the gaming software installed. Searching the internet, we could not figure out what was causing EmulationStation to fire up.
Finally we found /etc/profile had been modified to start the program during boot up. We commented that line out.
We need to read GPIO4 pin, so we made the following configuration changes to the system:
sudo echo 4 >/sys/class/gpio/export sudo echo in >/sys/class/gpio/gpio4/direction
We then used this scriplet to verify the pin was going high/low when we expected it:
while true;do cat /sys/class/gpio/gpio4/value sleep 1 done
The final step was to create a script that starts when the user pi logs in. This script waits for coins to be dropped, plays the game, and then reboots the RPI when the time runs out.
#!/bin/bash #these shouldn't be necessary every time, but they keep problems from cropping up for the kids down the road sudo echo 4 >/sys/class/gpio/export sudo echo in >/sys/class/gpio/gpio4/direction clear echo GamePlay Monitor. Waiting for coins.... while [[ $(cat /sys/class/gpio/gpio4/value) == '0' ]]; do sleep 1 done echo Starting Game #start game as separate process emulationstation & while [[ $(cat /sys/class/gpio/gpio4/value) == '1' ]]; do sleep 1 done sudo reboot
this file was named gameplay. It had its permissions change to allow it to be executed. Finally, the last line of .bashrc in the pi users home directory had the line added:
This is not pretty, but it works reasonably well. And we got it done with time to spare for them to work on some of the other parts.
As I was driving home I realized that rebooting the RPI was overkill. Instead of issuing a reboot, a killall emulationstation probably would have worked as well and not required an entire system boot.
Feb 2018 Update:
Circuit Cellar has written a 3 part series on money counting devices including the DG600F. The first is in the Dec 2017 (#329) issue.