ikarso has quit [Quit: Connection closed for inactivity]
m-atoms has quit [Quit: Leaving]
<set_>
GenTooMan! Wake up!
<set_>
I made a nice note. Oh and the PCBs arrived today. Ut oh!
<set_>
I am sensorsless in PCB land.
<set_>
And yes, it could be a word in my faction.
<set_>
Ha.
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #beagle
thinkfat has quit [Ping timeout: 250 seconds]
thinkfat has joined #beagle
troth has quit [Ping timeout: 265 seconds]
<set_>
I am too scared to open them. What if they are not as they are stated to be in resemblence?
<set_>
Too shakes!
* set_
shakes in agony
<set_>
They are gorgeous and not black?
<set_>
THey are purple.
<set_>
Hmm.
<set_>
Well, time to make something...
<set_>
Settle for ashes and receive volcanos!
troth has joined #beagle
<set_>
States Made In Germany but I know!
vagrantc has quit [Quit: leaving]
ikarso has joined #beagle
pruBegginer has joined #beagle
<pruBegginer>
Hi, Anyone here has experience with programming PRU on BBB
<pruBegginer>
I am going through PRU cookbook and having trouble toggling the GPIO pins with the PRU
<zmatt>
I do have a fair bit of experience with pru... I'm not really awake yet though -.-
<pruBegginer>
Thats great, happy to wait whenever you are
<zmatt>
(I've also written the py-uio python library that can be used to load code onto PRU, and inspect/control PRU ... https://github.com/mvduin/py-uio )
<pruBegginer>
Thats nice to know, Handy to test with.
<pruBegginer>
I was looking at doing some realtime work on the PRU with userspace app controlling the high level inputs
<pruBegginer>
So got my first BBB, have done a bit of driver work on linux in past, but first time into BBB
<zmatt>
realtime work is what PRU excels at
<pruBegginer>
True
<pruBegginer>
Usually, I design microcontroller boards which plug via usb to linux, with PRU its all inbuilt, which is nice
<zmatt>
yep, you can interact with pru simply via shared memory.
<pruBegginer>
true, i am running into issues with gpio
<zmatt>
pru's dedicated gpio, or just the regular gpio?
<pruBegginer>
Looks like my firmware is getting loaded, but no response on the gpio pins
<pruBegginer>
i would expect it to be general gpio, since I am using p9_11
<pruBegginer>
I am picking my way using PRUcookbook examples
<zmatt>
p9.11 indeed does not have a pru in/out mode
<pruBegginer>
you might have a point there, i tried config-pin pru out on that gpio and it spit an error
<pruBegginer>
but I tried another GPIO which did support pruout, hit the same issue
<zmatt>
you can use pruout mode or use general gpio (i.e. leave pinmux at default), either works although the details on how to use them are quite different
<pruBegginer>
>be sure to configure the pin as output before running the test
<pruBegginer>
Did you mean using config-pin P9_11 gpio?
<zmatt>
no, the pinmux is configured okay by default
<zmatt>
(in general, avoid using config-pin to set a pin to "gpio" since annooyingly that means "gpio with internal pullup/down disabled" which is generally undesirable since it can lead to floating pins)
<pruBegginer>
ok, would you reccomend doing it in the C code itself?
<zmatt>
no it needs to be done from linux
<pruBegginer>
via /sys/...
<zmatt>
echo low >/sys/class/gpio/gpio30/direction sets gpio0.30 (which is P9.11) to output-low
<zmatt>
or you can similarly echo high to set it to output-high
Guest5 has joined #beagle
<pruBegginer>
ok,
<pruBegginer>
I can see the pull up happening when writing high, for pullup
<pruBegginer>
The led lights up now
<pruBegginer>
I presume now the gpu is in an OUTPUT_PULL_UP state
<pruBegginer>
*GPIO
<zmatt>
no, you're confusing unrelated things
<pruBegginer>
Sorry, could you clarify where i am going wrong
<zmatt>
pinmux merely controls 1. peripheral is controlling a bit 2. whether the input receiver should be enabled 3. whether weak internal pullup/pulldown should be used to keep undriven pins from floating
<zmatt>
ehh, 1. which peripheral is controlling the pin
<zmatt>
the PIN_INPUT_ and PIN_OUTPUT_ macros are kinda badly named, they are PIN_INPUT_ENABLED_ and PIN_INPUT_DISABLED_ while having no influence on the output driver whatsoever
buzzmarshall has quit [Quit: Konversation terminated!]
Guest5 has quit [Quit: Client closed]
<pruBegginer>
ok
<pruBegginer>
I am following so far
<zmatt>
each configurable pin has a gpio mode which puts the pin under control of one of the four gpio controllers
<pruBegginer>
So from my understanding, we need to assign the GPIO to PRU peripheral?
<zmatt>
no, PRU is simply controlling the gpio peripherals
<zmatt>
however it cannot safely change the direction of a gpio (from input to output or vice versa) without risking a race condition
<zmatt>
which is why you should setup the direction from linux in advance
<zmatt>
the gpio controller has atomic-set and atomic-clear registers for the output value, which is why pru can safely toggle the output level of pins that are configured as output
<pruBegginer>
ok, so writing /sys/class/gpio/gpio30/direction does that
<zmatt>
yes
<pruBegginer>
ok that is now set to low, which should get the GPIO pin to the state I want
<zmatt>
that attribute reads as "in" or "out", and when writing you set it to "in", "low", or "high" since when changing a pin from input to output it also needs to know the initial output level
<pruBegginer>
cat /sys/class/gpio/gpio30/direction now reads out
<zmatt>
exactly
<zmatt>
so now the pru program should toggle the pin
<pruBegginer>
Now when I load the program, It does not change the LED state
<pruBegginer>
But logs confirm it went through
<pruBegginer>
[ 2690.367240] remoteproc remoteproc1: powering up 4a334000.pru
<pruBegginer>
[ 2690.367592] remoteproc remoteproc1: remote processor 4a334000.pru is now up
<zmatt>
I did notice it doesn't enable PRU's master port in this example... I wonder if that's needed for some versions of remotepru-pru but not others, or something, or if it's really just been omitted by accident
<zmatt>
I don't use remoteproc-pru myself since it doesn't have the features uio-pruss does
<zmatt>
(e.g. it lacks facilities for shared memory mapping)
<pruBegginer>
I suspect this example was recently broken, As this was used succesfully in the past by others
<pruBegginer>
Not sure if any kernel changes did that
<zmatt>
it's also possible people ran it successfully because they previously ran an example that enabled the pruss master port (which is persistent until you reboot)
<zmatt>
py-uio enables the pruss master port by default
<pruBegginer>
and see if that makes any difference
<zmatt>
that doesn't really make sense
<pruBegginer>
>that doesn't really make sense
<pruBegginer>
You mean the behaviour
<zmatt>
I mean, whatever the problem is is presumably a problem with this example code... trying a different pin is nonsensical unless you suspect the pin itself is physically broken, but you already know it isn't
<pruBegginer>
Picking another GPIO is meant to rule out if this one is a special GPIO's which the PRU has issues toggling
<zmatt>
there's no such thing
<zmatt>
pru has full access to all gpios and all peripherals
<zmatt>
and there's no difference between one gpio and another
<pruBegginer>
You should know better, lets go with your point of view
<zmatt>
I also made this header for controlling gpios: https://pastebin.com/anqLbyav ... I don't remember if it has been tested, like, at all though :D
vd has quit [Ping timeout: 256 seconds]
<pruBegginer>
Ok, now since I have tried known methods
<pruBegginer>
I might try your python lib and see if it is able to toggle the GPIO
<pruBegginer>
If that does, it would mean the C program needs work
<zmatt>
it *shouldn't* make much difference if code is loaded using remoteproc-pru or py-uio...
<pruBegginer>
if not it might mean something has changed underneath in the kernel
<zmatt>
(other than that py-uio will enable the master port for you)
<pruBegginer>
agree, so its good to verify that
troth has joined #beagle
<pruBegginer>
I will go away and give that a try,
<pruBegginer>
Thanks for your inputs zmatt
* zmatt
falls back asleep
<pruBegginer>
zmatt
<pruBegginer>
Hit errors while loading the py-uio
pruBegginer has quit [Quit: Client closed]
pruBegginer has joined #beagle
<zmatt>
did you follow the installation instructions in the README ?
<zmatt>
I should really include an install script or something
waldo323 has quit [Ping timeout: 256 seconds]
waldo323 has joined #beagle
troth has quit [Ping timeout: 256 seconds]
<pruBegginer>
I had done the uEnv settings to enable uio,
<pruBegginer>
the udev rules were missing, will add them in
<pruBegginer>
Yes an install script would be helpful
<AlejandroExojo[m>
Hello. I have a BeagleBone Black Wifi. It's untouched, never flashed or anything. Sometimes, plugging it to the computer via USB turns it on and shows the new USB device with instructions. But most of the times it doesn't. Is there something I could try to do?
jkridner has quit [Read error: Connection reset by peer]
jkridner has joined #beagle
<zmatt>
AlejandroExojo[m: you could try reflashing it with the latest image just in case. with a fresh device you never know what firmware is on there...
paulbarker has quit [Ping timeout: 256 seconds]
<AlejandroExojo[m>
Thanks! I'm still a bit lost on the beagleboard.org page, but I'll search for that
<zmatt>
easiest way is by downloading the "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher" image from the "Flasher Debian images" section of https://beagleboard.org/latest-images then write that to microSD card using Balena Etcher (https://etcher.io/)
<zmatt>
then boot the beaglebone from that sd card and it should automatically proceed to reflash the eMMC and then it will turn itself off
paulbarker has joined #beagle
<AlejandroExojo[m>
Excellent, thank you. Ultimately I want to use my own image, as I'm starting with Yocto. I have it built, but I don't have SD card yet. I'll start reading on that.
<zmatt>
if the firmware currently on the beaglebone is really old it may be necessary to force it to boot from SD card by holding down the S2 button (the button closest to the sd card slot) while powering on (you can let go of the button once the power led turns on)
<zmatt>
that may also be necessary to get it to boot a yocto image if debian is flashed to eMMC or vice versa
<zmatt>
another way to force it to boot from SD card (without having to fiddle with the S2 button) is by just wiping eMMC entirely using "sudo blkdiscard /dev/mmcblk1")
<AlejandroExojo[m>
Thank you. That would be when logged into the device, right?
<zmatt>
yes
<AlejandroExojo[m>
OK. I've never done that yet. I suppose a power source is gonna be better than plugging via USB, so I can free that port for keyboard/mouse
<zmatt>
uhh, keyboard/mouse plug into the usb-A port, which cannot be used to power the beaglebone
<zmatt>
(in the rare case you want to plug keyboard/mouse into a beaglebone in the first place)
<AlejandroExojo[m>
I'm afraid that yes, as I want to try out some GUI app (that's what I do 🙂 )
<AlejandroExojo[m>
Well, I need to do that on a device for a customer, but I don't have the customer's device
<zmatt>
powering the beaglebone is done either via the usb-B port (more precisely mini-B on the BBB and micro-B on the BBBW)
<zmatt>
or the 5V barrel jack
<zmatt>
(or the P9 header)
troth has joined #beagle
<AlejandroExojo[m>
Thanks! Much appreciated help 🙂
thinkfat has quit [Quit: Konversation terminated!]
troth has quit [Ping timeout: 264 seconds]
Shadyman has quit [Ping timeout: 264 seconds]
rob_w has joined #beagle
Shadyman has joined #beagle
troth has joined #beagle
Shadyman has quit [Remote host closed the connection]
samnob has quit [Ping timeout: 264 seconds]
samnob has joined #beagle
samnob has quit [Client Quit]
samnob has joined #beagle
otisolsen70 has joined #beagle
rob_w has quit [Ping timeout: 265 seconds]
pruBegginer has quit [Quit: Client closed]
troth has quit [Ping timeout: 250 seconds]
rob_w has joined #beagle
troth has joined #beagle
samnob_ has joined #beagle
samnob has quit [Ping timeout: 268 seconds]
florian has joined #beagle
samnob_ has quit [Ping timeout: 256 seconds]
samnob has joined #beagle
set_ has quit [Remote host closed the connection]
pbrobinson has quit [Ping timeout: 268 seconds]
vitorio has quit [Ping timeout: 264 seconds]
vitorio has joined #beagle
moto-timo has quit [Ping timeout: 268 seconds]
pbrobinson has joined #beagle
drewfustini has quit [Ping timeout: 268 seconds]
drewfustini has joined #beagle
moto-timo has joined #beagle
rob_w has quit [Ping timeout: 260 seconds]
vigneshr has quit [Ping timeout: 256 seconds]
vigneshr has joined #beagle
rob_w has joined #beagle
Posterdati has quit [Ping timeout: 268 seconds]
Posterdati has joined #beagle
markand has joined #beagle
<markand>
hi there
<markand>
I have a beaglebone black where usb0 does not show up (even though enabled in /etc/network/interfaces)
<markand>
oh looks like g_ether is required in /etc/modules
rob_w has quit [Remote host closed the connection]
buzzmarshall has joined #beagle
florian has quit [Quit: Ex-Chat]
vagrantc has joined #beagle
lucascastro has quit [Ping timeout: 256 seconds]
<zmatt>
markand: normally g_ether should not be in /etc/modules nor should usb0 be configured in /etc/network/interfaces ... doing either of those things will cause failures in the normal way usb0 is setup on beagleboard.org images
<zmatt>
normally generic-board-startup.service runs /opt/scripts/boot/generic-startup.sh which runs /opt/scripts/boot/am335x_evm.sh which sets up the composite usb gadget based on configuration variables in /etc/default/bb-boot
<zmatt>
/etc/network/interfaces should normally not be touched on a beagleboard.org image since connman is used as network manager (except for the usb interfaces, which are setup as mentioned above)
<zmatt>
I'm not sure why ifupdown is even installed, normally it makes no sense to have multiple network managers installed at the same time
lucascastro has joined #beagle
Shadyman has joined #beagle
waldo323_ has joined #beagle
waldo323 has quit [Ping timeout: 265 seconds]
nparafe has joined #beagle
GenTooMan has quit [Ping timeout: 264 seconds]
GenTooMan has joined #beagle
vd has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
vd has quit [Quit: Client closed]
vd has joined #beagle
ikarso has joined #beagle
set_ has joined #beagle
dkaiser has joined #beagle
<markand>
zmatt, nothing is normal at $JOB x)
<markand>
they use very *VERY* deprecated images
<GenTooMan>
hmm that can be problematic
bradfa has quit []
lucascastro has quit [Remote host closed the connection]
<markand>
it is, but that's life when you already have hundreds of those running in the wild
<markand>
especially since the last dev left the company leaving his crap all over the place
<markand>
not mentioning his terrible code
vd has quit [Quit: Client closed]
vd has joined #beagle
set_ has quit [Ping timeout: 256 seconds]
giort has joined #beagle
<giort>
Hello! Is there a way to create a PRU -> ARM exception with the BBB using C, without polling (or other blocking methods)? I've found this in the py-uio driver using asyncio, but is this possible with C as well?
<zmatt>
giort: yes, when using uio interrupts are delivered via a file descriptor
<zmatt>
markand: well in that case your question should begin with "I have a custom image where.." instead of "I have a beaglebone black where..." :P
<zmatt>
giort: the old crusty libprussdrv has functionality for it, although you could also use py-uio to do initialization and then pass the relevant file descriptor from python to a C executable... I've been meaning to make an example for that but haven't gotten around to it yet
mattb0ne has joined #beagle
<giort>
zmatt: and using C, how do I "get" the interrupt event from the file descriptor? By reading a specific bit/flag periodically?
set_ has joined #beagle
<mattb0ne>
zmatt: i got that nwtork issue resolved
<mattb0ne>
the issue was network manager was not managing the connections conman was
<mattb0ne>
and for some reason conman was not working well with the beaglebone
<zmatt>
mattb0ne: none of what you said makes sense
<zmatt>
giort: the interrupt makes the file descriptor readable (so you can use any event handling mechanism you want, similar to how you'd asynchronously receive data from a socket) and you read an uint32_t from it (and discard it). you also then need to reenable the interrupt output in the pruss intc. lemme see if I can quickly hack an example for this since I've wanted one anyway
<giort>
zmatt: that would be great!
ayjay_t has joined #beagle
lucascastro has joined #beagle
ayjay_t has quit [Client Quit]
set_ has quit [Remote host closed the connection]
ayjay_t has joined #beagle
<mattb0ne>
having stuff in interfaces file caused network manager not to work
<mattb0ne>
it was there by default
<mattb0ne>
anyways just passing that along
<mattb0ne>
I do have a question for you
<mattb0ne>
do you understand the difference between write and writelines in streamwriter
<zmatt>
if you define an interface in /etc/network/interfaces then network manager will not touch that interface
<zmatt>
but why did you mention connman? (which is not installed on any normal debian system)
<mattb0ne>
i guess it is now in debian 11
<zmatt>
no, it's not
<zmatt>
what on earth makes you think it is?
<mattb0ne>
ok
<mattb0ne>
the debian people
<zmatt>
??
<mattb0ne>
debian irc channgel
<zmatt>
they probably misunderstood you because you were talking about beaglebones
<mattb0ne>
oh
<zmatt>
that would be my guess
<mattb0ne>
well I needed to clear out that interfaces file
<mattb0ne>
now everything works
<zmatt>
yes but that interfaces file has nothing to do with connman
<mattb0ne>
oh
<zmatt>
/etc/network/interfaces is the config file of ifupdown
<mattb0ne>
so oh
<mattb0ne>
well I like network manager better than ifupdown
<zmatt>
I can't think of a reason you'd want to use ifupdown
<mattb0ne>
well they had that in there by default
<zmatt>
it had config for eth0 in there? on a desktop debian install?
<mattb0ne>
now I know to check that
<mattb0ne>
yes
<zmatt>
that sounds very odd to me
<mattb0ne>
i mean it was a guided install only so much I can mess up
<mattb0ne>
anyways I have a problem with streamwriter.write not sending all my data for a 1 time transmission
<mattb0ne>
I was thinking of switiching to writelines but that gives an error
<zmatt>
writelines appears weird and badly names
<mattb0ne>
yeah
<mattb0ne>
I cannot find any examples
<mattb0ne>
is there a way I can get write to not close prematurely
<zmatt>
stream.writelines(data) is equivalent to stream.write( b''.join(data) )