nice. i guess i'll need to get a Pi T-Cobbler and try it.


On Sun, Dec 29, 2013 at 2:04 PM, Krystian Lewandowski <
[email protected]> wrote:

> Good evening,
> i’d like to share with you some Raspberry Pi related work done for Plan 9
> BCM port.
>
> Using slightly modified (unmodified in most cases) uartmini.c GPIO
> functions i implemented #G/gpio device:
> Structure is as follows:
> #G/gpio/
>         /bcm/ ...
>         /board/ ...
>         /wpi/ ...
>         /OK
>
> - bcm uses board revision specific pin numbering
> - board uses human readable pin addressing (board revision agnostic)
> - wpi uses wiringPi pin assignment (board revision agnostic)
> - OK pin can be used to switch on/off OK LED on the board
>
> Each directory above contains files that are mapped to pins.
> Maybe it is an overkill, i don’t know.
>
> I used this page as reference for pin assignments:
> https://projects.drogon.net/raspberry-pi/wiringpi/pins/
>
> % du -a
> 0       ./bcm/0
> 0       ./bcm/1
> 0       ./bcm/4
> 0       ./bcm/7
> 0       ./bcm/8
> 0       ./bcm/9
> 0       ./bcm/10
> 0       ./bcm/11
> 0       ./bcm/14
> 0       ./bcm/15
> 0       ./bcm/16
> 0       ./bcm/17
> 0       ./bcm/18
> 0       ./bcm/21
> 0       ./bcm/22
> 0       ./bcm/23
> 0       ./bcm/24
> 0       ./bcm/25
> 0       ./bcm
> 0       ./board/SDA
> 0       ./board/SCL
> 0       ./board/GPIO7
> 0       ./board/CE1
> 0       ./board/CE0
> 0       ./board/MISO
> 0       ./board/MOSI
> 0       ./board/SCLK
> 0       ./board/TxD
> 0       ./board/RxD
> 0       ./board/GPIO0
> 0       ./board/GPIO1
> 0       ./board/GPIO2
> 0       ./board/GPIO3
> 0       ./board/GPIO4
> 0       ./board/GPIO5
> 0       ./board/GPIO6
> 0       ./board
> 0       ./wpi/8
> 0       ./wpi/9
> 0       ./wpi/7
> 0       ./wpi/11
> 0       ./wpi/10
> 0       ./wpi/13
> 0       ./wpi/12
> 0       ./wpi/14
> 0       ./wpi/15
> 0       ./wpi/16
> 0       ./wpi/0
> 0       ./wpi/1
> 0       ./wpi/2
> 0       ./wpi/3
> 0       ./wpi/4
> 0       ./wpi/5
> 0       ./wpi/6
> 0       ./wpi
> 0       ./OK
> 0       .
>
> Reference:
> - mount gpio:
>         % bind -a '#G’ /dev
> - read pin state:
>         % cat /dev/gpio/board/GPIO0
> - write pin state:
>         % echo 1 > /dev/gpio/board/GPIO0
>         % echo 0 > /dev/gpio/board/GPIO0
> - select pin function:
>         % echo func out > /dev/gpio/board/GPIO0
> (possible functions are: "in", "out", "f5", "f4", "f0", "f1", "f2", "f3”)
> - select pin pull state:
>         % echo pull up > /dev/gpio/board/GPIO0
> (possible pull states are: "off", "down", "up”)
>
> This is completely untested. I’m still waiting for cables and breadboard,
> i don’t want to play with pins until i’ll have it. Though OK pin (LED)
> seems to behave.
> Maybe something in this implementation is wrong or has no sense at all? If
> anyone would like to try to play with it, here is the commit (also includes
> /dev/cputemp i sent to this list some time ago). I don’t want to send the
> patch yet.
>
> https://github.com/elewarr/plan9-bcm/commit/18f1c470d1e16a63a55761094f723c2bd91b576d
> Please remember it is not tested - use it at your own risk.
>
> Other things:
> 1. OK LED is also used by emmc.c (search for okay(int))
> 2. devgpio.c keeps its own version of some GPIO related functions(gpio
> in/out, function selection, pull up/down state) defined in uartmini.c - it
> should probably be removed from uartmini.c but because i can’t test serial
> console connection i didn’t touch it
> 3. Is #G/gpio scheme OK (unreserved, correct)?
> 4. Events are not supported
>
> Greetings,
> Krystian
>

Reply via email to