Hi Jan,
I had another look at this, was able to replicate what you are seeing,
and think I know what's going on..
The part-number 'bone_pwm_P8_13' is already included in the kernel
build. I'm not really sure of the mechanics, but when doing a build from
the git repository, all the .dts files in the /firmware/capes folder get
compiled to individual .dtbo files, and from there into object files,
and then combined into a single built-in.o file.
The end result of this appears to be that putting an overlay file for
one of these built-in part-numbers into /lib/firmware doesn't achieve
anything, it just doesn't get read (even if you increment the version).
Anyway, it's an easy fix - once you know what's going on!! You should
just need to change the part-number to something else unique (and the
file name to suit), and then the options can be set in your overlay as
you'd expect..
Hope this helps,
Jon.
On 26/11/14 10:11, [email protected] wrote:
Good idea, thanks. I will try it. I think the positive pulse will be so
short that it will not be able to move the motor.
On Wednesday, November 26, 2014 8:29:31 PM UTC+11, Jon E wrote:
I'm not sure about that. Jan said before that it's only driven high
after loading the PWM driver, and the processor datasheet shows ball
T10 (P8_13) as driven low during/after reset.
Jan, not ideal, but to disable the output sooner you could load the
overlay through cape manager, and then write 0 to the run parameter
immedately afterwards. But I still think the correct approach is to
look at the devcetree/driver code and see why those parameters are
having no affect..
Regards,
Jon
--
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.
