3

So I'm planning on making an arcade style machine using a raspberry pi. Doing this will require some inputs like up, down, left, right, start etc. Exactly how would I go about doing this. Can the input be passed directly from the button to the pi, or would it have to go through something else first to turn it into something like a USB output? The model of Raspberry Pi is: Model B+ V1.

migrated from electronics.stackexchange.com Feb 22 '16 at 23:20

This question came from our site for electronics and electrical engineering professionals, students, and enthusiasts.

  • The pi has some normal digital IO that you can use. What sort of machine are you making? Do you need the pi to drive outputs? – user1582568 Feb 22 '16 at 22:38
  • 1
    Typically you want to use a USB HID Keyboard or Gamepad/Joystick setup. Otherwise you are looking at 16-24 gpio buttons and low level coding. – cde Feb 22 '16 at 23:00
  • Have a look at raspberrypi.org/learning/python-quick-reaction-game/worksheet This shows how to connect push button switches to the GPIO pins of the Raspberry Pi, and how to read the switches using Python (a programming language). – Steve G Feb 22 '16 at 23:29
  • Also have a look at the "sense hat". – pjc50 Feb 23 '16 at 10:22
5

The Raspberry Pi has a header which contains many GPIO (General-Purpose I/O) pins that can be controlled directly from software on the Pi. These pins can be configured as outputs or as inputs (which is what you'd need for your buttons).

You'll have to deal with contact bouncing, which means you'll have to learn about debouncing. There's an elaborate article on the subject I found extremely helpful.

Other approaches are possible, such as attaching a USB GPIO extender (example) or a microcontroller that you program to deal with the inputs/outputs. Both approaches add cost and complexity though, so you're probably better off starting with the Pi GPIOs, that's what they're for anyway :)

Using an external microcontroller does have the advantage that you can program it to deal with debouncing or other I/O issues (such as PWM, blinking, analog inputs, etc), freeing up your Pi for game stuff. So there are definitely use cases for this approach too.

You might also want to have a look at this related SO question which attracted several good answers.

3

I wrote a device tree overlay that uses a device called gpio-keys that does de-bounce, keyboard input etc. A "compatible" statement below. I had six keys: 4 arrows, enter, and home. My device tree source(DTS) also had a rotary encoder called wheel in the source code that you can ignore. I add /soc/gpio overlays to add pull-ups on the GPIO pins.

/*
 * wheelhat-overlay.dts
 */

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";

    fragment@0 {
        target-path = "/soc/gpio";
        __overlay__ {
            keypad_pins: keypad_pins {
                brcm,pins = <5 6 17 19 22 26>;
                brcm,function = <0>;
                brcm,pull = <2>;
            };
            wheel_pins: wheel_pins {
                brcm,pins = <13 27>;
                brcm,function = <0>;
                brcm,pull = <2>;
            };
        };
    };

    fragment@1 {
        target-path = "/soc";
        __overlay__ {
            wheel: wheel {
                compatible = "rotary-encoder";
                #address-cells = <1>;
                #size-cells = <0>;
                pinctrl-names = "default";
                pinctrl-0 = <&wheel_pins>;
                gpios = <&gpio 13 1>, <&gpio 27 1>; 
                linux,axis = <0>; /* REL_X */
                rotary-encoder,relative-axis;
            };
            keypad: keypad {
                compatible = "gpio-keys";
                #address-cells = <1>;
                #size-cells = <0>;
                pinctrl-names = "default";
                pinctrl-0 = <&keypad_pins>;
                autorepeat;

                button5: button5 {
                    label = "GPIO KEY_UP";
                    linux,code = <22>;
                    gpios = <&gpio 5 1>;
                };
                button19: 9button19 {
                    label = "GPIO KEY_DOWN";
                    linux,code = <32>;
                    gpios = <&gpio 19 1>;
                };
                button26: button26 {
                    label = "GPIO KEY_LEFT";
                    linux,code = <38>;
                    gpios = <&gpio 26 1>;
                };
                button22: button22 {
                    label = "GPIO KEY_RIGHT";
                    linux,code = <19>;
                    gpios = <&gpio 22 1>;
                };
                button17: button17 {
                    label = "GPIO KEY_HOME";
                    linux,code = <35>;
                    gpios = <&gpio 17 1>;
                };
                button6: button6 {
                    label = "GPIO KEY_ENTER";
                    linux,code = <18>;
                    gpios = <&gpio 6 1>;
                };
            };
        };
    };
    __overrides__ {
        up_key_code =    <&button5>,"linux,code:0";
        enter_key_code = <&button6>,"linux,code:0"; // center
        home_key_code =  <&button17>,"linux,code:0"; // corner
        down_key_code =  <&button19>,"linux,code:0";
        right_key_code = <&button22>,"linux,code:0";
        left_key_code =  <&button26>,"linux,code:0";
        relative_axis =  <&wheel>,"rotary-encoder,relative-axis";
        linux_axis =  <&wheel>,"linux,axis";
        rollover =  <&wheel>,"rotary-encoder,rollover";
        half-period =  <&wheel>,"rotary-encoder,half-period";
        steps =  <&wheel>,"rotary-encoder,steps";
    };
};

The overrides are used to set the keyboard codes for the buttons. In /boot/config/txt:

dtoverlay=wheelhat
dtparam up_key_code=72
dtparam down_key_code=80
dtparam left_key_code=75
dtparam right_key_code=77
dtparam enter_key_code=76
dtparam home_key_code=71

In the end it was implemented easily with the device tree, but learning the device tree in bits and pieces took a long time. Finding how to do pull-ups alone took weeks. To do a true Pi Hat, though, you have to have device tree blob(DTB) in an EEPROM on the hat.

0

There is few few thing to consider about such a development on a Raspberry pi. If you want to learn and have fun it is definitely a great project and you will have fun doing it but here is what I would consider. Most arcade games dont just use simple button, lots of them have potentiometer that require analog input and it is usually one per axis (joystick). Pi dont have analog input to read them. You could always recycle an old Nintendo 8 bytes controller and use the arrows. Then you would need at least a few buttons lets say A and B with Select and Start. so just for your controls you used up a lot of the pins available to you and you dont have much left but its ok we can manage that.

After that I would consider what kind of graphics you would like on your game. For a flat 2D game that you would program your self it will do the job. But if we are talking fast past game play with 3D well... you might find yourself with a project that will stay a project. But here is what I suggest. The idea of the game with a controller is nice and why not use the "still" potent power of an old P4 that will remain cheap and give you wider game play possibility. You can still build an awesome new kind of controller and custom design the box where it will all fit in to. I think that the raspberry Pi, as well as the Arduino, are good to explorer numerical world and behavior but they bring a regular PC a notch higher connecting your ideas to the physical world.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy