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. 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 <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 <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.
