Easy GPIO Hardware & Software


134 posts   Page 1 of 6   1, 2, 3, 4, 5, 6
by meltwater » Wed Nov 16, 2011 12:35 pm
Hi Guys/Gals.

I'm hoping to get a little more information regarding the use of the GPIO on the latest version of the device.

My current understanding is that the board will come without header pins on the GPIO (makes sense to protect against user related murder of the device). I am guessing later versions will have connections added, particularly for the education units (or some poor soul with have a classroom worth of devices to solder).

Also, I believe there was an LED and some switches on the GPIO which have been removed from the Alpha board for this final design. Is the wiring totally removed from the board or just not populated? i.e easy to add back on if required.

Finally, what software support is there for controlling the GPIO pins, is it built into any of the programming platforms yet (python, ruby) or is it possible directly through the distro? i.e. Can I solder on the header pins, connect up a few leds and switches and start to drive them once it's booted or is there still work needed to be done to access these pins? Not having any linux knowledge how difficult is this?

Clearly we are interested in the other ports on the device too and what we can and can not use them for, but the GPIO seems to be one of the key features which can be used for a wide range of applications. So hopefully a little information will help me and others with the ideas and concepts we have in mind to get an idea of what we can do out of the box.

Thanks.
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam
User avatar
Posts: 993
Joined: Tue Oct 18, 2011 11:38 am
by Gert van Loo » Wed Nov 16, 2011 1:03 pm
User avatar
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2081
Joined: Tue Aug 02, 2011 7:27 am
by meltwater » Wed Nov 16, 2011 1:55 pm
Yes I've been following that thread, the best I can anyway (more of a softy).

Certainly keen on the Gertboard and will be very keen to get one (whatever form it takes), I'm just wondering if flashing LEDs etc out of the box will be on the cards?

As I said I'm not familiar with linux so I don't know how you'd go about interfacing with low level hardware etc. through the os and how drivers etc fit in or if any of the groups such as KidRuby have been able to put I/O support in using Alpha boards.

I take it that the support won't be there at first, but hopefully when final devices get out there then I guess support will be close behind. I am hoping it is similar to other embedded software where you setup the registers and address the pins, I might stand a chance then.
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam
User avatar
Posts: 993
Joined: Tue Oct 18, 2011 11:38 am
by dom » Wed Nov 16, 2011 2:28 pm
GPIO driver will be standard linux. See here:
http://www.mjmwired.net/kernel.....n/gpio.txt

You can control it by reading/writing files in /sys/class/gpio/ from linux console and bash scripts.
I'm sure there also exist libraries to do this in C and other languages.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4043
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by meltwater » Wed Nov 16, 2011 2:42 pm
Thanks, I've got some learning to do! :D
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam
User avatar
Posts: 993
Joined: Tue Oct 18, 2011 11:38 am
by WizardOfOZ » Wed Nov 16, 2011 4:10 pm
Currently there simply isn't enough information available to start work in earnest, when it comes to the GPIO port. So please don't despair if you seem to run straight into a brick wall. The key sentence in the linked text provided by dom is this one:

The exact capabilities of GPIOs vary between systems.


My suspicion is that we will get the info required, once the boards have been shipping for a while. By then the key people may have had a chance to look at other issues beyond getting the core OS up and running, and I suspect a zillion other little things taking precedence for the main mission of the Pi to succeed.
Posts: 76
Joined: Thu Oct 13, 2011 8:08 am
by abishur » Wed Nov 16, 2011 5:05 pm
My basic understanding of your question is that yes, they removed some switches/leds from the alpha board for the final board. The good news is that these removals were planned from the get go, and not a last minute ditch. To get everything to fit on the smaller board size, they had to cut out some items, but that's what the gert board is for. It provides extend functionality for those who need it.

Now as for accessing it, my understanding is limited but here goes

