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

[Krystian Lewandowski <krystian.lew@gmail.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 5783 bytes --]

Thank you for the feedback,
i think "ctl" file and numbering scheme selection could do the job. And maybe it could help to establish reasonable base for SPI and others.

Is it safe to just generate new dev tree - to return either BCM, WiringPi or board pin set - based on pin numbering scheme selection made by user? What will happen if a process would try o read/write from/to pin when numbering scheme is changed? I tried to look at devproc.c (what would happen when process dies and something is reading its /proc entries) but i can^[.F^[N"t see any specific precautions there.

I^[.F^[N"m trying to learn something - including BCM and Plan 9, i don^[N"t feel very confident. But this Plan 9 BCM port really deserves more attention. :) I appreciate any help or feedback.

Regarding ISRs - this is not implemented yet. Polling at the moment is the only option. But maybe "events^[$B!I^[(B file, with data populated by interrupt routine would be the answer. Is it correct Plan 9 way of doing things? QIO looks very suitable for this purpose.

I tried to look at 9front BCM tree, it seems to be a bit different (no fakertc device for example) from the one at Bell Labs, is it by purpose or just trees are not synched? I^[.F^[N"m asking because i have 9front on my laptop and i^[N"d like to build BCM kernel there, and so i thought maybe i could use 9pi from 9front image instead, but i^[N"d like to know what is the status.

Thank you,
Krystian

Wiadomo^[$(D+\++^[(B napisana przez California Electric <californiaelectric@gmail.com> w dniu 30 gru 2013, o godz. 02:47:

> Krystian,
> 
> This is exciting.
> 
> I think it might be overkill to have the three separate tree structures for the numbering scheme. It's more typical in pi hacking to make call to set the numbering scheme and then go from there.
> 
> I like that you've accounted for the pull up/down function.
> 
> I do wonder though if it's better form to write to a ctl file in /dev/gpio specifying in/out and pull down/up/off  for a given pin, as in:
> 
> % echo wpi >/dev/gpio/ctl
> % echo 1 in up >/dev/gpio/ctl 
> 
> In order to set the numbering scheme, and set pin 1 as an input with pull up
> 
> Greg
> 
> Sent from my iPhone
> 
>> On Dec 29, 2013, at 2:04 PM, Krystian Lewandowski <krystian.lew@gmail.com> wrote:
>> 
>> Good evening,
>> i^[.F^[N"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^[.F^[N"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^[.F^[N" /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^[$B!I^[(B)
>> - select pin pull state:
>>   % echo pull up > /dev/gpio/board/GPIO0
>> (possible pull states are: "off", "down", "up^[$B!I^[(B)
>> 
>> This is completely untested. I^[.F^[N"m still waiting for cables and breadboard, i don^[N"t want to play with pins until i^[N"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^[.F^[N"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^[.F^[N"t test serial console connection i didn^[N"t touch it
>> 3. Is #G/gpio scheme OK (unreserved, correct)?
>> 4. Events are not supported
>> 
>> Greetings,
>> Krystian