Hi Jelena, thanks for your message. See my inline responses: On Sun, Apr 2, 2017 at 9:39 AM, Jelena Freiherr <jeli.freih...@gmail.com> wrote:
> Am Sonntag, 2. April 2017 17:26:10 UTC+2 schrieb Justin Pearson: > > On the 3.18 kernel, I was able to control the PWM with the PRU > without needing the PRU to initialize the PWM. The trick was to load the > PWM capes "am33xx_pwm" and "bone_pwm_P8_34" before running the PRU code. > (And also loading Derek's cape to initialize the pruss.) Loading the capes > causes some PWM kernel driver to initialize the PWM registers, I assume. > Once that's done, the PRU just has to tweak a couple registers to change > the duty cycle. Is this trick what you're referring to when you say "The > kernel driver should also work"? > > > > Would this trick of pre-loading the capes also work in a 4.x kernel? > > > > Sorry, I don't know any of the overlays you mentioned. And, as I said, I > never used any kernel driver for GPIO, QEP, CAP, PWM or ADC. Instead I > use an all-in-one driver (which I named libpruio), that handles all that > stuff easier, more flexible and faster than any kernel driver framework. > In order to get PWM output, there're just a few registers to set (see > file pruio_pwmss.p in the package), so no need for all that multi source > overhead. > Thank you for mentioning libpruio. I don't know very much about how device tree overlays interact with linux kernel drivers, so until I can find a good description of that, I'm inclined to use a more wasteful (but well-documented) method of configuring the I/O. Do you know of a good way to learn the details of how a device tree overlay is used by the kernel to configure the SoC registers? So far I haven't found much good documentation besides Derek Molloy's book. > BTW: You're developing PRU code and you're using a real time kernel. May > I ask why? Since the PRUSS are very efficient for real time tasks, I see > no reason for using additionally a real time kernel. > My team is working on a time-synchronization platform that aims to synchronize devices' clocks on a network. It's sort of like NTP, but allows users to specify the resolution of the time synchronization that they require. Here is a paper on it for more info: https://users.ece.cmu.edu/~agr/resources/publications/RTSS16-timeline.pdf We need the real-time Linux kernel for precise time synchronization, so that's why we're using a real-time kernel. Additionally, we're using the PRU to get precise I/O for some distributed control systems. Best, Justin > > Regards > > PS: > I just checked Derek's cape. From a first glance I found the line > > compatible = "ti,beaglebone", "ti,beaglebone-black"; > > is wrong. The order is important, most specific first. It must be > > compatible = "ti,beaglebone-black", "ti,beaglebone"; > > And it does more than just enabling the PRUSS (you're loading > unnecessary overhead). In the libpruio package there's the tool > dts_custom, which you can use to easy create, compile and install > minimal custom overlays (single source, no overhead). > > > Am 02.04.2017 um 17:25 schrieb Justin Pearson: > > Thank you TJF, I never would have known about that register if you hadn't > > mentioned it. One more question (see below): > > > > On Sat, Apr 1, 2017 at 9:20 PM, TJF <jeli.freih...@gmail.com> wrote: > > > >> Am Samstag, 1. April 2017 22:18:30 UTC+2 schrieb Justin Pearson: > >>> > >>> Are you saying that the only way to get PWM in a 4.x kernel is by > >>> modifying am33xx-clocks.dtsi? > >>> > >> > >> No. The kernel driver should also work (untested). But in your case > >> (controlling the PWM subsystem by PRU code) you have to modify that > file. > >> (Or you can develop a loadable kernel module that writes to the > register.) > >> > > > > On the 3.18 kernel, I was able to control the PWM with the PRU without > > needing the PRU to initialize the PWM. The trick was to load the PWM > capes > > "am33xx_pwm" and "bone_pwm_P8_34" before running the PRU code. (And also > > loading Derek's cape > > <https://github.com/derekmolloy/exploringBB/blob/ > master/chp13/overlay/EBB-PRU-Example.dts> > > to > > initialize the pruss.) Loading the capes causes some PWM kernel driver to > > initialize the PWM registers, I assume. Once that's done, the PRU just > has > > to tweak a couple registers to change the duty cycle. Is this trick what > > you're referring to when you say "*The kernel driver should also work*"? > > > > Would this trick of pre-loading the capes also work in a 4.x kernel? > > > > Thanks for all your help! > > Justin > > > > > > > > > >> > >> > >>> Also, how can I verify whether the register is set correctly? > >>> > >> > >> The PRU cannot write to the Control Module registers, but it can read > >> them. Get a word from 0x44E10664 and pass it to the ARM code. Bits 0:2 > must > >> be set to get output from all PWM subsystems. In your case bit 1 set is > >> sufficient to get ehrpwm1B working. > >> > >> Regards > >> > >> -- > >> 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/LZhL4S9taic/unsubscribe. > >> To unsubscribe from this group and all its topics, send an email to > >> beagleboard+unsubscr...@googlegroups.com. > >> To view this discussion on the web visit https://groups.google.com/d/ > >> msgid/beagleboard/3041a94e-58ab-4c28-ad29-ad3a2b90315b%40 > googlegroups.com > >> <https://groups.google.com/d/msgid/beagleboard/3041a94e- > 58ab-4c28-ad29-ad3a2b90315b%40googlegroups.com?utm_medium= > email&utm_source=footer> > >> . > >> > >> 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 a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/beagleboard/LZhL4S9taic/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beagleboard/85f0fe91-f65e-82f8-c6a0-5c8d133db5c4%40gmail.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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CABCHBhKKct1cK1dM%2Bh%2BVgLNomvD1i2iPF1rPpXKi_RmmXi-3ag%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
