Difference between revisions of "GPIO"

Revision as of 09:27, 31 January 2013

Overo GPIO

The Overo kernels support the sysfs gpio implementation for accessing GPIO from userspace.

This allows you to control GPIO from the command line this way

root@overo# echo 146 > /sys/class/gpio/export
root@overo:/sys/class/gpio# cat gpio146/direction
in
root@overo# echo out > /sys/class/gpio/gpio146/direction
root@overo:/sys/class/gpio# cat gpio146/direction
out
root@overo# cat /sys/class/gpio/gpio146/value
0
root@overo# echo 1 > /sys/class/gpio/gpio146/value
root@overo# cat /sys/class/gpio/gpio146/value
1

If you have an expansion card with a 40 pin header, then this will be controlling pin 27. You can use pin 1 for a ground. (If you don't have a meter, a p/n 276-0330 1.8V Red LED from Radio Shack works for testing.)

Schematics and pin-outs for the Gumstix expansion boards can be found here.

How It Works

See the kernel docs gpio.txt for an overview of gpio and the userspace sysfs interface. The "Sysfs Interface for Userspace (OPTIONAL)" section near the end discusses the userspace implementation.

See the OMAP35X Technical Reference Manual Section 7.6.3 PADCONFS Register Description and Table 7.5 Core Control Module PadConf Register Field in Section 7.4.4.3 Pad Multiplexing Register Fields for identifying the possible MUX configuration for each GPIO. For OVERO DM3730 see the Technical Reference Manual Section 13.6.3.2 PADCONFS Register Description.

Then see the U-Boot source code, board/overo/overo.h for how the pins on the Overo are actually being muxed. See include/asm-arm/arch-omap3/mux.h in the U-Boot tree for the definitions used in overo.h. The pins in mux mode M4 are already configured for GPIO.

Making Modifications

Currently all the GPIO multiplexing for the Overo's is being done by the bootloader U-Boot, so the conventional way to modify the pin muxing is to edit overo.h and rebuild U-Boot.

You can also change the mux configuration from within Linux. One simple approach is to do it from userspace accessing /dev/mem. A program devmem2 is part of the omap3-console-image and will work. See the remuxing example below.

If you are writing your own kernel module, you can also read/write the PADCONF registers the way you normally would after an ioremap.

Third, there is a Linux build config option CONFIG_OMAP_MUX, not normally enabled in the Overo configs, that will give you some additional utility functions to simplify mux changes within kernel or module code (see arch/arm/plat-omap/mux.c).

Finally, it looks like the Linux OMAP34xx pin muxing code is getting a complete overhaul. See this thread on the Linux OMAP mailing list. Judging from some posts on the Gumstix lists, it sounds like this will be available in 2.6.33.

Overo Kernel Usage

Just because pins are configured as GPIO in u-boot, doesn't necessarily mean you can use them. If you look at /sys/class/gpio on a default Overo, you'll get something like this.

root@overo:~# ls /sys/class/gpio
export	gpio164  gpio65       gpiochip160  gpiochip64
gpio15	gpio168  gpiochip0    gpiochip192  gpiochip96
gpio16	gpio176  gpiochip128  gpiochip32   unexport

The reason you see some GPIO already exported is because the linux code in arch/arm/mach-omap2/board-overo.c is explicitly exporting these pins for another use. Whether they are being used depends on the hardware you have attached. The kernel also uses pins configured as GPIO that it doesn't export. These depend on the board configuration and the kernel drivers being used.

To be more explicit, look inside board-overo.c, you'll see these definitions

#define OVERO_GPIO_BT_XGATE     15
#define OVERO_GPIO_W2W_NRESET   16
#define OVERO_GPIO_PENDOWN      114
#define OVERO_GPIO_BT_NRESET    164
#define OVERO_GPIO_USBH_CPEN    168
#define OVERO_GPIO_USBH_NRESET  183
...
#define OVERO_SMSC911X_GPIO    176
#define OVERO_SMSC911X2_GPIO   65
...
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145

Follow their usage inside the file and you will be able to explain the /sys/class/gpio output you see above.

Input or Output

Pins configured as GPIO are sometimes also specified as being strictly input or output.

This can happen when they are mux'd or when they are explicitly exported by the kernel.

In either of those cases you won't be able to change the I/O direction from userspace.

Electrical Specifications

Voltage is 1.8v

Current specifications <TODO ???>

Usable Pins

Here's a few GPIO you can use immediately from userspace without any u-boot or kernel changes. It will however require that the specific GPIO isn't used by the attached expansion board.

40 Pin Expansion Header

Pin 4 - gpio114
It's the pendown signal on the touchscreen controller but it's available if you aren't using a expansion board with touchscreen support.
This pin can not be configured as output, it is input only (see OMAP35X Technical Reference Manual p. 3389). Pulled-low, reads 0 with no input, reads 1 with an input applied

Pin 19 - gpio170
The HDQ/1-Wire output. Not used unless you explicitly enable the 1-wire module.
User exportable
Output only - configured this way in the u-boot muxing

Pin 27 - gpio146
Pin 29 - gpio147
User exportable
Direction can be changed
Floating state

Pin 28 - gpio145
Pin 30 - gpio144
Used with LCD, but available if not using an LCD
Configured as output only when exported by the kernel in board-overo.h. Can't change direction from userspace without modifying kernel.
Set to ON by kernel during init (not all configs, see board-overo.c). This could be a problem for real use, but okay for testing.

Palo43 Board

LED D2 - gpio21
LED D3 - gpio22
Userspace exportable, set the direction as out
echo 0 > gpioxx/value to turn on, echo 1 > gpioxx/value to turn off

Switch - gpio14
Switch - gpio23
Userspace exportable, leave direction as in
With the switch open (not pushed) will register a value of 1
Push the switch and the value will be 0

Example: Changing the multiplexing for a pin

If you aren't using the first SPI bus, then there are 5 pins on the 40-pin expansion header that you could repurpose for GPIO.

Pin 3 - gpio171(spi1_clk)
Pin 5 - gpio172 (spi1_mosi)
Pin 6 - gpio174 (spi1_cs0)
Pin 7 - gpio173 (spi1_miso)
Pin 8 - gpio175 (spi1_cs1)

The first step is to find the appropriate PADCONF register address for each gpio from Table 7.5 of the TRM. Pay attention to whether it is the low or high order 16 bits for each gpio. You should come up with these values.

gpio171 : 0x4800 21C8
gpio172 : 0x4800 21CA
gpio173 : 0x4800 21CC
gpio174 : 0x4800 21CE
gpio175 : 0x4800 21D0

Using devmem2, here is how you could read the current PADCONF value for what could be gpio171

root@overo# devmem2 0x480021c8 h
...
Value at address 0x480021C8 (0x400201c8): 0x100

Which corresponds to a mux value of (IEN | PTD | DIS | M0) using the U-Boot mux.h definitions. Mux mode 0 for this pin is the spi1_clk configuration found by looking in Table 7.5 of the TRM.

To reconfigure pin 3 to be gpio171, as input or output with inputs pulled low, write 0x010C to the controlling PADCONF register. This would correspond to (IEN | PTD | EN | M4). The bit fields are defined in the TRM Section 7.6.3.

root@overo# devmem2 0x480021c8 h 0x10c

Now you can export and configure gpio171 from userspace like the example with gpio146 at the beginning. To make it visible in sysfs:

echo 172 > /sys/class/gpio/export

If you want this multiplexing to be permanent, then you would modify the U-Boot file board/overo/overo.h and rebuild U-Boot. If you are using OE, then you'll want to generate a patch file to be used in the u-boot-omap3 recipe.

There are additional pins on the header that can be reconfigured this way.

To reconfigure pins from within a kernel module the following code can be used:

void *addr = ioremap(spi1_clk, 4);
if (!addr)
{
 printk("Cannot ioremap 0x%lx\n", spi1_clk);
} else {
 printk("ioremap OK:  0x%lx\n", spi1_clk);
 iowrite32( 0x010C | (0x010C << 16), addr);
 iounmap(addr);
}

This will make both gpio171 and gpio172 input or output with inputs pulled low.

Interrupts on GPIO pins

Here is an example on setting up an interrupt on GPIO pin 23 from within a kernel module:

irqreturn_t gpio_irq_handler(int irq, void *dev_id) {
 static int cnt=0;
 printk("gpio_irq_handler %i\n", cnt++);
 return IRQ_HANDLED;
}

int gpio_irq= gpio_to_irq(23);
int ret = request_irq(gpio_irq, gpio_irq_handler, IRQF_TRIGGER_FALLING, "gpio irq handler", gpio_irq_handler);
if (ret)
 printk("gpio interrupt request failed\n");
else
 printk("gpio interrupt request succeeded\n");

GPIO Software for the Overo

Dave Hylands has written several software packages to facilitate GPIO programming on the Overos.

GPIO Event Driver allows multiple GPIO lines to be monitored from user-space.

User GPIO Driver is a reflection of the kernel's gpiolib API into user space.

More Links

Here is another article BeagleBoardPinMux talking about OMAP3 pin muxing.

Verdex GPIO

• Logic level (3.3V) signals
• 3-4mA max

all GPIO's information and examples should go here

todo

According to the PXA270 datasheet: http://pubs.gumstix.com/documents/PXA%20Documentation/PXA270/PXA270%20Electrical,%20Mechanical,%20and%20Thermal%20Specification%20%5b280002-005%5d.pdf most of the pins are limited to 3mA, and a few can go upto 4 mA (see page 5-9)

Accessing GPIO's from userland

If proc-gpio is a module, add it to /etc/modules or do a modprobe proc-gpio.

A number of files exist under /proc/gpio, one for each GPIO on the PXA processor.

If you cat one of these files, you get, eg:

# cat /proc/gpio/GPIO12
12 GPIO in set

That tells you — GPIO number, function (either GPIO, AF 1, AF 2, or AF 3), in|out, set|clear.

You can change any of those values, by writing to the file, eg:

# echo "AF1 out" > /proc/gpio/GPIO12

This sets GPIO12 to AF1, out mode. (In the case of GPIO12, the PXA defines this function as putting out the 32kHz clock signal.) this is currently case-sensitive

If you have the GPIO set to an output, and GPIO mode, you can set or clear the signal:

# echo "GPIO out set" > /proc/gpio/GPIO12
# echo "GPIO out clear" > /proc/gpio/GPIO12

The alternative functions are described in the PXA255 Developer's Manual (link should be found in the Featured links-box) section 4.1.2.

Alternative method to access GPIO's from userland

The User GPIO Driver provides a reflection of the kernel's gpiolib library into userspace.

gpio-event driver

The GPIO Event Driver allows gpio changes to be captured from user-space.

Related pages on the old wiki:

http://docwiki.gumstix.org/index.php/Tips_and_tricks#Access_GPIOs_from_user-space

http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs

http://docwiki.gumstix.org/index.php/Kernel_programming

.