Hello,
Back on Top!
Sorry for the odd headline and full text of this/these short paragraphs.
Outside of being sorry.
- Has anyone else seen this gpiod.h directive in a C file create an unbootable instance on the BBBW or BBB w/ the am335x?
- I have my TTL to USB cable ready for use. Would an output on my end of the BBBW be of any help?
- I did see that the kernel is updated past the -r54 release recently. Has anyone tested C or Python3 w/ gpiod.h/gpiod?
I have not tested Python3 personally for now. I wanted to try C first and get it working. So, I will get back to it and figure out what it is I am missing to get it running through reboots…
What else does gpiod need to handle reboots on the BBB/BBBW?
For instance…in Python3:
import gpiod
from time import sleep
...
# Extra source everywhere
Anyway, here is the C file to review in case you have time to review it and make it a consideration.
/*
Simple gpiod example of toggling a LED connected to a gpio line from
the BeagleBone Black Wireless and Relay Cape.
Exits with or without CTRL-C.
*/
// This source can be found here: https://github.com/tranter/blogs/blob/master/gpio/part9/example.c
// It has been changed by me, Seth, to handle the RelayCape and BBBW Linux based SiP SBC.
// kernel: 5.10.140-ti-r52
// image : BeagleBoard.org Debian Bullseye Minimal Image 2022-11-01
// type gpioinfo and look for this line: line 20: "P9_41B" "relay1" output active-high [used]
// That line shows us the info. we need to make an educated decision on what fd we will use, i.e. relay1.
// We will also need to locate which chipname is being utilized. For instance: gpiochip0 - 32 lines:
// #include <linux/gpio.h>
#include <gpiod.h>
#include <stdio.h>
#include <unistd.h>
int main(int argc, char **argv)
{
const char *chipname = "gpiochip0";
struct gpiod_chip *chip;
struct gpiod_line *lineLED;
int i, ret;
// Open GPIO chip
chip = gpiod_chip_open_by_name(chipname);
if (!chip) {
perror("Open chip failed\n");
return 1;
}
// Open GPIO lines
lineLED = gpiod_chip_get_line(chip, 20);
if (!lineLED) {
perror("Get line failed\n");
return 1;
}
// Open LED lines for output
ret = gpiod_line_request_output(lineLED, "relay1", 0);
if (ret < 0) {
perror("Request line as output failed\n");
return 1;
}
// Blink a LED
i = 0;
while (true) {
ret = gpiod_line_set_value(lineLED, (i & 1) != 0);
if (ret < 0) {
perror("Set line output failed\n");
return 1;
}
usleep(1000000);
i++;
}
// Release lines and chip
gpiod_line_release(lineLED);
gpiod_chip_close(chip);
return 0;
}
In my mind here, I think this source runs for the Relay Cape. I believe it is an additional requirement that is needed to alter C files w/ cmake
and the gpiod.h directive.
No matter what, I am going to keep trying.
I know what people may feel about the transition and sysfs to another route of methods and fd’s.
Argh, right? Or…wozzers. Somethin new? Either way, boring or exciting on your end, give feedback on how I can help you help this rendition, please.
Seth
P.S. I got so happy when the file in question, that above C file, did not float the pin after running and then ending. Then, brrrrt. The BBBW and Relay Cape attached would not boot. This threw me a curve ball of sorts. Happy, unknowledgeable, and then anger. I was angry b/c I could not describe what was taking place or for what reasons it was taking place. Anyway, back to the old grind of wheels and gears for now. BBB!
This is the bit that is supposed to close the line and chip that was requested.
// Release lines and chip
gpiod_line_release(lineLED);
gpiod_chip_close(chip);
return 0;
}
Obviously, from the comment, this bit of source handles the release
and close
. I was thinking that this had some peculiar functionality in the GPIO pin assignment. I should check the .dts file for the Relay Cape again. Thank you for reading. Please reply!
Update
I think this link will describe to me what is exactly taking place when it is being built w/out my compilation of misguided queues. libgpiod/libgpiod.git - C library and tools for interacting with the linux GPIO character device
Anyway…off to flash yet another build from beagleboard.org … Updates on the way for anyone willing to read or reread my blast of a chatterbox posting.