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