reading GPIO input


21 posts
by ThijsDeschildre » Thu Sep 27, 2012 11:45 pm
I spent a few wonderful hours raging out, trying to read input from GPIO.
The wiki documents the use of setting an output: http://elinux.org/RPi_Low-level_periphe ... le_.28C.29

How do I set output in a similar fashion?
Where do I find the complete documentation of the GPIO functions of the library used?
Posts: 3
Joined: Thu Sep 27, 2012 11:35 pm
by jojopi » Fri Sep 28, 2012 12:45 am
Have you read the BCM2835-ARM-Peripherals datasheet, especially the descriptions of the GPIO registers starting on page90? See: http://www.raspberrypi.org/archives/615

Basically for an output you write the pattern 001 to the corresponding GPFSEL register bits, and then write to the GPSET or GPCLR bits. For an input you write 000 to GPFSEL, optionally configure pull-up/down, and then read from GPLEV.

Incidentally, unless you are writing bare-metal or kernel code, using alternate functions or other special features, or need the fastest possible access, you do not have to deal with the hardware registers yourself. WiringPi is a nice library that provides a simplified C interface, somewhat compatible with the way GPIO works on Arduino: https://projects.drogon.net/raspberry-pi/wiringpi/
User avatar
Posts: 2122
Joined: Tue Oct 11, 2011 8:38 pm
by ThijsDeschildre » Fri Sep 28, 2012 1:44 am
I just got it working with Wiringpi. I had to find out you need some additional commands when you used an installer for it, and the additional commands listed somewhere in the blog contained an error too.
Why doesn't the standard library support something like GPIO_READ, instead of fumbling with registers?

This whole affair is IMHO ridiculous, I lost three hours of time.
Posts: 3
Joined: Thu Sep 27, 2012 11:35 pm
by MattHawkinsUK » Fri Sep 28, 2012 11:03 am
I use the RPi.GPIO library to control GPIO pins in Python. This is installed in the latest Raspbian image by default. It's perhaps a bit of a leap to get there but once you are familiar with your library of choice it gets easier.

It may have taken 3 hours, but it wasn't wasted. You survived and can go on to greater things!
My Raspberry Pi blog and home of the BerryClip Add-on board : http://www.raspberrypi-spy.co.uk/
Follow me on Google+, Facebook, Pinterest and Twitter (@RPiSpy)
User avatar
Posts: 491
Joined: Tue Jan 10, 2012 8:48 pm
Location: UK
by gordon@drogon.net » Fri Sep 28, 2012 3:32 pm
ThijsDeschildre wrote:I just got it working with Wiringpi. I had to find out you need some additional commands when you used an installer for it, and the additional commands listed somewhere in the blog contained an error too.
Why doesn't the standard library support something like GPIO_READ, instead of fumbling with registers?

This whole affair is IMHO ridiculous, I lost three hours of time.


The RaspberryPi is a standard Linux device and as such there is no "standard library" for reading/writing GPIO pins.

There are various standardised methods for dealing with GPIO in Linux though (the /sys/class interface), as well as some user-developed codes - my wiringPi library is one of them - good for C, C++ and is used in other languages via 'wrapper' functions too - there are Python, PHP, Perl, Java implementations to read/write the GPIO using wiringPi as the underlying 'core' functions.

I'm surprised you had issues installing, and I'd like to know more - can you email me, or reply here about it?

But whatever you do - don't plug away alone - there are 1000's of us out there, just ask!

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1540
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by DexOS » Fri Sep 28, 2012 4:05 pm
jojopi wrote:Incidentally, unless you are writing bare-metal or kernel code, using alternate functions or other special features, or need the fastest possible access, you do not have to deal with the hardware registers yourself. WiringPi is a nice library that provides a simplified C interface, somewhat compatible with the way GPIO works on Arduino: https://projects.drogon.net/raspberry-pi/wiringpi/

Even in bare metal you do not need to deal with the hardware regs yourself, unless you want too.
Bare metal example:
Code: Select all
;*
;* Blink
;*
;* Basic raspberry pi bare metal example. Turns on an LED for one second,
;* then off for one second and so on.. we use the built in green
;* OK LED, gpio number 16 (see page 102 BCM2835 PDF)to keep things
;* simple.
;*
include 'DexBasic\DexBasic.inc'               
                                                 
