From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 31 Dec 2013 09:38:01 +1100 Message-ID: From: Shane Morris To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c38a22afeae604eec818bf Subject: Re: [9fans] "gpio device" for Plan 9 Topicbox-Message-UUID: a9c51e8c-ead8-11e9-9d60-3106f5b1d025 --001a11c38a22afeae604eec818bf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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=3D72&t=3D33113 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=92d like to share with you some Raspberry Pi related work done for Pla= n 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=92t 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=92 /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= =94) >> - select pin pull state: >> % echo pull up > /dev/gpio/board/GPIO0 >> (possible pull states are: "off", "down", "up=94) >> >> This is completely untested. I=92m still waiting for cables and breadboa= rd, >> i don=92t want to play with pins until i=92ll have it. Though OK pin (LE= D) >> 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=92t want= to >> send the patch yet. >> >> https://github.com/elewarr/plan9-bcm/commit/18f1c470d1e16a63a55761094f72= 3c2bd91b576d >> 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=92t test se= rial >> console connection i didn=92t touch it >> 3. Is #G/gpio scheme OK (unreserved, correct)? >> 4. Events are not supported >> >> Greetings, >> Krystian >> > > --001a11c38a22afeae604eec818bf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
This is pretty cool! Good work!

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


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

Lastly, I hope this email is seen by the list - "W= hen it is all mouth, and no ears, its known as an 'alligator'...&qu= ot;


On Mon, Dec 30, 2013 at 6:32 PM, Skip Tavakkolian <skip.tavakkoli= an@gmail.com> wrote:
nice. i guess i'll need to get a Pi T-Cobbler and try = it.

=


On Sun, Dec 2= 9, 2013 at 2:04 PM, Krystian Lewandowski <krystian.lew@gmail.com&= gt; wrote:
Good evening,
i=92d 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 function= s i implemented #G/gpio device:
Structure is as follows:
#G/gpio/
=A0 =A0 =A0 =A0 /bcm/ ...
=A0 =A0 =A0 =A0 /board/ ...
=A0 =A0 =A0 =A0 /wpi/ ...
=A0 =A0 =A0 =A0 /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=92t know.

I used this page as reference for pin assignments:
https://projects.drogon.net/raspberry-pi/wiringpi/pins/

% du -a
0 =A0 =A0 =A0 ./bcm/0
0 =A0 =A0 =A0 ./bcm/1
0 =A0 =A0 =A0 ./bcm/4
0 =A0 =A0 =A0 ./bcm/7
0 =A0 =A0 =A0 ./bcm/8
0 =A0 =A0 =A0 ./bcm/9
0 =A0 =A0 =A0 ./bcm/10
0 =A0 =A0 =A0 ./bcm/11
0 =A0 =A0 =A0 ./bcm/14
0 =A0 =A0 =A0 ./bcm/15
0 =A0 =A0 =A0 ./bcm/16
0 =A0 =A0 =A0 ./bcm/17
0 =A0 =A0 =A0 ./bcm/18
0 =A0 =A0 =A0 ./bcm/21
0 =A0 =A0 =A0 ./bcm/22
0 =A0 =A0 =A0 ./bcm/23
0 =A0 =A0 =A0 ./bcm/24
0 =A0 =A0 =A0 ./bcm/25
0 =A0 =A0 =A0 ./bcm
0 =A0 =A0 =A0 ./board/SDA
0 =A0 =A0 =A0 ./board/SCL
0 =A0 =A0 =A0 ./board/GPIO7
0 =A0 =A0 =A0 ./board/CE1
0 =A0 =A0 =A0 ./board/CE0
0 =A0 =A0 =A0 ./board/MISO
0 =A0 =A0 =A0 ./board/MOSI
0 =A0 =A0 =A0 ./board/SCLK
0 =A0 =A0 =A0 ./board/TxD
0 =A0 =A0 =A0 ./board/RxD
0 =A0 =A0 =A0 ./board/GPIO0
0 =A0 =A0 =A0 ./board/GPIO1
0 =A0 =A0 =A0 ./board/GPIO2
0 =A0 =A0 =A0 ./board/GPIO3
0 =A0 =A0 =A0 ./board/GPIO4
0 =A0 =A0 =A0 ./board/GPIO5
0 =A0 =A0 =A0 ./board/GPIO6
0 =A0 =A0 =A0 ./board
0 =A0 =A0 =A0 ./wpi/8
0 =A0 =A0 =A0 ./wpi/9
0 =A0 =A0 =A0 ./wpi/7
0 =A0 =A0 =A0 ./wpi/11
0 =A0 =A0 =A0 ./wpi/10
0 =A0 =A0 =A0 ./wpi/13
0 =A0 =A0 =A0 ./wpi/12
0 =A0 =A0 =A0 ./wpi/14
0 =A0 =A0 =A0 ./wpi/15
0 =A0 =A0 =A0 ./wpi/16
0 =A0 =A0 =A0 ./wpi/0
0 =A0 =A0 =A0 ./wpi/1
0 =A0 =A0 =A0 ./wpi/2
0 =A0 =A0 =A0 ./wpi/3
0 =A0 =A0 =A0 ./wpi/4
0 =A0 =A0 =A0 ./wpi/5
0 =A0 =A0 =A0 ./wpi/6
0 =A0 =A0 =A0 ./wpi
0 =A0 =A0 =A0 ./OK
0 =A0 =A0 =A0 .

Reference:
- mount gpio:
=A0 =A0 =A0 =A0 % bind -a '#G=92 /dev
- read pin state:
=A0 =A0 =A0 =A0 % cat /dev/gpio/board/GPIO0
- write pin state:
=A0 =A0 =A0 =A0 % echo 1 > /dev/gpio/board/GPIO0
=A0 =A0 =A0 =A0 % echo 0 > /dev/gpio/board/GPIO0
- select pin function:
=A0 =A0 =A0 =A0 % echo func out > /dev/gpio/board/GPIO0
(possible functions are: "in", "out", "f5", &= quot;f4", "f0", "f1", "f2", "f3=94)=
- select pin pull state:
=A0 =A0 =A0 =A0 % echo pull up > /dev/gpio/board/GPIO0
(possible pull states are: "off", "down", "up=94)<= br>
This is completely untested. I=92m still waiting for cables and breadboard,= i don=92t want to play with pins until i=92ll 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=92t want to send th= e patch yet.
https://github.com/elewarr/plan9-bc= m/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/o= ut, function selection, pull up/down state) defined in uartmini.c - it shou= ld probably be removed from uartmini.c but because i can=92t test serial co= nsole connection i didn=92t touch it
3. Is #G/gpio scheme OK (unreserved, correct)?
4. Events are not supported

Greetings,
Krystian


--001a11c38a22afeae604eec818bf--