Easy GPIO Hardware & Software

[gregd99]

I read somewhere that the GPIO pins when set to input include a pull-up resistor. this would mean that all you need is a switch to ground.

someone more expert would be able to confirm the pull-up status.

[meltwater]

gregd99 said:


I read somewhere that the GPIO pins when set to input include a pull-up resistor. this would mean that all you need is a switch to ground.

someone more expert would be able to confirm the pull-up status.


Ok, slowly building a clearer picture I hope.

1. An old post from JamesH (http://www.raspberrypi.org/for.....-2/#p26929) mentioned there were no pullups.  I think gert mentioned this too.  For now I"ll stick on the safe side and assume that is right, I take it there isn"t any major implications for experimenting circuits if you add extra pull-ups and pull-downs (obviously if you over do it, it just won"t see any changes).

2. As I suspected, the resistor directly connected to the pin is to protect in case you set the pin to an output instead  [ref:http://www.ladyada.net/learn/a.....sson5.html].  Since it would still only connect to GND it shouldn"t be a major issue (I assume the RPi wouldn"t supply enough current to destroy itself) but since we are going for safe design (and a resistor is a minimal cost to include) I"ll keep it in the circuit.  Value, looks to be about 100ohms, (I=V/R so 3.3/100 gives 33mA) which is probably ok, although I guess it could be even larger, say 470ohm (7mA).

While we are talking about it – the comments on the source and sink currents which gert made [ref: http://www.raspberrypi.org/for.....-3/#p18870, suggests to me they can be quite high, but you risk interfering with the operation and timings on the other pins, so if in doubt, keep it low.  Clearly I can't be totally sure until I can re-test everything on a real RPi.

I still don"t know of any official values, but I am aiming for about 10-5mA for circuits which don"t need any specific amount i.e. swtiching/signals etc.

As always, please correct anything I may have wrong…

[Andyh-rayleigh]

gregd99 said:


someone more expert would be able to confirm the pull-up status.



I'm no expert but have had a look at the "ARM Peripherals" document from Broadcom and there is a diagram on page 89 labelled "Figure 6-1 GPIO Block Diagram" which implies that each pin has a programmable pullup/pulldown as well as a variety of level and edge detect functions. Further on in the datasheet around page 100 is more detail - there is a fancy delayed activation function for changes to these that will complicate changing these "on the fly" or even the initial setup.

Note also that the default access to these pins is one bit at a time - in "ALT1" mode there appears to be byte and 16 bit access ... but no details in that document.

[meltwater]

Andyh-rayleigh said:


gregd99 said:


someone more expert would be able to confirm the pull-up status.


I"m no expert but have had a look at the "ARM Peripherals" document from Broadcom and there is a diagram on page 89 labelled "Figure 6-1 GPIO Block Diagram" which implies that each pin has a programmable pullup/pulldown as well as a variety of level and edge detect functions. Further on in the datasheet around page 100 is more detail – there is a fancy delayed activation function for changes to these that will complicate changing these "on the fly" or even the initial setup.

Note also that the default access to these pins is one bit at a time – in "ALT1" mode there appears to be byte and 16 bit access … but no details in that document.


I must admit I"d not looked into the document in much detail (about time I did some reading).  All this makes me think that this "easy" guide is worth doing…

In light of this information, the pull up/down resistors are optional…it seems.

I"m in two minds about this, I guess if pull up/down resistors are included in the circuit, it makes the coding easier (as you can leave those registers alone).  In fact, the test circuit should be able to be used as both (by not connecting the Vcc), so ultimately this can be explored as part of the guide.  The output protecting resistor is still worth including I think.

[Frank Buss]

For me it looks like the datasheet ( http://www.raspberrypi.org/wp-.....herals.pdf ) says, that you can program a pullup or pulldown function with the GPPUD register (page 100/101) and then with the GPPUDCLK0/1 register for which pins you want to set the programmed function, for multiple pins at once.

I think it is not a good idea to draw more than 3 mA per pin, maybe max 5 mA, see this note from Gert: http://www.raspberrypi.org/arc.....mment-6164 Many chips I know are not damaged, if a pin is shorted to GND for a short time (but the microcontroller program might crash), but if you short it permanent, it could be damaged.

Depending on the value of the internal pullup (for some chips it is in the range from 20 k to 100 k, I didn't found a value for the Broadcom chip), you could use a series resistor of 1 k for protecting it if set as output (assuming standard CMOS threshold levels for detecting 0 and 1). Then you could use a button to GND.

More safe for experiments would be the Gertboard or my GPIO expander board ( http://www.raspberrypi.org/for.....-i2c-board ). Resistors are already included in my board, so any pin can be shorted to GND or VCC permanently without damaging anything. And the Raspberry Pi GPIO ports are not ESD protected, so if you touch one, you could damage it. The PCA9555 I'm using in my board are ESD protected for 2000 V and maybe more because of the series resistors. I'll get the first batch of boards in 2 weeks.

[meltwater]

Yep, I've been watching your board, looks good!

I'll add it to the guides like I've done for the gert board.

I'm planning on producing a section about isolating/buffering the I/O too, but I've not started looking at that yet.

I'll up the protection resistor value as suggested.  Should end up with 10K pull up and 1K protection I expect.

[meltwater]

Update:

I've now added Switch Input tutorial to the completed section (feel free to improve/update etc).

http://elinux.org/RPi_Tutorial.....itch_Input

Next things I plan to do is the multiplexing using shift-registers, then I will probably finish the Alpha-numeric display entry (hopefully will have the 2-wire configuration ready for when I get a RPi).

[naicheben]

Thank you meltwater. Very good wiki page.

The part about definition between HIGH and LOW made me think of what happens when you put a resistor and a capacitor in series (what is shown in the debounce example). Then you have a periode were you can't tell what level the GPIO-Input has.

What will I get when my software reads the pin in the transition?

(sorry about my poor english, I hope you understand my question)

[rurwin]

If you are lucky, you will get a firm transition from 0 to 1 ( or 1 to 0) at some undefined point in the transition. If you are (very) unlucky you will get a period when the value oscillates between 0 and 1. With just an RC circuit and a simple switch, you should be safe.

To be sure to get a firm transition it would be best to put a Schmitt Trigger buffer after the RC circuit. If the signal might have noise on it (maybe the wires are long, the switch is very bouncy, or there is a lot of EMC noise in the environment) then that might be necessary.

[johnbeetem]

naicheben said:

The part about definition between HIGH and LOW made me think of what happens when you put a resistor and a capacitor in series (what is shown in the debounce example). Then you have a period where you can't tell what level the GPIO-Input has.
Another way to handle this is to read the unfiltered GPIO multiple times, with a 1-10 msec delay between reads, and perform debounce in software.  One way is by calculating a majority function.  My favorite way is with a saturating up/down counter, and use the MSb of the counter as the filtered value.  I once did this in hardware to make an electronic organ keyboard using paper clips as switches.  Worked great!  I used 7400 series TTL so didn't even need pull-ups.

[meltwater]

Please feel free to expand those sections if you want to (its not something I've done much with so I left it).

Almost finished with the first part of the shift-register one now (the background work anyway for parallel in, serial out).

I think it is working (using a CD4021) but for some reason input 4 and 8 seem to be linked internally (set one high and the other is high when it reads), but I think it is just a bad chip (I don't have another spare to try).

Any other reason perhaps? It may be since it is being used with 3.3V rather than 5V, not sure.

[Gert van Loo]

Beware that GPIO0 and GPIO1 are preset to be used as I2C interface. So there are 1K8 pulls up resistor on the board.

I have mentioned that elsewhere but the problem is that all these snippet of wisdom I provide are spread around the various forums.

Pull-up and pull-down: Check the data sheet!! There are some enabled from reset. I think they are listed in the GPIO ALT table.

I have not yet release the gertboard demo code used for the video but that code enables the pull-up on GPIO24 & 25 using:

// enable pull-up on GPIO24&25
GPIO_PULL = 2;
short_wait();
// clock on GPIO 24 & 25 (bit 24 & 25 set)
GPIO_PULLCLK0 = 0x03000000;
short_wait();
GPIO_PULL = 0;
GPIO_PULLCLK0 = 0;

[Frank Buss]

Maybe a good place to collect your wisdom, like the pull up resistors on the board, could be http://elinux.org/RPi_Low-leve.....eripherals , which then should be referenced by the FAQ.

[meltwater]

I imagine the whole Pull Up/Down side of it will need some careful explanation at some point for the specifics involved with the RPi.  The source/sink side is also a can of worms too.

I saw the section in the RPi datasheet on the pull up/down registers.  It is something I'll leave for others to explain better I think, I've sided on the cautious side for now and made my testing bits flexible (until I have a go with it I don't want to assume too much of what is needed and what isn't).

Thanks for the code example for setting the registers, seems fine.  Depending on what standard libs are available etc, the guide can be reworked to use less components etc if the software bit is simple enough (nice thing is software hides all of it away, so the hardware is simpler).

We need a Gert wisdom collector…

If you do have random notes you would like put in there then feel free to PM me with it and I can put it in.

Agreed, it can go in the wiki (don't worry about formatting/structure, that can be resolved after).

Reference to where it comes from will be handy though (so we can bring it up if it is wrong…"well Gert said this…")

EDIT: Double Check: Is [Pin12] GPIO1 one of the PWM pins as stated in the wiki?

[rPiWM]

eggn1n3 said:


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?


The Broadcom data for the BCM2835 provides memory map details for most of the peripheral devices. Reading the copy downloaded , I was unable to find the base address for the Pulse Width Modulators (PWM). The PWM resource is useful for motor speed control or, if not physically available, for timing purposes. Section 6, page 91 advises the reader to refer to section 16.2 for more information on GPFSELn to select alternative General Purpose Functions, presumably including PWM resources. The downloaded copy of the BCM2835 data finishes at the end of section 15 page 204.

Q1. What is the base address for the Pulse Width Modulators?

Q2. Is section 16 available for the Broadcom BCM2835?

[naicheben]

meltwater said:

...
Reference to where it comes from will be handy though (so we can bring it up if it is wrong…"well Gert said this…")

EDIT: Double Check: Is [Pin12] GPIO1 one of the PWM pins as stated in the wiki?



Thanks for putting this in to the wiki. The last Question has not been answered jet, is it? As far as I understand it, I have to choose between I2C and PWM for the Pins 11/12.

But I still have I2C on pins 3+5 ?

Are pins 3+5 the first I2C-Bus?

[Bakul Shah]

pwm said:


The Broadcom data for the BCM2835 provides memory map details for most of the peripheral devices. Reading the copy downloaded , I was unable to find the base address for the Pulse Width Modulators (PWM). The PWM resource is useful for motor speed control or, if not physically available, for timing purposes. Section 6, page 91 advises the reader to refer to section 16.2 for more information on GPFSELn to select alternative General Purpose Functions, presumably including PWM resources. The downloaded copy of the BCM2835 data finishes at the end of section 15 page 204.

Q1. What is the base address for the Pulse Width Modulators?

Q2. Is section 16 available for the Broadcom BCM2835?


I think GPFSELn alternative function information is in section 6.2 (page 102), not 16.2. Also see Section 9.5 where it says PWM DMA is mapped to DMA channel 5 (so its address is where ever DMA ch 5 is mapped). At least that is how I read it.

[meltwater]

The pins have been mentioned on this thread:

http://www.raspberrypi.org/for.....pins-11-12

I think perhaps my linking GPIO0 and GPIO1 to pins 11/12 may be incorrect, so hopefully we can work it out.  Can resolve it on the above thread and then correct the wiki.

[naicheben]

I think its confusing that we have GPIO0-7 labeld on the board and NOT corresponding to the numbers on the Chip. Thats what in the Wiki the "chip" row is about.

So your Linking might be true if you just add the information to what it belongs. Chip or Boardheader GPIO.

[mole125]

naicheben said:


I think its confusing that we have GPIO0-7 labeld on the board and NOT corresponding to the numbers on the Chip. Thats what in the Wiki the "chip" row is about.

So your Linking might be true if you just add the information to what it belongs. Chip or Boardheader GPIO.


It's even worse than that

GPIO0 is in position 11 on the header, which is connected to pin 17 of the chipset, so there are 3 different ways to refer to it.

Chipset Pin 12 isn't available on the header which prevents either another PWM or i2c channel.

[rPiWM]

Bakul, thank you for your comments. It would still be informative to have a complete, concise and comprehensive device map that tabulates all accessible peripherals with respective locations. The recent video of the Gertboard shows a PWM channel controlling the speed of a motor. Presumably Gert has the address of the PWM channel?

[mole125]

For Gert's video I think it was the GertBoard creating the PWM and not the RPi GPIO output - though I may be wrong as I wasn't able to hear the sound.

I agree though the wiki will need expanding to provide a section of each function and how to use it - including appropriate low level register addresses, references to the appropriate section of the data sheet and sample code (both low and ideally high level using helper libraries where available.  This will probably need to be a section rather than just a table though.

[meltwater]

The pin addressing is sorted out in the wiki now, which is good.

As for additional details on each pin function etc...I agree there is a lot more info which can go in the wiki when it becomes available, I imagine splitting it up into several pages if required will be ideal.  For now, there are only a few which know enough detail on this to write it, but hopefully when things become clearer this information will be entered in the wiki (plus I would expect a number of guides/tutorials appearing too, over time).

Frambozenier.org are likely to produce some datasheets which should also cover it in detail, again when the right information is available.

[rPiWM]

mole125 thanks for your post. It"s notable that obstacles to possible bottlenecks and developments are being anticipated with corresponding suggestions and requests for more details to be readily available. In software engineering, there is a "requirements analysis" phase, we seem to be gradually filling in the missing bits to enable informed programming of the RPi!

[rPiWM]

Gert, thank you for the sources that fill in more of the high level details to drive various I/O devices exercised in the video demo. It's a pity the 'stdio.h' file has been omitted as this would complete the picture by providing the base address/peripheral resource. A link to a relevant 'stdio.h' would be most welcome.