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

From eLinux.org
Jump to: navigation, search
m (Added some answers, suggested a better way of labeling pins.)
(Example code section should be split to another page)
 
(16 intermediate revisions by 7 users not shown)
Line 44: Line 44:
  
 
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)
 
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
 
Answers from Grumpy Mike
Line 51: Line 52:
  
 
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.
 
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
 +
 +
: 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. --[[User:Jamesmiller5|Jamesmiller5]] ([[User talk: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.
 +
 +
== Example code section should be split to another page ==
 +
 +
All the examples are great, but they clutter the page and can be a bit overwhelming. I suggest moving them to their own page and replacing them here with a section explaining the different methods of accessing external I/O.
 +
 +
  Feel free to make that happen. --[[User:Wmat|Wmat]] ([[User talk:Wmat|talk]]) 01:30, 2 February 2013 (UTC)
 +
 +
==Methods of writing to external I/O==
 +
;1. Directly write to the memory mapped control registers from your application.
 +
*Pro's / Cons of this approach
 +
*Link to C mmap example
 +
*Links to libraries that use this method.
 +
**WiringPi https://github.com/WiringPi/WiringPi
 +
**BCM2835 C library http://www.open.com.au/mikem/bcm2835/
 +
**Quick2wire https://github.com/quick2wire/quick2wire-python-api
 +
;2. Use the provided driver a control the I/O pins with the Linux kernel /sys/class interface.
 +
*Link to http://www.kernel.org/doc/Documentation/gpio.txt
 +
*Directions how to enable the kernel module in Raspian
 +
*Link to bash script to export gpio pin

Latest revision as of 18:30, 1 February 2013

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

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.

Example code section should be split to another page

All the examples are great, but they clutter the page and can be a bit overwhelming. I suggest moving them to their own page and replacing them here with a section explaining the different methods of accessing external I/O.

 Feel free to make that happen. --Wmat (talk) 01:30, 2 February 2013 (UTC)

Methods of writing to external I/O

1. Directly write to the memory mapped control registers from your application.
2. Use the provided driver a control the I/O pins with the Linux kernel /sys/class interface.