<set_> git pull obviously did something but the error is still on my output.
nparafe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nparafe has joined #beagle
<set_> pathlib still works. So, either I am doing something wrong, probably, or this might be a butter sandwich of ideas that I cannot make work just yet.
<set_> Either way, I will keep testing.
<set_> And then, when " echo 1 > value " commands are given, this is the output of no permission: -bash: value: Permission denied
<set_> So, I also have not been able to run the source under your lib. dir. w/out sudo. So, this is probably it.
<set_> I will retry from scratch.
<zmatt> don't use sudo
<zmatt> and yes, you doing something wrong sounds like a reasonable hypothesis
<set_> Ha.
<set_> I tried w/out sudo and received permission errors, i.e. even w/ the udev rule.
<zmatt> unless your system is entirely broken you should never get permission errors when trying to use gpio
<set_> I know, oh. So, I do not need the udev rule you mentioned that I called 84-gpio.rules?
<zmatt> like, this is something that works normally out of the box on any image
<set_> Oh. Right. I saw the udev rules for no-root-gpio.rules.
<zmatt> it doesn't matter too much what you call my udev rule, but it has nothing to do with permissions
<zmatt> yes, /etc/udev/rules.d/80-gpio-noroot.rules is responsible for setting permissions
<set_> I added another .rules to /etc/udev/rules.d/
<set_> Okay.
<zmatt> (part of the bb-customizations package)
<set_> I am going to erase the udev rules that I added in /etc/udev/rules.d/
<zmatt> ehm
<set_> What?
<zmatt> having my udev rules for gpio is still highly recommended too
<set_> Oh. Okay.
<zmatt> that just doesn't have anything to do with permissions, it's for creating symlinks
<set_> Right, so if this has nothing to do w/ permission errors, which is what I am having now, I will rebuild from scratch.
<set_> Maybe when I used sudo make install.
<zmatt> uhh, what did you make install?
<set_> Everything in overlays-utils.
<zmatt> overlay-utils has nothing to install, its makefile has no install rule
<set_> It said nothing was needed. So, I politely moved on. I know. I made this error in the beginning.
<zmatt> "make: *** No rule to make target 'install'. Stop"
<set_> Right.
<set_> So, let me rename overlay-utils and clone it again.
<zmatt> ??
<zmatt> this has nothing to do with overlay-utils
<set_> permissions has nothing to do w/ overlay-utils either?
<zmatt> no
<set_> Hmm.
<set_> Okay well, this is one for the books. B/c, dmesg is on the way.
<zmatt> what does ls -l show on whatever path you were getting permission errors on?
<set_> Let me show you.
<set_> root and not debian
<zmatt> ok, pastebin the contents of your /etc/udev/rules.d/80-gpio-noroot.rules
<set_> Okay. Please hold.
<zmatt> no that's 85-gpio-noroot.rules, not 80-gpio-noroot.rules
<set_> Dang it.
<set_> Okay. Please hold.
<set_> No such beast.
<zmatt> well there's your problem
<set_> I do not have 80-noroot-gpio.rules
<zmatt> it exists normally, so you apparently somehow managed to delete it
<set_> I have 80-i2c-noroot.rules
<set_> Nope. I have not.
<set_> I promise.
<set_> Serious.
<zmatt> the evidence says otherwise
<set_> I have not.
<set_> Fine.
<set_> Where can I find the udev rules for noroot-gpio?
<zmatt> I'm trying to figure out why "apt-get --reinstall install bb-customizations" doesn't reinstall that file if deleted
<set_> Oh. Okay, no issue.
<zmatt> right, because it's listed as a config file... so the question is how to get dpkg or apt to restore a config file
<set_> Serious?
<set_> I thought I could just add it and then udevadm --Blah Blah.
<zmatt> sudo apt-get -o DPkg::options::=--force-confmiss --reinstall install bb-customizations
<set_> Argh.
<set_> Okay.
<zmatt> that will reinstall any missing config files
<zmatt> I guess you could also just recreate that one file
<zmatt> but who knows what else got mangled
<set_> is bb-customizations still a thing?
<zmatt> ehm, yes?
<zmatt> why would it not be?
<set_> Oh. Okay.
<set_> It would not be b/c I know nothing. Are you new?
<set_> Ha.
<set_> I thought everyone knew I knew nothing.
<set_> Okay.
<set_> So, I will do it.
<set_> Should I report any adverse affects?
<zmatt> ?
<set_> Like if the board halts its actions and does not reply to my commands...then should I say something?
<zmatt> ??
<set_> Okay.
<set_> Let me try the command.
<set_> It is working so far.
<set_> Do I need to restart?
<set_> 82-gpio-config-pin.rules is something I have on my /etc/udev/rules.d/ dir.
<zmatt> the command should have created 80-noroot-gpio.rules
<set_> It did not
<zmatt> wtf
<set_> Serious.
<set_> It did not.
<zmatt> can you pastebin the output of apt-cache policy bb-customizations
<set_> Sure.
<set_> Please hold.
<zmatt> or just, what version of bb-customizations did it install?
<set_> Installed: 1.20220316.0-0~bullseye+20220316
<zmatt> oh wtf why are you on bullseye?
<set_> Oh. B/c...I am testing.
<zmatt> (also, wtf why is that udev rule missing on bullseye?)
<set_> See. Now, you got the question correct.
<zmatt> rcn-ee: what happened to 80-noroot-gpio.rules on bullseye?
<set_> Why is the udev rule not already there on Bullseye?
<zmatt> (or an equivalent rule to set sysfs gpio permissions)
<set_> Hmm. It seems this may be a fault of the char driver persons?
<set_> GPIO this chip that.
<set_> Dang it.
<zmatt> set_: please stop "testing" bullseye... you have no capacity to distinguish between issues with bullseye and issues you've caused yourself
<zmatt> you're just creating more confusion for yourself and more work for me in trying to decode what's going on
<set_> Okay.
<set_> I am not going to write a new image tonight for now.
<set_> I will "update" to Buster later.
<set_> I just assumed everyone was testing w/ this image and kernel.
<set_> That is my mistake.
<set_> There are so many of them right now on the "shelf." It is hard to test one and stay w/ it.
<zmatt> just use the latest official image
<set_> Where is that now?
<zmatt> the same place it's always been?
<set_> On beagleboard.org/latest-images?
<zmatt> yes
<set_> Argh. Last I tried it was updating and upgrading. I will go back.
<set_> Sheesh.
<zmatt> ??
<set_> There is a lot of work to be done. One cannot just assume everyone is using the same image and kernel, right?
<zmatt> most people are yes
<set_> Oh.
<set_> Hmm. Okay, my mistake. It just seems like b/c of the forums, things changed a bit. The kernels people use and the images too are all available in plain sight for people like me to just get, grab, and go.
<set_> I will get an older image to "steal" the show w/ the 80-noroot-gpio.rules file.
<set_> Then, I can use this lib. Oh hey, @zmatt, can I chat about your lib. on the forums once I get it working correctly due to udev and "my" missing files?
<zmatt> ?
<zmatt> what do you mean by "chat about" my lib?
<set_> Serious. Oh, I want to discuss it w/ random people that may seem to like it. Polls of libs. once created are fun. I know this is usually more serious than just plain-Jane fun around here.
<set_> But...I am not ordinary groupy.
* set_ is like a monster groupy.
<set_> Ha.
<set_> Anyway, I joke, I kid, and I tell lies.
<set_> So, back to the ole, drawing board for me.
<set_> Argh.
<set_> Have you ever heard that song?
<set_> "and we are telling lies." It is some American country song from the '50s I guess. It is awesome!
<set_> It may be called, "If you like sinnin'."
<set_> Anyway, sorry to waste your time AGAIN!
<set_> SUBSYSTEM=="i2c", GROUP="gpio", ACTION=="add", \ <<< Can i use this idea but w/ the SUBSYSTEM=="gpio", for noroot-gpio.rules?
<zmatt> no
<set_> Dang it.
<set_> Okay. I will go and search around to see if I can find it.
<set_> Hey, how did you know where it was located?
<zmatt> google
<set_> Google, heh. Well...I will try to handle my searching skills later. time to update! Thank you.
<set_> Dang it. Not so easy.
<set_> It has been a while since the beagleboard/customizations has been updated.
<zmatt> yeah I think this is actually the correct repository, but the file is the same anyway: https://github.com/rcn-ee/repos/blob/master/bb-customizations/suite/buster/debian/80-gpio-noroot.rules
<set_> Oh. Okay.
<set_> Well, I tried it out. No go.
<set_> It did work.
<set_> I had to reboot the machine.
<set_> I still get that illegal seek for some reason.
<set_> maybe b/c of gpio_open_output being before gpio_open in the source?
<set_> This is my issue still >>> pwrite /dev/gpio/relay-jp3/value: Illegal seek
<zmatt> uhh, what does your source look like?
<set_> I research the issues for this idea. I came across many man pages but...oh.
<set_> Please hold. I will show you.
<zmatt> why are you opening a gpio twice? don't do that
<set_> Oh.
<set_> I could not compile in any other format so far.
<zmatt> also, this can't possibly compile... or at least it shouldn't
<set_> It did!
<set_> w/ make!
<zmatt> ugh wtf C why does this not give an error
<set_> Of course, I added the file in the Makefile to be converted.
<set_> Ha.
<set_> What did I do?
<set_> I opened the GPIO device twice. Okay but what else? What else did I do that is incorrect?
<zmatt> I guess it's allowing implicit conversion from pointer to bool, but that's fucked up
<zmatt> still doesn't explain the illegal seek, that's really bizarre
<set_> Hmm. Yea and about that...
<set_> Sir, get this.
<zmatt> passing "low" or "high" is bogus btw
<set_> I could not compile in any other way. When you say converting bool to pointer.
<zmatt> it's expecting a boolean, not a string
<set_> Oh. It works.
<set_> It turns on!
<zmatt> "low" is interpreted as true, i.e. as high
<zmatt> "high"" is interpreted as true, i.e. as high
<set_> It just does not turn off, i.e. Ha.
<zmatt> "sdfdskjfdhskjf" is interpreted as true, i.e. as high
<set_> Right.
<set_> Now, I know.
<set_> Ha.
<set_> Okay.
<set_> I got it now.
<set_> This is the issue.
<set_> Let me retest.
<zmatt> it's really dumb that this doesn't cause an error though
<zmatt> like, I understand why this is so, but it sucks
<set_> So, I need a 0 or 1 or a true or false?
<set_> You say bool. True of False.
<set_> Okay.
<set_> But, did your source change any of that aspect to the boolean values?
<set_> Now.
<zmatt> you can use either 0/1 or false/true
<zmatt> maybe I should make the argument int instead of bool
<set_> It turned off and the permissions issue is back but w/ open and not pwrite.
<set_> No issue. Boolean values are fine.
<zmatt> ok I can reproduce the seek, lemme see what's going on
<set_> open /dev/gpio/relay-jp3/direction: Permission denied
<set_> Okay.
<zmatt> you can't change the direction of these gpios... they're controlling relays so they're always output
<set_> Aw. Okay.
<set_> Darf.
<zmatt> oh I see the problem, it's your fault... although the error message could have been clearer
<set_> Oh.
<set_> I know this idea has to be true.
vagrantc has quit [Quit: leaving]
<zmatt> you used gpio_open() with the last argument (bool input_only) set to true ("low")
<set_> Yes...
<zmatt> which will cause any attempt to perform a write to fail, since you opened it as input-only
<set_> Aw.
<zmatt> this code makes no sense anyway
<set_> So right, the lib. stated that the input only boolean value is for input and not output.
<set_> Ha.
<zmatt> just use gpio_open_output() open and initialize an output
<set_> Okay.
<zmatt> and use gpio_write() to change it
<set_> Aw.
<set_> Okay.
<zmatt> don't use gpio_set_direction_output except to change a bidirectional pin from input to output
<set_> gpio_write() is for the change. I read incorrectly (as usual). Oh. Nice.
<set_> Okay.
<zmatt> also dunno what you're doing with the timeout thing, none of that makes sense
<set_> Hhahaha. I know.
<zmatt> the timeout was part of the input example which was waiting for input changes
<set_> Right.
<set_> I kept it for the glory.
<zmatt> you kept it to confuse people, gotcha
<set_> No.
<set_> For the idea of me being me. Not for others.
<set_> Ha.
<zmatt> maybe I should use enums instead of booleans, just for type-safety
<set_> Ut oh.
<zmatt> given how eager C/C++ is to convert any shit you provide into a bool
<set_> I think i blinked so quickly, I could not see it.
<set_> LEDs!
<set_> Well...
<set_> I turned the switch into a buzzer.
<set_> Hhahah. Dang it.
<set_> and done. Almost rest time.
<set_> Phew.
<set_> Luckily it compiled w/ my sleep ideas.
<set_> @zmatt: Sorry for the trouble. It all works and dandy like.
<set_> Way to go, sir. May I pause for intermission?
<set_> I used uSleep for 5000 in my source and the switch turned into a buzzer. Oops.
<set_> @zmatt: Do you ever have to compile w/ specific statements for usleep?
<set_> Not in general, you. I am asking about if you do it for BBB or am335x related tasks...
<set_> Never mind. I am seeing that compiling physical files like QCSRC are maybe for .asm files?
<set_> Wait, this is for .c files.
<set_> So, naming a member in a source file, C/C++, "needs" specific statements for compilation. Hmm. Neat.
<set_> I have only been introduced to command line compilation commands so far. I am not too in depth right now on this effort.
thinkfat has quit [Ping timeout: 250 seconds]
thinkfat_ has joined #beagle
Shadyman has joined #beagle
<zmatt> ?????
<set_> Forget it.
<set_> It works. I thought I had to use nanoseconds but that had not been introduced until 5.13.x or somewhere around that kernel.
<set_> So, my kernel will not work for that idea.
<zmatt> usleep() and nanosleep() both exist, and both have existed for a very very long time
<set_> Oh.
<set_> I know usleep() has existed. I just saw nanosleep() as its replacement.
<zmatt> I mean, usleep is fine for most purposes and it ain't going anywhere (regardless of what POSIX might think)
<set_> Oh.
<set_> Okay.
<set_> This is good news.
<zmatt> I'm pretty sure usleep() is actually simply implemented as a wrapper around nanosleep()
<set_> Oh.
<set_> Hmm. Okay.
buzzmarshall has quit [Quit: Konversation terminated!]
mag_ has joined #beagle
mag has quit [Ping timeout: 250 seconds]
Shadyman has quit [Remote host closed the connection]
ikarso has joined #beagle
xet7 has quit [Quit: Leaving]
xet7 has joined #beagle
xet7 has quit [Quit: Leaving]
ikarso has quit [Quit: Connection closed for inactivity]
thinkfat_ has quit [Remote host closed the connection]
thinkfat_ has joined #beagle
buckket has quit [Quit: buckket]
thinkfat_ has quit [Quit: Konversation terminated!]
buckket has joined #beagle
thinkfat has joined #beagle
thinkfat has quit [Ping timeout: 240 seconds]
jfsimon1981_b has joined #beagle
starblue has quit [Ping timeout: 240 seconds]
ketas- has joined #beagle
jfsimon1981 has quit [Ping timeout: 240 seconds]
ketas has quit [Read error: Connection reset by peer]
vagrantc has joined #beagle
mag has joined #beagle
mag_ has quit [Ping timeout: 250 seconds]
argonautx has joined #beagle
starblue has joined #beagle
thinkfat has joined #beagle
thinkfat has quit [Quit: Konversation terminated!]
thinkfat has joined #beagle
thinkfat has quit [Ping timeout: 250 seconds]
Guest4 has joined #beagle
Guest4 has quit [Client Quit]
starblue has quit [Ping timeout: 256 seconds]
Guest89 has joined #beagle
Guest89 has quit [Client Quit]
thinkfat has joined #beagle
thinkfat has quit [Ping timeout: 240 seconds]
Mohamed has joined #beagle
<Mohamed> hi
<Mohamed> I want to know BeagleBone® AI board dimenions ?
<Mohamed>  I want to know BeagleBone® AI board dimensions ?
<zmatt> the pcb itself is same size and shape as the beaglebone black, 86 x 54mm
<zmatt> (some connectors slightly stick out)
Mohamed has quit [Ping timeout: 256 seconds]
vagrantc has quit [Quit: leaving]
starblue has joined #beagle
buzzmarshall has joined #beagle
otisolsen70 has joined #beagle
otisolsen70 has quit [Quit: Leaving]
argonautx has quit [Quit: Leaving]
xet7 has joined #beagle
hnv has quit [Ping timeout: 256 seconds]
shodan45 has quit [Ping timeout: 256 seconds]