Changes between Version 1 and Version 2 of OpenWrt/gpio


Ignore:
Timestamp:
02/27/2018 04:14:02 PM (7 years ago)
Author:
Tim Harvey
Comment:

removed deprecated gpioctl

Legend:

Unmodified
Added
Removed
Modified

  • OpenWrt/gpio

    v1 v2  
    1010This framework allows kernel board-support to define GPIO configuration (direction, direction-changeable, user-friendly name, state, and userspace configurable). The benefit of this standard method is:
    1111 1. its a linux standard
    12  2. it allows you to configure GPIO's in such a way that users don't have the ability to change them to invalid states per hardware design (although OpenWrt {{{gpioctl}}} defeats this protection)
     12 2. it allows you to configure GPIO's in such a way that users don't have the ability to change them to invalid states per hardware design
    1313 3. it allows you to name gpio's with a user-friendly name
    1414
    1515For details on using the Linux gpio class from userspace see the [wiki:gpio#gpiolib gpio] page.
    16 
    17 [=#gpioctl]
    18 == OpenWrt gpioctl - NOW DEPRECATED ==
    19 The older method of controlling GPIO's used by OpenWrt was the {{{gpioctl}}} userspace utility and the kernel driver ({{{package/feeds/packages/gpiotoggling}}}). This was is an OpenWrt creation (as opposed to a 'linux standard' driver/API). It has the benefit (or downside depending on your point of view) of having 'full control' over the GPIO's even if the user should not. It was created at a time where linux-gpio was changing and lacked some standardization.
    20 
    21 The downside of this application/API:
    22  1. it is not linux standard (It has been removed from current OpenWrt trunk and thus won't be present in future Gateworks firmware)
    23  2. it does not allow you to determine the current configuration mode of a pin (input/output)
    24  3. it is not as easy to script (need to use sed/awk/grep)
    25  4. it can override GPIO configuration in cases where board-support does not wish to allow you to do so
    26 
    27 This driver/application can be useful however if a GPIO is not configured/exported correctly in the kernel and it can co-exist just fine with the more standard gpio-class mechanism shown below.
    28 
    29 Example usage:
    30 {{{
    31 #!bash
    32 # configure gpio8 as an input
    33 gpioctl dirin 8
    34 
    35 # get current state of gpio8
    36 gpioctl get 8
    37 
    38 # configure gpio8 as an output
    39 gpioctl dirout 8
    40 
    41 # set gpio8 state
    42 gpioctl set 8 ;# high
    43 gpioctl clear 8 ;# low
    44 }}}
    4516
    4617
    … …  
    7445[=#button-hotplug-gw]
    7546== OpenWrt gpio-button-hotplug driver ==
    76 Our modern OpenWrt based BSP's use OpenWrt {{{procd}}} as PID1. One of {{{procd}}}'s features is to catch messages from the kernel and act upon them, much in the way a conventional linux system uses a hotplug helper and udev. The {{{/etc/hotplug.json}}} file configures how various events are handled:
     47OpenWrt uses a home-grown app called {{{procd}}} as PID1. One of {{{procd}}}'s features is to catch messages from the kernel and act upon them, much in the way a conventional linux system uses a hotplug helper and udev. The {{{/etc/hotplug.json}}} file configures how various events are handled:
    7748 * using makedev to create device nodes in /dev on 'add' events and removing the nodes on 'remove' events
    7849 * facilitate firmware loading