GPIO not functioning for BBORG-MOTOR.dtbo overlay 6.1.83

General Discussion
1

I have upgraded to Bookworm 6.1.83-ti-arm64-r63 successfully loaded the overlay:
k3-j721e-beagleboneai64-BBORG-NOTOR.dtbo

I am trying to figure out how to toggle the pin P8_14. The previos method was by echoing, 5.10, as follows:
$ sudo echo 375 > /sys/class/gpio.export
I expected to see a file created /sys/class/gpio/gpio375 created, which doesn’t happen. What is the current method for accessing the pin. First by using a shell command and the second by using C++.

2

P8_14 exported as an led m3_high: src/arm64/overlays/k3-j721e-beagleboneai64-BBORG_MOTOR.dts · v6.1.x-Beagle · BeagleBoard.org / BeagleBoard-DeviceTrees · GitLab

3

I see that do I drop the GPIO_ACTIVE_HIGH or change the flag to something else? I ultimately will use that overlay as a template.

4

off:

echo 0 > /sys/class/leds/m3_high/brightness

on

echo 1 > /sys/class/leds/m3_high/brightness

Regards

5

Thanks works great. Do you have a gpioset example?

6

the pins are taken by class/led, so gpioset won’t work, till you remove them from the overlay.

Regards,

7

That is good since I address them from a C++ program. Is their a book that you would recommend for understanding Device Trees in particular the Beaglebone’s.

8

@RobertCNelson ,

Does m1_high mean motor one on the headers of the Motor Cape?

Also, is the older Motor Cape repo. on github current with what to expect when creating source for the Motor Cape?

So, P9_16 is motor one and so is m1_high?

Seth

P.S. Either things changed or I cannot create viable source so far. I know the latter is definitely true. I had some working source for the PWM and GPIO available for Motor One on the Motor Cape headers but then all of a sudden things stopped working.

I changed the source...

Now, without my notes on what I did, I am stuck!

Wait for the source in case anyone can push me in the correct direction!

9

I used the same labels that are found on the schematic.

Regards,

1 Like
10 
// Differences from Sean J. Miller on element14
// Since its conception, the links have changed and have since been lost!

#include <stdio.h>
#include <unistd.h>
// #include <gpiod.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <errno.h>

#define BRIGHT 1
#define ENABLE 1
#define DUTY   (2 / 20) * 100
#define PERIOD 1000

int bright = 0;
int enable = 0;
int duty   = 0;
int period = 0;

void setup_GPIO_One() {
    bright = open("/sys/class/leds/m1_high/brightness", O_WRONLY);
    if (bright == -1) {
        perror("Unable to open");
        exit(1);
    }
}

void setupPWM() {
    enable = open("/dev/beagle/pwm/P9_16/enable", O_WRONLY);
    if (enable == -1) {
        perror("Unable to open");
        exit(1);
    }
}

void setupPWM_Period() {
    period = open("/dev/beagle/pwm/P9_16/period", O_WRONLY);
    if (period == -1) {
        perror("Unable to open");
        exit(1);
    }
}

void pwm_duty() {
    duty = open("/dev/beagle/pwm/P9_16/duty_cycle", O_WRONLY);
    if (duty == -1) {
        perror("Um...cannot open?");
        exit(1);
    }
}

int main() {
    printf("Setting up\n");
    setupPWM();
    setup_GPIO_One();
    setupPWM_Period();
    pwm_duty();

    for (int i = 0; i < 20; i++) {
        if (write(bright, "1", 1) != 1) {
            PERIOD;
            DUTY;
            ENABLE;
            perror("Error");
            exit(1);
        }

        usleep(500000);

        if (write(bright, "0", 1) != 1) {
            PERIOD;
            DUTY;
            ENABLE;
            perror("Error");
            exit(1);
        }

        usleep(500000);
    }
    close(bright);
    pwm_duty(0);
    return 0;
}

Here is the simple source I am currently using. Can anyone see the error and/or direct me on the build that may be a bit more directed at the Motor Cape technologies?

Seth

11

Make sure you call:

sudo beagle-pwm-export --pin p9_16

as that’ll enable the /dev/beagle/pwm/P9_16/ symlink dir…

Regards,

1 Like
12

Done!

I will keep trying with my odd way of creating source!

Seth

13

I am working on a C++ class that uses /sys/class/pwm/ read write calls that don’t require sudo privileges. This class worked for BBAI & BBB, and needs some upgrades to work with Debian 6.1. One thing that I will have to do is to change the group to something other then “root”. I suspect that this will revert to “root” on every version upgrade or boot with a new overlay. Anyway I got this to use “echo commands” to operate P8_13 several days ago with Nelson’s help.

I also have a similar C++ class’s for the leds, i2c, spi, gpio, as well as pwm that require upgrading which I hope to at least have pwm, and leds working. They all used /sys/class/xxx/yyy read/write calls.

PS: Just checked both export files for leds and pwm are assigned to the group “gpio” so no changes should be required their so that answers my previous suspicion of changing during boot. I also noticed that the PWM naming is pwm0 & pwm1 vs. a and b.

$ echo 1 > /sys/class/leds/m3_high/brightness works for me.

1 Like
14

with the symlink script we set these to the ‘gpio’ group…

Regards,

15

Oh good. Thanks again