> > *Why? Using PRUs to access peripherals makes no sense to me either, unless > you need *really* tight timing.* >
Determinism. I do agree with what you're saying, but sometimes, you need things to happen at exactly <some time interval >. In userland, you may be able to achieve that most of the time, but you will not be able to achieve that all of the time. Even if that time interval does not happen very often. As an added bonus, we get to offload the main core in the process :) > *No such thing exists. Are you confusing uio with iio? I never really > explored iio in much detail, using direct userspace access was more > convenient.* > Yes, I did confuse iio with uio. Or more correctly thinking of one thing, while speaking about another . . hah. Been reading too much lately, about too many things, I think. uio I suppose I know *of* but have not done much reading on it yet. uio:device0 *should have been* iio:device0 *I have absolutely no idea what you could mean by that. * So /dev/iio:device0 is a buffer for the ADC when operating in continuous mode . . . long story short - I now consider iio a waste of time. In a way, like you, I do not like unnecessary abstraction layers. Especially those that seem to fight against ones willingness to learn . . .Especially difficult ones, that seem to require a "secrete handshake" to get any decent information about. E.G. buy a high dollar Linear technologies device. Maybe I'm over stating things a bit ? Maybe . . .but either way I'm done wasting my time with iio. *No, I said some people. :-) I personally much prefer to directly access > peripherals than go through thick layers of overhead to ultimately > accomplish exactly the same time. I even setup DMA transfers from userspace > ;-)* > Ok, well I was just putting that out there . . . One of the biggest things in my mind about what makes Linux great, is it's flexibility. So when so-n-so tries to tell me "you can't do x.y.z, because of a.b.c . . ." Not only do I end up laughing to myself over it, I usually let them have "what for", because that's how I am ;) On Sun, Nov 1, 2015 at 10:59 PM, Matthijs van Duin < [email protected]> wrote: > On 2 November 2015 at 06:22, William Hermans <[email protected]> wrote: > >> *Correct, pretty much anything can be used from userspace like that, >>> although some people will frown at you for bypassing the kernel if you do.* >>> >> >> So maybe to you, and others this seems like an argument. >> > > No, I said *some people*. :-) I personally much prefer to directly access > peripherals than go through thick layers of overhead to ultimately > accomplish exactly the same time. I even setup DMA transfers from userspace > ;-) > > > > >> Actually, my ideal "elegant" way to use the registers for peripherals. >> Would be by using the PRU's through remoteproc / rpmsg. >> > > Why? Using PRUs to access peripherals makes no sense to me either, unless > you need *really* tight timing. > > >> It seems as though I should read up on *uio_pdrv_genirq *though*. *Granted, >> "IRQ" to me spells "trouble". As when using hardware like this, as such. >> > > An uio device in general behaves like a chunk of /dev/mem, corresponding > to the register range declared in DT. It's a little safer than /dev/mem > since the device only gives access to that predeclared range, and as I > mentioned you get benefits like being able to have the kernel automatically > enable the module in PRCM when you open the device (and disable it again > after closing it). > > The "genirq" is in the name because it also includes a generic way to > receive IRQs if you wish to: you should declare the interrupt in DT, after > opening the device you write (u32)1 to it to enable interrupts and > read(u32) from it to wait for an interrupt, or you can use poll() or any > other event loop. At most one IRQ is supported per device, but you can just > declare extra uio devices in DT consisting of just an IRQ (no regs) if you > need them. > > IRQ latency test on an RT kernel, with a userspace process waiting for a > GPIO-triggered IRQ and pulsing another GPIO in response. Not great but > good enough for many purposes: > > > > > >> The uio driver for the ADC >> > > No such thing exists. Are you confusing uio with iio? I never really > explored iio in much detail, using direct userspace access was more > convenient. > > Was hoping to "spot" some uio buffer layout goodness :) > > > I have absolutely no idea what you could mean by that. > > -- > 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.
