[9fans] Pi updates

[9fans] Pi updates

[Brian L. Stuart]

A few months ago I brought up the question of small
platforms suitable for a course on small/embedded
computing.  If you recall the conversation, with input
from the collective wisdom, I decided to use the Pi.
At that time several people asked if I could share
any results from the course that I'm able to.  I've
finally finished putting some of it together in a form
that's useful.  In

/n/sources/contrib/blstuart/pi/ ...
http://cs.drexel.edu/~bls96/plan9/pi/ ...

are a collection of changes with all the changes
collected into a tarball:

/n/sources/contrib/blstuart/pi.tgz
http://cs.drexel.edu/~bls96/plan9/pi.tgz

The changes include:
- Richard's post 9pi.img changes on contrib
- I2C and SPI contributions from Steve Simon with the
I2C support ported from Inferno
- Enhancements for I2C and SPI
- Devgpio driver
- Man pages for I2C, SPI, and GPIO
- Support for a 320x480 SPI TFT display
- Enhancements to the USB keyboard support to handle
the Rii k12 keyboard/trackpad combination

I've also posted a little video (apologies in advance for
the quality, or lack thereof) of a Pi with the TFT screen
and k12 keyboard controlling a PiBog vehicle my wife
gave me for Christmas:

http://cs.drexel.edu/~bls96/plan9/robot9.mp4

I'll look into making the slides I used in the lecture
available if there's interest.

There are some rough edges, but hopefully it might be
useful to some.

BLS

Re: [9fans] Pi updates

[Anthony Sorace]

Wow, that’s amazing timing. I was reading about SPI on
the Pi, considering getting one of those TFT displays,
closed the window to head to bed, and there’s your
message. This is super useful, thanks. And yes, I’d be
interested in seeing your slides, although you’ve already
given me enough to keep my busy for a bit.

Anthony

Re: [9fans] Pi updates

[Skip Tavakkolian]

Cool! Thank you.

-Skip

> A few months ago I brought up the question of small
> platforms suitable for a course on small/embedded
> computing.  If you recall the conversation, with input
> from the collective wisdom, I decided to use the Pi.
> At that time several people asked if I could share
> any results from the course that I'm able to.  I've
> finally finished putting some of it together in a form
> that's useful.  In
>
> /n/sources/contrib/blstuart/pi/ ...
> http://cs.drexel.edu/~bls96/plan9/pi/ ...
>
> are a collection of changes with all the changes
> collected into a tarball:
>
> /n/sources/contrib/blstuart/pi.tgz
> http://cs.drexel.edu/~bls96/plan9/pi.tgz
>
> The changes include:
> - Richard's post 9pi.img changes on contrib
> - I2C and SPI contributions from Steve Simon with the
> I2C support ported from Inferno
> - Enhancements for I2C and SPI
> - Devgpio driver
> - Man pages for I2C, SPI, and GPIO
> - Support for a 320x480 SPI TFT display
> - Enhancements to the USB keyboard support to handle
> the Rii k12 keyboard/trackpad combination
>
> I've also posted a little video (apologies in advance for
> the quality, or lack thereof) of a Pi with the TFT screen
> and k12 keyboard controlling a PiBog vehicle my wife
> gave me for Christmas:
>
> http://cs.drexel.edu/~bls96/plan9/robot9.mp4
>
> I'll look into making the slides I used in the lecture
> available if there's interest.
>
> There are some rough edges, but hopefully it might be
> useful to some.
>
> BLS

Re: [9fans] Pi updates

[Richard Miller]

Thanks, Brian - that all looks very useful to make the pi more amenable
to hardware tinkering.

One small suggested amendment: your spiclock() says this -

/*
 * According the Broadcom docs, the divisor has to
 * be a power of 2.  This code rounds up so that the
 * resulting clock is the highest value no greater than
 * what's requested.
 */

but http://raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md
has an erratum suggesting "power of 2" should be "multiple of 2".  I have
been using a default divisor of 250 for a 1MHz clock, and that's the frequency
I see on my oscilloscope.

Re: [9fans] Pi updates

[Skip Tavakkolian]

> - Enhancements for I2C and SPI

is there an updated devrtc3231.c, or a conventional user space fs, that uses the new i2c?

Re: [9fans] Pi updates

[Brian L. Stuart]

> but http://raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md
> has an erratum suggesting "power of 2" should be "multiple of 2".  I have
> been using a default divisor of 250 for a 1MHz clock, and that's the frequency
> I see on my oscilloscope.