pinMode  GPIO16, OUTPUT                       
                                                   
LetsLoop:                                       
                                               
digitalWrite  GPIO16, HIGH                       
delayMicroseconds  1000000                       
digitalWrite  GPIO16, LOW                         
delayMicroseconds  1000000                       
                                                 
goto  LetsLoop
Batteries not included, Some assembly required.
User avatar
Posts: 864
Joined: Wed May 16, 2012 6:32 pm
by ThijsDeschildre » Fri Sep 28, 2012 9:03 pm
well yes, in Python it's easier to read a pin, but I insist to write in C.
I'm working with a really old fashioned 5x10 LED matrix that's multiplexed. At 1000hz refresh rate I get 17% CPU usage in Python, and 2.5% in C.
gordon@drogon.net wrote:There are various standardised methods for dealing with GPIO in Linux though (the /sys/class interface), as well as some user-developed codes - my wiringPi library is one of them - good for C, C++ and is used in other languages via 'wrapper' functions too - there are Python, PHP, Perl, Java implementations to read/write the GPIO using wiringPi as the underlying 'core' functions.

I'm surprised you had issues installing, and I'd like to know more - can you email me, or reply here about it?

Hey Gordon,
nice to meet you.
I know about coding, but aren't too skilled in dealing with all the libraries and dependencies around it. I installed Wiringpi through git and used the new ./build script. I'm a bit surprised you need additional parameters for compiling. I figured out the script would add wiringpi to the gcc libraries. The parameters are " -L /usr/local/include/ -L /usr/local/lib/ -lwiringPi" as pointed out in https://projects.drogon.net/raspberry-p ... d-install/ comments
[quote]gcc -o “%e” -l/usr/local/include “%f” -L/usr/local/lib -lwiringPi[/.quote]
there's another post saying you need "-L /usr/local/include" since lowercas "-l /usr/local/include" doesn't work

Anyway, WiringPi seems to work well and offers a lot of functionality. Keep up the good work Gordon :D
Posts: 3
Joined: Thu Sep 27, 2012 11:35 pm
by gordon@drogon.net » Fri Sep 28, 2012 9:09 pm
ThijsDeschildre wrote:well yes, in Python it's easier to read a pin, but I insist to write in C.
I'm working with a really old fashioned 5x10 LED matrix that's multiplexed. At 1000hz refresh rate I get 17% CPU usage in Python, and 2.5% in C.
gordon@drogon.net wrote:There are various standardised methods for dealing with GPIO in Linux though (the /sys/class interface), as well as some user-developed codes - my wiringPi library is one of them - good for C, C++ and is used in other languages via 'wrapper' functions too - there are Python, PHP, Perl, Java implementations to read/write the GPIO using wiringPi as the underlying 'core' functions.

I'm surprised you had issues installing, and I'd like to know more - can you email me, or reply here about it?

Hey Gordon,
nice to meet you.
I know about coding, but aren't too skilled in dealing with all the libraries and dependencies around it. I installed Wiringpi through git and used the new ./build script. I'm a bit surprised you need additional parameters for compiling. I figured out the script would add wiringpi to the gcc libraries. The parameters are " -L /usr/local/include/ -L /usr/local/lib/ -lwiringPi" as pointed out in https://projects.drogon.net/raspberry-p ... d-install/ comments
gcc -o “%e” -l/usr/local/include “%f” -L/usr/local/lib -lwiringPi[/.quote]
there's another post saying you need "-L /usr/local/include" since lowercas "-l /usr/local/include" doesn't work

Anyway, WiringPi seems to work well and offers a lot of functionality. Keep up the good work Gordon :D


To compile your own code, you should just need to add

-lwiringPi

to the compile line. But then, I'm using Debian (Raspbian), maybe your on Arch and it has a different setup for gcc?

If you needed to change anything to make wiringPi compile and install, then please let me know - just email as much details as you can.

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1540
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by mntmst » Sat Oct 06, 2012 12:16 am
I working on a project to include the RPi GPIO and GERTBOARD into the Comedi daq driver library. Most of the actual RPi GPIO code has been taken from others that understand the device much better than I do.
This allows the development of programs with a common DAQ abstraction level.

