Easy GPIO Hardware & Software

[Gert van Loo]

bredman said:

There seems to be major confusion about the pitch of the expansion pins.

According to several sources, for example http://elinux.org/Rpi_GPIO, the pitch is 1.27mm (50 mil). However Gert says 2.54mm (100 mil).

Gert is one of the few people who has handled a beta board, so I assume he is correct.

Can we get a clear statement on the pitch for the production boards? Not the beta boards. I will update any errors in wikis that I find.

1.27mm (50 mil) was the Alpha board.

2.54mm (100 mil) is the Beta board.

Beta board IS the production board, at least for the first 10K. Nobody knows what the future holds but I would assume the foundation will try to stick close to what is already out there. e.g. if there will be more GPIO pins the first 26 will be the same.

It takes a while to do a major re-design. So depending on the demand, my guess is that they will stick with the dimensions for at least the next 100K.

Gert, thanks for the clarification.

Glad to see the move to 100mil, it is less scary for amateurs with soldering irons in their shaky hands. Also easier to buy/scavenge components.

Gert said:

bredman said:

There seems to be major confusion about the pitch of the expansion pins.

According to several sources, for example http://elinux.org/Rpi_GPIO, the pitch is 1.27mm (50 mil). However Gert says 2.54mm (100 mil).

Gert is one of the few people who has handled a beta board, so I assume he is correct.

Can we get a clear statement on the pitch for the production boards? Not the beta boards. I will update any errors in wikis that I find.

1.27mm (50 mil) was the Alpha board.

2.54mm (100 mil) is the Beta board.

Beta board IS the production board, at least for the first 10K. Nobody knows what the future holds but I would assume the foundation will try to stick close to what is already out there. e.g. if there will be more GPIO pins the first 26 will be the same.

It takes a while to do a major re-design. So depending on the demand, my guess is that they will stick with the dimensions for at least the next 100K.

wiki updated with link, thanks for pointing it out!

[Gert van Loo]

Not exactly related:

