Hi John
1. You said that i can execute control functions / time critical functions using PRU, but how ? Is there any guide/sample code to using the PRU like in github ? 2. There is nothing described about using PRU in the TRM, except that its has 7 interrupt lines so are there application notes or guides or ready to use libraries. 3. Any reason why you suggested that i can use PRU for time critical operations and can generate a signal to the user-space reliably without that jitter you were referring to ? Thanks On Thursday, September 11, 2014 12:50:36 AM UTC+5:30, john3909 wrote: > > > From: neo <[email protected] <javascript:>> > Reply-To: "[email protected] <javascript:>" < > [email protected] <javascript:>> > Date: Wednesday, September 10, 2014 at 5:13 AM > To: "[email protected] <javascript:>" <[email protected] > <javascript:>> > Subject: Re: [beagleboard] Re: registering asynchronous events on kernel > thread in user space > > Hi Brandon > > Thanks for the reply. > I will summarize here what i found about controlling a GPIO and about > using interrupts. > > 1. Using sysfs one can easily control the gpio and using threading can > re-create pseudo-interrupt from user space. Found a useful project called > libsoc https://github.com/jackmitch/libsoc. They use threading along > with polling using poll(2) > 2. Using mmap() one can import the memory space of the GPIO peripheral > and with a combination of threads can re-create pseudo-interrupt from user > space. Found useful project called BBBIOlib > https://github.com/VegetableAvenger/BBBIOlib. > 3. Using /dev/input/event for controlling GPIO from user space. > 4. Using an LKM from kernel space where one can use request_irq() or > request_threaded_irq() and using some kind of buffering to transfer the > data to userspace. Here one will be writing actual interrupts. Some bits > can be found here > > http://processors.wiki.ti.com/index.php/GPIO_Driver_Guide#Sysfs_entries_configuration > > I have very good idea about 1 and 2. > > I am still working on 3-> /dev/input and also on 4-> about writing a real > ISR. > > Although the above methods enable GPIO control I am not sure which will > give me the highest performance. > > I read that using mmap() method gives faster switching on forums and the > using sysfs gives the slowest switching rate. I am not sure about > /dev/input method. The LKM method gives faster ISR and i am guessing that > LKM in combination with mmap() will give faster response timings. > > Any thoughts on the above... > > You are on the right path. One thing to remember, whenever you are doing > any I/O from user space, you are dealing with context switching and thread > scheduling, which means that your application won’t respond to a GPIO event > for anywhere from a few ms to 100mS. This is true because of both the > interrupt latency in Linux and thread scheduler. In most cases, this is > fine, because the user doesn’t know the difference. However, if you are > attempting to do some sort of control, then you may want to consider the > PRU. The PRU can still send events to your user space app. Another solution > might be Xenomai which reduces to interrupt latency to about 50uS on the > BBB, but you still have the context switch delay. > > Regards, > John > > > On Wednesday, September 10, 2014 8:20:18 AM UTC+5:30, Brandon I wrote: >> >> Before you jump into the kernel hole, is there a reason that you're not >> using the existing sysfs gpio interface ( >> https://www.kernel.org/doc/Documentation/gpio/sysfs.txt) for the >> interrupts? >> >> Using this, if you set the gpio up as an interrupt with the sysfs >> interface, you poll() the value file and it will block until there's an >> interrupt. When it unblocks, you can read the current value. >> >> Or, you can make the gpio look like an event/button: >> http://bec-systems.com/site/281/how-to-implement-an-interrupt-driven-gpio-input-in-linux >> >> Any sane way you do it will be the same at the low level. You'll have a >> read or ioctl function on the kernel device file that blocks in the kernel >> using a completion/semaphore, putting your process/thread to sleep. When >> the interrupt fires, the interrupt handler function is called to release >> the completion/semaphore, unblocking your process/thread and allowing it to >> continue executing. This unblocking is how the userspace program is >> signaled. >> >> So, if you *want* to reinvent the wheel, for understanding, then that's >> fine. But, there's an existing interface that exists, only a few lines of >> code away. >> >> --Brandon >> >> On Tue, Sep 9, 2014 at 7:10 PM, neo star <[email protected]> wrote: >> >>> Hi Brandon >>> >>> I read through the link, very informative thanks.I can create a thread >>> to do the polling and signal me when its ready. >>> But how to really write an ISR in arm. I see a lot of guides but they >>> say that it will work in Intel processors but they are not sure about ARM. >>> For sure from my readings i see that i need a kernel object to handle an >>> ISR, But how to really do that. >>> One example about how to handle interrupts is in >>> http://stackoverflow.com/questions/15245626/simple-interrupt-handler-request-irq-returns-error-code-22 >>> The other one is request_threaded_irq() as mentioned by Kavita in the >>> above post. >>> Is there any How to and guide to writing one. Any links. >>> Thanks. >>> >>> >>> On Wednesday, September 10, 2014 12:59:08 AM UTC+5:30, Brandon I wrote: >>>> >>>> See UIO: https://www.kernel.org/doc/htmldocs/uio-howto/ >>>> >>>> The uio_pruss.c driver that comes with the pru package is a good >>>> example. >>>> >>>> > I have written a kernel module that registers interrupts on the >>>> rising edge on a GPIO pin and want to relay this message to user space. >>>> >>>> The sysfs gpio interface already does this. Check out the code. >>>> >>>> On Thursday, August 28, 2014 2:44:12 AM UTC-7, [email protected] wrote: >>>>> >>>>> I have read online that we can't handle interrupts from user >>>>> space. Instead - >>>>> 1) We can write a kernel thread and have that thread wait on an event. >>>>> 2) Once the interrupt occurs, send one asynchronous event from the >>>>> kernel module/driver to user space where we will have one signal handler >>>>> with FASYNC to tackle this >>>>> >>>>> I have written a kernel module that registers interrupts on the rising >>>>> edge on a GPIO pin and want to relay this message to user space. How do I >>>>> go about implementing the above? >>>>> >>>>> Thanks! >>>>> >>>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "BeagleBoard" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/beagleboard/eNX0CU7-noE/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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 [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
