Hey There,
To anyone interested…
I am trying to get a few GPIO pins running on the BeagleY-AI with kernel 7.1.x and coming up short. Does anyone know how to get the GPIO pins running on the BeagleY-AI? Also, will you share how to get them running.
I tried the documentation and I have failed so far.
I think the docs. are a bit dated and gpiod.find_line('') is not listed in gpiod any longer or something… I am just not sure right now how to manage to get a GPIO pin working on the board in question.
This?
gpiocli request --output "P9_27"
gpiocli set "P9_27"=1
gpiocli set "P9_27"=0
I read here on the forums about something called gpio-manager… Off to try it…
I am generally a bit lost for words…
What ever happened to searching Google?
This is what I had after a few seconds:
(program listing followed)
But you’re right; the docs are written for libgpiod 1.x,
so here’s your chance to feed something useful back to the community:
Once you have a good solution working, why not amend the docs?
PR’s are always appreciated!
Okay. I have researched google for a bit now on the whereabouts of libgpiod-dev, gpiod, python3-libgpiod packages. I have just recently found the gpio-manager stuff on this forum.
Written for v1.0 and kernel 7.1.x seems to be on v2.x.x while gpio-manager, from what I read, is for v3.x.x.
Although complicated, I guess I can try again. I will try to make a GPIO work and report it to the gitlab instance.
Although this task seems a bit complicated since I am on a newer kernel and things have changed dramatically in recent times, all I can do is try here.
Okay. So, in kernel 7.2.x, v1.0 of libgpio-dev is obsolete.
There is no reason to handle keeping that around if I am going to update kernels along with current times.
I will be reading the not-so-obsolete GPIO APIs soon. Reports on the way.
Since working in mainline kernels and testing GPIO on the beagley-ai from beagleboard.org, is there a GPIO driver that beagleboard.org uses for the BeagleY-AI?
I have tried most things so far and I keep getting an older error of file does not exist which makes me think that there is already a driver available.
Is there a driver already available for the BeagleY-AI and GPIO?
See, this is my exact error so far…
I do not know how to discuss ti,davinci-gpio on the BeagleY-AI and how to handle multiplexing pins around the images available through beagleboard.org.
Multiple Additions here:
Google Brain Here…
Source File: drivers/gpio/gpio-davinci.c
Device Tree Compatible: ti,davinci-gpio
User-Space Interface: Managed via libgpiod character devices (/dev/gpiochip*)
Okay. So, would I need to apply specifics in my config? Yes.
Where should I go to get this config? Beagleboard.org or Mainline?
I just understood something. I was always reaching out while I could have done it myself.
Should I do the entire kernel configuration myself or can I rely on beagleboard.org to handle this build effort and image manufacturing?
https://forum.digikey.com/t/debian-getting-started-with-the-beagley-ai/55792
I will be going over this document in time and upgrading ideas. I was close this morning but forgot my one computer dislikes .tar files in transferring data via USB still.
So, I am going to update the build.
One idea of closure I would like is this:
Are there any parts I should look over in the build to change NOT being able to use make menuconfig?
I tried to set up the distros and failed to use “my own” kernel and “my own” toolchains.
is there a known way around these ideas? I mean, where would I look to use my own kernel with make menuconfig abilities and my own specified toolchains?
Update
Okay. So, once the kernel is built, I then use nodes and bases in DTS to handle the outcome of what comes into userland.
Does that sound right?
And…I have to review the TRM, say GPIO in this matter, to handle what specific bits are offset to make sure the processor knows what exactly I am telling it to do.
Is that close?
Okay and for Testing before the PR to Openbeagle.org and for v2 of GPIOd and so on…
- gpio.h has all definitive data
- A short listing of data can be found here: GPIO Character Device Userspace API — The Linux Kernel documentation
- It is definitely more complicated now than ever before today (so I say)…
- It is like it is a cyclic thing now.
- So, instead of simply calling
/dev/gpiochipN and requesting lines and setting values, one really needs to understand the userspace cyclic ways.
- I am trying and coming up empty for now.
- I will continue and report findings.
It seems simply calling GPIO_V2_LINE_FLAG_INPUT as an input via the struct under a, say, gpiochipN may work but then there are other cyclic “moves” to make in userspace.
Anyway, I am pretty close. I got a library so far that runs. Why does it run? No clue…
I answer there, “No clue…,” because the source code halts all execution of the library that was called within the source code.
I guess this is where Python3 and packaging come into play in a very generalized sense within Debian/GNU Linux.
Okay…
Enough chat for now. I will get back to it… Oh and first, sorry, the PR that will be made will just describe two outputs and one input and a library and some source code for handling a motor driver and end stop. Sorry. No e-stop for now.
Update
I feel like a failure now. I tried…
The code is there and working but my recollection of making libraries work in real-world scenarios is getting complicated to me again.
I seem to be one error away no matter what I do. I will post the code in case someone can see my altercation in its poor state. Please wait for more updates.
When I type:
gpiod --version: Nothing is registered on the output. I mean…there is not any output.libgpiod-dev --version: Same thing…python3-libgpiod --version: Same…
When I try to install them via the Debian Distro, I get that they are already installed.
When I look up in /usr/bin/, gpiod is not listed and I think this is why I am receiving error after error.
It is like the machine states yay but when I look it over, I am saying nay.
Anyway, if people are willing to address this concern with me and others in mind, please speak up. I will keep researching ideas and try to update when finalized.
Update
I broke my endstop! My code is garbage but it works now!
Seth
Okay. I got past the errors on programming. Phew. Anyway and of course, the errors were mine and mine alone but…
What would be a way to handle amplifying a GPIO signal of what mA of the GPIO peripheral on the BeagleY-AI?
So, say the GPIO on the BeagleY-AI promotes 4.6mA per GPIO pin available on the headers, how could I encourage the 4.6mA to handle 7mA or 9mA?
The reason I am asking:
- I have a motor driver that does not accept what I was familiar with during the BBB ideas on mA per GPIO pin.
- I am using the BeagleY-AI now.
- I need to amplify the mA per two GPIO pins, one for a direction and another for a step set of pins, to set up this driver.
- I have other drivers that I can use but I wanted to try these…
I want to be 100% sure it is not me that is mistaken on making these drivers work as stated. I understand I could probably just use a different board with 5v TTL logic but no fun in that idea for now. CMOS!
I will be researching ideas slowly and I will return service once I can configure something of warrant!
@lranders ,
How can I attempt to promote a gain in mA just from the 3.3v GPIO amperage?
Also, how can I exactly gain 4mA to 5mA preferably?
Not too much current needs to be adjusted and I do not want to mess up my board at all. Like something I can find in my house… I mean this idea. I have older electronics, e.g. nothing up-to-date. I also have broken electronics I want to salvage at times. So, maybe a good source…
This is a fine chat to have now. I think the BJT is okay but I like MOSFET tech. better, i.e. as it takes away from needed resistors in the mix. I already have only and only resistors which does not support my cause for now. Anyway, if you have delightful news or ideas, I am all ears.
mathematics are missing in my curriculum now for this adventure. Should I use Ohms Law (not a resistor technology so to say but they may or may not be needed) or another form of found technology?
It might be worth checking if the GPIO-bits include drive-strength settings.
Otherwise, I’d go with some 74LVC buffers; those can be gotten as 1G variants.
They’re also 5V tolerant, so that’s an added bonus.
• LowPower Consumption, 10-µA Maximum ICC
• ±24-mA Output Drive at 3.3 V
I found some types of the 74LVC that I may actually have on hand. Anyway, do the above mentioned bullet points mean that I can control the mA output at 3.3v?
For instance, 4-20 mA Loops is for Auto. Control…yes. And, it is serious business from what I understand. It is past the let-go threshold. Meaning, contractions of muscles and not being able to let go happen on these types of 24 mA thresholds.
Anyway, I am an adult. So, I take full credit for making error. Outside of that idea, no matter how much I read, I am slowly gaining some more confidence in the electronics field.
Outside of that fact: https://www.digikey.com/en/resources/conversion-calculators/conversion-calculator-ohms will help me foolproof my exercises.
And right about the 5v needed for powering off and on the device (motor driver). I will need this idea for powering off the device if it goes ape-wire like last time when it broke my limit switch and its logic.
So, finding resistance is basically:
If voltage is 24 V, then R = 24 V / 0.024 A = 1000 Ohms
I will need to double check the datasheet and replace accordingly the amount of amperes to suit its needs for correct configuration. The first highlighted bullet points deal with this driver: SN74LVC2G241.
Misspoken: I have a 74HC04N only now. The 74LVC types are not in my inventory…
I will keep looking. Blah. One last update until I hear from you…
I have the 74HC inverting type and a 74HC non-inverting type only. I think I am out. Off to purchase whenever they pay me another day…
It’s really hard to give you any kind of advice because you’re all over the map…
Now it sounds like you’re looking for a constant-current source.
You’ve lost me, so all disclaimers apply to the maximum possible extent under the law!
That is what I got working so far. No much but it keeps my hopes alive and well…
@lranders ,
Hey there…I am all over the map. I only have so many chips to utilize for now.
When I get paid again, I can get the chips shipped so I can utilize those instead. Do you know maybe why my motor stays warm during the "constant-current source" issue?
I started another post about the issue at hand.
Maybe you can chime in and let me know your thoughts while I get the schematic done and completed. I am using Pspice for TI but they do not have an exact match for now. I will need to add an addition to my current set of parts.
Also, does the OE section of a 74LVC Buffer mean another GPIO pin is needed?
That depends on which gate you get. An LVC14 f. ex. doesn’t come with an OE.
If we’re talking about an LVC125, you don’t have to use the OE. Just ground it…
I am researching 74LVC chips now. Thank you! I can only find this one in PDIP format…
SN74LVC244AN… Blah. I will keep searching.
You’re constraining yourself too much. Just get some SO-to-PDIP adapters…
I have looked around. As soon as I configure something of use, I will get a PCB made. Until, “Grumpy, Old Men”, play on IMAX, I am looking to entertain ideas…
Also, I looked at surface mount to PDIP so far. I will keep looking.