I have no HTML knowledge (Well you can't know everything) but I often want to add data to a more public available place then a forum. e.g. I recently uploaded C-code for mapping the GPIO registers and then access them. It is in the in the education/gertboard forum. Can somebody put that in the Wiki as well??

http://www.raspberrypi.org/for.....ard/page-4

Gert said:

Not exactly related:

I have no HTML knowledge (Well you can"t know everything) but I often want to add data to a more public available place then a forum. e.g. I recently uploaded C-code for mapping the GPIO registers and then access them. It is in the in the education/gertboard forum. Can somebody put that in the Wiki as well??

http://www.raspberrypi.org/for.....ard/page-4

Alpaca had already added it, although just put link on there too.

Looking forward to trying it out for real!

Am I correct in reading the code as follows:

1. Turn on GPIO Pin 7 through to 11


2. Turn off GPIO Pin 7 through to 11


3. Do this process 10 times…

Thanks again!

Humm, the forum doesn"t work nicely with < code > markers it seems, you only get the first line.

I"ve also found the preview button, although the preview lies!  The best so far was using < pre >.

Update to this thread...

I've got a TI LaunchPad sent to me (it worked out at about £2.40 I think - directly from TI, that was including shipping and only two a few days from TX!).

Anyway, this gives me a platform to test the various circuits on and experiment with, as well as an 8-channel 10-bit ADC, so I can test out some sensors too (in particular some IR transceivers which should also work as proximity sensors).

Since the voltage levels are the same as the RPi (3.3V) my circuits should transfer well, and I think the current limits are similar.

So far I've been able to drive a selection of LEDs, take a switch input and today I managed to drive a 2x16 Alpha Numeric LCD display (with the help of http://www.circuitvalley.com/2.....h-pad.html).

Later on I hope to try out the 2-wire interface circuit too (may be useful for other projects), which will be very handy for the RPi (otherwise it uses at least 6 I/O pins)!

--Such a module could make quite a nice standard output device.

I can also experiment with the circuit suggested previously and see how well you can measure analogue signals through the digital input duration.

I've also got a STM32 Primer (V1) to use, which also has GPIO so plenty to mess around with.

meltwater said:

I've got a TI LaunchPad ...

Excellent progress.

For ease of use it would be great to have the LaunchPad communicating over USB via the back channel UART so it appears as a /dev/tty* device and so easily usable from any programming language - do you know if there will be R-Pi drivers to do that ?

Well comms over uart is probably do able.

I don't know about programming/debugging it though (happy to use another pc to do that if required).

Not quite sure if I'll use the LaunchPad directly or just for testing hardware, however it may be possible to interface with it through SPI, I2C if required.  As mentioned before by others, there are probably better solutions out there, but can't argue for the price for a platform to experiment with.

The STM32 Primer could be interesting, since it's got a small screen and motion sensors, and the Circle OS makes it a little easier to program (although not tried the GPIO yet).

Added a wiki page, since I have started trying circuits out using the LaunchPad.

Help and advice is always welcome.

http://elinux.org/RPi_Tutorial.....6_Software

Robin McB said:

Hi – just to add a couple of points:

re: 1 LED Output

I would suggest the following



Note that you drive the IO Pin low to turn the LED on.  The advantage is tha the port outputs are likely to have a higher sink ability (switched "0V") than source (Switched +ve). t also makes calculating the value of RLimit very easy!

i.e. Subtract LED forward voltage (usually between 1V8 and 2V2)  from the supply voltage (3V3) then divide by the current required to light your LED (no more than 3-4mA,  choose a low-current LED).

The Cct you show to drive a higher power LED is pretty much right, I would  make it clear that the supply for the LED can (probably should!) be different from the 3V3(?) RasPi voltage.



This would be used as you show with an LED connected to "OC" or as below to a relay )I"ve shown a BT47W which is an industry standard – and quite cheap   – 2 Pole Change Over relay. This is good for switching quite a few things for experiments. They are also in a standard package and very easy to mount on stripboard, etc. You can also wire to two "poles" in parallel to switch a higher current. NOT for mains use though.



I know this is very basic stuff, but I hope it may be of use to anyone who knows basically what they have in mind but wants a more specific details of what values, etc are likely to actually be!

ok and re: 3 Simple switch.  I"ve made that work (using a 100n cap) connected to 5 PIC chip I/O Port, but with 200m of cable out to the (low quality) switch and a very simple software debounce. I would say you can feel confident that it would work with a reasonable button / switch and a few centimeters from the board!

I"m quite happy share any info re-interfacing, such that I can …

@Robin McB - I somehow missed your post!  Sorry for not commenting on it, very useful information there.

You can see the tutorials (so far just the LED one) starting to take shape now on the wiki:

http://elinux.org/RPi_Tutorial.....6_Software

Feel free to add anything/comment/correct if you wish to.

Update: On the software side…some extra info is in this thread (ukscone using devmem2):

http://www.raspberrypi.org/for.....g-question

bredman said:

Gert, thanks for the clarification.

Glad to see the move to 100mil, it is less scary for amateurs with soldering irons in their shaky hands. Also easier to buy/scavenge components.

Guys, this is my first post so bear with me if I get this wrong.

I am interested in the GPIO port but wonder how feasible it is to hand solder on a 6 layer board?

Since this is a through-hole header, there will be pads on the top and bottom to solder to. It shouldn't be any more difficult than a two-layer board, though you might not be used to having a full plane to sink all the heat away from your iron on power nets.

[rurwin]

If you can solder Veroboard, you can put the header onto a RaspPi.

you might not be used to having a full plane to sink all the heat away from your iron on power nets

It is standard practise to limit the amount of copper connected to vias -- something about heat I think. So it probably would not affect soldering. Anything over a 15W iron shouldn't have a problem anyway.

Yep I should imagine it'll be ok, with care of course (and a decent soldering tip - most cheap soldering irons come with fat ones which can be replaced with finer tips, highly recommended).

There was talk that they might have the headers populated anyway, although it has not been confirmed either way, but Liz did mention that there was a chance that they got left in the pick-list (list of populated components) like the betas, although that was before the delays etc so they may have changed it since.  It'll be a nice bonus if they are, but it shouldn't really be a problem if not (at this stage most people will have to do some kind of soldering to make use of it until plug in boards appear).

Either way, it is worth learning to solder if you are connecting things to the GPIO, so if you are a little rusty, then perhaps have a practise first with some random components or build up some test circuits while you are waiting.

If you (or anyone else) are really worried, then there may well be people locally who will offer to do it for you, or at a push email a local university/collage/school and nicely ask if they will help (they may well be glad if they don't know what a RPi is).

[Gert van Loo]

rurwin said:

.....
It is standard practise to limit the amount of copper connected to vias -- something about heat I think. ....

Look it up on the internet using 'via thermal relief'.

If you do not have thermal relief the copper of your power planes suck away the heat. On hand soldering you notice this because you have to hold the solder iron in place for a long time. (At least if you are soldering the way you should). On automatic (wave) soldering you want all connections to have about the same behavior. (Thermal stress etc.) Also you transfer more heat into the board which again heats  up your ICs: Bad idea.

If you have a good hot solder iron it will take 2-3 seconds per pin. So 26 pins is just over a minute. Environmentalists will hate me for saying this but anyway: If you are new or inexperienced use leaded solder. It is ten times easier.

Back pain is often helped out via thermal relief.

I've done the first tutorial now (hopefully it makes sense and is correct), working on the next one soon hopefully.

http://elinux.org/RPi_Tutorial.....6_Software

Couldn't this all be accomplished very easily by adding a Tinkerforge master brick over usb and adding some bricklets to sense and control things?

http://www.tinkerforge.com/

This is what I intend to do when (if!) I get my Rpi.

This is open source hardware AFAIK with lots of sensors and other stuff available so wouldn't it be better to merge these projects? Perhaps integrate the 'master brick' functionality with the Raspberry?

An SBC that you can just plug sensors and relays in would be a dream for home automation. Considering the popularity of this thread there's a lot of people like me who want to control and monitor things. Problem is I'm a software guy, I prefer to stay away from assembling circuits and soldering 'headers'.

Well, that stuff is neat,  and of course you *could* do that, but it's very expensive and adds additional layers of complexity. It's also USB, so both latency and bandwidth will be severely compromised versus using the native GPIO. And then there's form factor to think about. It solves, I think, a different problem than is being tackled here - giving people like yourself that want to avoid hardware access to some 'real world' interface capability. Which is great, and I suspect something that will happen (probably in a much less coherent way than what they've got there, but happen nonetheless) eventually with Pi addon boards.

Gertboard seems like a similar sort of concept, though less flexible. If you just want a bit of protected I/O and a motor driver or two, might work for you. Even comes with a microcontroller.

This thread is about using the I/O capabilities that the Pi already has, adding minimal extra hardware.

From a brief look at the link, it looks like a great idea.  I like the module design and the easy fitting together of the parts etc.

I think there is room for using this with the RPi, but it would add a lot of extra cost and complication for many projects (just depends on what you are doing/plan to do I suppose).

There are quite a few different kits etc, as well as a lot of information for interfacing stuff with the Arduino, so I want to keep a balance between repeating all that info again, and providing some simple examples which people can be sure are suitable for the RPi.

My current aim is to build up the basics, at bare bones level (by relearning the stuff I've not needed to use for a while – I'm on the software side too).  Once you've got a few basic bits together, it isn't too hard to have a play and experiment to get some useful things working (and interesting stuff to write software for).

At the moment, I am pitching the guides at slightly below my own skill/knowledge level, i.e. the basics I needed to do it (perhaps with some more detail to be added for the software side).  Later on I'll have a look back and see if that is a reasonable level or not, or others can fill in more detail if they feel it is needed (that's why I've classed them as an open project), or just ask and I'll answer what I can and ensure the wiki includes it!

At some point I'll also take some photos of the kit which I build up to do stuff, there shouldn't be anything there which costs too much for the average user and a lot can be done without soldering (although soldering shouldn't be something people should avoid, the hardest bit is holding three/four things at once).

I've just made a start on the following guide:

Alpha-numeric 2x16 LCD Display - It might seem like an odd choice considering the level I've done so far, but having a debug display is always useful for working with, and I am also very keen to get a working 2-wire version ready for the RPi (for those times when a full screen isn't always needed).  Also it helps that a lot of it is well documented already, the 6-wire version already works fine on the TI Launchpad.

There are also some small (and very cheep) 90x60 displays which could also be useful later on, although will get the basics done before moving onto those (there are a huge range of similar ones around - and many people looking at using them, so will hold off until I am ready - plenty more to do here first).

Wouldn't you just use a Linux terminal window as a place to write debug output?

Keeping in mind the intended end users and goals of the Raspi, and how the Broadcom ARM device is a lot more complicated than the simple devices many of us first learned on, I have a few thoughts…

The Raspi is a full up computer with an OS. A bit overwhelming to use as an introduction to microprocessor hardware architecture.

The Gertboard approach of an external 8-bit micro controller (PIC, AVR) as an introductory hardware reference system is best in my opinion. Learning clock timing, predefined pin functions, current source and sink limitations, and lots of other basics on a simple architecture is a needed accessory for the Raspi.

A socketed (sub 1$ cost) 8-bit micro as a target system, with the Raspi as the host development system will keep it simple for beginners.

Something like the WinAVR GCC toolchain running on the Raspi, talking to a simple 8-bit micro that can be breadboard mounted.

Guys,

this might well be a crazy question....

my background is micro controllers and I am a bit of a linux newbie despite having sued it many years ago at uni.

I am very used to having an interrupt routine servicing low level hardware so that input and output events are handled in a timely manner without blocking application processes.

What is the equivalent process for a linux box? is there a way to "hook"an interrupt? do you need to write a driver to be built in the kernel?

Thanks in anticipation.

[plugwash]

Interrupts do exist in the linux kernel and if you need the lowest possible latency response to hardware events then an interrupt handler in a kernel driver would be the way to go. Having said that if low latency is your goal then

What usually happens in userland processes is you (or a library you include) has a big loop round a function like "select" (or it's more modern and efficient replacements "poll" and "epoll") which waits for events on multiple FDs. So your process (or the thread within your process that is responsible for IO) waits* in select until the kernel wakes it up because an event has happened.

There are also signals that can interrupt a userland process at any time but those are normally only used for special cases.

* That is the task scheduler in the kernel removes it from the list of "runnable" threads until the kernel decides it's time to wake it up again.

[plugwash]

Interrupts do exist in the linux kernel and if you need the lowest possible latency response to hardware events then an interrupt handler in a kernel driver would be the way to go. Having said that if low latency is your goal then the SOCs seen on devices like the Pi probablly aren't the best choice, all the caches, memory protection, kernel code etc will make interrupt latencies MUCH higher than on simpler devices.

What usually happens in userland processes is you (or a library you include) has a big loop round a function like "select" (or it's more modern and efficient replacements "poll" and "epoll") which waits for events on multiple FDs. So your process (or the thread within your process that is responsible for IO) waits* in select until the kernel wakes it up because an event has happened.

There are also signals that can interrupt a userland process at any time but those are normally only used for special cases.

* That is the task scheduler in the kernel removes it from the list of "runnable" threads until the kernel decides it's time to wake it up again.

Sorry I missed the above replies until now.

gregd99 said:

Wouldn't you just use a Linux terminal window as a place to write debug output?

Of course, but I don't always intend to have a screen connected to it, so a simple text output is very useful.  Also, the debug in this case would need to be different to the verbose debug you use in non-embedded programming.  For my purposes it is a handy tool.

ridge said:

Keeping in mind the intended end users and goals of the Raspi, and how the Broadcom ARM device is a lot more complicated than the simple devices many of us first learned on, I have a few thoughts…

The Raspi is a full up computer with an OS. A bit overwhelming to use as an introduction to microprocessor hardware architecture.

The Gertboard approach of an external 8-bit micro controller (PIC, AVR) as an introductory hardware reference system is best in my opinion. Learning clock timing, predefined pin functions, current source and sink limitations, and lots of other basics on a simple architecture is a needed accessory for the Raspi.

A socketed (sub 1$ cost) 8-bit micro as a target system, with the Raspi as the host development system will keep it simple for beginners.

Something like the WinAVR GCC toolchain running on the Raspi, talking to a simple 8-bit micro that can be breadboard mounted.

I love the Gertboard approach and I really hope to get one, and if I can build my skills up, produce guides for that too.  However...in some ways that could also be rather overwhelming too (lots of extra electronics etc).  Of course, there is room for both approaches (boards like the Gertboard will be excellent for learning with).

However, adding a few components to the GPIO pins I would say is a small baby step.  Adding additional boards etc is a bigger step, but yes very important and far easier for learning the whole picture.  The oddities, such as controlling the GPIO through linux can easily be smoothed by libraries and access functions so that it resembles any other basic method (see Gerts example code), a lot can be done with very little (when the device is $25, a lot of people will limit what they plan to spend on extras).

People shouldn't be scared to try connecting simple stuff to the RPi GPIO, obviously we just have to be careful to protect it and advise people suitably.  This is why I'm doing it, since I'm not 100% sure about all of it so I'm building up the information (open for comment/corrections etc) so that we can recommend the best possible solutions.

____________________________

I am currently looking at the details for the switch input, one thing I am not sure about is the resistor connected on the GPIO input (a lot of circuits omit this).

I'm guessing that in this configuration, it probably isn't needed (since connection is either direct to ground or through the top resistor).  If round the other way, i.e active high -switch on top, it would be preferable for protection.  Or is it helpful to protect if the GPIO pin is set as an output instead???  What criteria should the value of this resistor be determined by?



I currently have the top resistor as around 10K, which should keep the current low anyway.  The capacitor, 470nF will probably suit, if for some reason software de-bouncing isn't used.