<giort>
Hello. Im trying to use libgpiod on the beaglebone black. My code toggles a pin on P9, but the output voltage doesnt change. Im running this example code: https://github.com/starnight/libgpiod-example
<giort>
Is there any setting I need to change before being able to use the libgpiod api?
Shadyman has left #beagle [#beagle]
<giort>
even the gpioset utility doesnt work on the user leds
xet7 has joined #beagle
Daulity has joined #beagle
<Daulity>
hey all
buzzmarshall has joined #beagle
CrazyEddy has quit [Ping timeout: 264 seconds]
troth has quit [Ping timeout: 258 seconds]
rob_w has quit [Quit: Leaving]
troth has joined #beagle
argonautx has joined #beagle
troth has quit [Ping timeout: 245 seconds]
lucas_ has joined #beagle
vd has quit [Quit: Client closed]
lucascastro has quit [Read error: No route to host]
lucas__ has joined #beagle
vd has joined #beagle
lucas_ has quit [Ping timeout: 258 seconds]
<zmatt>
giort: the user leds are controlled by the kernel hence cannot be controlled from userspace via sysfs-gpio or gpiod, though leds do have their own sysfs interface
<zmatt>
giort: all pins default to gpio mode unless they're already in use for a specific purpose, you can check the current mode of pins e.g. using my show-pins utility: https://github.com/mvduin/bbb-pin-utils/#show-pins
lucas__ has quit [Quit: Leaving]
giort has quit [Read error: Connection reset by peer]
giort has joined #beagle
set_ has quit [Ping timeout: 260 seconds]
M-blaise has joined #beagle
M-blaise has quit [Quit: WeeChat 2.8]
florian has quit [Quit: Ex-Chat]
M-blaise has joined #beagle
vagrantc has joined #beagle
giort has quit [Quit: giort]
CrazyEddy has joined #beagle
vd has quit [Quit: Client closed]
lucascastro has joined #beagle
vd has joined #beagle
mattb00ne has quit [Quit: Client closed]
ikarso has quit [Quit: Connection closed for inactivity]
michaelo_ has quit [Quit: Lost terminal]
vd has quit [Quit: Client closed]
vd has joined #beagle
Shadyman has joined #beagle
behanw has joined #beagle
mattb0ne has joined #beagle
<mattb0ne>
whats a low overhead way of tracking real world time in a loop
<mattb0ne>
i have a for (;;) loop that I want to break after 3 minutes of real world time
<mattb0ne>
I am on the pru
ikarso has joined #beagle
<zmatt>
why would pru care about stuff on the scale of minutes? isn't pru just doing a control loop?
CrazyEddy has quit [Ping timeout: 264 seconds]
<mattb0ne>
well my issue is when I halt the core from python the motor does not cut
<mattb0ne>
and my program just has that for (;;) loop so it never terminates
<zmatt>
ok, so it's like a watchdog... I'd just a much shorter interval than 3 minutes
<zmatt>
also, aren't you continuously logging data to python? you could halt if that buffer is full (since that presumably means python stopped consuming the data)
<mattb0ne>
I just want to stop the motor when I stop the PRU
<mattb0ne>
i guess I could stop from python
<zmatt>
if you're halting the core from python then there's nothing PRU can possibly do about it since you halted the core
<zmatt>
the alternative would to communicate a stop-request to PRU and have it turn the motor off and halt itself
<zmatt>
(and likewise do the same if python appears to have unexpectedly disappeared, like I said you could use overflow of the ringbuffer to detect that)
otisolsen70 has quit [Quit: Leaving]
argonautx has quit [Quit: Leaving]
set_ has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
Guest42 has joined #beagle
Guest42 has quit [Client Quit]
vd has quit [Quit: Client closed]
vd has joined #beagle
vagrantc has quit [Quit: leaving]
<set_>
Dang it. Ran out of room...no room for sore something or others. Blah.
<set_>
I got the .hex file to be applied to the chip but there was obviously not enough room on the memory of the chip.
<set_>
Too bad. I could be movin' and groovin' right now!
<set_>
GenTooMan: What are you doing?
<mattb0ne>
zmatt: question for you is there anyway the PRU could that technique you used to increase the resolution of the encoder make it more error prone
<zmatt>
??
<mattb0ne>
i have been struggling with the positioning, I was always missing the mark so I am doing a simple test where I do a quarter turn of the shaft and try to get 90 degrees
<mattb0ne>
i am not and worse yet when I rotate back I do not get back to zero it is sort of like a drift
<mattb0ne>
so rotating back and forth between zero and 90 degrees the miss gets worse
<zmatt>
what does the decoder you're currently using look like? (I remember many versions)
<zmatt>
ehhh
<zmatt>
none of my versions should have drift
<mattb0ne>
the encoder value is change as I turn so no slipping or anythin g
<zmatt>
I can't imagine any way you could have drift that doesn't involve a mechanical problem... or maybe electrical noise but even that generally shouldn't cause drift
<zmatt>
this version has the maximum resolution possible
<mattb0ne>
if I do not turn the shaft I do not increment
<mattb0ne>
could it be something in how the C code is reading the PRU
<zmatt>
seems unlikely but dunno what you're doing