Excellent.  I had suspected that statement was too restrictive, but hadn't
seen the errata or gotten around to checking on a scope.  I'll update that
today.

Thanks,
BLS

Re: [9fans] Pi updates

[Brian L. Stuart]

> Excellent.  I had suspected that statement was too restrictive, but hadn't
> seen the errata or gotten around to checking on a scope.  I'll update that
> today.
 
New versions posted.  spiclock() now rounds the divisor up to the smallest
even number that results is a clock rate less than or equal to that requested.
Let me know if you run into anything else that needs attention.

BLS

Re: [9fans] Pi updates

[Brian L. Stuart]

On Mon, 12/28/15, Anthony Sorace <a@9srv.net> wrote:
> And yes, I’d be interested in seeing your
> slides, although you’ve already given me
> enough to keep my busy for a bit.
 
Anthony,
I've put the slides up in the directory at:

http://cs.drexel.edu/~bls96/plan9/

The class met one night a week and we have 10 week
quarters.  So there are only 9 sets of slides.  There's not
a lot of textual meat in them.  I tend to have a lot of figures
I talk over with some outline-level textual material.

BLS

Re: [9fans] Pi updates

[Brian L. Stuart]

On Wed, 12/30/15, Skip Tavakkolian <9nut@9netics.com> wrote:
> > - Enhancements for I2C and SPI
>
> is there an updated devrtc3231.c, or a conventional user space
> fs, that uses the new i2c?

Yes, there's a devi2c userland interface ported over from Inferno.
That's what's being used to drive the robot in the video clip.

BLS

Re: [9fans] Pi updates

[Joseph Stewart]

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

Thanks for posting your slides and other work Brian.

On Wed, Dec 30, 2015 at 5:22 PM, Brian L. Stuart <blstuart@bellsouth.net>
wrote:

> On Wed, 12/30/15, Skip Tavakkolian <9nut@9netics.com> wrote:
> > > - Enhancements for I2C and SPI
> >
> > is there an updated devrtc3231.c, or a conventional user space
> > fs, that uses the new i2c?
>
> Yes, there's a devi2c userland interface ported over from Inferno.
> That's what's being used to drive the robot in the video clip.
>
> BLS
>
>

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

Re: [9fans] Pi updates

[erik quanstrom]

On Wed Dec 30 14:27:27 PST 2015, blstuart@bellsouth.net wrote:
> On Wed, 12/30/15, Skip Tavakkolian <9nut@9netics.com> wrote:
> > > - Enhancements for I2C and SPI
> >
> > is there an updated devrtc3231.c, or a conventional user space
> > fs, that uses the new i2c?
>
> Yes, there's a devi2c userland interface ported over from Inferno.
> That's what's being used to drive the robot in the video clip.

i'm looking @ the gpio interface, and i wonder what the recommended
technique for sampling a pin might be from a shell script?

- erik

Re: [9fans] Pi updates

[Brian L. Stuart]

On Fri, 1/1/16, erik quanstrom <quanstro@quanstro.net> wrote:
> i'm looking @ the gpio interface, and i wonder what the recommended
> technique for sampling a pin might be from a shell script?

I haven't really used it in shell scripts, but if I were going to do
so, I'd probably write up a little utility to take a hex string and
a bit number and do the 'and' on it.  Then feed that with the
result of dd to get exactly one sample from devgpio.  On the
other hand, if one of the usual suspects (e.g. hoc, bc, dc, awk)
have some bit-wise operators I'm forgetting, use that.

BLS

Re: [9fans] Pi updates

[erik quanstrom]

On Fri Jan  1 21:15:03 PST 2016, blstuart@bellsouth.net wrote:
> On Fri, 1/1/16, erik quanstrom <quanstro@quanstro.net> wrote:
> > i'm looking @ the gpio interface, and i wonder what the recommended
> > technique for sampling a pin might be from a shell script?
> 
> I haven't really used it in shell scripts, but if I were going to do
> so, I'd probably write up a little utility to take a hex string and
> a bit number and do the 'and' on it.  Then feed that with the
> result of dd to get exactly one sample from devgpio.  On the
> other hand, if one of the usual suspects (e.g. hoc, bc, dc, awk)
> have some bit-wise operators I'm forgetting, use that.

the (atom) aux/number program does do that; none of the others do
for fairly fundamental reasons: as awk and hoc are really floating
point, and bc and dc are mp, and the mp library has no bit operations.
i believe acid can as well, but only with great pain.

perhaps just using base 2 for the encoding would make life a lot easer. so 

00000000000000000000000000010000000000000000000000000000000000000

for bit 27 active.  with this format there's no limit to the number of bits one
could represent.