For any program you must first load the physical address location of the gpio you want to use then you can move a bit (on/off) into the gpio address or read the state. It is my hope that people who are smarter than I am will make a basic framework program that provides the various addresses as a method that we can put into our programs and call whenever we want to read from or write to the GPIO address during a specific condition.
Dear forum: Play nice ;-)
User avatar
Forum Moderator
Forum Moderator
Posts: 4307
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by Lakes » Wed Nov 16, 2011 5:51 pm
Reminds me of the old PEEK and POKE commands in BASIC. :)
Posts: 267
Joined: Wed Aug 24, 2011 2:17 pm
by Burngate » Wed Nov 16, 2011 6:09 pm
So we'll need to know the physical address of the gpio? When will we be told this / given somewhere to go to find out? At launch? Or when edu. roll-out begins? Or should I just try prodding around, then publish my findings? Same goes for things like the frame-buffer. Though blind prodding is a waste of time if the info will already be out there.
If this (or things like I2C) is handled through the GPU, I remember reading something about messages, so learning about those is on my to-do list.
Wyszkowski's Second Law: Anything can be made to work if you fiddle with it long enough.
Brain surgery is easier than psychoanalysis
User avatar
Posts: 2931
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK
by eggn1n3 » Wed Nov 16, 2011 6:41 pm
You would expect that as this is a Broadcom chip (BCM2835), Broadcom would have some documentation about the GPIO lines and corresponding addresses (it could be that the Raspberry Pi does not use all of the available IO pins of course).
If these IO addresses are known, you could do something like this:
http://forum.sparkfun.com/view.....hp?p=52483
As Eben is working for Broadcom, would he know?
Posts: 106
Joined: Fri Jul 29, 2011 10:36 am
by WizardOfOZ » Wed Nov 16, 2011 6:49 pm
Quote from Burngate on November 16, 2011, 18:09
So we'll need to know the physical address of the gpio?

No, we need to know (at least):

  • How many I/O pins there are.
  • Organization/bit ordering of actual I/O pins.
  • Which peripherals are there (I2C, SPI, etc.)
  • Specs of any peripherals, and 'command protocols' for same.
  • Peripheral multiplexing with ordinary 'plain' I/O pins, if any, and how to switch around between them.
  • What the initialization procedure is (if not built into any driver provided).
  • 5V tolerant inputs? (Guessing no...)
  • Max. sink/source current.
  • Driver functionality (assuming Linux kernel module).
  • The little things we would never guess in a million years, and which would prevent our contraptions from working.


and all the rest I forget right now. This is not like on a C64, and unfortunately we cannot just prod around and hope to discover any of this. We simply need an excerpt of the relevant parts of the BC SoC datasheet. :)

As to when? I am guessing we may not have this at launch, if that alone would mean a delay for no other reason. Seems the hardware people already have their work cut out for them, so I intend to just hang around and wait for the info to become available.

In another thread Liz recently told us we would probably get to know which peripherals are on there 'soon', but even that won't be enough to start hacking away.
Posts: 76
Joined: Thu Oct 13, 2011 8:08 am
by meltwater » Wed Nov 16, 2011 9:20 pm
I've no doubt that the info will be made available and the R-Pi people will give us the support needed. At present things will be very busy with double/triple checking the initial boards, which is obviously fair enough.

Also, I expect they are keeping info limited until things are shipped to avoid too much upset if there are any last minute changes. The last thing you want is people spending time and money developing things which are not going to be of use.

For now it is useful for noobs like me to gain an idea of what kind of interfaces and ways such things are accessed. Not all of us are linux gurus (yet...lol). My initial aim would be very similar to the sparkfun link above, otherwise could just program using a normal computer/tablet.

The removal of the switches and led is fair enough, interesting though since I guess they probably formed part of the board testing, which means there are possible things available or at least a starting point. Part of me is also keen to see how the education setup will work out, so I was interested to see if any initial interfacing was in place.

The capabilities of the chip look spectacular, so there is huge potential I guess we will have to wait to see how this potential translates on the physical device. It is clear that they've been living and breathing this device for sometime so it is quite clear that they will use every opportunity to help it develop as far as possible. Just hope they are willing to throw their baby to wolves soon.
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam
User avatar
Posts: 993
Joined: Tue Oct 18, 2011 11:38 am
by jamesh » Wed Nov 16, 2011 9:47 pm
Quote from WizardOfOZ on November 16, 2011, 18:49
Quote from Burngate on November 16, 2011, 18:09
So we'll need to know the physical address of the gpio?

