[9fans] "gpio device" for Plan 9

[9fans] "gpio device" for Plan 9

[Krystian Lewandowski]

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

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

[erik quanstrom]

> 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.

first off, cool!

#G seems fine to me.

 it might be just as well to just export only the board wiring, letting
something in the boot-time configuration set this up.

seems worth implementing uartmini (and spi) on top, and allowing group
pin allocation to support this.

- erik

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

[Skip Tavakkolian]

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

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: 4557 bytes --]

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

[Shane Morris]

[-- 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 --]

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

[Krystian Lewandowski]

[-- 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

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

[erik quanstrom]

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^[.F^[N"t see any specific
> precautions there.

(sorry about the funny formatting.  the header specifies
	Content-Type: text/plain; charset=iso-2022-jp-2
which might be the same as iso-2022-jp, but i haven't tracked this down yet.)

there is a 1 character argument to attach.  you can avoid the issue
by letting the attach argument specify which scheme you'd like, e.g.:

	mount -a '#Gx' /dev

> 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.

"long" reads are an established way to avoid polling.  plan 9
was doing this long before i'd heard the term.  the network drivers
work this way.

- erik

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

[Shane Morris]

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

Erik,

Just for the purposes of edification (and curiosity), are you able to
elaborate on "long reads"? Its understandable such a scheme would be
implemented in the network drivers, but how exactly does it work, as
opposed to a polling scheme or an ISR? I will, of course, Google in a sec
as well.

Many thanks!


On Wed, Jan 1, 2014 at 6:18 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> 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�♯ see any specific
> > precautions there.
>
> (sorry about the funny formatting.  the header specifies
>         Content-Type: text/plain; charset=iso-2022-jp-2
> which might be the same as iso-2022-jp, but i haven't tracked this down
> yet.)
>
> there is a 1 character argument to attach.  you can avoid the issue
> by letting the attach argument specify which scheme you'd like, e.g.:
>
>         mount -a '#Gx' /dev
>
> > 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.
>
> "long" reads are an established way to avoid polling.  plan 9
> was doing this long before i'd heard the term.  the network drivers
> work this way.
>
> - erik
>
>

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

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

[Skip Tavakkolian]

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

i won't answer for Erik, but...

there is nothing magic about "long" reads. basically you create multiple
proc's (i.e. rfork) and dedicate one to the reader function. ioproc(2)
library takes care of the housekeeping nicely; also the man page has an
example.



On Tue, Dec 31, 2013 at 11:37 AM, Shane Morris <edgecomberts@gmail.com>wrote:

> Erik,
>
> Just for the purposes of edification (and curiosity), are you able to
> elaborate on "long reads"? Its understandable such a scheme would be
> implemented in the network drivers, but how exactly does it work, as
> opposed to a polling scheme or an ISR? I will, of course, Google in a sec
> as well.
>
> Many thanks!
>
>
> On Wed, Jan 1, 2014 at 6:18 AM, erik quanstrom <quanstro@quanstro.net>wrote:
>
>> 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�♯ see any specific
>> > precautions there.
>>
>> (sorry about the funny formatting.  the header specifies
>>         Content-Type: text/plain; charset=iso-2022-jp-2
>> which might be the same as iso-2022-jp, but i haven't tracked this down
>> yet.)
>>
>> there is a 1 character argument to attach.  you can avoid the issue
>> by letting the attach argument specify which scheme you'd like, e.g.:
>>
>>         mount -a '#Gx' /dev
>>
>> > 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.
>>
>> "long" reads are an established way to avoid polling.  plan 9
>> was doing this long before i'd heard the term.  the network drivers
>> work this way.
>>
>> - erik
>>
>>
>

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

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

[erik quanstrom]

On Tue Dec 31 14:40:29 EST 2013, edgecomberts@gmail.com wrote:

> Erik,
>
> Just for the purposes of edification (and curiosity), are you able to
> elaborate on "long reads"? Its understandable such a scheme would be
> implemented in the network drivers, but how exactly does it work, as
> opposed to a polling scheme or an ISR? I will, of course, Google in a sec
> as well.

it could be that i misunderstood the op's point.  what i understood from the
original post was a scheme was envisioned where a user process would poll a
status file to get interrupt status.  if i understood this correctly, then providing
an interrupt file that returns even 0 bytes when there's an interrupt would be
an alternative providing interrupt semantics to the up.  there are some
bits to work out if the user process falls behind, but it's no different than a
network device.

does that answer your question?

- erik

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

[Shane Morris]

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

Certainly, that answers my question.

Of things interrelated, I wish to sample a 10kHz square wave into a GPIO,
which I am certain the RPi will do, see my earlier post with link to RPi
forums. This will be a constant signal (an output of a GPSDO, with
potentially a rubidium oscillator backup). So while the 10kHz is constant,
the users input is not, and I wish to correlate in time the users input to
the rising edge of the 10kHz signal, as it is then to be sent over a
network with the time data of the event.

Obviously, one would need to "trim" events (so, no interrupt file of 0
bytes being transmitted) if no user input was received. This is merely to
minimise network overheads.

I could be wildly off here Erik in my way of thinking, but my motivation is
to extend the syncfs module to correlate precisely in time. The example
system used by the Indiana University had no synchronisation across the
network - presumably the only synchronised filesystem was the local
filesystem on the cart robot? I will also be writing some kind of memory
bounding for the ramfs. So, the events themselves are asynchronous and
non-deterministic, however the clock source against which the events are
placed in time is deterministic, and allows for easy reference and auditing.

Perhaps there is a better way of doing this, I am not sure. Remember, I am
an outsider to Plan 9 ways of thinking, although I am mostly unspoiled by
Linux ways of thinking. To be precise, my ways of thinking are MSDOS, if
that is at all possible in this day and age. I accept any and all better
suggestions.


On Wed, Jan 1, 2014 at 6:50 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> On Tue Dec 31 14:40:29 EST 2013, edgecomberts@gmail.com wrote:
>
> > Erik,
> >
> > Just for the purposes of edification (and curiosity), are you able to
> > elaborate on "long reads"? Its understandable such a scheme would be
> > implemented in the network drivers, but how exactly does it work, as
> > opposed to a polling scheme or an ISR? I will, of course, Google in a sec
> > as well.
>
> it could be that i misunderstood the op's point.  what i understood from
> the
> original post was a scheme was envisioned where a user process would poll a
> status file to get interrupt status.  if i understood this correctly, then
> providing
> an interrupt file that returns even 0 bytes when there's an interrupt
> would be
> an alternative providing interrupt semantics to the up.  there are some
> bits to work out if the user process falls behind, but it's no different
> than a
> network device.
>
> does that answer your question?
>
> - erik
>
>

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

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

[erik quanstrom]

> Of things interrelated, I wish to sample a 10kHz square wave into a GPIO,
> which I am certain the RPi will do, see my earlier post with link to RPi
> forums. This will be a constant signal (an output of a GPSDO, with
> potentially a rubidium oscillator backup). So while the 10kHz is constant,
> the users input is not, and I wish to correlate in time the users input to
> the rising edge of the 10kHz signal, as it is then to be sent over a
> network with the time data of the event.
[...]
>
> I could be wildly off here Erik in my way of thinking, but my motivation is
> to extend the syncfs module to correlate precisely in time. The example
> system used by the Indiana University had no synchronisation across the
> network - presumably the only synchronised filesystem was the local
> filesystem on the cart robot? I will also be writing some kind of memory
> bounding for the ramfs. So, the events themselves are asynchronous and
> non-deterministic, however the clock source against which the events are
> placed in time is deterministic, and allows for easy reference and auditing.
>
> Perhaps there is a better way of doing this, I am not sure. Remember, I am
> an outsider to Plan 9 ways of thinking, although I am mostly unspoiled by
> Linux ways of thinking. To be precise, my ways of thinking are MSDOS, if
> that is at all possible in this day and age. I accept any and all better
> suggestions.

it seems that the system timer is already 1mhz.  but i suppose the issue is
that there is no external reference.  do you think you could get .1 ppm
time resolution with ntp between raspberry pis?  if not, i don't think i know
enough about your setup to say much of use other than to note frequency
is not directly related to precision.  if local timing can is stable to .1ppm for
a longish period of time, then a low-frequency strobe of high precision and
known timing could be enough.  the bbc does this with the tone at the top
of the hr.

- erik

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

[Shane Morris]

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

So, in effect, a 1PPS signal would be sufficient to clock second to second?
I suppose it could be, there would be little drift in the oscillator per
the second.

As for NTP, this has been suggested to me, and I acknowledge its place,
certainly. However, I do not wish to tie up network resources in terms of
clocking, and GPS provides me with an independent reference - Navsync
CW12-TIMs can be had for $89, and do not tie up network resources. You
could then say "Ah, but you said a 1PPS is fine... now you're saying 1PPS
via the network isn't?" That is due to a mesh topology being used in the
eventual network, and the bandwidth, latency and propagation issues
inherent in such a network. I wish to dedicate the network wholly and
solely to requisite control data traffic, not superfluous traffic like
clocking, which may not get there in time. Certainly, mine is a complex
undertaking, but one I think can work.


On Wed, Jan 1, 2014 at 9:03 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Of things interrelated, I wish to sample a 10kHz square wave into a GPIO,
> > which I am certain the RPi will do, see my earlier post with link to RPi
> > forums. This will be a constant signal (an output of a GPSDO, with
> > potentially a rubidium oscillator backup). So while the 10kHz is
> constant,
> > the users input is not, and I wish to correlate in time the users input
> to
> > the rising edge of the 10kHz signal, as it is then to be sent over a
> > network with the time data of the event.
> [...]
> >
> > I could be wildly off here Erik in my way of thinking, but my motivation
> is
> > to extend the syncfs module to correlate precisely in time. The example
> > system used by the Indiana University had no synchronisation across the
> > network - presumably the only synchronised filesystem was the local
> > filesystem on the cart robot? I will also be writing some kind of memory
> > bounding for the ramfs. So, the events themselves are asynchronous and
> > non-deterministic, however the clock source against which the events are
> > placed in time is deterministic, and allows for easy reference and
> auditing.
> >
> > Perhaps there is a better way of doing this, I am not sure. Remember, I
> am
> > an outsider to Plan 9 ways of thinking, although I am mostly unspoiled by
> > Linux ways of thinking. To be precise, my ways of thinking are MSDOS, if
> > that is at all possible in this day and age. I accept any and all better
> > suggestions.
>
> it seems that the system timer is already 1mhz.  but i suppose the issue is
> that there is no external reference.  do you think you could get .1 ppm
> time resolution with ntp between raspberry pis?  if not, i don't think i
> know
> enough about your setup to say much of use other than to note frequency
> is not directly related to precision.  if local timing can is stable to
> .1ppm for
> a longish period of time, then a low-frequency strobe of high precision and
> known timing could be enough.  the bbc does this with the tone at the top
> of the hr.
>
> - erik
>
>

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

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

[erik quanstrom]

> So, in effect, a 1PPS signal would be sufficient to clock second to second?
> I suppose it could be, there would be little drift in the oscillator per
> the second.
>
> As for NTP, this has been suggested to me, and I acknowledge its place,
> certainly. However, I do not wish to tie up network resources in terms of
> clocking, and GPS provides me with an independent reference - Navsync
> CW12-TIMs can be had for $89, and do not tie up network resources. You
> could then say "Ah, but you said a 1PPS is fine... now you're saying 1PPS
> via the network isn't?" That is due to a mesh topology being used in the
> eventual network, and the bandwidth, latency and propagation issues
> inherent in such a network. I wish to dedicate the network wholly and
> solely to requisite control data traffic, not superfluous traffic like
> clocking, which may not get there in time. Certainly, mine is a complex
> undertaking, but one I think can work.

if not on the normal network, how do you plan on distributing the clock
signal?

- erik

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

[Krystian Lewandowski]

Wiadomość napisana przez erik quanstrom <quanstro@quanstro.net> w dniu 31 gru 2013, o godz. 20:50:

> On Tue Dec 31 14:40:29 EST 2013, edgecomberts@gmail.com wrote:
> 
>> Erik,
>> 
>> Just for the purposes of edification (and curiosity), are you able to
>> elaborate on "long reads"? Its understandable such a scheme would be
>> implemented in the network drivers, but how exactly does it work, as
>> opposed to a polling scheme or an ISR? I will, of course, Google in a sec
>> as well.
> 
> it could be that i misunderstood the op's point.  what i understood from the
> original post was a scheme was envisioned where a user process would poll a
> status file to get interrupt status.  if i understood this correctly, then providing
> an interrupt file that returns even 0 bytes when there's an interrupt would be
> an alternative providing interrupt semantics to the up.  there are some 
> bits to work out if the user process falls behind, but it's no different than a
> network device.
> 
> does that answer your question?
> 
> - erik
> 

I’ll answer at the bottom, to not make even more mess i did before. :)

I’m not even sure what is my point of view. For ISR i was thinking about an interrupt routine writing something (a single byte) to a file when an interrupt occurs - writing using functions defined in qio - something similar to /dev/kprint - reading user process is waiting for new data if i understood the behavior correctly. It is not clear to me how this „0 bytes” method:
> providing
> an interrupt file that returns even 0 bytes when there's an interrupt would be
> an alternative providing interrupt semantics to the up
could be implemented and how ioproc is related (how ioread can be woken up with 0 bytes returned). But now, my mind isn’t quite clear now.

As i said i don’t know much about BCM, Plan 9 and the whole thing and basic GPIO implementation seemed to be a good entry point. Now i’m trying to figure out how it can be extended in the future, regarding your feedback. But if you think it is worth to extend this thread with new information then that would be great.

Thanks for this discussion!
Krystian

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

[Shane Morris]

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

My apologies for hijacking the thread, it is an interrelated work, and a
practical example of your work Krystian. In any case, my hat is off to you
for this work. Erik has noted I would get a reasonable accuracy within a
seconds timeframe from the onboard oscillator, and disciplining it is well
within the capabilities of the ARM microcontroller on the RPi board. If you
were to observe any real drift over the 100usec range, I think you'd be
asking for a new board...!

Erik, clocking signals are received, not distributed... or to wit, the US
Government distributes the clocking signals for me, by means of the GPS
network. I would prefer to use GLONASS of course, but I am uncertain of how
many "birds" in the Russian constellation are over Australia at any one
time, and I am unsure of whether my chosen GPSDO is a GLONASS receiver. I'm
assuming negative answers to both queries, although that is a matter for my
own investigation, and in its due time.

As an aside, I have priced Rockwell GPS modules with a 1PPS signal, the
princely sum of US$9, free shipping. I thought this may be a good place to
start my timing investigations with Plan 9 on the RPi, by seeing if I can
get the RPi to consistently clock over a considerable period of time. The
next challenge will be to make the whole lot happen "in respect to time"
according to the non-deterministic input of the user. That input would be
placed in time in both the ramfs, as well as the syncfs.

Many thanks for entertaining my notions, in any case. Happy New Year to you
both, and to the rest of the list!


On Wed, Jan 1, 2014 at 9:57 AM, Krystian Lewandowski <krystian.lew@gmail.com
> wrote:

>
> Wiadomość napisana przez erik quanstrom <quanstro@quanstro.net> w dniu 31
> gru 2013, o godz. 20:50:
>
> > On Tue Dec 31 14:40:29 EST 2013, edgecomberts@gmail.com wrote:
> >
> >> Erik,
> >>
> >> Just for the purposes of edification (and curiosity), are you able to
> >> elaborate on "long reads"? Its understandable such a scheme would be
> >> implemented in the network drivers, but how exactly does it work, as
> >> opposed to a polling scheme or an ISR? I will, of course, Google in a
> sec
> >> as well.
> >
> > it could be that i misunderstood the op's point.  what i understood from
> the
> > original post was a scheme was envisioned where a user process would
> poll a
> > status file to get interrupt status.  if i understood this correctly,
> then providing
> > an interrupt file that returns even 0 bytes when there's an interrupt
> would be
> > an alternative providing interrupt semantics to the up.  there are some
> > bits to work out if the user process falls behind, but it's no different
> than a
> > network device.
> >
> > does that answer your question?
> >
> > - erik
> >
>
> I’ll answer at the bottom, to not make even more mess i did before. :)
>
> I’m not even sure what is my point of view. For ISR i was thinking about
> an interrupt routine writing something (a single byte) to a file when an
> interrupt occurs - writing using functions defined in qio - something
> similar to /dev/kprint - reading user process is waiting for new data if i
> understood the behavior correctly. It is not clear to me how this „0 bytes”
> method:
> > providing
> > an interrupt file that returns even 0 bytes when there's an interrupt
> would be
> > an alternative providing interrupt semantics to the up
> could be implemented and how ioproc is related (how ioread can be woken up
> with 0 bytes returned). But now, my mind isn’t quite clear now.
>
> As i said i don’t know much about BCM, Plan 9 and the whole thing and
> basic GPIO implementation seemed to be a good entry point. Now i’m trying
> to figure out how it can be extended in the future, regarding your
> feedback. But if you think it is worth to extend this thread with new
> information then that would be great.
>
> Thanks for this discussion!
> Krystian
>

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

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

[Shane Morris]

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

As an addendum to my comments, and the ones made by Erik, I post this
RaspberryPi thread:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=52393

The topic in that thread is the generation of a 50kHz output signal from
the RPis "free running" 1MHz oscillator. Thus, it could not be disciplined
as such, but the CPUs time, in respect to the output of the oscillator,
could be maintained, and regulated with the 1PPS. Over a second timespan,
and updated every second, drift would be infinitesimally small.


On Wed, Jan 1, 2014 at 10:16 AM, Shane Morris <edgecomberts@gmail.com>wrote:

> My apologies for hijacking the thread, it is an interrelated work, and a
> practical example of your work Krystian. In any case, my hat is off to you
> for this work. Erik has noted I would get a reasonable accuracy within a
> seconds timeframe from the onboard oscillator, and disciplining it is well
> within the capabilities of the ARM microcontroller on the RPi board. If you
> were to observe any real drift over the 100usec range, I think you'd be
> asking for a new board...!
>
> Erik, clocking signals are received, not distributed... or to wit, the US
> Government distributes the clocking signals for me, by means of the GPS
> network. I would prefer to use GLONASS of course, but I am uncertain of how
> many "birds" in the Russian constellation are over Australia at any one
> time, and I am unsure of whether my chosen GPSDO is a GLONASS receiver. I'm
> assuming negative answers to both queries, although that is a matter for my
> own investigation, and in its due time.
>
> As an aside, I have priced Rockwell GPS modules with a 1PPS signal, the
> princely sum of US$9, free shipping. I thought this may be a good place to
> start my timing investigations with Plan 9 on the RPi, by seeing if I can
> get the RPi to consistently clock over a considerable period of time. The
> next challenge will be to make the whole lot happen "in respect to time"
> according to the non-deterministic input of the user. That input would be
> placed in time in both the ramfs, as well as the syncfs.
>
> Many thanks for entertaining my notions, in any case. Happy New Year to
> you both, and to the rest of the list!
>
>
> On Wed, Jan 1, 2014 at 9:57 AM, Krystian Lewandowski <
> krystian.lew@gmail.com> wrote:
>
>>
>> Wiadomość napisana przez erik quanstrom <quanstro@quanstro.net> w dniu
>> 31 gru 2013, o godz. 20:50:
>>
>> > On Tue Dec 31 14:40:29 EST 2013, edgecomberts@gmail.com wrote:
>> >
>> >> Erik,
>> >>
>> >> Just for the purposes of edification (and curiosity), are you able to
>> >> elaborate on "long reads"? Its understandable such a scheme would be
>> >> implemented in the network drivers, but how exactly does it work, as
>> >> opposed to a polling scheme or an ISR? I will, of course, Google in a
>> sec
>> >> as well.
>> >
>> > it could be that i misunderstood the op's point.  what i understood
>> from the
>> > original post was a scheme was envisioned where a user process would
>> poll a
>> > status file to get interrupt status.  if i understood this correctly,
>> then providing
>> > an interrupt file that returns even 0 bytes when there's an interrupt
>> would be
>> > an alternative providing interrupt semantics to the up.  there are some
>> > bits to work out if the user process falls behind, but it's no
>> different than a
>> > network device.
>> >
>> > does that answer your question?
>> >
>> > - erik
>> >
>>
>> I'll answer at the bottom, to not make even more mess i did before. :)
>>
>> I'm not even sure what is my point of view. For ISR i was thinking about
>> an interrupt routine writing something (a single byte) to a file when an
>> interrupt occurs - writing using functions defined in qio - something
>> similar to /dev/kprint - reading user process is waiting for new data if i
>> understood the behavior correctly. It is not clear to me how this "0 bytes"
>> method:
>> > providing
>> > an interrupt file that returns even 0 bytes when there's an interrupt
>> would be
>> > an alternative providing interrupt semantics to the up
>> could be implemented and how ioproc is related (how ioread can be woken
>> up with 0 bytes returned). But now, my mind isn't quite clear now.
>>
>> As i said i don't know much about BCM, Plan 9 and the whole thing and
>> basic GPIO implementation seemed to be a good entry point. Now i'm trying
>> to figure out how it can be extended in the future, regarding your
>> feedback. But if you think it is worth to extend this thread with new
>> information then that would be great.
>>
>> Thanks for this discussion!
>> Krystian
>>
>
>

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

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

[Krystian Lewandowski]

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

I don’t mind! I don’t think what i did is a major improvement - only some ideas of a begginer. BCM port in general was a milestone. I’m just trying to connect dots while learning something - and have some fun with it.
Happy new year for you too.
Krystian

Wiadomość napisana przez Shane Morris <edgecomberts@gmail.com> w dniu 1 sty 2014, o godz. 00:16:

> My apologies for hijacking the thread, it is an interrelated work, and a practical example of your work Krystian. In any case, my hat is off to you for this work. Erik has noted I would get a reasonable accuracy within a seconds timeframe from the onboard oscillator, and disciplining it is well within the capabilities of the ARM microcontroller on the RPi board. If you were to observe any real drift over the 100usec range, I think you'd be asking for a new board...!
> 
> Erik, clocking signals are received, not distributed... or to wit, the US Government distributes the clocking signals for me, by means of the GPS network. I would prefer to use GLONASS of course, but I am uncertain of how many "birds" in the Russian constellation are over Australia at any one time, and I am unsure of whether my chosen GPSDO is a GLONASS receiver. I'm assuming negative answers to both queries, although that is a matter for my own investigation, and in its due time.
> 
> As an aside, I have priced Rockwell GPS modules with a 1PPS signal, the princely sum of US$9, free shipping. I thought this may be a good place to start my timing investigations with Plan 9 on the RPi, by seeing if I can get the RPi to consistently clock over a considerable period of time. The next challenge will be to make the whole lot happen "in respect to time" according to the non-deterministic input of the user. That input would be placed in time in both the ramfs, as well as the syncfs.
> 
> Many thanks for entertaining my notions, in any case. Happy New Year to you both, and to the rest of the list!
> 
> 
> On Wed, Jan 1, 2014 at 9:57 AM, Krystian Lewandowski <krystian.lew@gmail.com> wrote:
> 
> Wiadomość napisana przez erik quanstrom <quanstro@quanstro.net> w dniu 31 gru 2013, o godz. 20:50:
> 
> > On Tue Dec 31 14:40:29 EST 2013, edgecomberts@gmail.com wrote:
> >
> >> Erik,
> >>
> >> Just for the purposes of edification (and curiosity), are you able to
> >> elaborate on "long reads"? Its understandable such a scheme would be
> >> implemented in the network drivers, but how exactly does it work, as
> >> opposed to a polling scheme or an ISR? I will, of course, Google in a sec
> >> as well.
> >
> > it could be that i misunderstood the op's point.  what i understood from the
> > original post was a scheme was envisioned where a user process would poll a
> > status file to get interrupt status.  if i understood this correctly, then providing
> > an interrupt file that returns even 0 bytes when there's an interrupt would be
> > an alternative providing interrupt semantics to the up.  there are some
> > bits to work out if the user process falls behind, but it's no different than a
> > network device.
> >
> > does that answer your question?
> >
> > - erik
> >
> 
> I’ll answer at the bottom, to not make even more mess i did before. :)
> 
> I’m not even sure what is my point of view. For ISR i was thinking about an interrupt routine writing something (a single byte) to a file when an interrupt occurs - writing using functions defined in qio - something similar to /dev/kprint - reading user process is waiting for new data if i understood the behavior correctly. It is not clear to me how this „0 bytes” method:
> > providing
> > an interrupt file that returns even 0 bytes when there's an interrupt would be
> > an alternative providing interrupt semantics to the up
> could be implemented and how ioproc is related (how ioread can be woken up with 0 bytes returned). But now, my mind isn’t quite clear now.
> 
> As i said i don’t know much about BCM, Plan 9 and the whole thing and basic GPIO implementation seemed to be a good entry point. Now i’m trying to figure out how it can be extended in the future, regarding your feedback. But if you think it is worth to extend this thread with new information then that would be great.
> 
> Thanks for this discussion!
> Krystian
> 


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

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

[Shane Morris]

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

I do remember some post asking about the status of the GPIO interfacing to
the Plan 9 OS some time ago, when you released the temperature readouts, I
had some hopes you might go on and address the GPIO functions, of which
until your work consisted solely of the serial port for debug purposes -
correct me if I'm wrong at any point other members of the list.

This of course opens up the Plan 9 OS for control applications - simply to
make a control application you read from or write to a file! I hope to
implement such an application to, in user space, discipline the free
running 1MHz oscillator from a 1PPS signal (thanks for your help on that
one Erik!). My next challenge will be to examine the output of a HID device
over USB, the Playstation 3 joypad, and integrate that into Plan 9 for the
"non-deterministic user interaction."


On Wed, Jan 1, 2014 at 11:04 AM, Krystian Lewandowski <
krystian.lew@gmail.com> wrote:

> I don't mind! I don't think what i did is a major improvement - only some
> ideas of a begginer. BCM port in general was a milestone. I'm just trying
> to connect dots while learning something - and have some fun with it.
> Happy new year for you too.
> Krystian
>
> Wiadomość napisana przez Shane Morris <edgecomberts@gmail.com> w dniu 1
> sty 2014, o godz. 00:16:
>
> My apologies for hijacking the thread, it is an interrelated work, and a
> practical example of your work Krystian. In any case, my hat is off to you
> for this work. Erik has noted I would get a reasonable accuracy within a
> seconds timeframe from the onboard oscillator, and disciplining it is well
> within the capabilities of the ARM microcontroller on the RPi board. If you
> were to observe any real drift over the 100usec range, I think you'd be
> asking for a new board...!
>
> Erik, clocking signals are received, not distributed... or to wit, the US
> Government distributes the clocking signals for me, by means of the GPS
> network. I would prefer to use GLONASS of course, but I am uncertain of how
> many "birds" in the Russian constellation are over Australia at any one
> time, and I am unsure of whether my chosen GPSDO is a GLONASS receiver. I'm
> assuming negative answers to both queries, although that is a matter for my
> own investigation, and in its due time.
>
> As an aside, I have priced Rockwell GPS modules with a 1PPS signal, the
> princely sum of US$9, free shipping. I thought this may be a good place to
> start my timing investigations with Plan 9 on the RPi, by seeing if I can
> get the RPi to consistently clock over a considerable period of time. The
> next challenge will be to make the whole lot happen "in respect to time"
> according to the non-deterministic input of the user. That input would be
> placed in time in both the ramfs, as well as the syncfs.
>
> Many thanks for entertaining my notions, in any case. Happy New Year to
> you both, and to the rest of the list!
>
>
> On Wed, Jan 1, 2014 at 9:57 AM, Krystian Lewandowski <
> krystian.lew@gmail.com> wrote:
>
>>
>> Wiadomość napisana przez erik quanstrom <quanstro@quanstro.net> w dniu
>> 31 gru 2013, o godz. 20:50:
>>
>> > On Tue Dec 31 14:40:29 EST 2013, edgecomberts@gmail.com wrote:
>> >
>> >> Erik,
>> >>
>> >> Just for the purposes of edification (and curiosity), are you able to
>> >> elaborate on "long reads"? Its understandable such a scheme would be
>> >> implemented in the network drivers, but how exactly does it work, as
>> >> opposed to a polling scheme or an ISR? I will, of course, Google in a
>> sec
>> >> as well.
>> >
>> > it could be that i misunderstood the op's point.  what i understood
>> from the
>> > original post was a scheme was envisioned where a user process would
>> poll a
>> > status file to get interrupt status.  if i understood this correctly,
>> then providing
>> > an interrupt file that returns even 0 bytes when there's an interrupt
>> would be
>> > an alternative providing interrupt semantics to the up.  there are some
>> > bits to work out if the user process falls behind, but it's no
>> different than a
>> > network device.
>> >
>> > does that answer your question?
>> >
>> > - erik
>> >
>>
>> I'll answer at the bottom, to not make even more mess i did before. :)
>>
>> I'm not even sure what is my point of view. For ISR i was thinking about
>> an interrupt routine writing something (a single byte) to a file when an
>> interrupt occurs - writing using functions defined in qio - something
>> similar to /dev/kprint - reading user process is waiting for new data if i
>> understood the behavior correctly. It is not clear to me how this "0 bytes"
>> method:
>> > providing
>> > an interrupt file that returns even 0 bytes when there's an interrupt
>> would be
>> > an alternative providing interrupt semantics to the up
>> could be implemented and how ioproc is related (how ioread can be woken
>> up with 0 bytes returned). But now, my mind isn't quite clear now.
>>
>> As i said i don't know much about BCM, Plan 9 and the whole thing and
>> basic GPIO implementation seemed to be a good entry point. Now i'm trying
>> to figure out how it can be extended in the future, regarding your
>> feedback. But if you think it is worth to extend this thread with new
>> information then that would be great.
>>
>> Thanks for this discussion!
>> Krystian
>>
>
>
>

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

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

[Matthew Veety]

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


On Dec 31, 2013, at 12:46 PM, Krystian Lewandowski <krystian.lew@gmail.com> wrote:

> 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.

Our kernel has some significant changes to it compared to the Bell Labs kernel. So it's kind of both on purpose and because we don't sync them as much as we probably should. 9pi works fine (I use it daily), and since you use 9front, if you want to support it that would be great because we really don't have anyone working on that as much as we should.

--
Veety

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

[Richard Miller]

> 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.

If you want your work to be useful to the Plan 9 community (and I hope you do), please
stay with us and improve the real Plan 9.

You can safely leave out the fakertc driver when building a bcm kernel.  The
only consequence is that you'll be prompted for date and time when booting with
root filesystem on the local SD card (because the Pi doesn't have a rtc).  If
your root fs comes from another server (which I recommend), fakertc isn't used.

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

[erik quanstrom]

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

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

[Krystian Lewandowski]

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
>