Raspberry Pi 3 Model B GPIO 40 Pin Block Pinout

Are there any actual electrical specs for this I/O?  In particular,

• what voltage standard do these I/Os employ?
• if not 5V I/Os, are they 5V tolerant inputs?
• how much current can they deliver?
• are there requirements regarding power-up sequence relative to attached devices?

Also, schematics?

Thanks, Graham

Hi Graham,

The Raspberry Pi doesn't have such detailed information regarding the circuit, and there are no full schematics available - it is kind of (in)famous for this for many years now.

The closest to official information is at these locations:

https://www.raspberrypi.org/documentation/hardware/raspberrypi/README.md

(Click on the GPIO link there - the information there is not much however) and

https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=12248

and

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=25335

(Notice the RPF forum moderators there have confirmed that to be about as much as you'll get).

Given the absence of such information (you can ask at raspberrypi.org as much as you like, they won't supply additional documentation), here are the practical answers to your questions, from experience:

(a). 3.3V LVTTL logic levels, don't exceed 3.3V

(b) Nope, not 5V tolerant because any documentation does not state it. Some people believe there is some tolerance from experiments, but I wouldn't do that

(c) See the link earlier. A few mA, or higher but depends how many you simultaneously drive.

(d) In general don't connect to a source (unless through a reasonably high impedance) until the RPI is powered up.

If you are looking for practical input and output circuits that you can use for interfacing to the 'pi (and some examples for 5V circuit interfacing to the pi), see here:

Raspberry Pi GPIO Explained

Agreed, did they say that  there is a new GPIO memory map now we have a new SOC or have they kept it the same or none of the above??

This will be important if the puplic expect the H/W that gets plugged in to work ????

Agreed, did they say that  there is a new GPIO memory map now we have a new SOC or have they kept it the same or none of the above??

This will be important if the puplic expect the H/W that gets plugged in to work ????

Hi!

No idea to be honest, it wouldn't be surprising if it has changed again. RPF don't mention these things on day 1 (to prevent people asking awkward questions that conflict with the 'backwards compatible' messaging to the public) but someone will eventually 'document' it - on their forum buried in a discussion thread I'm sure. User manuals and datasheets are old-school  : )

Two and a half decades ago, I wrote a program called "chipmunk" that allows you to examine memory mapped registers on a live linux system. It would be easy to check some things.

Anyway, for a quick overview:

 

tree:/proc> cat iomem

00000000-3affffff : System RAM

  00008000-0078959f : Kernel code

  007fa000-0093f79b : Kernel data

3f006000-3f006fff : dwc_otg

3f007000-3f007eff : /soc/dma@7e007000

3f00b840-3f00b84e : /soc/vchiq

3f00b880-3f00b8bf : /soc/mailbox@7e00b800

3f200000-3f2000b3 : /soc/gpio@7e200000

3f201000-3f201fff : /soc/uart@7e201000

  3f201000-3f201fff : uart-pl011

3f202000-3f2020ff : /soc/sdhost@7e202000

3f215040-3f21507f : serial

3f300000-3f3000ff : /soc/mmc@7e300000

3f980000-3f98ffff : dwc_otg

tree:/proc>

My RPI-2 is not currently "on", so I can't compare it right now.

However, I WOULD expect it to be the same.

As I understand things, RPI foundation has asked Broadcom for a more powerful processor, (of course with some inside knowledge that they already had experience with the A53, Wifi etc.) and apparently the RPI market is big enough for Broadcom to do a chip just for raspberry pi. Then it makes sense to start out with a BCM2836 and change only what's needed. Keep as much as possible the same.

Hi Roger,

I too would wish this to be true, but there were comments on another forum that possibly the UART has now moved to a soft-UART implementation to use the interface pins instead for synchronous serial to the wireless IC, so perhaps things have moved around (which a schematic or datasheets would reveal). I don't have any more information or datapoints though (still waiting to receive my Pi 3 to examine it).

Drivers of course should in theory make such things transparent to the user, but there will always be people doing things differently enough (or drivers behaving subtly different) for things to sometimes not behave as expected.

My PI3 has a ttyAMA, the ARM-uart that previous raspberries had:

3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 83, base_baud = 0) is a PL011 rev2

But I see a getty running on /dev/tttyS0. Ah:

3f215040.uart: ttyS0 at MMIO 0x3f215040 (irq = 29, base_baud = 50000000) is a 16550

... On the one hand an improvement: the 16550 has a 16-byte buffer, on the other hand, SOME things must have moved around to make this as compatible as possible.

My /boot/cmdline specifies: console=ttyAMA0,115200 , whereas my kernel has been started with: console=ttyS0,115200 , Tricky hacking in the videocore startup files....

Hi Roger,

That is interesting. I guess they had to do this mapping to use the same config files (since it is the same image for the Pi variants), i.e. to try to make it transparent to the end user.