Gumstix User Wiki - User contributions [en]

GPIO

2011-11-14T04:20:44Z

Dhylands: Fixed links that pointed to gumstix.net

== 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 [http://pubs.gumstix.com/boards/ here.]

=== How It Works ===

See the kernel docs [http://www.kernel.org/doc/Documentation/gpio.txt 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 [http://www-s.ti.com/sc/techlit/spruf98 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. 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 [http://www.mail-archive.com/linux-omap@vger.kernel.org/msg18474.html 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. 
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 

=== 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.

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.

=== 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 [http://elinux.org/BeagleBoardPinMux BeagleBoardPinMux] talking about OMAP3 pin muxing.

== Verdex GPIO ==
{| border="1" cellpadding="5" cellspacing="0" style="width:100px"
| style="background:yellow;" | 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:
<pre>
# cat /proc/gpio/GPIO12
12 GPIO in set
</pre>

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:
<pre>
# echo "AF1 out" > /proc/gpio/GPIO12
</pre>

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:
<pre>
# echo "GPIO out set" > /proc/gpio/GPIO12
# echo "GPIO out clear" > /proc/gpio/GPIO12
</pre>
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

.
[[Category:Literature]]
[[Category:GPIO]]

GPIO Event Driver

2010-06-30T08:13:33Z

Dhylands: Added overview of how the gpio-event driver works.

This page documents the gpio-event driver, which allows multiple GPIO lines to be monitored from user-space.

== Overview ==

The gpio-event driver consists of a loadable kernel module, which registers an interrupt handler, along with an example user-mode program, which allows the settings to be manipulated and changes to be reported.

== Driver Sources ==

The source code can be found [http://svn.hylands.org/linux/gpio-event/ here]. The app directory contains the example user mode application, and the module directory contains the loadable kernel module. The Makefiles have been setup such that if you define the environment variable OVEROTOP then you should be able to just type make in top level directory and both the app and module will be built.

There are also some bitbake recipes in the [http://svn.hylands.org/linux/oe/user.collection/recipes/gpio-event-app gpio-event-app] and [http://svn.hylands.org/linux/oe/user.collection/recipes/gpio-event-module gpio-event-module] directories.

== Adding pins to be monitored ==

The gpio-event program can be used to add gpio pins to be monitored. Simply run the gpio-event program, passing it a pin specification of the form: pin:edge:debounce. pin should be the GPIO number that you want to monitor. Edge should be r, f, or b to monitor rising, falling, or both edges, and debounce should be the number of milliseconds of debounce that you'd like. A debounce of 0 may be used for "clean" signals. For example:
gpio-event 58:f:20 59:r:20 60:b:20

would cause gpio 58 to be monitored for falling edges, gpio 59 to be monitored for rising edges, and gpio 60 to be monitored for both rising and falling edges. Each pin will have a debounce of 20 milliseconds (which should be adequate for most pushbuttons).

You can pass as many pins to be monitored as you'd like on the command line. Each call is cumulative. If you specify the same pin, the new specification will override whatever is currently set. You can see the current pins being monitored by using:
cat /proc/gpio-event/pins

Passing in a negative gpio number will cause the pin to stop being monitored.

== Detecting events ==

Once pins are setup to be monitored, any program can read /dev/gpio-event to get notified of the events. By default, an ASCII string of the form: "pin edge timestamp" followed by a newline will be delievered to /dev/gpio-event for each event that occurs. Running gpio-event with the -m or --monitor command line will cause the events to be monitored and printed. You could also use the command:
cat /dev/gpio-event

to achieve a similar result. For C programs, you can opt to use a binary interface instead. The binary versus ASCII setting is maintained on a per-file basis, so each program could each open /dev/gpio-event with a different ASCII/binary setting.

The edge will be an R or an F depending on whether a rising or falling edge is being reported. The timestamp is a number with the integer portion being the current system time (as returned from the gettimeofday function) and the fractional portion reporting in microseconds.

== Lauching a script ==

The gpio-event program can also be given the -e or --execute command line option, and the provided program or script will be launched with the same 3 paramters (gpio edge timestamp). For example:
gpio-event --execute echo

will produce similar output to
gpio-event --monitor

== Integrating/Building with Open Embedded ==

In order to build the driver under OE, you can do the following:
<pre>
cd to the directory containing org.embedded.dev
svn co http://svn.hylands.org/linux/oe/user.collection user.collection
bitbake task-gpio-all
</pre>

This will build the following packages for gpio-event:
./deploy/glibc/ipk/overo/gpio-event-module_svn20100218-r50.5_overo.ipk
./deploy/glibc/ipk/armv7a/gpio-event-app_svn20100218-r2.5_armv7a.ipk

and these packages for the [[User GPIO Driver]]
./deploy/glibc/ipk/overo/gpio-module_svn20100218-r50.5_overo.ipk
./deploy/glibc/ipk/armv7a/gpio-app_svn20100218-r0.5_armv7a.ipk
./deploy/glibc/ipk/armv7a/gpio-lib_svn20100218-r0.5_armv7a.ipk

Note that the numeric portions of the pathnames will almost certainly be different.

== How it works ==

Everything starts with the module_init directive near the very end of the gpio-event-drv.c file. The function passed to this directive, namely gpio_event_init, will be called automatically when the module is loaded. Similarly, the gpio_event_exit function, passed to the module_exit directive, will be called when the module is unloaded.

=== gpio_event_init ===
* alloc_chrdev_region - Allocates a major number dynamically
* create_proc_entry - Creates a directory, namely /proc/gpio-event
* create_proc_entry - Creates a proc entry, namely /proc/gpio-event/pins. This particular proc entry is processed using the functions described in pins_proc_ops.
* register_sysctl_table - Registers some sysctl entries, described by gSysCtl and gSysCtlSample. I find using sysctl entries a quick and easy way to enable debug flags in my drivers. The sysctl entries will appear in /proc/sys/gpio-event and cause the global variables gLostEvents, gDebugTrace, gDebugIoctl, and gDebugError to be manipulated.
* cdev_init associates the functions in gpio_event_fops against the major number allocated earlier with alloc_chrdev_region.
* cdev_add registers the driver with the kernel, and makes it "go live". Once cdev_add is called, user mode programs can open the driver.
* class_create creates a class, and device_create registers that class. This gets picked up by udev which will create the /dev/gpio-entry and associate with the dynamically allocated major number.

=== gpio_event_open ===

gpio_event_open is called when a user mode program calls open on /dev/gpio-event. The gpio-event driver assumes that it can be opened by multiple applications simultaneously, and uses a GPIO_FileData_t structure to keep track of each instance of the driver which is open. gFileList is a kernel list which contains a list of all of the currently open GPIO_FileData_t data structures.

=== GPIO_FileData_t data structure ===

{| border="1 px" cellpadding="4" cellspacing="0"
|-
! list
| Element used to make list of GPIO_FileData_t structures
|-
! waitQueue
| Object that reader waits on when no events are available.
|-
! queueLock
| Mutual exclusion lock acquired when manipulating queueData, getIndex, putIndex, or numEvents.
|-
! queueData
| Circular queue of events waiting to be read for a given file.
|-
! getIndex
| Index of the next item to be retrieved from the circular queue.
|-
! putIndex
| Index of the next place that an event will be placed into the circular queue.
|-
! numEvents
| The number of events currently in the circular queue.
|-
! readMode
| Determines if this file is being read in binary or ASCII mode. Defaults to ASCII.
|-
! buffer
| Contains the next event worth of data, formatted in either binary or ASCII format.
|-
! bufBytes
| The number of bytes of data that are currently sitting in buffer.
|}

Note: When manipuating the gFileList linked list, the driver should hold the gFileListLock spinlock with interrupts disabled.

=== gpio_event_ioctl ===

gpio_event_ioctl is called when a user mode program issues an ioctl call on the file handle returned from opening /dev/gpio-event. The user mode program can use GPIO_EVENT_IOCTL_MONITOR_GPIO to add/removee/modify monitoring for a pin. The user mode program can use GPIO_EVENT_IOCTL_SET_READ_MODE to set the read mode to binary or ASCII.

=== gpio_event_poll ===

gpio_event_poll adds the appropriate glue to allow the poll or select calls to work as expected from user mode. Basically, this function determines if there is data to be read or not.

=== gpio_event_read ===

gpio_event_read is called when the user issues a read call on the files handle returned from opening /dev/gpio-event. It first checks to see if any data remains from previous calls. If a non-blocking read is performed and no events are available, then it returns immediately, otherwise it blocks waiting for an event to be placed in the queue before returning. If multiple events are available, and the caller provided sufficient buffer space, then as much data as can be returned will be. gpio_event_dequeue_event is called to retrieve queued events.

=== gpio_event_release ===

gpio_event_release is called when a given file handle is closed. It removes the GPIO_FileData_t structure from the list of open files.

=== gpio_event_monitor ===

gpio_event_monitor is called in response to the GPIO_EVENT_IOCTL_MONITOR_GPIO ioctl. If monitoring for a pin is being added, then request_irq is called to register an interrupt handler, gpio_event_irq, whenever an appropriate type of edge is detected, and init_timer is called to setup the debounce timer. If monitoring for a pin is being removed, then free_irq is called, along with del_timer_sync to unregister the timer.

=== GPIO_PinData_t data structure ===

There is an instance of this structure for each pin which is actively being monitored.

{| border="1 px" cellpadding="4" cellspacing="0"
|-
! list
| Element used to make list of GPIO_PinData_t structures
|-
! gpio
| The gpio pin which is being monitored.
|-
! debounceTimer
| Timer object used to perform debounce.
|-
! debounceMilliSec
| Amount of time that the debounce timer should be activated for after an edge.
|-
! devName
| device name used when registering an irq handler (shows up in /proc/irq)
|-
! edgeType
| The type of edge that is being monitored.
|-
! pinState
| Holds the current state of the pin.
|}

Note: When manipuating the gPinList linked list, the driver should hold the gPinListLock spinlock with interrupts disabled.

=== gpio_event_irq ===

gpio_event_irq is called whenever an edge is detected on enabled pins. The type of edge is determined and an event is queued using gpio_event_queue_event. If pin deboucing is used, then interrupts are disabled (for the particular pin) and a timer is started.

=== gpio_event_timer ===

If debouncing is used on a pin, then a timer is started when an edge occurs. This allows interrupts to be disabled for a short time when the pin "bounces" or generates lots of edges. At the end of the timeout, interrupts are re-enabled.

=== gpio_event_dequeue_event ===

gpio_event_dequeue_event is called to retrieve any events queued up for a given file descriptor.

=== gpio_event_queue_event ===

gpio_event_queue_event adds an event to all open file descriptors. The waitQueues for each file descriptor is also "woken" which allows any readers which are blocked waiting for an event to run.

=== find_pin ===

find_pin is a utility function to detemine if a particular gpio is being monitored.

=== pins_proc_open ===

Called when a user mode program opens /proc/gpio-event/pins

=== pin_seq_xxx ===

Set of functions which are called to process the output which goes to /proc/gpio-event/pins.

[[Category: GPIO]]

User GPIO Driver

2010-02-18T17:29:32Z

Dhylands: Added instructions for building under OE

This page documents the user GPIO driver, which is a reflection of the kernel's gpiolib API into user space.

==Overview==

The kernel provides an API, called gpiolib, which abstracts access to GPIO pins. It has a mechanism for exporting pins into userspace, and in general this is the preferred method of accessing gpio pins from userspace. This method works particularly well if it is setup for a given overo/daughtercard combination. However, since the kernel is often configured in a more generic manner, using the export method is inconvenient, so the user-gpio driver was created.

WARNING: It is possible to damage your overo chip if you do things incorrectly. This code has no way of knowing for example, if a pin is physically connected to an output or not. If, for example, a GPIO pin was connected to Vcc, and you choose to configure that pin as an output and drive it low, you've essentially created a short circuit, and this can stress or damagethe pin, possibly bricking your processor. You have been warned.

== Driver Sources ==

The source code can be found [http://svn.hylands.org/linux/gpio/ here]. The app directory contains the example user mode application. The lib directory contains the usermode library which translates the C API into the appropriate ioctl calls into the kernel driver, and the module directory contains the loadable kernel module. The Makefiles have been setup such that if you define the environment variable OVEROTOP then you should be able to just type make in top level directory and both the app and module will be built.

There are also some bitbake recipes in the [http://svn.hylands.org/linux/oe/user.collection/recipes/gpio-app gpio-app], [http://svn.hylands.org/linux/oe/user.collection/recipes/gpio-lib gpio-lib] and [http://svn.hylands.org/linux/oe/user.collection/recipes/gpio-event-module gpio-event-module] directories.

== Integrating/Building with Open Embedded ==

In order to build the driver under OE, you can do the following:
<pre>
cd to the directory containing org.embedded.dev
svn co http://svn.hylands.org/linux/oe/user.collection user.collection
bitbake task-gpio-all
</pre>

This will build the following packages for the [[GPIO Event Driver]]:
./deploy/glibc/ipk/overo/gpio-event-module_svn20100218-r50.5_overo.ipk
./deploy/glibc/ipk/armv7a/gpio-event-app_svn20100218-r2.5_armv7a.ipk

and these packages for the user gpio driver:
./deploy/glibc/ipk/overo/gpio-module_svn20100218-r50.5_overo.ipk
./deploy/glibc/ipk/armv7a/gpio-app_svn20100218-r0.5_armv7a.ipk
./deploy/glibc/ipk/armv7a/gpio-lib_svn20100218-r0.5_armv7a.ipk

Note that the numeric portions of the pathnames will almost certainly be different.

[[Category: GPIO]]

GPIO Event Driver

2010-02-18T17:27:05Z

Dhylands: Added instructions on building for OE

GPIO

2010-02-11T20:46:00Z

Dhylands: Added link to User GPIO Driver

{| border="1" cellpadding="5" cellspacing="0" style="width:100px"
| style="background:yellow;" | 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:
<pre>
# cat /proc/gpio/GPIO12
12 GPIO in set
</pre>

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:
<pre>
# echo "AF1 out" > /proc/gpio/GPIO12
</pre>

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:
<pre>
# echo "GPIO out set" > /proc/gpio/GPIO12
# echo "GPIO out clear" > /proc/gpio/GPIO12
</pre>
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

.
[[Category:Literature]]
[[Category:GPIO]]

User GPIO Driver

2010-02-11T20:45:25Z

Dhylands: Initial version of user-gpio driver page

GPIO

2010-02-11T19:57:35Z

Dhylands: Added GPIO Category

{| border="1" cellpadding="5" cellspacing="0" style="width:100px"
| style="background:yellow;" | 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:
<pre>
# cat /proc/gpio/GPIO12
12 GPIO in set
</pre>

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:
<pre>
# echo "AF1 out" > /proc/gpio/GPIO12
</pre>

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:
<pre>
# echo "GPIO out set" > /proc/gpio/GPIO12
# echo "GPIO out clear" > /proc/gpio/GPIO12
</pre>
The alternative functions are described in the PXA255 Developer's Manual (link should be found in the Featured links-box) section 4.1.2.

== 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

.
[[Category:Literature]]
[[Category:GPIO]]

Category:GPIO

2010-02-11T19:56:32Z

Dhylands: Added GPIO category

These pages are all related to using GPIO pins.

GPIO

2010-02-11T19:54:14Z

Dhylands: Added link to new GPIO Event Driver page. Removed reference to docwiki page for gpio-event-driver

{| border="1" cellpadding="5" cellspacing="0" style="width:100px"
| style="background:yellow;" | 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:
<pre>
# cat /proc/gpio/GPIO12
12 GPIO in set
</pre>

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:
<pre>
# echo "AF1 out" > /proc/gpio/GPIO12
</pre>

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:
<pre>
# echo "GPIO out set" > /proc/gpio/GPIO12
# echo "GPIO out clear" > /proc/gpio/GPIO12
</pre>
The alternative functions are described in the PXA255 Developer's Manual (link should be found in the Featured links-box) section 4.1.2.

== 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

.
[[Category:Literature]]

GPIO Event Driver

2010-02-11T17:49:28Z

Dhylands: moved GpioEventDriver to GPIO Event Driver: Forgot how the title stuff worked

GpioEventDriver

2010-02-11T17:49:28Z

Dhylands: moved GpioEventDriver to GPIO Event Driver: Forgot how the title stuff worked

#REDIRECT [[GPIO Event Driver]]

GPIO Event Driver

2010-02-11T17:39:25Z

Dhylands: Initial version of gpio-event for the new wiki

Help:Editing

2010-02-11T17:30:30Z

Dhylands: Copied Editing:help from the old wiki since it doesn't seem to exist in the new wiki

The [http://en.wikipedia.org/wiki/Wikipedia:Quick_guide Quick guide] shows some of the simple ways of doing things.

The [http://en.wikipedia.org/wiki/Help:Wiki_markup_examples Wiki markup examples] goes into more details.

[[Category: Wiki]]

Category:Setup - Psyco JIT compiler for Overo build environment for Fedora 10

2009-08-26T15:18:26Z

Dhylands: Added note about Psyco and 64-bit architectures

__FORCETOC__
==Download Psyco JIT compiler sources from svn==
svn co http://codespeak.net/svn/psyco/dist/ psyco-dist/

==Run the python installation script as a super user==
cd psyco-dist

su python setup.py install

==Note: Psyco only supported on 32-bit architectures==
If you download and try to install Psyco on a 64-bit architecture, you'll get the following error:
c/codegen.h:15:3: error: #error "-----------------------------------------------------"
c/codegen.h:16:3: error: #error "Sorry, non-32-bit platforms are not supported at all."
c/codegen.h:17:3: error: #error "You may try with a Python compiled in 32-bit "
c/codegen.h:18:3: error: #error "compatibility mode. Note that Psyco will probably "
c/codegen.h:19:3: error: #error "never support non-32-bit platforms, as it is no "
c/codegen.h:20:3: error: #error "longer actively developed. Instead, the PyPy group "
c/codegen.h:21:3: error: #error "plans to replace it with a more flexible and easily "
c/codegen.h:22:3: error: #error "retargettable Psyco-for-PyPy during the year 2006. "
c/codegen.h:23:3: error: #error "See http://codespeak.net/pypy/ "
c/codegen.h:24:3: error: #error "-----------------------------------------------------"

[[Category:How_to_-_general]]

Robostix toolchain

2009-08-24T17:40:13Z

Dhylands: Added

This page describes setting up the AVR toolchain, needed to build code for the robostix and roboaudiostix boards.

==Install compiler==

When things work, you can do the following under ubuntu:

sudo apt-get install gcc-avr avr-libc gawk

However, some versions of avr-libc will give you compile errors when trying to build the i2c bootloader. (the error will mention __eerd_block). Ubuntu 9.04 installs a version of avr-libc with this problem. See below for details on manually installing a newer runtime library.

==Manually install runtime library==

The following steps can be used to install (or replace) the avr runtime library (avr-libc). Ubuntu-9.04 installs version 1.6.2, which has some issues.

<nowiki>wget http://mirror.csclub.uwaterloo.ca/nongnu/avr-libc/avr-libc-1.6.7.tar.bz2</nowiki>
tar xjf avr-libc-1.6.7.tar.bz2
cd avr-libc-1.6.7/
./configure --build=`./config.guess` --host=avr --prefix=/usr/lib
make
sudo make install

[[Category:How_to_-_robotics]]