GPIO
Contents
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.
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. TODO: show an example
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.
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 touchscreen.
Configured as input only when exported by the kernel in board-overo.h. Can't change the direction from userspace without modifying kernel.
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
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
| GPIO( n ) |
- 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
.
