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

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

Hello again,
recently i made some changes, to the original idea, i’m happy with.

https://github.com/elewarr/plan9-bcm (Readme.md presents some samples)
https://github.com/elewarr/gpio_test

I have a plan to write some code for simple examples. And, i hope, something more.

This is based on Bell Labs Plan9. I managed to get RPi working via u9fs (thank you for the tip), works pretty well.

Cheers,
Krystian

Wiadomość napisana przez erik quanstrom <quanstro@quanstro.net> w dniu 1 sty 2014, o godz. 23:16:

> On Tue Dec 31 12:47:30 EST 2013, krystian.lew@gmail.com wrote:
>> 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’t see any specific precautions there.
>> 
>> I’m trying to learn something - including BCM and Plan 9, i don’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” 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’m asking because i have 9front on my laptop and i’d like to build BCM kernel there, and so i thought maybe i could use 9pi from 9front image instead, but i’d like to know what is the status.
>> 
>> Thank you,
>> Krystian
>> 
>> Wiadomość napisana przez California Electric <californiaelectric@gmail.com> w dniu 30 gru 2013, o godz. 02:47:
> 
> the problem with the encoding of this email has been fixed.  iso-2022-jp-2 should
> now be properly recognized.  /n/atom/patch/tcs2022-jp-2
> 
> there are several further extensions which mostly embed multibyte characters, but 
> i'm ignoring them for now.
> 
> - erik
>