Please note that User Registration has been temporarily disabled due to a recent increase in automated registrations. If anyone needs an account, please request one here: RequestAccount. Thanks for your patience!--Wmat (talk)
Please email User:Wmat if you experience any issues with the Request Account form.

Difference between revisions of "Talk:RPi Low-level peripherals"

From eLinux.org
Jump to: navigation, search
(GPIO C driving example: new section)
(20 intermediate revisions by 8 users not shown)
Line 1: Line 1:
 +
Save old header pinout table
 +
 +
'''Header Pinout:'''
 +
{| border="1" style="text-align:center;"
 +
| '''Top Row''' || bgcolor="red" | <span style="color:white">5V0</span> || DNC || bgcolor="black" | <span style="color:white">GND</span> || bgcolor="yellow" | UART0_TXD || bgcolor="yellow" | UART0_RXD || bgcolor="lime" | GPIO1_PWM || DNC || bgcolor="lime" | GPIO4 || bgcolor="lime" | GPIO5 || DNC || bgcolor="lime" | GPIO6 || bgcolor="purple" | <span style="color:white">SPI_CE0_N</span> || bgcolor="purple" | <span style="color:white">SPI_CE1_N</span>
 +
|-
 +
| '''Bottom Row''' || bgcolor="orange" | 3V3 || bgcolor="cyan" | I2C0_SDA || bgcolor="cyan" | I2C0_SCL || bgcolor="lime" | GPIO7 || DNC || bgcolor="lime" | GPIO0 || bgcolor="lime" | GPIO2 || bgcolor="lime" | GPIO3 || DNC || bgcolor="purple" | <span style="color:white">SPI_MOSI</span> || bgcolor="purple" | <span style="color:white">SPI_MISO</span> || bgcolor="purple" | <span style="color:white">SPI_SCLK</span> || DNC
 +
|}
 +
 +
 +
{| border="1"
 +
! Colour legend
 +
|-
 +
| bgcolor="red" | <span style="color:white">+5V</span>
 +
|-
 +
| bgcolor="orange" | +3.3V
 +
|-
 +
| Do not connect
 +
|-
 +
| bgcolor="yellow" | UART
 +
|-
 +
| bgcolor="lime" | GPIO
 +
|-
 +
| bgcolor="purple" | <span style="color:white">SPI</span>
 +
|-
 +
| bgcolor="cyan" | I2C
 +
|}
 +
 +
----
 +
 
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: "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". [[User:Jstrout|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. --[[User:Polymerheart|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.
 +
--[[user:danpeirce|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
 +
 +
--[[user:danpeirce|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!
 +
--[[user:Grumpy Mike|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

Revision as of 01:52, 8 September 2012

Save old header pinout table

Header Pinout:

Top Row 5V0 DNC GND UART0_TXD UART0_RXD GPIO1_PWM DNC GPIO4 GPIO5 DNC GPIO6 SPI_CE0_N SPI_CE1_N
Bottom Row 3V3 I2C0_SDA I2C0_SCL GPIO7 DNC GPIO0 GPIO2 GPIO3 DNC SPI_MOSI SPI_MISO SPI_SCLK DNC


Colour legend
+5V
+3.3V
Do not connect
UART
GPIO
SPI
I2C

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