From: neo <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Saturday, September 13, 2014 at 6:17 AM To: "[email protected]" <[email protected]> Subject: Re: [beagleboard] Re: registering asynchronous events on kernel thread in user space
> Hi Brandon > > I am learning to use the BBB to interface a 802.15.4 radio to BBB without a > MCU between BBB and CC2500. I want to remove the MCU and interface directly to > the Kernel. Are you referring to the CC2520? If so, there is a driver in the linux-wpan repo: https://github.com/linux-wpan If you want support, send ³subscribe linux-wpan² e-mail to: [email protected] Regards, John > > So for this i have to service interrupts which will be a gpio interrupt to BBB > if a new packet arrives. So that the reason for the Doubts n questions. > And also the reason why i want to know which method is faster or better. > But I think that i have to do some profiling as u pointed out. > Will post the results ASAP here. > > Thanks for the reply > > On Friday, September 12, 2014 1:19:26 AM UTC+5:30, Brandon I wrote: >> OK, one more time. All userspace interrupts work the same, pru, network >> driver, *anything*. The process blocks until the interrupt handler unblocks >> the process with a semaphore or completion in the kernel. For example, when >> you read data for a socket connection, it blocks. When data comes in, the >> data is copied to userspace, the read function unblocks. Again, this is all >> explained in that LDD3 chapter I linked. There's no other way to do it, >> except going around the kernel and polling memory. >> >> 1. This isn't a realtime kernel. You will always have jitter. Does it matter? >> I don't know what you're doing. You don't need to use polling. UIO and select >> doesn't use polling. >> >> 2. Using select (and even poll() since it's just a wrapper for select()) on >> the gpio doesn't poll. It's interrupt driven. Same method as described. >> >> 3. Same method as described. >> >> If you use the PRU, it will be the same method to notify your userspace >> application with the same shortcomings, unless you put all of your code into >> the pru. If you want deterministic timing, you either need a realtime kernel, >> or put all your code on the pru. But, I can guarantee you don't need >> deterministic timing, and I can guess that you're worrying about nothing >> Seriously, do some benchmarks with sysfs. It's only a few lines of code. And, >> there are all sorts of userspace hardware drivers that use userspace >> interrupts out there including graphics and network. >> >> If you only need to know when a gpio event happened, and process it later (it >> will always be later since this isn't a realtime kernel or in the pru), you >> can timestamp the event. I believe you can do this with the enhanced timers, >> and I know you can do this in the pru. So it would go, event happens, >> pru/etimer hardware timestamps the event, sends interrupt, userspace gets >> interupt using "the only way possible", userspace reads timestamp from >> hardware, pretends that the event happened at the timestamp for any >> calculations. >> >> If you explained what you were doing, we could advise you better. >> >> Good luck! >> >> On Thursday, September 11, 2014, neo <[email protected] <javascript:> > >> wrote: >>> Hi Brandon >>> 1. I agree with jitter involved with processing interrupts and 100% cpu >>> usage during polling for the same, so is there no way to let the user-space >>> know that interrupt has occurred apart from polling ? >>> 2. The reason why i said pseudo-interrupt is because we are polling and >>> waiting there which is same as watching a flag in a UART register for RX >>> flag to set. >>> 3. I am curious as to how interrupts for Ethernet and usb are written. I am >>> guessing that the ISR will use the DMA to transfer bytes to user-space. But >>> even in that case the userspace should know that a new data has arrived. >>> Then hoe to synchronize the kernel space and user-space if there are to >>> share a data ? >>> Thanks... >>> >>> On Thursday, September 11, 2014 2:26:15 AM UTC+5:30, Brandon I wrote: >>>>> > pseudo-interrupt from user space >>>> >>>> There's nothing pseudo about it. Again, any usual way to have a userspace >>>> application respond to an interrupt will be the exact same. The kernel will >>>> block the userspace process until the interrupt is seen. The only real >>>> alternative is burning up the cpu with memory polling, which appears to be >>>> what the BBIOlib method uses. So, your latency is limited to your poll >>>> speed (which can be faster than interrupts). But, if you have a constant >>>> poll for minimum latency, lets hope you're not trying to do something >>>> important elsewhere since your cpu usage will be at 100%, and you'll be >>>> maximizing process to process context switching! >>>> >>>> For 4, The only difference between a userspace and kernel space interrupt >>>> handler is where the code is that responds to the interrupt. You will only >>>> benefit from writing your own interrupt handler if you put all of your code >>>> that does something with that interrupt in the kernel. Otherwise, you're >>>> back to process blocked by kernel, interrupt occurs, kernel unblocks >>>> process, process does something after seeing the interrupt....back to the >>>> sysfs/UIO method. >>>> >>>> I would try some benchmarks. See if the regular UIO/sysfs interrupt method >>>> gives you sufficient performance. And definitely keep in mind John's >>>> statement. You're going to see a massive amount of jitter for anything in >>>> userspace or kernel space (better jitter since you can disable interrupts >>>> and whatnot, but if you don't finish quickly in kernel space, you'll crash >>>> the kernel). >>>> >>>> If something like a precise timestamp is needed for an async event, then >>>> there are other ways to approach this. If you're looking for fixed low >>>> latency, you're doomed. >>>> >>>> On Wed, Sep 10, 2014 at 5:13 AM, neo <[email protected]> wrote: >>>>> pseudo-interrupt from user space >>>> >>>> >>> >>> -- >>> 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]. > 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.
