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

From eLinux.org
Jump to: navigation, search
Line 38: Line 38:
  
 
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"?
 
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.

Revision as of 07:02, 30 March 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.