No, we need to know (at least):

  • How many I/O pins there are.
  • Organization/bit ordering of actual I/O pins.
  • Which peripherals are there (I2C, SPI, etc.)
  • Specs of any peripherals, and 'command protocols' for same.
  • Peripheral multiplexing with ordinary 'plain' I/O pins, if any, and how to switch around between them.
  • What the initialization procedure is (if not built into any driver provided).
  • 5V tolerant inputs? (Guessing no...)
  • Max. sink/source current.
  • Driver functionality (assuming Linux kernel module).
  • The little things we would never guess in a million years, and which would prevent our contraptions from working.


.


I'll try and answer (from memory) so please excuse possible mistakes.

16 or 17. Now the map I saw had gaps in (there are lots more GPIO on the chip than exposed) so I am not sure if the driver maps 0-16 to the order on the 2735. Maybe.
I2C and SPI were there I think, and camera interface.
Driver will handle initialisation.
Think you will need buffers for 5v tolerance (Gert's board would help there, that has those designed in, as well as lots of other goodies)
Driver conforms to the standard Linux GPIO driver spec. See Dom's link above.

So, nothing to peek or poke, just use the linux driver.

I think.
Volunteer at the Raspberry Pi Foundation, helper at Picademy September and October 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11964
Joined: Sat Jul 30, 2011 7:41 pm
by eggn1n3 » Wed Nov 23, 2011 12:31 pm
Well, there are several ways to access GPIO.
1. Using the driver, in this case you can access GPIO from /sys/class/gpio/ for example or use the gpiolib framework.
2. Connect to the IO (memory) address directly like this example in C:
gpio = mmap(0, getpagesize(), PROT_READ|PROT_WRITE, MAP_SHARED, fd, GPIO_BASE);
(http://forum.sparkfun.com/view.....hp?p=52483)

There are possibily more ways to access the GPIO lines...
Posts: 106
Joined: Fri Jul 29, 2011 10:36 am
by meltwater » Thu Dec 01, 2011 1:30 pm
Thank you for all the above information, it really helps to give me an idea of what accessing the pins will involve on the software side, it sounds similar to what I was expecting but being new to linux it was something I wasn't sure about (I hope that when the boards come out the various ways will be a little clearer anyway).

In order to keep with the theme of this thread (the "easy" bit), particularly since more details are now available, I would like to ask about the hardware side.

The question is, what is simplest hardware required you'd recommend to interface to the GPIO?
In this instance I'm thinking a few discrete components rather than isolating ICs etc (I've been following the other threads and a huge range of solutions have been thrown around, all with their own merits, but well beyond casually trying something out).

I'm hoping that beginners can get started with some very simple bread/veroboard circuits, learn a little about the device and hopefully not kill it.

1. LED output
2. Small DC motor drive
3. Simple on/off switch input
4. Analogue sensor driving a digital input (i.e use a variable resistor to set the trigger threshold).
5. Analogue input via an ADC (that is probably over the level I'm thinking of, but still).

I'll have a look around and see what resources I can find, but thought it might be useful for others to get an idea on this too. I'll draw up some suggestions too, but my knowledge is limited anyway, so I keen to hear what considerations have to be taken.
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam
User avatar
Posts: 993
Joined: Tue Oct 18, 2011 11:38 am
by hippy » Thu Dec 01, 2011 3:30 pm
Quote from meltwater on December 1, 2011, 13:30
The question is, what is simplest hardware required you'd recommend to interface to the GPIO?


A LED on one GPIO, a push button on another.

That's the simplest hardware everyone can understand and even novices should be able to follow the instructions to do that.

Those with electronics experience but lacking Linux skills may need help in understanding how to control the LED and read the button, so provide a simple tutorial showing; how to turn the LED on and off and how to tell if the button is pushed, for example, turn the LED on when the button is pushed.

It may seem simple but I believe a lot of people will be very grateful for that plus it covers the foundations for everything else and it's probably best to get a simple tutorial done and dusted before moving onto more complicated things.
Posts: 820
Joined: Fri Sep 09, 2011 10:34 pm
by eggn1n3 » Thu Dec 01, 2011 3:42 pm
I agree that a simple LED and push button with some basic IO examples in multiple programming languages could get people up to speed. In fact, if the Raspberry Pi wants to become succesful it is imperative that there is good documentation available besides a low price.

If I have the time, I will for sure write some howtos how to access IO.
Posts: 106
Joined: Fri Jul 29, 2011 10:36 am
by jamesh » Thu Dec 01, 2011 4:04 pm
Remember that the GPIO's are unbuffered - so it will be safer to have some circuitry in their to buffer rthe device against nasty shocks.

The Gertboard provides this - but you will need to solder it up yourself! That said, you only do the bits you need, and it will be a good introduction to all things GPIO.
Volunteer at the Raspberry Pi Foundation, helper at Picademy September and October 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11964
Joined: Sat Jul 30, 2011 7:41 pm
by meltwater » Thu Dec 01, 2011 4:36 pm
I'd love a gertboard! More than happy to solder it up, it's the design side I'm lacking.

If you put everything through transistors to switch (Darlington-pair for the higher power things), is that enough to buffer?
[will draw up my imagined circuits later]
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam
User avatar
Posts: 993
Joined: Tue Oct 18, 2011 11:38 am
by WizardOfOZ » Thu Dec 01, 2011 5:09 pm
Quote from jamesh on December 1, 2011, 16:04
Remember that the GPIO's are unbuffered - so it will be safer to have some circuitry in their to buffer rthe device against nasty shocks.
I assume there are limits to the current the SoC pins are able to sink and/or source, along with limits to total allowable ground- and supply pin current(s) as well? Most modern 3.3V MCUs can sink a few mA per pin, yet many can hardly source much current at all.

Unless told otherwise many people may assume they can treat the SoC like a 5V PIC. IE. 16x20mA sink current may perhaps be a bit too much? :)

In any case a few resistors plus a BC547x per pin should do the trick for most LED driving situations, barring more detailed specifications.
Posts: 76
Joined: Thu Oct 13, 2011 8:08 am
by meltwater » Tue Dec 06, 2011 2:35 pm
Right, here are my basic circuits…hopefully I"m not a 1000 miles away from what is required.

Circuits
http://forum.xda-developers.com/picture.php?albumid=1033&pictureid=17837
1. LED output
Directly driven (will need very low powered LED) or driven via transistor (allowing higher current).
2. Small DC motor drive
MOSFET or Darlington Pair to provide high power drive and reverse bias diode to protect from motor coils. (Input voltage may also need to be higher of course depending on the motor).
3. Simple on/off switch input
Top resistor pulls pin high when switch not active. Capacitor used to smooth the switching.
4. Analogue sensor driven as a digital input

Am I anywhere near the right kind of circuits? Or have I got my assumptions wrong?
Oh also seen elsewhere, may need to put a diode on the 5V supply (or use the 3.3V supply instead) to avoid over-voltage on the lines.

At the very least it should make the seasoned hardware guys chuckle.

Thanks.

[UPDATE] Added circuit 4.
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam
User avatar
Posts: 993
Joined: Tue Oct 18, 2011 11:38 am
by meltwater » Thu Jan 05, 2012 10:35 am
Ok, an update of other discussions I"ve been having else where (also the diagram wasn"t viewable for some so updated the location for that).

