Talk:RPi Low-level peripherals

Save old header pinout table

Header Pinout:

Donster2k: "Kernel boot messages go to the UART at 115200bps." - This should be configurable as a kernel parameter. It is the bootloader that will always output to the uart on the header, correct?

Donster2k: What will be the power-on states of the GPIO pins?

Donster2k: USB2 spec states that the max current draw from a port (either powered hub or PC's usb) is 500mA. Does this mean that the revB module will need to be powered via a usb charger?

Donster2k: Most of the reference links to the forum are broken. Probably happened when they moved the forum.

naicheben: The color legend is fine for the table "Header Pinout" but it does not correspond to the GPIOs.gif as stated below the GIF. Shouldn't we better use same color "coding"?

Russell: I was just reading the datasheet "BCM2835 ARM Peripherals" and found that section 1.3 requires memory barrier operations to be used when accessing peripherals. This says to me that use user space access to the GPIO or any other peripheral is somewhat dangerous/error prone. Unless the kernel stopped from using any other peripheral, these registers would have to be accessed atomically, with barrier instructions, from a kernel driver.

What is this "1k8" referenced several times throughout the page? Do we mean to say "1kΩ"? If so, any objection to changing all those eights to ohms? Or if for some reason we're not comfortable using the ohm (omega) symbol, even just "1k" would be clearer to me than "1k8". Jstrout 13:43, 30 May 2012 (UTC)
 * No, it doesn't mean 1 kOhm. It is a standard syntax meaning 1.8 kOhm. It is written that way because when writing values, especially if writing very small, a decimal point could easily be rubbed off or missed, whereas a k is much clearer. If it is confusing, I don't think anyone would object to writing 1k8 Ohms, though the context normally makes it clear. --Polymerheart 21:14, 16 July 2012 (UTC)

Answers from Grumpy Mike From Donster2k: What will be the power-on states of the GPIO pins? ..... They are all inputs except GPIO 14 & 15 which are serial input / output and can be used to log in. From Jstrout What is this "1k8" ...... it is short for one point eight K ohms. It is so you can't accidentally miss the decimal point.

The pin out on this page is very bad, it should referee to all the pins as GPIO numbers. Most of the alternative pin functions are only one possible out of 6 and they initialise as inputs anyway.

I can't recall seeing designations like top row, bottom row, left and right on a pinout for a connector. This would be because there is much ambiguity (in general) about which of the four sides of the board should be top (more typically top would refer to the through hole component side of the board). More typically everything is referenced relative to a key like the pad for PIN 1. Since the connector is at the board edge there could be a great deal more clarity for the novice if the board edge were marked in the diagram. I notice now that if I click on the source link under the pin diagram I am taken to another diagram that actually includes enough of the board that it is clear which row is at the board edge. For novice users I suggest adding a photo with superimposed pin numbers. The photo should show the corner of the board containing the connector and nearby parts. --danpeirce 9:49 20 August 2012 (UTC)

I'm thinking something like this could be useful (I combined part of an RPi image from this site File:RPi-Front-JPB.jpg) with the pin information on this page. see http://danpeirce.net46.net/dokuwiki/lib/exe/detail.php?id=raspberry_pi&media=rpi:gpio_pins.png

--danpeirce 18:49 20 August 2012 (UTC)

That diagram is OK apart from the line that says "The Alt 0 function is defined at boot time" It is not! --Grumpy Mike 18:49 28 August 2012 (UTC)

GPIO C driving example
There are quite a few examples found on the web showing memory access using /dev/mem but with the same error of allocating a block of (page-aligned) user memory to pass as the 1st parameter to mmap.

setup_io could be rewritten as follows:

// // Set up a memory regions to access GPIO //

void setup_io {  /* open /dev/mem */ if ((mem_fd = open("/dev/mem", O_RDWR|O_SYNC) ) < 0) { printf("can't open /dev/mem \n"); exit (-1); }

/* mmap GPIO */

// Now map it  gpio_map = (unsigned char *)mmap(      NULL,       // was (caddr_t)gpio_mem,      BLOCK_SIZE,      PROT_READ|PROT_WRITE,      MAP_SHARED, // was MAP_SHARED|MAP_FIXED,      mem_fd,      GPIO_BASE   );

close(mem_fd); // no need to keep fd open after mmap

if ((long)gpio_map < 0) { printf("mmap error %d\n", (int)gpio_map); exit (-1); }

// Always use volatile pointer! gpio = (volatile unsigned *)gpio_map;

} // setup_io


 * I've updated the C code example with your suggestions,a pruning of unnecessary includes and compilation with `gcc -Wall gpio.c` fixing a minor cast error. Code has been tested on a Raspberry Pi and seems to work fine. --Jamesmiller5 (talk) 17:53, 1 January 2013 (UTC)

Thank you for fixing that! I noticed the same thing and came back here to fix it.