From: rhonig <rav...@gm...> - 2009-07-08 15:04:43
|
Hi, I have been trying to write a program that uses the gpio-event functionality to monitor gpio pins at a potentially high frequency. I would like to be able to monitor at up to 27 mHz without losing events, but after what I've done so far this seems fairly unrealistic. I have been able to monitor frequencies of about 8 kHz accurately without losing any events, but I am a little unclear on how the event queue actually works. Sometimes I will run my program, with the 8 kHz frequency, and I will have no lost events, but then if I run the program again directly after that, I will lose events as soon as it begins. This leads me to believe that there are still events in the queue when I start the program again, so I would like to find out if there is a way to clear the event queue before I start the program. In the gpio-event-drv.c file, there is a dequeue function, but I don't seem to have any way of using that function in my program. Is there a way that I can clear the queue? I'll copy in the code for my program in case anyone has an idea on how to speed it up. Thanks for any help in advance. #include <iostream> #include <fstream> #include <stdio.h> #include <stdlib.h> #include <getopt.h> #include <fcntl.h> #include <ctype.h> #include <unistd.h> #include <string.h> #include <time.h> #include <stropts.h> extern "C"{ #include "gpio-event-drv.h" } using std::cout; using std::cin; using std::endl; using std::ifstream; using std::ios; int main() { FILE *eventf; GPIO_EventMonitor_t monitor; char sec[1000000]; char micro[1000000]; char edge[1000000]; eventf = fopen( "/dev/gpio-event", "r" ); monitor.gpio = 76; monitor.onOff = 1; monitor.edgeType = GPIO_EventRisingEdge; //monitor.edgeType = GPIO_EventFallingEdge; //monitor.edgeType = GPIO_EventBothEdges; monitor.debounceMilliSec = 0; ioctl( fileno( eventf ), GPIO_EVENT_IOCTL_MONITOR_GPIO, &monitor ) ioctl( fileno( eventf ), GPIO_EVENT_IOCTL_SET_READ_MODE, 1 ); int c = 0; while(c < 100000) { GPIO_Event_t event; fread( &event, 1 , sizeof( event ), eventf ); sec[c] = event.time.tv_sec; micro[c] = event.time.tv_usec; c++; } fclose(eventf); return 0; } -- View this message in context: http://www.nabble.com/help-with-gpio-event-and-understanding-the-event-queue-tp24393033p24393033.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2009-07-08 17:24:50
|
Hi, > Hi, I have been trying to write a program that uses the gpio-event > functionality to monitor gpio pins at a potentially high frequency. I would > like to be able to monitor at up to 27 mHz without losing events, but after > what I've done so far this seems fairly unrealistic. I'll say that's a little unrealistic. On a 600 MHz processor, that means that you need to be able to deal with each gpio event using only 22 assembly language instructions. You'll probably find this impossible to do, even if the silicon could deal with this, and you coded everything in assembler. > I have been able to > monitor frequencies of about 8 kHz accurately without losing any events, but > I am a little unclear on how the event queue actually works. Sometimes I > will run my program, with the 8 kHz frequency, and I will have no lost > events, but then if I run the program again directly after that, I will lose > events as soon as it begins. This leads me to believe that there are still > events in the queue when I start the program again, so I would like to find > out if there is a way to clear the event queue before I start the program. The problem is that other interrupts occur on the system. If any of those interrupts takes more than 125 microseconds to process (1/8000), then you will loose an event. I highly recommend that you profile how long it takes for the linux interrupt handler to fire, and then reset your expectations.... > In the gpio-event-drv.c file, there is a dequeue function, but I don't seem > to have any way of using that function in my program. Is there a way that I > can clear the queue? I'll copy in the code for my program in case anyone > has an idea on how to speed it up. Thanks for any help in advance. The event queue is a simple, circular buffer implemented using an array. The array has GPIO_EVENT_QUEUE_LEN elements in it, and there is a get index and a put index. Setting the get index equal to the put index will "empty" the queue. numEvents should also be set to zero to keep things consistant. gpio-event wasn't designed to be a high-performance driver. It was designed to allow user-mode access to gpio events, typically for dealing with user-interface type stuff. If you want high-performance stuff you really need to do everything from kernel space, and forget about involving user-space. There's too much overhead involved in the user-space to kernel space context switches. Typically, the only way you can successfully do any type of bi-banged I/O in linux is if the linux host also generates the clock which controls the "flow". If you don't have that, then I can pretty much guarantee that you will miss events. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: rhonig <rav...@gm...> - 2009-07-08 18:15:48
|
Do you know what a more reasonable maximum sampling frequency is that can be achieved on the gumstix? I could possibly slow the signal down to whatever the maximum frequency the gumstix can monitor is. -- View this message in context: http://www.nabble.com/help-with-gpio-event-and-understanding-the-event-queue-tp24393033p24396723.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2009-07-08 19:44:04
|
Hi, On Wed, Jul 8, 2009 at 11:15 AM, rhonig<rav...@gm...> wrote: > > Do you know what a more reasonable maximum sampling frequency is that can be > achieved on the gumstix? I could possibly slow the signal down to whatever > the maximum frequency the gumstix can monitor is. That's going to depend on the code doing the sampling, and what else is running on the system at the time.... What type of signal are you sampling? -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: rhonig <rav...@gm...> - 2009-07-08 19:56:19
|
Dave Hylands wrote: > > Hi, > > On Wed, Jul 8, 2009 at 11:15 AM, rhonig<rav...@gm...> wrote: >> >> Do you know what a more reasonable maximum sampling frequency is that can >> be >> achieved on the gumstix? I could possibly slow the signal down to >> whatever >> the maximum frequency the gumstix can monitor is. > > That's going to depend on the code doing the sampling, and what else > is running on the system at the time.... > > What type of signal are you sampling? > Well, I've got an NTSC video signal going into a decoder, with 9 lines coming out, 8 giving a binary value for a pixel and one being the clock bit, with the pixels going out at 27 mHz. I was hoping I'd be able to attach these to gpios on the gumstix in order to read in the data. -- View this message in context: http://www.nabble.com/help-with-gpio-event-and-understanding-the-event-queue-tp24393033p24398200.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2009-07-08 20:07:32
|
Hi, > Well, I've got an NTSC video signal going into a decoder, with 9 lines > coming out, 8 giving a binary value for a pixel and one being the clock bit, > with the pixels going out at 27 mHz. I was hoping I'd be able to attach > these to gpios on the gumstix in order to read in the data. Somebody did a test on the verdex, and with a tight loop, the fastest they could toggle an output GPIO was around 10 MHz. To handle anything like that you're going to need to use DMA with a big FIFO... I'd recommend that you try benchmarking something like a memcpy and see how many cycles it takes just to copy the data, without even factoring in the capture... -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Ned F. <nfo...@wh...> - 2009-07-08 20:59:19
|
On 07/08/2009 04:07 PM, Dave Hylands wrote: > Hi, > >> Well, I've got an NTSC video signal going into a decoder, with 9 lines >> coming out, 8 giving a binary value for a pixel and one being the clock bit, >> with the pixels going out at 27 mHz. I was hoping I'd be able to attach >> these to gpios on the gumstix in order to read in the data. > > Somebody did a test on the verdex, and with a tight loop, the fastest > they could toggle an output GPIO was around 10 MHz. > > To handle anything like that you're going to need to use DMA with a big FIFO... > > I'd recommend that you try benchmarking something like a memcpy and > see how many cycles it takes just to copy the data, without even > factoring in the capture... I'd second that. I have an application that reads externally clocked 11Mbit/sec data from the SPI port, using descriptor DMA, and then adds a little meta-data and retransmits it as UDP packets. That requires about 70% of a 400MHz PXA255, just to send 1.4Mbytes/sec. Now my kernel driver might not be the most efficient, and the standard Ethernet driver for the SMC chip that is on the Netstix does not support DMA for transmit, but I'd be surprised if you could do anything with data at 20 times that rate (27Mbyte/sec), even with kernel drivers. -- Ned Forrester nfo...@wh... Oceanographic Systems Lab 508-289-2226 Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/ http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 http://www.whoi.edu/hpb/Site.do?id=1532 http://www.whoi.edu/page.do?pid=10079 |
From: Søren S. C. <li...@ss...> - 2009-07-08 21:03:06
|
I would strongly recommend using the camera interface this purpose instead of trying to make some "strange" solution using GPIOs. The camera interface was designed for exactly this use case - Just feed it the data and a sampling clock, and it will be able to handle the task - Only drawback I see in this way forward is, that the interface isn't the most accessible on the Overo I agree :-) Best regards - Good luck Søren -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Wednesday, July 08, 2009 10:07 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] help with gpio-event and understanding the event queue Hi, > Well, I've got an NTSC video signal going into a decoder, with 9 lines > coming out, 8 giving a binary value for a pixel and one being the clock bit, > with the pixels going out at 27 mHz. I was hoping I'd be able to attach > these to gpios on the gumstix in order to read in the data. Somebody did a test on the verdex, and with a tight loop, the fastest they could toggle an output GPIO was around 10 MHz. To handle anything like that you're going to need to use DMA with a big FIFO... I'd recommend that you try benchmarking something like a memcpy and see how many cycles it takes just to copy the data, without even factoring in the capture... -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users Checked by AVG - www.avg.com Version: 8.5.387 / Virus Database: 270.13.8/2224 - Release Date: 07/08/09 05:53:00 |
From: rhonig <rav...@gm...> - 2009-07-09 13:36:52
|
Søren Steen Christensen wrote: > > I would strongly recommend using the camera interface this purpose instead > of trying to make some "strange" solution using GPIOs. The camera > interface > was designed for exactly this use case - Just feed it the data and a > sampling clock, and it will be able to handle the task - Only drawback I > see > in this way forward is, that the interface isn't the most accessible on > the > Overo I agree :-) > > Best regards - Good luck > Søren > Well, I'm currently using a verdex pro and I'm not familiar with the overo, but if it has the functionality that I need, that would be fantastic. Do you know where I can find more information about the camera interface on the overo? Thanks. -- View this message in context: http://www.nabble.com/help-with-gpio-event-and-understanding-the-event-queue-tp24393033p24410298.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Søren S. C. <li...@ss...> - 2009-07-09 19:48:03
|
> > Well, I'm currently using a verdex pro and I'm not familiar with the > overo, > but if it has the functionality that I need, that would be fantastic. > Do you know where I can find more information about the camera interface > on the overo? The interface is documented in the OMAP3 documents: TRM Chapter 12: http://focus.ti.com/lit/ug/sprufa2b/sprufa2b.pdf DM: http://focus.ti.com/lit/ds/symlink/omap3503.pdf The connector on Overo is documented at: http://www.gumstix.net/Hardware/view/Motherboard-I/O/Connector-J5-for-Overo-to-manage-camera-controls/112.html Good luck Søren |