<set_>
@zmatt: Are you still upset at me for using libgpiod?
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #beagle
<zmatt>
I'm not upset "for using libgpiod", I'm annoying because you keep discarding things that work in favor of things that don't, then ask for help, and then discard the advice
<set_>
Oh.
<set_>
I understand now.
<set_>
Okay.
<set_>
I will try to narrow my sights on what works instead of reinventing ideas into new ways of doing things.
<set_>
Can we agree yet?
vagrantc has quit [Quit: leaving]
dinuxbg_ is now known as dinuxbg
CrazyEddy has quit [Ping timeout: 240 seconds]
rob_w has joined #beagle
David21 has joined #beagle
<David21>
Hello, Looking for Beagle bone black ver2.1
<David21>
anybody can suggest where i can get it?
CrazyEddy has joined #beagle
xet7 has quit [Read error: Connection reset by peer]
otisolsen70 has joined #beagle
David21 has quit [Quit: Client closed]
jduchniewicz has quit [Quit: You have been kicked for being idle]
florian has joined #beagle
ikarso has joined #beagle
Shadyman has quit [Remote host closed the connection]
lucascastro has quit [Ping timeout: 272 seconds]
lucascastro has joined #beagle
rob_w has quit [Remote host closed the connection]
argonautx has joined #beagle
xet7 has joined #beagle
Steve__ is now known as SJFriedl
xet7 has quit [Client Quit]
xet7 has joined #beagle
johanhenselmans has quit [Read error: Connection reset by peer]
johanhenselmans has joined #beagle
otisolsen70 has quit [Quit: Leaving]
xet7 has quit [Quit: Leaving]
ikarso has quit [Quit: Connection closed for inactivity]
ikarso has joined #beagle
lucascastro has quit [Ping timeout: 260 seconds]
vagrantc has joined #beagle
florian has quit [Quit: Ex-Chat]
alan_o has quit [Ping timeout: 240 seconds]
alan_o has joined #beagle
argonautx has quit [Quit: Leaving]
ikarso has quit [Quit: Connection closed for inactivity]
lucascastro has joined #beagle
xet7 has joined #beagle
lucascastro has quit [Remote host closed the connection]
<zmatt>
set_: oh I just realized yet another reason you shouldn't use libgpiod ... a program that uses libgpiod to control relay-jp1 or relay-jp2 that "works" (ignoring that it breaks the sysfs gpios) when the overlay-utils version of the BBORG_RELAY-00A2 overlay is installed will cause a short-circuit (and potentially destroy the BBB) when the bb.org-overlays version of the BBORG_RELAY-00A2 is used, and ...
<zmatt>
...conversely if the libgpiod code "works" with the bb.org-overlays version of the overlay then it'll fry the hardware when used with the overlay-utils version of the overlay
<set_>
Oh.
<set_>
That is not good.
<set_>
Why would the /dev/gpio/relay-jp3/value file cause such an issue?
<zmatt>
it doesn't
<set_>
I am not using the .dtsi file now.
<set_>
But...the files are still there at that location.
<set_>
Oh. I see what you typed now.
<set_>
relay-jp1/2.
<set_>
So, is there a way around such an issue or since it is libgpiod, you are against using your time to tell me?
<zmatt>
normally the kernel would prevent libgpiod from using gpiod that are already in use, that but that's been patched out in rcn's kernels (an action I do not agree with, even though I know why it was done)
<zmatt>
set_: easy workaround: DON'T USE LIBGPIOD
<set_>
I know, I know how you feel. Okay, so, there are still issues w/ it and for the am335x w/ what has been produced in .dtsi/.dtbo files.
<set_>
I will stop using it in case the rcn kernels get altered.
<set_>
I should make myself more aware of the issue pertaining to the source and how it can conflict w/ the images/boards/BBBWs.
<set_>
I need to alter the lib. now on github. Did you see the update for pathlib yet?
<zmatt>
set_: btw, in C_SRC/MyFirst.c you're trying to write to /dev/gpio/relay-jp3/direction .. don't do that, it's read-only
<zmatt>
(writing direction is not only unnecessary but doesn't, or shouldn't, work since this attribute is only writable for bidirectional gpios while the relays are output-only)
<zmatt>
also beware that if you used libgpiod on any of these gpios even once, it'll break them for sysfs access until you reboot
<rcn-ee>
okay, that bb-customizations package for bullseye is now fixed.. Had the flu for this week, so i've not really been aroudn..
<set_>
Oh.
<set_>
No!
<set_>
The flu. Yikes. It is march.
<set_>
Get well soon.
<rcn-ee>
and the snow is melting... i'm allergic to allergies.. ;) i'm good now..
<set_>
Yikes. Allergies. oh. good. Pulling through the sickness is half the battle.
<set_>
I say stop eating out. Those people are sickos.
<set_>
No offense to people doing well in the food industry.
<zmatt>
rcn-ee: any idea why the official BBORG_RELAY-00A2 overlay is so weird? it declares the relays as leds instead of just exporting them as gpios...
<rcn-ee>
yeah, i did that few years ago... led's are one echo off/on..
<rcn-ee>
vs, 3 lines for export, echo, echo..
<set_>
brb
<rcn-ee>
i know we have a udev rule that takes care of the export.. so it's 2 echo's vs 1. ;)
<zmatt>
rcn-ee: gpios are exported automatically if you use gpio-of-helper
<zmatt>
rcn-ee: no you're confusing gpio with pwm maybe
<zmatt>
gpios are automatically exported by the kernel if setup appropriately, and gpio-of-helper takes care of that setup
<zmatt>
(I've now also tweaked my USES_PIN macro to disable the gpio exported by cape-universal in addition to disabling the bone-pinmux-helper, but of course that needs a fairly recent kernel)
<rcn-ee>
at the time it was quick, and everything was mainline to make it work..
<rcn-ee>
your version would also work well..
<set_>
You guys...
<zmatt>
gpio-of-helper really ought to be mainline... unfortunately mainline has the delusion that the new gpiod is actually a good thing :P
<set_>
what is gpio-of-helper and bone-pinmux-helper and how can I use them to alter pin config(s)?
<rcn-ee>
gpiod is great... till the application stops/exits... and then your pin's return to default state.... and the laser cutter burns the house down.... ;)
<zmatt>
rcn-ee: btw, that udev rule I show in the comments of my overlay is pretty nice too, for using sysfs gpio without hardcoding gpio numbers: https://pastebin.com/raw/TukGTYWD
<zmatt>
rcn-ee: yes, fucking rude
<zmatt>
kernel shouldn't touch my gpio unless I ask it to
<rcn-ee>
it needs to be fixed, so that when the ioctrl is closed, the state it in, DOES NOT change... till then /sys/class/gpio can never be removed, as it doesn't actually replace it..
<zmatt>
that's just one of many problems
<zmatt>
access control granularity is another (sysfs gpio is per-pin)
<rcn-ee>
zmatt: what do you want to do with am6x.. same issue... (but unlike am57xx) it has a working gpio pinctrl...
<rcn-ee>
ah crap... gotta run... (picking up parts for thing this weekend..) back tomorow...
<zmatt>
rcn-ee: what do you mean, what issue? sysfs gpio should work fine on any linux system that has gpios
<zmatt>
the best way to deal with gpiod is by ignoring it exists
<set_>
You guys, I am going to look up gpio-of-helper and bone-pinmux-helper. Sheesh. If anyone has time to make me understand, please try to let me know about these libs.
behanw has quit [Quit: Connection closed for inactivity]
<zmatt>
set_: they're not libs, they're drivers. don't worry about it