frostsnow has quit [Read error: Connection reset by peer]
frostsnow has joined #beagle
v0n has quit [Quit: WeeChat 4.2.2]
frostsnow has quit [Ping timeout: 260 seconds]
frostsnow has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #beagle
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #beagle
KREYREN has quit [Read error: Connection reset by peer]
aussetg has quit [Remote host closed the connection]
aussetg has joined #beagle
Shadyman has joined #beagle
aussetg has quit [Remote host closed the connection]
aussetg has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
mvaittin has joined #beagle
mvaittin has quit [Ping timeout: 272 seconds]
rob_w has joined #beagle
mvaittin has joined #beagle
ikarso has joined #beagle
florian has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
ft has quit [Quit: leaving]
set_ has quit [Remote host closed the connection]
set_ has joined #beagle
Shadyman has quit [Quit: Leaving.]
jfsimon1981_b has joined #beagle
jfsimon1981 has quit [Ping timeout: 260 seconds]
xet7 has joined #beagle
rob_w has quit [Quit: Leaving]
mvaittin has quit [Ping timeout: 260 seconds]
mvaittin has joined #beagle
mvaittin has quit [Ping timeout: 268 seconds]
Stat_headcrabed has joined #beagle
buzzmarshall has joined #beagle
jfsimon1981_b has quit [Remote host closed the connection]
jfsimon1981_b has joined #beagle
<zmatt> set_: note that this isn't something new, it's been like this for a very long time. exporting hasn't been needed since cape-universal was introduced, and unnecessarily exporting anyway has been causing breakage for almost as long I think
<zmatt> actually no I think the breakage is a bit newer than that, I think rcn introduced that patch to allow gpiod to work
<zmatt> but that was still a long while ago, definitely kernel 4.x series
russ has quit [Read error: Connection reset by peer]
russ has joined #beagle
Stat_headcrabed has quit [Quit: Stat_headcrabed]
mvaittin has joined #beagle
mvaittin has quit [Ping timeout: 255 seconds]
ft has joined #beagle
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Remote host closed the connection]
vagrantc has joined #beagle
SJFriedl has quit [Quit: Leaving]
SJFriedl has joined #beagle
vagrantc has quit [Quit: leaving]
<set_> gpiod!
<set_> It is me...I already understand.
<set_> I have little talent and big ambition.
<set_> Anyway, it seems what is available now in Bookworm is not really available or something along those lines.
<set_> For instance, GPIO60/P9_12 cannot be used as GPIO at all and it does in fact remove itself once altered with gpiod and not available with sysfs.
<set_> A reboot will make it come back to life.
<set_> Anyway, no issue. I was just going to make some motors move. I thought all this old source could be used to alter motors...
<set_> Updating the source to current times has not been difficult, e.g. outside of the source doing nothing.
<set_> That has been the most difficult part.
<set_> And yes, @zmatt, it has been this way for a long time. Slow to motivate and slow to leave or whatever...I have had some issue with this driver and another driver or two other drivers with just using GPIO to alter DIR/STEP and sometimes ENABLE/DISABLE.
<set_> I even tried some docs.beagleboard.org source to move the stepper with a specific driver. The source runs. No issue. The run source does not do what I thought it would do.
<set_> Now, is there a reason? Yes. Do I know this reason? Of course not!
<zmatt> using gpiod on a gpio will also break the sysfs gpio interface for that gpio yes, the root cause is the same in both cases
<set_> I keep thinking it is a timing circumstance when it is some sysfs system not obeying my commands. Of course...I have not tried to make it go rotate, the motor(s), with bash scripts yet or even on the command line with commands.
<set_> Oh.
<set_> I understand this fact to be evident. I have witnessed it.
<set_> Is there any particular "cure?"
<zmatt> so just don't do that, stick to sysfs gpio *or* if for some reason you want to use gpiod (even though it's mostly just more annoying to use) then stick to using gpiod for that pin
<zmatt> don't mix the two (at least not for the same pin)
<set_> Okay.
<set_> @zmatt: Would you like to see something I think you would think is funny from '22?
<set_> It is source...nothing odd.
<zmatt> I'd suggest sticking to sysfs-gpio since it's overall more convenient to use
<zmatt> (gpiod feels like it was designed by people who don't understand gpio)
<set_> Okay. I have tried. The gpio pins work and there are "no" errors or warnings reported. The source just does not do anything.
<set_> '22
<zmatt> that's probably just a problem with whatever you're doing
<zmatt> dunno, you always have problems with everything :P
<set_> You are right. I am hoping for some enlightenment.
<set_> Is that spelled correctly? Off to check. brb
<set_> Like, a light switch but with source...
<set_> And yes, I spelled it correctly. Sheesh.
<set_> euphamisms are terrible and that is one of mine that I use to this day. Blah.
<set_> Wait for the '22 source.
<set_> Bear with me.
<set_> Line 41 has fooled me so far: https://pastebin.com/HKpFNjkz
<set_> I think this was from you...ha.
<set_> I know...why would I completely disregard learning for so long to try to make some motor(s) move?
<set_> no clue! But what I do know is this... My motors are not rotating and gravity/electricity/magnets are failing as we speak...
<set_> Where you playing a hoopla on me?
<zmatt> this doesn't look like my code no
<set_> Oh.
<set_> Hmm.
<set_> Okay.
<zmatt> this is definitely not my code
<set_> Are you sure?
<zmatt> I think
<set_> Oh well. No issue.
<zmatt> or it's partially my code but modified
<set_> Yes.
<set_> I modified it and never got it to make the motor move.
<set_> Now, where did I modify it, noctural animals know? Anyway, can you fix it or am I on my own?
<set_> And sir, do you understand line 41? It is making a binary 0 a string?
<zmatt> here's my original version of that particular class: https://pastebin.com/UwDFNb9Z
<zmatt> all of the changes done are nonsensical
<set_> Okay!
<zmatt> this class assumed direction is already setup in advance
<set_> Ha.
<set_> I have been going loopy for three years, '22 to '24. Oh, two years.
<zmatt> I've had more full-featured examples too, this one was just meant to be basic
<zmatt> your version is badly broken
<set_> I understand.
<set_> I know.
<set_> I wonder wherever I attained it and if changed by myself, did I recover ever or make notes? No idea. The basis for simplicity is overwhelming me when I see how well you type it. I just bash randomness together and hope for rain...
<zmatt> write random code, get random results
<set_> There has to be a science about it. I would have expected for random results. Just not "NO" results.
<set_> Nothing happened.
<set_> So, I have tried some pathlib examples, some toggling GPIO pins via GPIOD, and some random-no-result source so far for these drivers.
<set_> If that script you have works, am I allowed to use it?
<set_> I mean...I can use it test motors with my BBB?
<set_> Never forget the Titans. Oh and I will test it and see how far it takes me. config-pin is no more!
<zmatt> uhh what?
<set_> I am on Bookworm distros from kernel 5.10.x and I cannot use config-pin any longer.
<set_> Bullseye! Good to go with config-pin. Bookworm! No more config pin. Both having the kernel 5.10.x for the BBB (am335x).
<zmatt> is the image still unfinished maybe?
<set_> Probably.
<set_> It works. Things have been known to work (I think).
<zmatt> that would at least explain why the latest image for BBB at https://www.beagleboard.org/distros is the bullseye image
<set_> Oh.
<set_> Well, dang.
<zmatt> well if config-pin is missing I wouldn't say "it works"
<set_> Aw. I think that just keeps getting more broken by time and lack of effort for a new method or something.
<zmatt> not as far as I know
<set_> Oh. Okay.
<zmatt> the driver used by config-pin (bone-pinmux-helper) is a trivial driver that afaik only uses well-supported kernel interfaces
<set_> Whelp, I tried kernel 6.1.x and 5.10.x and neither seem to have the "Bookworm" allowable config-pin interface/command line tool.
<zmatt> and there's certainly no reason why it would matter what distro version you're using (bullseye vs bookworm), it would only depend on the kernel version
<set_> I will try Bullseye.
<set_> Oh.
<zmatt> I mean, installing a different kernel isn't going to magically install a commandline utility
<zmatt> maybe there's just some package missing
<zmatt> dunno
<zmatt> can't be bothered to dig into it right now honestly
<set_> Right and A-Okay. No issue.
<zmatt> afk
<set_> Okay. Toodley-Doodley.
<set_> Up, up, and otay!