Hi Justin!

I just tried to answer you mail, but the google board doesn't work (once
again). I try to answer from my mail client, which I never did before.


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.

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.

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%40googlegroups.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 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/85f0fe91-f65e-82f8-c6a0-5c8d133db5c4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to