OK, I will use the busy-wait loop w/ usleep and test. The reason I used select was I thought it would allow me to do other things (I need to have another process, thread, or loop in this same application serving out audio data to another client, synchronized with this data). My understanding was that the process blocking on select() to return would free the CPU for other things, but allow a quick wake-up to refresh the buffer as needed.
BTW, I have only mentioned the problems - but it does *almost* work. In my tests, I ran 12,500 4KiB buffers from ARM to PRU and measured (on the PRU side, using the precise CYCLE counter) to see if the PRU ever had to wait for the next buffer fill. Turns out that the PRU had to wait about 180 times, or about 1.5% of the buffer fill events. The worse case wait (stall) time was ~5milliSeconds. On Thursday, March 23, 2017 at 3:03:47 AM UTC-7, William Hermans wrote: > > > > On Wed, Mar 22, 2017 at 10:13 PM, ags <[email protected] <javascript:> > > wrote: > >> I thought using select() to wait for notification of an event (by >> "listening" to the fsys uio files) would free the ARM cpu to do other >> things while waiting, but provide the most immediate path to the user space >> application to send more data. Is there a better way? >> > > So that select() is probably your whole problem. Unless, you're using > other system calls as well. But I've already discussed with you the best, > and fastest way to achieve your goal. Several times in fact. Use a bit in > memory, *somewhere*. > > PRU side: > while(somewhere & 0x1 ) > usleep(1000); > /* Do our work after while() fall through */ > > Userspace side: > while(! (somewhere & 0x1) ) > usleep(1000); > /* Do our work after while() fall through */ > > No need for select(), no need for fancy threading calls, or other magical > hand waving. Just two simple busy wait loops waiting for their respective > turns. But, don't forget to toggle the bit back, when you're done. Anyway, > it's not really Linux that's off in the weeds. Well perhaps it is, but your > application is pushing it into the weeds. > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2c4feb8c-824d-4a64-8c8f-dfbb5c14d962%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