This discussion is from PCB Prototyping offer thread from Cephas Borg, but I was pushing it too far off topic.

_______________________

meltwater said:


The idea really is to have some standard circuits for people to do the very basics with the R-Pi, on breadboards or stripboards, but a PCB with a selection of these circuits on (say two of each, plus 2 additional LEDs circuits) would be very handy I think for beginners to use.  Obviously they are far more basic than what you are offering anyway, but it"s something which I think will help people with building their understanding of interfacing to hardware on a low level and at very low cost.

My circuits probably aren"t quite right (such as missing protection/smoothing etc) but my electronics knowledge is a little rusty.


_______________________

Cephas Borg said:


I think that"s a great idea to get some interaction going with real-world devices. And your electronics isn"t as rusty as you think! I"d be inclined to add some debouncing to your switch inputs – have a look at the debounce circuits towards the bottom of this page for some ideas. The only other suggestion I"d make would be to use a simple op-amp buffer for your sensors – most sensors are either really low or extremely high impedance, which will either swamp the GPIO pins, or not trigger them at all. It"s easy enough to add multiple op-amps to a "universal" type board, and would give you more options. That said, I"m not entirely sure what Gert"s board does in terms of I/O; nor am I sure how easily the GPIOs can be read/controlled once Linux is running. Lots of learning to be done! I hope this helps!



_______________________

wjrust said:


