Difference between revisions of "Talk:RPi Low-level peripherals"
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 00: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.