Wozzers…very powerful. It is nice to see people do so much and give back. I will be testing it.
Seth
P.S. This way, I can learn more-more-more!
@benedict.hewson and @bbbpaul and @foxsquirrel ,
So, it seems I can enable the motor, first by adding too much oomph into it (it got hot), enable it without it getting it hot (thankfully), and now I am stuck. The driver understands the commands I am giving it but my commands are either outdated or random (bad logic).
Please see this source from the BBG (and yes, I have compiled the firmware for the g although I cannot get it to work efficiently):
// Better builds for "current" systems
// 08/2024
// Seth
#include <stdio.h>
#include <unistd.h>
#include <linux/gpio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <errno.h>
void argh() {
int fd = open("/sys/class/gpio/gpio66/direction", O_WRONLY);
if (fd == -1) {
perror("Unable to open...");
exit(1);
}
if (write(fd, "out", 3) != 3) {
perror("Not working...");
exit(1);
}
close(fd);
}
/*
void GPIO_One(int Gpio) {
FILE *bright;
if (write("/sys/class/gpio/gpio66/direction", out, 3) != 3) {
fseek(bright, 0, SEEK_SET);
fprintf(bright, "%d", 1 * Gpio);
fclose(bright);
}
}
*/
void GPIO_Two(int Gpio) {
FILE *bright;
bright = fopen("/sys/class/gpio/gpio66/value", "w");
fseek(bright, 0, SEEK_SET);
fprintf(bright, "%d", 1 * Gpio);
fclose(bright);
}
void setupPWM(int enable) {
FILE *pwm;
pwm = fopen("/dev/bone/pwm/1/a/enable", "w");
fseek(pwm, 0, SEEK_SET);
fprintf(pwm, "%d", 1 * enable);
fclose(pwm);
}
void setupPeriod(int period_one) {
FILE *period;
period = fopen("/dev/bone/pwm/1/a/period", "w");
fseek(period, 0, SEEK_SET);
fprintf(period, "%d", 10 * period_one);
fclose(period);
}
void pwm_duty(int the_duty_multiplier) {
FILE *duty;
duty = fopen("/dev/bone/pwm/1/a/duty_cycle", "w");
fseek(duty, 0, SEEK_SET);
fprintf(duty, "%d", 100 * the_duty_multiplier);
fclose(duty);
}
int testInteger = 0;
int main() {
printf("Setting up\n");
setupPWM(0);
while(1) {
printf("Enter an integer, Please: ");
scanf("%d", &testInteger);
if (testInteger >= 10) {
setupPWM(1);
setupPeriod(140);
pwm_duty(10);
GPIO_Two(1);
}
usleep(2500);
if (testInteger <= 2) {
setupPWM(1);
setupPeriod(250);
pwm_duty(0);
GPIO_Two(0);
}
usleep(2500);
}
pwm_duty(0);
return 0;
}
So, what (if anything) I was doing was trying to make the stepper turn via the BeagleY-AI and got shifted to the BBG for access to /sys/class/gpio/gpio*. It is an older image I was testing to use the PRU and PASM but…
- Blah.
- Double Blah.
- What is it about that source that is creating the build to not listen?
Is it the source that has created the commands to be obsolete or the hardware set up? I can try to draw out the hardware set up if necessary. I will go back to GPIO if necessary but…
This is what I have been trying recently if anyone did not know currently.
Seth
Well I am not surprised it is getting hot !
If you are using the PWM output to drive the step pin you are stepping way too fast.
Check the datasheet for the stepper motor and it will tell you the max step rate. But that depends on voltage and load. Potentially to get to the max step rate you would need to accelerate and then also decelerate when stopping to prevent overshoot. But for simple testing keep the step rate below the max step rate.
Using a hardware PWM signal to drive a stepper motor is not a good idea without some form of position feed back to stop the PWM when you have reached the desired point. If you just want the motor to turn and don’t care about positioning then ok.
Your usleep() calls are very short - 2.5ms. That is not enough time for the motor to step very far assuming your PWM signal was a reasonable frequency, which it isn’t.
I believe the PWM period is set in ns (nano seconds) so you are either setting a period of 1.4us or 2.5us. You are trying to step probably several thousand times faster than the motor can step. You are also possibly exceeding the step rate of the driver chip.
Just toggle the pin as a GPIO pin is a much better solution.
Hook up a scope to the clock and direction lines to visually see what you are doing. While not a requirement anyone getting into hardware control should really have access to a scope and know how to use one.
1 Like
Thank you…level headedness. I have been back and forth throughout the day trying to get this stepper to move via source without learning…
Seth
P.S. I will get the scope out. Also…my hardware seems to work on the GPIO from the BBG but that is what is creating the motor to get hot (I think my wiring is off to a bad start). I will try to better associate myself with the (bad start) wiring too. I need to change things. I have four inputs and two outputs on the op amp. LM358-N is the op amp in question. As soon as one GPIO hits the op amp, the motor gets severely hot. My finger tips show the truth!
Why are you using op-amps ? If this is still the Pi motor hat, you don’t need anything to control this from any of the Beagleboards.
1 Like
I switched to a DM332T driver from stepper-online because using the BeagleY-AI with the Pi motor hat was iffy…
I type iffy because I could only get the hat working when the hat was “powering” the BeagleY-AI.
I am using op-amps because I was setting up the DM332T driver(s) for use.
All I know is the beagleboard.org boards work just fine and luckily I have not caused issue to them but while learning about motor drivers and how to supply them with commands via source, I have come across some concerns.
For one, the motor got too hot to handle with my current circuit along with GPIO only control of the op-amp. I am not even sure I need two GPIO pins to handle one output to the op-amp.
Seth
P.S. I can create square waves from the op-amp and saw tooth waves. I have not set up the op-amp with GPIO pins to handle either wave form because I put two GPIO pins in instead of GND and GPIO. Blah. I think, and I know this is my fault, this is what needs to take place now.
I need GPIO and GND per input into the op-amp (LM358N) instead of two GPIO pins into +/- of the op-amp.
I have been reading about filters and I am not sure what exact method to use. So, I will be testing slowly. No rush.
well op-amps seem a bit overkill to me. All you need are 3 NPN transistors & resistors, one for each control line, or if maybe using more than 1 controller something like the ULN2003.
1 Like
Okay… I will keep learning during this process. I can try the ULN2003 but this op-amp, even with it being a bit too powerful, seems to have two outputs if I can just get the circuit correct.
I can finally get the motor to adhere to commands (enable only).
Seth
Ben…I have only so many parts here and things (prices) have skyrocketed in theory.
So, I will most likely use this LM358N and a AND Gate for TTL signal usage. I am still dealing with a good, ole fellow from TI about my current set up. I am not discrediting what you have said so far in text. Again, only so many parts on hand...
Seth
P.S. The enable pin works but the source is logically deprived and the motor is over sourced while it gets way to hot to handle. I would show a schematic but the LTspice program does not carry a drop-in replacement for the LM358N.
Hello friend,
May I know more about this.
My senario is this:
If my fan’s PWM pin is on A while Rasp Pi default fan’s PWM pin is on B, can I redirect pin B to Pin A?
1 Like
Use wires instead, I think…
So, instead of attaching the Cape/Hat/Daughter Card to the BeagleY-AI, only the wires you need…
Seth
P.S. I am not currently thinking that python3-gpiod can support pin assignment at an already configured header.
1 Like
iam using BeagleY-AI in the board i performed UART loopbback using pin8,9 (/dev/ttyS3) it will execute. so ia want to access another uart using different pins but it accessible . can anyone tell how it will be access. i will attach pins diagram. please help me