If R-Pi"s Linux is like that on the BeagleBoard/Bone then it is very easy to read and write GPIO pins in a polling mode. All you have to do is export the pin so it"s visible as a file, set the mux so the physical pin has the desired function and set the direction, either in or out. That"s it. I"ve written Java code to do it, so you can do it in most any language. Many of the examples use cat and echo to read and write the pins (not real useful but entertaining to flash the user leds). One caveat, you might need to run your programs as root. Also, the exports aren"t permanent, so you need to do the exports after every boot. Anyways, good luck.



_______________________

meltwater said:


Apparently the software interfacing as described above, and I would imagine that various groups will produce helpful libraries to use them easily.

The Gertboard, is a beast, and really, really I want one (it uses the SPI to interface with a PIC which then has numerous I/O pins including loads of analogue inputs, as well as motor drivers, all with buffering/protection and lots of other nice features). Frankly, I will probably want most of the boards Gert has been talking about so far! It"s a great piece of kit, but it will cost and will require a little skill to assemble and program. Therefore I think there is room below this, to have some very basic circuits too.

Also I think by having very simple circuits, it allows people to understand how they work better. However, those circuits were my best guess, so I am not really the person to design them as I don"t know what is right from wrong.

Ok, sounds like I"ll need some ICs then (I was avoiding them if possible since not only do they add cost, but I find ICs add a mental barrier to beginners since it is confusing to select and find the correct ones out of the millions of black legged bugs out there).

1. Would using an Op-Amp buffer also protect the GPIO, or would an optocoupler be better (would that then avoid the need for an op-amp too)?

2. Are the ST (schmitt triggers) totally necessary, isn"t that something which could be countered by software de-bouncing instead?


_______________________

So that"s the story so far, and I would like to continue it, as I said, need help and advice.

I think the goal after we have some circuits is to create a wiki with various versions for prototype/breadboards, for vero/stipboards, and hopefully some ready made PCBs, with some help and advice about what components to use and where to get them from.
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam
User avatar
Posts: 993
Joined: Tue Oct 18, 2011 11:38 am
by meltwater » Thu Jan 05, 2012 4:14 pm
Ok...here's something else, as pointed out by Point3Forever in this thread http://www.raspberrypi.org/for.....o-analysis

It's the launchpad...it's key features of interest are $5 price (£3.64 from Farnell), SPI and 8 channel ADC...

http://processors.wiki.ti.com/.....-EXP430G2)

It is lacking any I/O protection, but I hope to have something in my circuits to cover that, and at the very least it'll only blow the launchpad not R-Pi.

For me this will be a good stop gap (if I can use it) before:

a) the R-Pi comes and,

b) before the Gert board is available (potentially it could operate like the Gert board is intended to).

Thoughts??
______________
http://www.themagpi.com/
A Magazine for Raspberry Pi Users
Read Online or Download for Free.

My new book: goo.gl/dmVtsc

Meltwater's Pi Hardware - pihardware.com

Like the MagPi? @TheMagP1 @TheMagPiTeam
User avatar
Posts: 993
Joined: Tue Oct 18, 2011 11:38 am
by Tomo2k » Thu Jan 05, 2012 6:25 pm
meltwater said:

2. Small DC motor drive
MOSFET or Darlington Pair to provide high power drive and reverse bias diode to protect from motor coils. (Input voltage may also need to be higher of course depending on the motor).



The motor drive would need to have the transistor between the motor and gnd, as drawn it won't work and may damage the RPi.
- I would also use an opto-isolator to drive a MOSFET to protect the RPi from under/overvolt from motor start/stop. This also allows the motor to have a completely separate power supply at any (safe) voltage.

The GPIO inputs to the RPi are not 5v-tolerant, so all inputs must be 3v3.

The GPIO port provides a 3v3 supply pin that can source a max. of 50mA, bear that in mind when selecting resistor values.
Posts: 126
Joined: Mon Dec 19, 2011 10:00 pm
by hippy » Thu Jan 05, 2012 7:32 pm
Tomo2k said:

The GPIO inputs to the RPi are not 5v-tolerant, so all inputs must be 3v3.


It's usually possible to connect higher voltages ( even mains ) to GPIO pins through simple use of a suitable current limiting resistor.

That should work with the R-Pi ( it has with every device I've ever tried ) but without the GPIO electrical specification I cannot say that it will work, won't damage the R-Pi or suggest what a suitable resistor value would be.
Posts: 820
Joined: Fri Sep 09, 2011 10:34 pm