How are you counting your pulses? If you are firing interrupts faster than you can service them then you will be missing interrupts. There are only 2 ways to get faster interrupts on the beaglebone than what your are doing now and that is by either writing a kernel driver, to avoid the latency in the context switches, or by using the PRU.
On 29/10/13 19:01, sudhir v wrote: > Hi Jack, > > I apologize if my previous reply came across as rude. Let me be more > humble and do proper homework before posting from now on :-) > I didn't have the time to work on this till now. You were right in > pointing out usage of POLLPRI instead of POLLIN. I had tried both > earlier and it did not work. Turns out it was because of the faulty pin > (assuming here..pin stayed high always regardless of settings). I am > using a different pin and POLLPRI and it is working fine. > Although I did not understand the part about the interrupts. I am > keeping a counter to count the interrupt event and using function > generator, I am feeding pulses to BBB. It is a bare minimum code to to > just increment counter upon every rising edge detected. I set the number > to 10,000 initiallly and it takes wall clock time of 0.22 seconds to > detect 10000 rising edges. I wasn't sure if the number was correct so I > increased the frequency of the pulses to 40,000 and even then the wall > clock time is around ~0.2-0.3 seconds. Why might this be? How to check > what's the maximum number of edges which can be detected without losing > any edges. > > Thanks, > sudhir. > > On Monday, 21 October 2013 17:31:47 UTC-4, Jack Mitchell wrote: > > Hi Sudhir, > > If you are not well versed in Linux and C then the speed of your own > code will be no faster than using my library with debugging disabled > I imagine. > > Without looking seriously at your code there are two things I want > to say. > > 1) You should be using POLLPRI - look at my library for an example > 2) Poll does not introduce 150ms latency > > If you run the tests included with my libsoc library you will see > that it can service 10,000 interrupts in a non-blocking context in > roughly 3 seconds on a beaglebone white. That's per interrupt and > simple ISR style routine. I would be suprised if you could get it > much faster than that using standard read/write file techniques. > > If you really want to roll your own, and are still struggling then > just base it off my library. That way you have a fully working > example to compare your code with. > > Cheers, > Jack. > > On 10/21/13 19:08, sudhir v wrote: >> Hi Jack, >> >> Thanks for the help!. I looked at your library and it appears that >> you are using poll(2) as well which is similar to the example I am >> trying to use in the original post. >> >> There are two things I want to mention >> 1. Latency : I came across somewhere that poll() by itself >> introduces 150ms latency which is not good for the system I am >> building. (But I want it to work first) And you have mentioned >> that the library is optimized for reliability rather than speed. >> 2. Complexity : Interrupt capture is just a small part of the >> system I am building and I want the code to be as simple and >> little as possible. This Code >> <https://developer.ridgerun.com/wiki/index.php/Gpio-int-test.c> appears >> to be simple enough and does just the functionality. >> >> Since you have built the library, Can you please just point out >> where in the code I might be going wrong? The problem might be >> trivial but I am missing something. I am using POLLIN and it >> continuously outputs GPIO 117 interrupt occurred even though I >> have not connected any signals to GPIO 117. More details/analysis >> done in the original post. >> >> Thank you! >> sudhir. >> >> On Friday, 18 October 2013 13:25:09 UTC-4, Jack Mitchell wrote: >> >> Sudhir, >> >> If you don't object to using a library there is libsoc[1] >> which is made >> for this exact purpose. >> >> https://github.com/jackmitch/libsoc >> <https://github.com/jackmitch/libsoc> >> >> Cheers, >> Jack. >> >> On 18/10/2013 17:31, sudhir v wrote: >> > >> > Hi, >> > >> > I want to monitor a pin on BBB for interrupt. I chose pin >> 117 (pin 25 on >> > P9 -> GPIO3_21 = 32*3+21 = 117. I hope that's correct?) >> > I came across this question on stackoverflow >> > >> >> <http://stackoverflow.com/questions/3021146/poll2-doesnt-empty-the-event-queue >> >> <http://stackoverflow.com/questions/3021146/poll2-doesnt-empty-the-event-queue>>. >> >> > And This is my question on stackoverflow >> > >> >> <http://stackoverflow.com/questions/19434157/poll-to-monitor-a-pin-on-beaglebone-black-continuous-output-even-though-pin-n >> >> <http://stackoverflow.com/questions/19434157/poll-to-monitor-a-pin-on-beaglebone-black-continuous-output-even-though-pin-n>> >> >> > I am following this program from ridgerun >> > >> <https://developer.ridgerun.com/wiki/index.php/Gpio-int-test.c >> <https://developer.ridgerun.com/wiki/index.php/Gpio-int-test.c>> >> and made >> > minor changes since I want to monitor just one pin and not >> any other >> > files. Changes are highlighted in the code below which I am >> trying to >> > run. (I have pasted just the main. Rest is the same as the >> code from the >> > site) >> > The problem is, when I run the program, it continuously >> outputs "poll() >> > GPIO 117 interrupt occurred" even though I haven't connected >> anything to >> > that particular pin and I have to do ctrl+C to stop the >> execution. >> > POLLPRI does not work and the program prints just ... after >> every >> > timeout and I think POLLIN is proper since it is not a >> priority data. >> > >> > Where am I going wrong? >> > >> > I read about potential problems and the program seems to >> take care of >> > the below. >> > 1. The poll() doesn't fail. >> > 2. read() is called after every poll() so data should be >> consumed. ( I >> > just want the program to notify whenever there is a rising >> edge saying >> > there is an event occured. I do not want to read data from >> pin. but >> > included this to avoid potential pitfalls) >> > 3. struct pollfd is being reset inside while loop ( >> > memset((void*)fdset,0,sizeof(fdset)); ) >> > >> > | >> > >> > int main(int argc, char **argv) >> > { >> > *struct pollfd fdset[1];* >> > *int nfds= 1;* >> > int gpio_fd, timeout, rc; >> > char *buf[MAX_BUF]; >> > unsigned int gpio; >> > int len; >> > if (argc< 2) { >> > printf("Usage: gpio-int <gpio-pin>\n\n"); >> > printf("Waits for a change in the GPIO pin >> voltage level or input on stdin\n"); >> > exit(-1); >> > } >> > gpio= atoi(argv[1]); >> > gpio_export(gpio); >> > gpio_set_dir(gpio, 0); >> > gpio_set_edge(gpio, "rising"); >> > gpio_fd= gpio_fd_open(gpio); >> > timeout= POLL_TIMEOUT; >> > while (1) { >> > memset((void*)fdset, 0, sizeof(fdset)); >> > *fdset[0].fd= gpio_fd; >> > fdset[0].events= POLLIN;* >> > rc= poll(fdset, nfds, timeout); >> > if (rc< 0) { >> > printf("\npoll() failed!\n"); >> > return -1; >> > } >> > if (rc== 0) { >> > printf("."); >> > } >> > *if (fdset[0].revents& POLLIN) { >> > len= read(fdset[0].fd, buf, MAX_BUF);* >> > printf("\npoll() GPIO %d interrupt >> occurred\n", gpio); >> > } >> > fflush(stdout); >> > } >> > gpio_fd_close(gpio_fd); >> > return 0; >> > } >> > >> > | >> > >> > Thanks, >> > sudhir >> > >> > -- >> > For more options, visit http://beagleboard.org/discuss >> > --- >> > You received this message because you are subscribed to the >> Google >> > Groups "BeagleBoard" group. >> > To unsubscribe from this group and stop receiving emails >> from it, send >> > an email to beagleboard...@googlegroups.com. >> > For more options, visit >> https://groups.google.com/groups/opt_out >> <https://groups.google.com/groups/opt_out>. >> >> >> -- >> >> Jack Mitchell (ja...@embed.me.uk) >> Embedded Systems Engineer >> http://www.embed.me.uk >> >> -- >> > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google > Groups "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer Cambridgeshire, UK http://www.embed.me.uk -- -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