also, mightn't there be some value in presenting the full state of the device
to allow it to be restored directly from the status file, so perhaps 3 lines
could be added, one each for up/down/float settings?

00000000000000000000000000010000000000000000000000000000000000000
00000000000000000000000000010000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000

might represent bit 27 set, with the pull up resistor active.  (perhaps
float ≡ (pullup | pulldown) == 0? and could be elimitated.

i'm sure a little tinkering with this idea can make it a lot more useful.

- erik

Re: [9fans] Pi updates

[Bakul Shah]

FWIW, when I was looking at doing a gpio drive I was thinking of
something like the following.

Devices:
    #G/gpio/ctl
    #G/gpio/$pin/ctl
    #G/gpio/$pin/data
    #G/gpio/$pin/event
    ...

    bing -a '#G' /dev

A pin must be configured before use (and only if neither of
its data & event file is open). For example:

    echo 'in rising edge high' > /dev/gpio/10/ctl

Syntax
    reset	# reset to default
    in [async][rising|falling][edge] [high|low] [init $value] [buf $value]
    out [pullup|pulldown] [init $value] [strength $value]
    alt [0..5]	# pi specific

You can use the same syntax to configure multiple pins by
writing to /dev/gpio/ctl and appending pin numbers.

    echo 'out pullup 4 12 17' > /dev/gpio/ctl

You can *gang* multiple pins into a single port. For example:

    echo 'create 100 1 2 5 10' > /dev/gpio/ctl

This creates a new "pin" 100 (number must be >= # of physical
pins) and creates a new entry in /dev/gpio.  This succeeds
only if the pins can actually be ganged (this is device
dependent).  You can now configure the port:

    echo 'in rising edge low' > /dev/gpio/100/ctl

To delete a port

    echo 'delete 100' > /dev/gpio/ctl

All constituent pins revert to their default state.

Reading /dev/gpio/N/data returns a sample of the present value.

[The following needs more work]
Reading /dev/pio/N/event blocks the caller until something
changes.  Returns value and timestamp (in case of "async"
inputs, events are handled in the interrupt handler and
buffered).

Random notes:
An "in" pin has an init value since some pins can be
bidirectional.  "alt" may create other devices as a
side-effect such as SPI, I2C, I2S, PWM, UART etc.

Configs are sticky and persist across device opens, which is
why there is a "reset" command.

While this may be easy to use, its implementation would be
somewhat complex.... Ideally one would break this into a small
core kernel mode driver and a fancier user mode one for
configuring.  I stopped at this point for various reasons and
never got back to it.

On Sat, 02 Jan 2016 10:06:31 PST erik quanstrom <quanstro@quanstro.net> wrote:
> On Fri Jan  1 21:15:03 PST 2016, blstuart@bellsouth.net wrote:
> > On Fri, 1/1/16, erik quanstrom <quanstro@quanstro.net> wrote:
> > > i'm looking @ the gpio interface, and i wonder what the recommended
> > > technique for sampling a pin might be from a shell script?
> >
> > I haven't really used it in shell scripts, but if I were going to do
> > so, I'd probably write up a little utility to take a hex string and
> > a bit number and do the 'and' on it.  Then feed that with the
> > result of dd to get exactly one sample from devgpio.  On the
> > other hand, if one of the usual suspects (e.g. hoc, bc, dc, awk)
> > have some bit-wise operators I'm forgetting, use that.
>
> the (atom) aux/number program does do that; none of the others do
> for fairly fundamental reasons: as awk and hoc are really floating
> point, and bc and dc are mp, and the mp library has no bit operations.
> i believe acid can as well, but only with great pain.
>
> perhaps just using base 2 for the encoding would make life a lot easer. so
>
> 00000000000000000000000000010000000000000000000000000000000000000
>
> for bit 27 active.  with this format there's no limit to the number of bits
> one could represent.
>
> also, mightn't there be some value in presenting the full state of the device
> to allow it to be restored directly from the status file, so perhaps 3 lines
> could be added, one each for up/down/float settings?
>
> 00000000000000000000000000010000000000000000000000000000000000000
> 00000000000000000000000000010000000000000000000000000000000000000
> 00000000000000000000000000000000000000000000000000000000000000000
> 00000000000000000000000000000000000000000000000000000000000000000
>
> might represent bit 27 set, with the pull up resistor active.  (perhaps
> float =E2=89=A1 (pullup | pulldown) =3D=3D 0? and could be elimitated.
>
> i'm sure a little tinkering with this idea can make it a lot more useful.
>
> - erik