Are you sure that board has PWM on it, the pin out shows pwm1 &0.
However, the spec sheet does not mention any thing about PWM. So, that would lead me to make a loose assumption that PWM is either PRU or Software. Hence, your code would not work on that board, regardless. If you can post more info about that I would like to see it. I ordered the same board you have and was getting ready to create a roadmap and the lack of PWM has raised some questions.
UPDATE: @silver2row
I was wrong and just found it starting on page 1947 of the TRM, they call it EPWM. Might be why I did not see it. Loaded an overlay and tried to turn it on manually using sys and it might need more than period, duty, cycle to get it going.
There’s nothing inherently wrong with those functions, you certainly may do it like that. Its clear and explicit, which is always good. There are however a couple of comments regarding style I could make -
1: You are masking any errors
2: The 3 functions are quite similar, you dont have to combine them, but it’s worth considering.
If it were me, I would probably write it more like this (depending on the specific circumstances)
const char* enablePath = "/dev/beagle/pwm/P9_16/enable";
const char* periodPath = "/dev/beagle/pwm/P9_16/period";
const char* dutyPath = "/dev/beagle/pwm/P9_16/duty_cycle";
int myFunc(const char* path, int val) {
FILE *theFile;
int ret;
theFile = fopen(path, "w");
if (theFile == NULL)
return -1;
ret = fseek(theFile, 0, SEEK_SET);
if (ret == 0)
ret = fprintf(theFile, "%d", val);
fclose(theFile);
return ret;
}
// use it like this
ret = myFunc(brightPath, 1);
No, mine is loaded with the same image. Just posted that to share with you. I might have over looked something.
As it stands at this moment, pwm on that board is going to be a waste of time. Part of the problem is doing that on a linux os is very difficult. You can work on it via registers however you will have a jalopy.
That EPWM module is very powerful according the specs, it will sync and has configurable input / capture. Most certainly worth looking into if your project would do a $M a year in sales. It most likely will have to be some bare-metal/rtos.
Best option at this point is to buy some stepper drive controls and connect them to gpio that are active. You can bit bang a square wave for stepping and have couple different frequencies for high/low rpm. Then use 2 more lines for enable and direction.
I found some really cheap ones on amazon 2 for $16 and free shipping. Suppose to handle a nema 17 stepper, when those arrive I will work on getting them up on that board.
Yaya…no money on my end so far. So, testing and testing until blue in the face is a key notion.
Thank you for making me understand the ePWM module a bit more.
I have this stepper drive. Three GPIO pins and go-go-go. It is nice for now but…
I cannot incorporate it into a full build just yet.
The “Hat” is needing to supply the BeagleY-AI with power to make things work.
I am not willing to move forward with powering the BeagleY-AI via this “Hat” and for good reason.
Like someone stated, I have intermittent power failures on the action of the “Hat” most likely due to the 5v pin onboard powering the Chip without specific level translation. Right?
Seth
P.S. I have searched the fs so far and found some very tidy and neat things placed in specific files. Can I use them yet? Nope. Still trying over here. $M!
Powering a SBC from any node other than its dedicated power input can be a bit risky. Usually, header pins are positioned on the output side of the regulator, and the traces there tend to be smaller. Ideally, power conductors should have larger surface areas to handle greater power capacity safely and efficiently.
You can just use gpio, it depends on what you need.
Gpio timing is not particularly accurate on linux. For low speed this is probably not an issue, but for higher speeds or high accuracy (which is kind of why you’d use steppers in the first place) it might be a deal breaker.
Pwm may be easier to code for too, depending on your point of view, as you can set the frequency and just let it run. You would possibly still need accurate timing or pulse counting though. Again it depends on your needs.
If you’re unsure - try it and see if it works for you.
Yes, I seen that. Its faux pwm, not using the hardware, just bit banging gpio. If you only want to run blinky and fans it is perfect for that. When you have motors and such involved its not a serious option other than demonstration purposes.
Posted this on e2e and best response was a snippet for device tree overlay… If Ti cannot explicitly state a meaning full response it becomes very clear what game(s) they are playing with the “low value” customer base that are not strategically important to them .
Apart from playing around you do not want to do any real motor control with Linux. You need to use a real time processor such as a PRU or dedicated hardware.