Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
GPIO command line util for FreeBSD
86 views
Skip to first unread message
Big Bad Bob
Aug 18, 2016, 11:58:26 AM8/18/16
to
Recently, FreeBSD 11 went into 'release candidate' mode and they've
expanded their support for Raspberry Pi, so I tested it [and with minor
difficulties, got it working on a model 1 'B'].
one of the first things I noticed was that the /proc method of toggling
IO pins wasn't there. (maybe it just wasn't enabled, but I didn't like
that interface much anyway, being inherently inefficient).
I did see a link (from a related web page) to a project that has an open
source Perl and Python interface, and of course that's _something_ but
didn't do what I wanted.
So, I created THIS:
https://github.com/bombasticbob/FBSDRPiGPIO
It's a simple utility that lets you configure, read, write to, and query
status of the GPIO pins. It's intended to be fast and efficient and
easy to work with from a shell script.
(I'm still working on the build environment, i.e. Makefile and man page,
and plan on putting it in 'ports', hopefully as 'sysutils/gpio-rpi' or
similar. Preliminary versions of the Makefile and man page have already
been pushed to github)
At this time the application has the name 'gpio'. if it clashes with
others [haven't found any yet] I'll change it before creating a
port/package for it.
There are also instructions in the project wiki on github on how to set
up the RPi running FreeBSD with respect to security for the /dev/gpioc0
device, so that non-root users can access it [basically set up
/etc/devfs.conf and an entry in /etc/group specifying a group like
'gpio' to have access to it).
In any case, give it a try, post what you think
On a related note, if you wanted to blink the status LED twice, you
could use a command line like this:
gpio -w16=0 -d250000 -w16=1 -d250000 -w16=0 -d250000 -w16=1
that would assign 0 to GPIO 16 (the status LED), wait 250000
microseconds, then set it to a 1, then wait again, then set it to a
zero, etc.. When GPIO16 is a zero, the LED is lit. Normally it's a 1.
in theory you could build a command line that sent an entire bytes'
worth of data over something similar to an SPI port, although the delay
function just uses 'usleep()' at the moment. If timing becomes critical
it could theoretically be modified to switch into a near 'real time'
priority and spin for timing control. so maybe as sample code it has
even MORE use...
expanded their support for Raspberry Pi, so I tested it [and with minor
difficulties, got it working on a model 1 'B'].
one of the first things I noticed was that the /proc method of toggling
IO pins wasn't there. (maybe it just wasn't enabled, but I didn't like
that interface much anyway, being inherently inefficient).
I did see a link (from a related web page) to a project that has an open
source Perl and Python interface, and of course that's _something_ but
didn't do what I wanted.
So, I created THIS:
https://github.com/bombasticbob/FBSDRPiGPIO
It's a simple utility that lets you configure, read, write to, and query
status of the GPIO pins. It's intended to be fast and efficient and
easy to work with from a shell script.
(I'm still working on the build environment, i.e. Makefile and man page,
and plan on putting it in 'ports', hopefully as 'sysutils/gpio-rpi' or
similar. Preliminary versions of the Makefile and man page have already
been pushed to github)
At this time the application has the name 'gpio'. if it clashes with
others [haven't found any yet] I'll change it before creating a
port/package for it.
There are also instructions in the project wiki on github on how to set
up the RPi running FreeBSD with respect to security for the /dev/gpioc0
device, so that non-root users can access it [basically set up
/etc/devfs.conf and an entry in /etc/group specifying a group like
'gpio' to have access to it).
In any case, give it a try, post what you think
On a related note, if you wanted to blink the status LED twice, you
could use a command line like this:
gpio -w16=0 -d250000 -w16=1 -d250000 -w16=0 -d250000 -w16=1
that would assign 0 to GPIO 16 (the status LED), wait 250000
microseconds, then set it to a 1, then wait again, then set it to a
zero, etc.. When GPIO16 is a zero, the LED is lit. Normally it's a 1.
in theory you could build a command line that sent an entire bytes'
worth of data over something similar to an SPI port, although the delay
function just uses 'usleep()' at the moment. If timing becomes critical
it could theoretically be modified to switch into a near 'real time'
priority and spin for timing control. so maybe as sample code it has
even MORE use...
Big Bad Bob
Aug 22, 2016, 4:45:37 AM8/22/16
to
On 08/18/16 08:59, Big Bad Bob so wittily quipped:
program that does one thing at a time, which is a nice built-in but my
utility is better for some things
so now I can write generic simple scripts using the built-in, or more
interesting complex ones using my utility. anyway, I'll consider
whether or not it needs to become a 'port' or not.
more testing and bug reports (on the OS) to follow I'm sure
> Recently, FreeBSD 11 went into 'release candidate' mode and they've
> expanded their support for Raspberry Pi, so I tested it [and with minor
> difficulties, got it working on a model 1 'B'].
>
> one of the first things I noticed was that the /proc method of toggling
> IO pins wasn't there. (maybe it just wasn't enabled, but I didn't like
> that interface much anyway, being inherently inefficient).
after having toyed with it for a while, I found there's a 'gpioctl'
> expanded their support for Raspberry Pi, so I tested it [and with minor
> difficulties, got it working on a model 1 'B'].
>
> one of the first things I noticed was that the /proc method of toggling
> IO pins wasn't there. (maybe it just wasn't enabled, but I didn't like
> that interface much anyway, being inherently inefficient).
program that does one thing at a time, which is a nice built-in but my
utility is better for some things
so now I can write generic simple scripts using the built-in, or more
interesting complex ones using my utility. anyway, I'll consider
whether or not it needs to become a 'port' or not.
more testing and bug reports (on the OS) to follow I'm sure
Gordon Henderson
Aug 22, 2016, 5:37:46 PM8/22/16
to
In article <xbKdnQr6U5uBRijK...@earthlink.com>,
but I've not had time to look at it yet. wiringPi has a gpio
command to do "stuff" with the GPIO pins.
e.g.
gpio mode 0 out ; gpio write 0 1
would set gpio.0 (bcm 17, physical 11) to output mode and set it
high.
>in theory you could build a command line that sent an entire bytes'
>worth of data over something similar to an SPI port, although the delay
>function just uses 'usleep()' at the moment. If timing becomes critical
>it could theoretically be modified to switch into a near 'real time'
>priority and spin for timing control. so maybe as sample code it has
>even MORE use...
I've seen people write entire small factory automations in bash
using wiringPi's gpio command, and a complete I2C master stack
in (my) BASIC which uses wiringPi... Don't underestinate what
people will do...
Cheers,
-Gordon
Big Bad Bob <BigBadBob-at...@testing.local> wrote:
>At this time the application has the name 'gpio'. if it clashes with
>others [haven't found any yet] I'll change it before creating a
>port/package for it.
I've been toying with the idea of porting wiringPi to FreeBSD,
>At this time the application has the name 'gpio'. if it clashes with
>others [haven't found any yet] I'll change it before creating a
>port/package for it.
but I've not had time to look at it yet. wiringPi has a gpio
command to do "stuff" with the GPIO pins.
e.g.
gpio mode 0 out ; gpio write 0 1
would set gpio.0 (bcm 17, physical 11) to output mode and set it
high.
>in theory you could build a command line that sent an entire bytes'
>worth of data over something similar to an SPI port, although the delay
>function just uses 'usleep()' at the moment. If timing becomes critical
>it could theoretically be modified to switch into a near 'real time'
>priority and spin for timing control. so maybe as sample code it has
>even MORE use...
using wiringPi's gpio command, and a complete I2C master stack
in (my) BASIC which uses wiringPi... Don't underestinate what
people will do...
Cheers,
-Gordon
0 new messages