> > *I'll check out that pastbin of yours, so see if I can glean what I've > been missing thus far.* >
Ah, perhaps information and things I had not considered yet. But not what I was hoping for ;) config files, and device tree files I can usually figure out fairly easily. Was hoping to "spot" some uio buffer layout goodness :) On Sun, Nov 1, 2015 at 10:22 PM, 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. But it's not. > Just a point I feel the need to put out there. Using /dev/mem/ + mmap() is > in no way different than using the PRU's to do the same thing. That is, in > the context of accessing the registers. Obviously though the PRU's have the > deterministic aspect on their side. Anyhow, the "drivers" have no idea > what is going on in either case. Assuming a driver is even used. But I've > found that one can simply "poke" the correct registers, in the correct > order to use the ADC module - Without even using a driver module . . . So I > would assume most, if not all peripheral modules would be the same. > > *A bit more elegant than using /dev/mem is using the uio_pdrv_genirq >> driver, which lets you set the permissions of the device using udev hence >> avoid the need to be root, and also allows you to receive irqs in >> userspace. If the device tree node(s) also have the appropriate ti,hwmods >> property (e.g. if you simply reuse an existing DT node but alter it to use >> uio) then the kernel will also enable the module clocks for you when you >> open the device, saving you from manually fiddling with PRCM. This is an >> example I made earlier for doing this for the ADC, but other modules are >> similar: http://pastebin.com/GrHwgYiR <http://pastebin.com/GrHwgYiR>* >> > > Actually, my ideal "elegant" way to use the registers for peripherals. > Would be by using the PRU's through remoteproc / rpmsg. I've been reading > up on that subject, as well as the general usage of the PRU's, and I have > to say: It's so far a very steep learning curve. For me though, I've been > mostly a high level language developer most of my . . . hobbyist "career". > So anything low level, can be an adventure for me. 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. I'm typically going > for all out performance. I've found in all cases so far, that system > interrupts, tend to slow down code considerably . . .The uio driver for the > ADC I've found to be like this so far. But I am in no way an expert, and to > be perfectly honest I do not know the layout of uio buffer ( > /dev/uio:device0) at all. I am able to read the first 32 bits, and mask out > the data, and ID fields, but have no idea how to access the whole buffer, > or how it's laid out - Yet. I mostly got bored with it after realizing that > I can pretty much max out the ADC, in userspace by using /dev/mem/ . . . as > much as one can anyway, before system latency starts taking it's toll - > Even on an RT kernel. > > I'll check out that pastbin of yours, so see if I can glean what I've been > missing thus far. > > On Sun, Nov 1, 2015 at 9:32 PM, Matthijs van Duin < > [email protected]> wrote: > >> On 2 November 2015 at 04:33, William Hermans <[email protected]> wrote: >> >>> I honestly do not know the eCAP / PWM modules at all, but I suspect that >>> you would not necessarily need to use the PRU to access these modules. >> >> >> Although I haven't yet tried to use the eCAP in PRUSS, I don't think >> there's any particular obstacle to using it directly. You don't need to get >> the PRU cores involved if you don't want to. I just mentioned them as a way >> to create *even more* PWM outputs (via PRU's GPOs) if you'd need them. >> >> >>> Pretty much anything that can be accessed via the PRU's can be accessed >>> from a C program through /dev/mem/ + mmap(). >> >> >> 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. >> >> A bit more elegant than using /dev/mem is using the uio_pdrv_genirq >> driver, which lets you set the permissions of the device using udev hence >> avoid the need to be root, and also allows you to receive irqs in >> userspace. If the device tree node(s) also have the appropriate ti,hwmods >> property (e.g. if you simply reuse an existing DT node but alter it to use >> uio) then the kernel will also enable the module clocks for you when you >> open the device, saving you from manually fiddling with PRCM. This is an >> example I made earlier for doing this for the ADC, but other modules are >> similar: http://pastebin.com/GrHwgYiR >> >> Beware btw that the eHRPWM modules have an additional little >> complication: their counters also need to be ungated via a control module >> register. The purpose of this is to allow the modules to run synchronized >> by configuring them to the same frequency and then ungating their counters >> simultaneously. The control module however requires privileged writes, and >> any write performed in a normal way from userspace gets ignored. >> Fortunately, you can easily get the kernel to perform the write for you, >> e.g. using process_vm_readv( getpid(), ... ). >> >> Matthijs >> >> >> -- >> 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.
