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 <quans...@quanstro.net> w dniu 1 sty 2014, o godz. 23:16: > On Tue Dec 31 12:47:30 EST 2013, krystian....@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 <californiaelect...@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 >