The driver under development is here (DIO 4 pins only now).
https://github.com/nsaspook/daq_gert daq_gert.c

This video shows a demo program running on the RPi board that can also run unchanged at the source code level on a NI DAQCard-700 pcmcia card on X86 Linux.
http://www.flickr.com//photos/nsaspook/ ... 5094/show/

I have a gertboard on order but have an unknown shipping date. I may just have to breadboard the ADC and DAC chips to get started on that code sooner.
Posts: 16
Joined: Thu Sep 27, 2012 11:26 pm
by gordon@drogon.net » Sat Oct 06, 2012 10:21 am
mntmst wrote:I have a gertboard on order but have an unknown shipping date. I may just have to breadboard the ADC and DAC chips to get started on that code sooner.


Should be pretty trivial to put the same ADC/DAC on the Gertboard on a breadboard setup - just join the dots ;-)

And if you want example code, then do have a look at the adc/dac drivers I put together for the Gertboard as part of wiringPi. https://projects.drogon.net/raspberry-pi/gertboard/analog-inout/

It uses the kernel SPI drivers. You can load them with

Code: Select all
gpio load spi


if you've installed wiringPi.


-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1540
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by mntmst » Sat Oct 06, 2012 5:15 pm
I plan to use the kernel level code like in spi-bcm2708 inside my module to communicate with the devices so I won't be needing the userland (ioctl) interface. This allows a program written using the Comedi library a measure of isolation from the underlying hardware. I've written SPI device driver code for PIC18 controllers before so I have pretty good handle on the SPI basics.

Thanks for the great code in wiringPI.
Posts: 16
Joined: Thu Sep 27, 2012 11:26 pm
by Dogga » Mon Oct 08, 2012 9:53 pm
Ok. Im still a little confused at to whether the library will load.
But I will try to run the LED test you have provided on your web page.
I hope its alright to contact you again if I am still having trouble. It looks like just the right thing I need for my project so am just eager to get it running smoothly as quickly as possible and due to my inexperience what may be minor glitches to you seem like major throwbacks to me!

thanks very much

Laura
Posts: 8
Joined: Mon Sep 17, 2012 3:50 pm
by mntmst » Wed Oct 10, 2012 4:17 am
Here is a HOWTO to test the daq_gert module. It's still in development but most of the DIO function code is in place with fake analog devices in place for now.

https://github.com/nsaspook/daq_gert/bl ... _HOWTO.txt
Posts: 16
Joined: Thu Sep 27, 2012 11:26 pm
by Pieter-Jan5000 » Sat Oct 13, 2012 8:50 am
To do it in a similar fashion as provided by the eLinux website you can simply use this:

Code: Select all
#define GPIO_READ(g)    *(gpio + 13) &= (1<<(g))


You can check chapter 6 of http://www.raspberrypi.org/wp-content/u ... herals.pdf to see why this works.

Hint: GPLEV is 13 registers away from the gpio base address (0x 7E20 0000). This is a 32-bit value that shows which GPIO pin's are 1 or 0, so you have to mask out the bit you want to read with an and-operation.

Sorry if this was already said. I did not have time to read everything.
http://www.pieter-jan.com/
Posts: 37
Joined: Tue Jun 12, 2012 7:20 pm
by mntmst » Thu Oct 25, 2012 2:02 pm
mntmst wrote:Here is a HOWTO to test the daq_gert module. It's still in development but most of the DIO function code is in place with fake analog devices in place for now.

https://github.com/nsaspook/daq_gert/bl ... _HOWTO.txt


Updated the driver with analog input support using a PIC18 SPI slave as substitute for the Gertboard device (Still waiting for mine)

PIC slave code: https://github.com/nsaspook/daq_gert/bl ... C/SlaveO.c
Posts: 16
Joined: Thu Sep 27, 2012 11:26 pm
by Yfory » Tue Nov 06, 2012 11:09 pm
Hi Gordon,

