BeagleY-AI and Motors

Hey There...

I have been working on a specific motor use case from Linux to hardware.

I am using the BeagleY-AI, mostly intended for AI applications (hence the name), for promoting motors and the driver installments for getting motors to actually move. I have found that even with CMOS 3.3v logic, some drivers are finnicky.

I am currently using a DM332T driver with a 3.0A motor (bipolar stepper motor) for this use case. The driver calls for something with a little less amperage. I am bringing this motor and driver to the unknown (not smart but for testing purposes)... Science.

So, I have a small script of source code to handle a simple command.

./MY_FILE 0 8500 500

MY_FILE is the file being ran in binary form from the C/C++ application while 0 is for CW. 8500 is the number of steps and the 500 is the delay. I can make the motor either move slower or faster due to a quick delay change or a different example.

Anyway, I made the source code available and a short video to show the application in question during use.

To protect the GPIO pins used to handle the DIRECTION and PULSE (both GPIO pins), I have used a resistor for each GPIO pin. Depending on your driver, you may get a different resistor value. There are many ideas floating around for how to sum your resistor values through a mathematical approach. I found that sparkfun has some nice starter docs. on resistors. Resistor logic is a good way to understand how to "choke hold" your current, i.e. especially when reverse voltage is applicable.

Anyway, here is the sparkfun site I found with a short on ideas: https://learn.sparkfun.com/tutorials/resistors/all#current-limiting

That will bring you right to where you can apply yourself in the world of "choke holds" on electric current (resistors).

Anyway, here is a short on the application in use:

Here is a set of C/C++ source code to run two GPIO pins to handle the differentiation in the DIR and PUL pins on the DM332T (both GPIO pins in this case).

So, one change to make, no matter if they say, "Yay, your driver can be controlled with the OPTO pin at 3.3v, " or not, use 5v to power the DM332T driver on the OPTO pin.

Again and I repeat, use 5v current on the OPTO pin on the DM332T driver(s).

Oh...the source code:

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <libgen.h>
#include <gpiod.h>

#ifndef CONSUMER
#define CONSUMER    "consumer"
#endif

#define DIR_PIN 7
#define STEP_PIN 33
#define EN 41

struct gpiod_chip *chip0 = NULL;
struct gpiod_chip *chip1 = NULL;
struct gpiod_line *dir_pin = NULL;
struct gpiod_line *step_pin = NULL;
struct gpiod_line *enable = NULL;

int setupGPIO(char* consumer) {

    int ret1, ret2, ret3;
    chip0 = gpiod_chip_open_by_name("gpiochip0");
    if (!chip0) {
        perror("The opening of Chip0 is failing...\n");
        return -1;
    }

    chip1 = gpiod_chip_open_by_name("gpiochip1");
    if (!chip1) {
        perror("Not opening Chip1...\n");
        return -1;
    }

    dir_pin = gpiod_chip_get_line(chip0, DIR_PIN);
    if (!dir_pin) {
        perror("Get dir_pin failed\n");
        return -1;
    }

    step_pin = gpiod_chip_get_line(chip1, STEP_PIN);
    if (!step_pin) {
        perror("Get step_pin failed\n");
        return -1;
    }

    enable = gpiod_chip_get_line(chip1, EN);
    if (!enable) {
        perror("Setting up enable failed...\n");
        return -1;
    }

    ret1 = gpiod_line_request_output(dir_pin, consumer, 1);
    if (ret1 < 0) {
        perror( "Request dir_pin as output failed\n" );
        return -1;
    }
    gpiod_line_set_value(dir_pin, 0);

    ret2 = gpiod_line_request_output(step_pin, consumer, 1);
    if (ret2 < 0) {
        perror("Request step_pin as output failed\n");
        return -1;
    }
    gpiod_line_set_value(step_pin, 0);

    ret3 = gpiod_line_request_output(enable, consumer, 1);
    if (ret3 < 0) {
        perror("Requesting opto as gpio failed...\n");
        return -1;
    }
    gpiod_line_set_value(enable, 0);

    return 0;
}

void releaseGPIO(void) {

    if (enable) {
        gpiod_line_set_value(enable, 0);
        gpiod_line_release(enable);
    }

    if (dir_pin) {
        gpiod_line_set_value(dir_pin, 0);
        gpiod_line_release(dir_pin);
    }

    if (step_pin) {
        gpiod_line_set_value(step_pin, 0);
        gpiod_line_release(step_pin);
    }


    if (chip0) {
        gpiod_chip_close(chip0);
    }

    if (chip1) {
        gpiod_chip_close(chip1);
    }
}

void stepMotor(int dir, int steps, int delay, int en) {
    gpiod_line_set_value(enable, en);
    gpiod_line_set_value(dir_pin, dir);

    for (int i = 0; i < steps; i++) {
        gpiod_line_set_value(enable, 1);
        usleep(450);
        gpiod_line_set_value(step_pin, 1);
        usleep(delay);
        gpiod_line_set_value(step_pin, 0);
        usleep(delay);
    }

}


void intHandler(int) {
    fprintf(stderr, "\nintHandler called\n");
    releaseGPIO();
    exit(0);
}



int main(int argc, char** argv) {

    __sighandler_t rc;

    rc = signal(SIGINT, intHandler);  // catches ctrl c
    if (rc == SIG_ERR) {
        perror("SIGINT error");
    }

    rc = signal(SIGTERM, intHandler);  // catches kill commands
    if (rc == SIG_ERR) {
        perror("SIGTERM error");
    }


    if (argc < 3) {
        puts("you must supply direction and steps when running the program");
        puts("e.g");
        puts("\tto step 100 steps CW:    prog 0 100");
        puts("\tto step 500 steps CCW:   prog 1 500");
        puts("an optional 3rd argument can be added to overide step delay");
        puts("fourth option is to set the enable pin directly...");
        exit(0);
    }

    char* progname = basename(argv[0]);
    fprintf(stderr, "running - %s\n", progname);

    int en = atoi(argv[4]);
    int dir = atoi(argv[1]);
    int steps = atoi(argv[2]);
    int delay = 9000;
    if(argc == 3) {
        delay = atoi(argv[3]);
    }

    printf("DIR: %d STEPS: %d DELAY: %d\n", dir, steps, delay, enable);

    if (setupGPIO(progname) == 0) {

        stepMotor(dir, steps, delay, enable);
    }

    releaseGPIO();

    return 0;
}

So, to start, this source controls actually three GPIO pins all of which can be found via gpioinfo. Once you get your actual defined GPIO pins from the beagley-ai from beagleboard.org and their Debian Distro from their personnel, try to run the source to see if you come across any issues. This quad-core aarch64 am67a has oomph to it. Once updated and upgraded and running one of their images, the builds should go smoothly.

I have an off image now, e.g. so I am a bit buggy for now. Anyway, back to it.

If you want to not use the EN pin via the beagley-ai GPIO pin, erase most things about the ENABLE pin called EN in the source and the words enable...

So, that should be it for now. Oh!

Those pins muxed for the beagley-ai can be found at the link below the photo, i.e. enjoy.

Seth

P.S. If anyone has any discrepancies or ideas, send 'em on over...