OpenBSD Journal

[h2k8]: Now Generally Useful: OpenBSD's GPIO Subsystem

Contributed by mitja on from the dancing-on-the-tip-of-a-pin dept.

Marc Balmer (mbalmer@) writes in from h2k8 about a major change in the GPIO subsystem that he just committed:

OpenBSD has had support for General Purpose Input/Output devices since the 3.6 release. GPIO devices, or gpios for short, provide an easy way to interface electronic circuits which can be as simple as a LED or that provide more complex functionality like a 1-Wire or I2C bus.

The GPIO implementation in OpenBSD 3.6 up to and including 4.4, however, has some problems and drawbacks which made me rework larger parts of this subsystem during the h2k8 hardware hackathon in Coimbra, Portugal.

The full story can be found here.

(Comments are closed)

Comments

  1. By David Chisnall (82.7.199.50) on

    I played a bit with gpio on my WRAP (Soekris-like board) and it was easy to make the three lights on the front flash from a script. I hacked together something quickly that would poll the status of the network links and turn the lights on and off to reflect this, but I wonder if there is an easy way of making them flash when there is network traffic.

    Comments

    1. By Anonymous Coward (84.166.91.245) on

      > [..] , but I wonder if there is an easy way of making them flash when
      > there is network traffic.

      $ cd /usr/ports/sysutils/gpioflicker
      $ sudo make install

  2. By pkplex (pkplex) pkplex@orcon.net.nz on http://127.0.0.1

    Pondering doing i2c using GPIO pins.. is there a built in library that I can use for this, or is it a roll your own type thing?

    Comments

    1. By Damien Miller (djm) on http://www.mindrot.org/~djm/

      > Pondering doing i2c using GPIO pins.. is there a built in library that
      > I can use for this, or is it a roll your own type thing?

      man 4 iic
      man 4 gpioiic

      I2C drivers live in kernel-space, but a really easy to write (I'm not a kernel guy and I still managed to write a couple).

  3. By Anonymous Coward (208.181.67.27) on

    Would it be possible to use this to make a poor man's version of fancontrol? Is there an OpenBSD fancontrol scheme? How would I figure out what to poke at to control the fans on a random board? Can Linux bricabrac be examined for info?

    Comments

    1. By Anonymous Coward (219.90.217.111) on

      The most reliable thing would be to get a pin description for the CPU/SOC. Then trace the tracks you are interested in back to the chip.
      Of course, that could be quite invasive on a running system and/or impracticable due to the board layout.

      You could also try poking each of the gpios in turn to see what happens.

      Comments

      1. By Anonymous Coward (208.181.67.27) on

        That would be fairly difficult with the board in question.
        Would this be the preferred method for implementing something like this, or is there a more sane method for fan control on OpenBSD? Google is oddly silent on this issue...

        Comments

        1. By Anonymous Coward (219.90.217.111) on

          Are you sure the fans are controllable? You can probably read fan speed with the sensors framework (i would expect this to be attached to an i2c bus), but the speed is more likely to be controlled by a thermistor on the board.

          Comments

          1. By sthen (2a01:348:108:155:216:41ff:fe53:6a45) on

            > Are you sure the fans are controllable? You can probably read fan speed with the sensors framework (i would expect this to be attached to an i2c bus), but the speed is more likely to be controlled by a thermistor on the board.

            Some sensor chips (sometimes I²C, sometimes ISA) have fan speed controllers, you should be able to find this out by looking at the data sheets. But they won't always be wired up, or safe to use if they are connected.

            It might make more sense to interface with them via ACPI though.

      2. By sthen (2a01:348:108:155:216:41ff:fe53:6a45) on

        > The most reliable thing would be to get a pin description for the CPU/SOC. Then trace the tracks you are interested in back to the chip.
        > Of course, that could be quite invasive on a running system and/or impracticable due to the board layout.
        >
        > You could also try poking each of the gpios in turn to see what happens.

        Check the comment in theo.c about gpio.

        On some systems randomly poking gpio pins is a Really Bad Idea<tm>. For example some powerpc-based systems use it to configure the system (cpu speed, bus speed and so on).

        See why it's moved to securelevel?

        Comments

        1. By Anonymous Coward (208.181.67.27) on

          "You are in a maze of gpio pins, all alike, all undocumented, and a few are wired to bombs."

          http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c?rev=1.105;content-type=text%2Fplain

    2. By Daniel Gracia (paladdin) on http://www.alpuntodesal.com

      > Would it be possible to use this to make a poor man's version of fancontrol? Is there an OpenBSD fancontrol scheme? How would I figure out what to poke at to control the fans on a random board? Can Linux bricabrac be examined for info?

      PWM is the answer. As fans are quite slow changing speed, you don't need a very high frequency rate to achieve a practical result.

      In this case, let's put a little routine that is timed to execute every 10ms. This routine has a counter that runs until 20, for example, then resets to 0.

      All you have to do to control the fan speed is turn your output on from 0 to x, being x relative to the speed you desire. The rest of the time until counter overflows you have to turn output off... And that's all.

      Basics electronic -just a resistor and a transistor, maybe 20cents-, a wire from your GPIO output, and you're done :)

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]