I really like the concept of your WiringPi project, but I just can't appreciate it being released with an LGPL license. I feel it would have been a much better service to the community if it had an MIT license (or compatible). Of course, this is just my humble opinion and in no way meant to lessen the great work you have put in to the project!
Posts: 96
Joined: Thu Apr 19, 2012 10:29 am
by gordon@drogon.net » Wed Nov 07, 2012 7:59 am
Yfory wrote:Hi Gordon,

I really like the concept of your WiringPi project, but I just can't appreciate it being released with an LGPL license. I feel it would have been a much better service to the community if it had an MIT license (or compatible). Of course, this is just my humble opinion and in no way meant to lessen the great work you have put in to the project!


Why?

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1540
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by Yfory » Wed Nov 07, 2012 8:27 am
gordon@drogon.net wrote:Why?


I feel LGPL is an unhealthy compromise between GPL and MIT...

I am sure you know; GPL would have meant that no one could create a commercial product from your code, more or less. If that's the aim, then I would have felt more comfortable with a GPL license. GNU themselves hold a page suggesting that you should not use LGPL but rather GPL.

There in lays the issue from my perspective. Your code is fantastic, and there is a significant chance that many people experimenting with the Pi for small business ideas will not know the difference between compiling your code into theirs and linking to it as a library. As a result they will place themselves as risk of being sued by you (not to say that you would!), when the Pi could represent a chance for someone to do that small business dream they never thought possible.

RPi.GPIO for Python has been released under MIT, but not every piece of software is going to be coded using Python; people I know see WiringPi as a great way to learn C. No such licensed libraries are currently available for C/C++. mikem's alternative is GPL'd, as noted above, this stops a lot of business models developing.

Any code I build and place on github related to the Pi is released under MIT, etc. so I practice what I'm saying; and I'm not against GPL, I just believe LGPL is an unhealthy compromise. :)

As I said, your code is fantastic, it will help many, as a result, it also stands a chance of putting many who do not know C/C++ as well as you/I/other seasoned coders at risk.

In all honesty, I think that certain projects are deserving of community bounties, e.g. the community donate to see it happen. Your GPIO libraries and the accelerated X drivers are great examples of bounties I am sure many would be willing to donate to.
Posts: 96
Joined: Thu Apr 19, 2012 10:29 am
by gordon@drogon.net » Wed Nov 07, 2012 10:43 am
Yfory wrote:
gordon@drogon.net wrote:Why?


I feel LGPL is an unhealthy compromise between GPL and MIT...

I am sure you know; GPL would have meant that no one could create a commercial product from your code, more or less. If that's the aim, then I would have felt more comfortable with a GPL license. GNU themselves hold a page suggesting that you should not use LGPL but rather GPL.

There in lays the issue from my perspective. Your code is fantastic, and there is a significant chance that many people experimenting with the Pi for small business ideas will not know the difference between compiling your code into theirs and linking to it as a library. As a result they will place themselves as risk of being sued by you (not to say that you would!), when the Pi could represent a chance for someone to do that small business dream they never thought possible.

RPi.GPIO for Python has been released under MIT, but not every piece of software is going to be coded using Python; people I know see WiringPi as a great way to learn C. No such licensed libraries are currently available for C/C++. mikem's alternative is GPL'd, as noted above, this stops a lot of business models developing.

Any code I build and place on github related to the Pi is released under MIT, etc. so I practice what I'm saying; and I'm not against GPL, I just believe LGPL is an unhealthy compromise. :)

As I said, your code is fantastic, it will help many, as a result, it also stands a chance of putting many who do not know C/C++ as well as you/I/other seasoned coders at risk.

In all honesty, I think that certain projects are deserving of community bounties, e.g. the community donate to see it happen. Your GPIO libraries and the accelerated X drivers are great examples of bounties I am sure many would be willing to donate to.


So... This isn't really the thread topic to discuss this, however... I've just spent half an hour reading up (again) the merits or otherwise of the various licenses.

FWIW: WiringPi was originally GPLv3 and I was persuaded to move it to LGPLv3 and the argument put to me at the time was a very good one. (Thanks, Friggle)

As for MikeM's "alternative"... He originally took wiringPi when it was GPLv3 and hacked it about to his own uses without any attribution. Shame on him, but hey ho...

