Quick BeagleBone Black PWM commands

[bluehash 1,581]

From phys-x.org.

 

So a big thanks for how to write PWM on the BeagleBone Black forums.  It just goes to show how we need to get more tutorials and examples on the web for programming the BeagleBone Black.  So I adapted the post here:


https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/wjbOVE6ItNg


to write a 50 Hz signal with 50% duty cycle, units when you right to file are in nanoseconds.


If it is the first time you are setting things up you need to setup the filesystem, note specific numbers will change so please double check your directory structure


# echo am33xx_pwm > /sys/devices/bone_capemgr.9/slots


Note this will be for pin 13 on header P8


# echo bone_pwm_P8_13 > /sys/devices/bone_capemgr.9/slots


Now write out the period and duty.  Clearly this would be easy in python, c++, etc., just seems a pain to make a general purpose library.


# echo 20000000 > /sys/devices/ocp.2/pwm_test_P8_13.15/period


so  20000000= 0.02 seconds


# echo 10000000 > /sys/devices/ocp.2/pwm_test_P8_13.15/duty


so  10000000 = 0.01 seconds

 

[01txdmax 0]

Is there any way to make the bone_capemgr.8/slots file remember that I want P8_13 to be designated after a power cycle?

 

It seems that this registry resets back to default when the power is cycled on the board. 

[yyrkoon 250]

You could possibly have the device tree file written exactly how you want, and loaded from uEnv.txt file through $optargs . . . hold on a second let me find an example.

 

EDIT:

 

Had to fire up my BBB . . .

 

I disable the HDMI stuff on the BBB at boot.

 

optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

 

To enable a device tree overlay . . 

 

optargs=capemgr.enable_partno=<overlay>

 

I dont know of any proper overlay names off the top of my head . . . I'd use one of the HDMI over lays from above, but these are already loaded by default through am335x-boneblack.dtb I believe(and I would not want to give anyone the wrong impression that it would work ).

[01txdmax 0]

I feel like the guy in the AT&T commercial 'Infinity times infinity".....  

 

I'll do some research, come back smarter, and give this a shot.

 

Thanks!

[yyrkoon 250]

If you mean about the uEnv.txt file.

 

uEnv.txt file is located in the /boot/uboot directory on the first partition of the eMMC, or uSD card that some people boot from. uEnv,txt is used by u-boot, to accomplish several possible things, but it does not really need to be used in some cases. Well technically, there are default settings that are hard coded into the u-boot.img file that can be overridden by making changes to uEnv.txt.

 

$optargs is the u-boot environment variable for the variables that are passed to the kernel. So if you hear someone talking about passing parameters to the kernel. This is how it is done using u-boot.

 

Also, in this context think of u-boot for the Beaglebone black, as an equivalent to a PC's BIOS, for the PC. The Beaglebone black has no BIOS, but does need to know some BIOS like things at start up. Like how to initialize various aspects of the hardware.

 

in what order does the hardware need to be initialized ?

Where does / can the BBB boot from ?

Does it need an IP Address before loading the kernel / root file system ?

Does it need to start the on-board USB before loading anything ?

Where in memory does it load the kernel into ?

 

These questions and more can be "answered" by u-boot before the kernel even starts to load.

 

Hopefully that did not make the confusion worse lol.

[01txdmax 0]

No, actually that clears it up quite a bit.  I'll do so more digging...... 

 

Thanks!

[yyrkoon 250]

To answer your original question from 30,000 feet. There are three ways that I can think of.

 

1) like stated above load device tree blob through uEnv.txt.

2) Run an init script at boot that performs the commands for you at boot time.

3) In the case where you may only want to run these commands when a specific user logs in, you can put this into a specific users .bashrc file.

 

Granted, there may be potential permissions issues on the second two options, but I * think * this could be solved by putting the given user in a group appropriate for those given commands. My Linux knowledge in this area is a but "fuzzy".

 

EDIT

 

Actually the permissions issue would only be for the last case.

[01txdmax 0]

I think the permission idea is good for my scenario.

 

It is possible that there will be a few users of the BBB once I'm done with it, and I don't want any of them to easily be able to make any changes. 

 

The script at boot time is good too, and sounds easy enough.  The GPIO pins I will be using will remain constant, so this may be the way I go for pin declarations. 

 

Thanks!