From: Frank A. <ft...@ya...> - 2010-09-16 13:24:36
|
I've uploaded to github a couple of device drivers that might be of interest: 1) OMAP capture driver. This driver can set up a pin on the OMAP 35xx processor as an input capture source. The original purpose was to measure the frequency of a signal that corresponded to the RPM of a motor. Only 4 pins on the 35XX can be used for capture: 144, 145, 146 nd 147. The driver assumes that the capture pin is in "Mode 2" (pwm_evt). The driver default is to set up pin 147 for capture. To set up one of the other pins as capture,invoke the driver with "capture_pin=xxx", where "xxx" is one of 144, 145, 146 and 147. Pulse width (rising edge to falling edge) and frequency measurements can be made on a signal connected to the capture pin. The driver continuously captures width and frequency counts. If there is no input on the pin, or the input goes away, the driver will report 0 for pulse width and frequency counts. The ioctl interface will provide an integer count for pulse width, frequency and clock source. To determine the values in milliseconds, divide the returned count of width or frequency by the clock source count and multiply by 1000. Source code: http://github.com/ftagius/OMAP-Capture 2) OMAP 35xx control module pad configuration (aka cmpc) driver. Derived from the mux driver code by Scott Ellis. This driver can set the control module configuration register on the OMAP 35xx processor. This allow configuring from user space the mode (from mode 0 to mode 7) for individual pins. Source code: http://github.com/ftagius/OMAP-cmpc Both drivers should work, but are a little rough around the edges. Comments are welcome. frank |
From: Oswald B. <op...@sd...> - 2010-10-16 19:58:38
|
hi frank, excellent, i just tested the cmpc driver on the beagle. here's a nano-patch for cmpc.c, as otherwise the gpio ports aren't accessible via /sys/class/gpio after configuring. bst, oswald --- a/cmpc.c +++ b/cmpc.c @@ -250,6 +250,8 @@ static ssize_t cmpc_write(struct file *filp, const char __user *buff, printk(KERN_ERR PREFIX "gpio_request failed for pin %ld \n", pin); } gpio_direction_output(pin, 0); + + gpio_free(pin); } // read the new pin state reg = ioread16(base + gp_map[pin]); Frank Agius <ft...@ya...> writes: > I've uploaded to github a couple of device drivers that might be of > interest: > > 1) OMAP capture driver. This driver can set up a pin on the OMAP 35xx > processor as an input capture source. The original purpose was to > measure the frequency of a signal that corresponded to the RPM of a > motor. Only 4 pins on the 35XX can be used for capture: 144, 145, 146 > nd 147. The driver assumes that the capture pin is in "Mode 2" > (pwm_evt). The driver default is to set up pin 147 for capture. To set > up one of the other pins as capture,invoke the driver with > "capture_pin=xxx", where "xxx" is one of 144, 145, 146 and 147. Pulse > width (rising edge to falling edge) and frequency measurements can be > made on a signal connected to the capture pin. The driver continuously > captures width and frequency counts. If there is no input on the pin, > or the input goes away, the driver will report 0 for pulse width and > frequency counts. The ioctl interface will provide an integer count for > pulse width, frequency and clock source. To determine the values in > milliseconds, divide the returned count of width or frequency by the > clock source count and multiply by 1000. > > Source code: > http://github.com/ftagius/OMAP-Capture > > 2) OMAP 35xx control module pad configuration (aka cmpc) driver. > Derived from the mux driver code by Scott Ellis. This driver can set > the control module configuration register on the OMAP 35xx processor. > This allow configuring from user space the mode (from mode 0 to mode 7) > for individual pins. > > Source code: > http://github.com/ftagius/OMAP-cmpc > > Both drivers should work, but are a little rough around the edges. > Comments are welcome. > > > frank > > > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > -- Sent from |
From: Frank A. <ft...@ya...> - 2010-10-18 21:11:19
|
On 10/16/2010 3:58 PM, Oswald Berthold wrote: > > hi frank, > > excellent, i just tested the cmpc driver on the beagle. here's a > nano-patch for cmpc.c, as otherwise the gpio ports aren't accessible via > /sys/class/gpio after configuring. > > bst, oswald > > --- a/cmpc.c > +++ b/cmpc.c > @@ -250,6 +250,8 @@ static ssize_t cmpc_write(struct file *filp, const char __user *buff, > printk(KERN_ERR PREFIX "gpio_request failed for pin %ld \n", pin); > } > gpio_direction_output(pin, 0); > + > + gpio_free(pin); > } > // read the new pin state > reg = ioread16(base + gp_map[pin]); > > Good catch! Thanks for the feedback. I've committed the change. frank |
From: maq <ma...@sw...> - 2010-10-18 22:03:36
|
Hi all, the PIXHAWK student team has designed and build a robotics framework for aerial robotics that supports Gumstix Overo. We've won the EMAV 2009 indoor autonomy competition with an Overo-driven system. http://pixhawk.ethz.ch/ Our research hardware design is now for the first time available (on a non-profit basis), along with the public release of our flight control and inertial measurement software. The original hardware design files will also be made available later. http://pixhawk.ethz.ch/wiki/electronics/ IMPORTANT NOTE: To synchronize the first production run, the hardware is only orderable for the first batch until October 20, 2010! So if you're interested, please order now! You can use almost any of the standard Overo baseboards in conjunction with the pxIMU design. The specialty of our system design is that the Flight control - Linux interface code is soon available, along with a computer vision framework and several example processes (e.g. pattern recognition). The PIXHAWK toolkit represents the only toolkit designed from scratch for aerial robotics. http://pixhawk.ethz.ch/buy-hardware/ http://pixhawk.ethz.ch/wiki/software/ Regards, PIXHAWK Student team |