The difference between someone compiling my code into their code and linking to it is so minimal that it's not worth anyones time borthering about it. Really. There's no difference from my point of view. I have also helped people in the past incorporate wiringPi into their own projects (and sometimes even been paid for it!) most of the time it's nothing more than explaining how a Makefile works...

Then there's the differences between the LGPL and MIT licenses - it boils down to what's called "copyleft" which essentially says that if you modify the (wiringPi) code, then you must release that modified code.

The LGPL says that you only need to release the modified code - not your own code, proprietary or otherwise. The LGPL doesn't "taint" your own code - it stands on it's own.

The MIT license doesn't have the "copyleft" part, so if you modify any MIT licensed code then you don't need to do anything. Keep it to yourself if you like.

Neither licenses prevent selling your product with the open-sourced code.

This page has a good summary:

http://www.cnx-software.com/2011/10/10/open-source-licenses-overview-gpl-lgpl-apache-bsd/

See the paragraph headed: Practical Examples

So I've had a think about it, and for now, I want people to publish modified versions of wiringPi, so I am going to keep it under the LGPLv3. If just one person can benefit from someone elses changes to wiringPi, then IMO that's good.

I have had several people feed their changes back to me and sometimes I've even incorporated them into the main project (with attribution). I don't need to, but again, sometimes it's for the good. The MIT thing looks like a grab all you can get (for free) and give nothing back license. At least GNU enforces (or tries to enforce) sharing, and I like sharing. That's why I give wiringPi away for free. Share and enjoy.

If you modify wiringPi, then all you need to do is stick a .tgz on a website somewhere and reference its location in your product, and if you don't have that facility, then I'll do it for you.

Of-course, if you want a proprietary license for wiringPi, then by all means ask for it. And you can pay me for it and optionally pay me to support it, but for the most part most people seem happy with the way it is.

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1540
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by Yfory » Wed Nov 07, 2012 2:43 pm
Hi Gordon,

Thanks for taking the time to consider my point of view; I appreciate that and respect your decision.

I still think that there is mileage in you receiving donations for the work you have put in to WiringPi. :)

As for MikeM's "alternative"... He originally took wiringPi when it was GPLv3 and hacked it about to his own uses without any attribution. Shame on him, but hey ho...


That's a shame and I wasn't aware of that had occurred, both GPL and MIT require you to attribute the original author somewhere along the way and it's a real shame when people omit to do so.

Of-course, if you want a proprietary license for wiringPi, then by all means ask for it. And you can pay me for it and optionally pay me to support it, but for the most part most people seem happy with the way it is.


I think the above should be noted on your website; as I wrote before, some people may have small business ideas and not want to make their code or "how it works" public. If they have the option of buying a more suitable licensed edition from yourself at a reasonable fee that is accessible to small businesses, then it's the best of both worlds.

I sincerely hope I caused no offence. :)
Posts: 96
Joined: Thu Apr 19, 2012 10:29 am
by gordon@drogon.net » Wed Nov 07, 2012 7:43 pm
Yfory wrote:Hi Gordon,

Thanks for taking the time to consider my point of view; I appreciate that and respect your decision.

I still think that there is mileage in you receiving donations for the work you have put in to WiringPi. :)

As for MikeM's "alternative"... He originally took wiringPi when it was GPLv3 and hacked it about to his own uses without any attribution. Shame on him, but hey ho...


That's a shame and I wasn't aware of that had occurred, both GPL and MIT require you to attribute the original author somewhere along the way and it's a real shame when people omit to do so.

Of-course, if you want a proprietary license for wiringPi, then by all means ask for it. And you can pay me for it and optionally pay me to support it, but for the most part most people seem happy with the way it is.


I think the above should be noted on your website; as I wrote before, some people may have small business ideas and not want to make their code or "how it works" public. If they have the option of buying a more suitable licensed edition from yourself at a reasonable fee that is accessible to small businesses, then it's the best of both worlds.


You're probably right. I made a start with some other (non Pi) code, but have been busy elsewhere recently...

Yfory wrote:I sincerely hope I caused no offence. :)


Dim wories.

Slàinte,

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1540
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK