Hi John Thanks for the link.
On Sun, Sep 14, 2014 at 3:44 AM, John Syn <john3...@gmail.com> wrote: > > From: neo <prag.in...@gmail.com> > Reply-To: "beagleboard@googlegroups.com" <beagleboard@googlegroups.com> > Date: Saturday, September 13, 2014 at 6:17 AM > To: "beagleboard@googlegroups.com" <beagleboard@googlegroups.com> > 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: > > majord...@vger.kernel.org > > 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 <prag....@gmail.com> wrote: >>> >>> Hi Brandon >>> >>> 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 ? >>> 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. >>> 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 <prag....@gmail.com> 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 >>> beagleboard+unsubscr...@googlegroups.com. >>> 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 beagleboard+unsubscr...@googlegroups.com. > 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 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 > beagleboard+unsubscr...@googlegroups.com. > 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
