Re: [9fans] "gpio device" for Plan 9

[Shane Morris <edgecomberts@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4548 bytes --]

This is pretty cool! Good work!

I have a question - what would the maximum ISR rate be for a rising edge of
a square wave sampled on one of the GPIO pins? At the link:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=72&t=33113

Its quoted to be 10,000 events per second using a standard ISR. Of course,
thats under Linux. It also says it can be 100,000 events per second using a
modified ISR, but I only need to sample the rising edge of a 10kHz square
wave.

Lastly, I hope this email is seen by the list - "When it is all mouth, and
no ears, its known as an 'alligator'..."


On Mon, Dec 30, 2013 at 6:32 PM, Skip Tavakkolian <
skip.tavakkolian@gmail.com> wrote:

> 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 <
> krystian.lew@gmail.com> 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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 5793 bytes --]