|
1 | 1 | .. _gpio_api: |
2 | 2 |
|
3 | | - |
4 | 3 | General-Purpose Input/Output (GPIO) |
5 | 4 | ################################### |
6 | 5 |
|
7 | 6 | Overview |
8 | 7 | ******** |
9 | 8 |
|
| 9 | +The GPIO API provides a generic method to interact with General Purpose Input/Output (GPIO) |
| 10 | +pins. It allows applications to configure pins as inputs or outputs, read and write |
| 11 | +their state, and manage interrupts. Key features include: |
| 12 | + |
| 13 | +**Pin Configuration** |
| 14 | + Configure pins as input, output, or disconnected. |
| 15 | + Support for internal pull-up/pull-down resistors and drive strength configuration. |
| 16 | + |
| 17 | +**Data Access** |
| 18 | + Read input values and write output values. |
| 19 | + |
| 20 | +**Interrupts** |
| 21 | + Configure interrupts on pin state changes (rising edge, falling edge, |
| 22 | + level low, level high) and register callbacks to handle these interrupts. |
| 23 | + |
| 24 | +**Devicetree Integration** |
| 25 | + GPIOs are typically defined in the Devicetree, allowing |
| 26 | + drivers and applications to reference them in a hardware-agnostic way using |
| 27 | + :c:struct:`gpio_dt_spec`. |
| 28 | + |
| 29 | +Devicetree Configuration |
| 30 | +************************ |
| 31 | + |
| 32 | +GPIO controllers are defined in the Devicetree as nodes with the ``gpio-controller`` property. |
| 33 | +The ``#gpio-cells`` property typically specifies that 2 cells are used to describe a GPIO: the pin |
| 34 | +number and the flags. |
| 35 | + |
| 36 | +Example of a GPIO controller definition: |
| 37 | + |
| 38 | +.. code-block:: devicetree |
| 39 | +
|
| 40 | + gpio0: gpio@40022000 { |
| 41 | + compatible = "ti,cc13xx-cc26xx-gpio"; |
| 42 | + reg = <0x40022000 0x400>; |
| 43 | + interrupts = <0 0>; |
| 44 | + gpio-controller; |
| 45 | + #gpio-cells = <2>; |
| 46 | + }; |
| 47 | +
|
| 48 | +Example of referencing a GPIO: |
| 49 | + |
| 50 | +.. code-block:: devicetree |
| 51 | +
|
| 52 | + leds { |
| 53 | + compatible = "gpio-leds"; |
| 54 | + led0: led_0 { |
| 55 | + gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>; |
| 56 | + label = "Green LED"; |
| 57 | + }; |
| 58 | + }; |
| 59 | +
|
| 60 | +Basic Operation |
| 61 | +*************** |
| 62 | + |
| 63 | +GPIO operations are usually performed on a :c:struct:`gpio_dt_spec` structure, which is a container |
| 64 | +for the GPIO pin information specified in the Devicetree. |
| 65 | + |
| 66 | +This structure is typically populated using :c:macro:`GPIO_DT_SPEC_GET` macro (or any of its |
| 67 | +variants). |
| 68 | + |
| 69 | +.. code-block:: c |
| 70 | + :caption: Populating a gpio_dt_spec structure for a GPIO pin defined as alias ``led0`` |
| 71 | +
|
| 72 | + #define LED0_NODE DT_ALIAS(led0) |
| 73 | + static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios); |
| 74 | +
|
| 75 | +The :c:struct:`gpio_dt_spec` structure can then be used to perform GPIO operations. |
| 76 | + |
| 77 | +.. code-block:: c |
| 78 | + :caption: Configuring a GPIO pin (``led`` from the previous snippet) as output and setting it |
| 79 | + to its active level |
| 80 | +
|
| 81 | + int ret; |
| 82 | +
|
| 83 | + ret = gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE); |
| 84 | + if (ret < 0) { |
| 85 | + return ret; |
| 86 | + } |
| 87 | +
|
| 88 | + ret = gpio_pin_set_dt(&led, 1); |
| 89 | + if (ret < 0) { |
| 90 | + return ret; |
| 91 | + } |
| 92 | +
|
| 93 | +Refer to :zephyr:code-sample:`blinky` for a complete example of basic operations on GPIOs using the |
| 94 | +:c:struct:`gpio_dt_spec` structure. |
| 95 | + |
| 96 | +GPIO operations can also be performed directly on a GPIO controller device, in which case you will |
| 97 | +use the GPIO API functions that take a device pointer as an argument. For example |
| 98 | +:c:func:`gpio_pin_configure` instead of :c:func:`gpio_pin_configure_dt`. |
| 99 | + |
| 100 | +GPIO Hogs |
| 101 | +********* |
| 102 | + |
| 103 | +GPIO hogs provide a mechanism to automatically configure GPIO pins during system initialization. |
| 104 | +This is useful for pins that need to be set to a specific state (e.g., reset lines, power enables) |
| 105 | +and don't require runtime control by an application. |
| 106 | + |
| 107 | +Hogs are defined in the Devicetree as children of a GPIO controller node. |
| 108 | + |
| 109 | +- The ``gpio-hog`` property marks the node as a hog. |
| 110 | +- The ``gpios`` property specifies the pin and its active state. |
| 111 | +- One of ``input``, ``output-low``, or ``output-high`` properties specifies the configuration. |
| 112 | + |
| 113 | +Example Devicetree overlay: |
| 114 | + |
| 115 | +.. code-block:: devicetree |
| 116 | +
|
| 117 | + &gpio0 { |
| 118 | + hog1 { |
| 119 | + gpio-hog; |
| 120 | + gpios = <1 GPIO_ACTIVE_LOW>; |
| 121 | + output-high; |
| 122 | + }; |
| 123 | +
|
| 124 | + hog2 { |
| 125 | + gpio-hog; |
| 126 | + gpios = <2 GPIO_ACTIVE_HIGH>; |
| 127 | + output-low; |
| 128 | + }; |
| 129 | + }; |
| 130 | +
|
| 131 | +If you need runtime control of a pin configured as a hog beyond the initial state being |
| 132 | +automatically set during system initialization, you may consider using the :ref:`regulator_api` |
| 133 | +instead, with a :dtcompatible:`regulator-fixed` Devicetree node. |
| 134 | + |
10 | 135 | Configuration Options |
11 | 136 | ********************* |
12 | 137 |
|
13 | | -Related configuration options: |
| 138 | +Main configuration options: |
14 | 139 |
|
15 | 140 | * :kconfig:option:`CONFIG_GPIO` |
| 141 | +* :kconfig:option:`CONFIG_GPIO_SHELL` |
| 142 | +* :kconfig:option:`CONFIG_GPIO_GET_DIRECTION` |
| 143 | +* :kconfig:option:`CONFIG_GPIO_GET_CONFIG` |
| 144 | +* :kconfig:option:`CONFIG_GPIO_HOGS` |
| 145 | +* :kconfig:option:`CONFIG_GPIO_ENABLE_DISABLE_INTERRUPT` |
16 | 146 |
|
17 | 147 | API Reference |
18 | 148 | ************* |
|
0 commit comments