Skip to main content
Android mainboards · Touch displays · Firmware — since 2013
LUMA AI StudioStart a project

GPIO

Static methodsSet: broadcast · Get: sysfs read

Control the general-purpose pins. Outputs are driven with a broadcast; reads come back synchronously from a device file.

The pin is selected by a two-character string code, not a pin number argument. This is the least obvious part of the API, so read the encoding below before you write anything.

Set a pin as output (and drive it)​

public static void setGpioOut(Context context)

The pin and level are chosen by the "value" the broadcast carries. The code is two characters: first digit = GPIO index, second digit = level.

valueMeaning
"00"GPIO0 → output LOW
"01"GPIO0 → output HIGH
"10"GPIO1 → output LOW
"11"GPIO1 → output HIGH
"20"GPIO2 → output LOW
"21"GPIO2 → output HIGH
Selecting a pin other than GPIO0

The setGpioOut(context) helper drives GPIO0 low. To target a different pin or drive it high, send the broadcast directly with the code you need:

Intent intent = new Intent("android.intent.item.gpio.a0.set");
intent.putExtra("value", "11");   // GPIO1 → HIGH
context.sendBroadcast(intent);

The parameterised helper form is being finalised — until then, use the direct broadcast above for per-pin control.

Switch a pin to input​

public static void setGpioInput(Context context)

Same encoding, but the level digit is unused — only the GPIO index matters.

valueMeaning
"00"GPIO0 → input
"10"GPIO1 → input
"20"GPIO2 → input

For a pin other than GPIO0, send the direction broadcast directly:

Intent intent = new Intent("android.intent.item.gpio.a0.direction");
intent.putExtra("value", "10");   // GPIO1 → input
context.sendBroadcast(intent);

Read a pin​

Unlike everything else in this API, the getters return a value immediately.

public static String getGpio0()   // "0", "1", or "getGpio0 failed!"
public static String getGpio1()
public static String getGpio2()
String level = ItempApiPub.getGpio0();
if ("1".equals(level)) {
    // pin is high
}

How the read actually works​

The getters do not send a broadcast. They read a single line from a device file and split it on commas:

/sys/class/mynode_class/mynode_device/gpiovalue

The file returns a comma-separated list — getGpio0 is the first field, getGpio1 the second, and so on. Two things follow from that:

  • The number of readable pins is whatever that file exposes. The reference source shows getGpio0 through getGpio2 and then //..., meaning more getters follow the same pattern. Check the file on your board to see how many fields it actually returns.
  • A failed read returns the string "getGpioN failed!", not an exception. Always compare against "0" / "1" explicitly rather than assuming any non-empty string means high.

Notes​

Set direction before you read. A pin left as output reads back its driven level, not an external signal. Call setGpioInput for that pin first.

No hardware debounce. A mechanical contact produces several transitions per press. If you poll getGpioN in a loop, ignore changes within ~20 ms of the last one.

Levels are logic states, not voltages. Confirm the electrical level and current limit for the header on your board page before wiring anything to it.

  • Board pages — which physical header pin maps to GPIO0/1/2
  • Overview — the broadcast model these set-calls use