<rcn-ee>
August snapshots are now up... https://forum.beagleboard.org/tag/latest-images (BBAI-64 had a late fix, those massive files are uploading in the same directory, i'll update the forum page tomorrow..)
<set_>
Nice!
brook has quit [Remote host closed the connection]
akaWolf has quit [Ping timeout: 240 seconds]
brook has joined #beagle
akaWolf has joined #beagle
vagrantc has joined #beagle
vagrantc has quit [Quit: leaving]
GenTooMan has quit [Ping timeout: 255 seconds]
noahm_ is now known as noahm
marcheu_ is now known as marcheu
starblue has quit [Quit: WeeChat 3.0]
samael has joined #beagle
ikarso has joined #beagle
otisolsen70 has joined #beagle
Shadyman has quit [Remote host closed the connection]
samael has quit [Ping timeout: 240 seconds]
buckket has quit [Quit: buckket]
buckket has joined #beagle
GenTooMan has joined #beagle
samael has joined #beagle
lucascastro has joined #beagle
Guest97 has joined #beagle
Guest97 has quit [Client Quit]
xet7 has quit [Remote host closed the connection]
buzzmarshall has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
Posterdati has quit [Read error: Connection reset by peer]
brook has quit [Ping timeout: 240 seconds]
Posterdati has joined #beagle
brook has joined #beagle
vagrantc has joined #beagle
lucascastro has quit [Quit: Leaving]
ikarso has quit [Quit: Connection closed for inactivity]
brook has quit [Remote host closed the connection]
brook has joined #beagle
samael has quit [Ping timeout: 268 seconds]
lucascastro has joined #beagle
brook has quit [Remote host closed the connection]
starblue has joined #beagle
lucas_ has joined #beagle
lucascastro has quit [Ping timeout: 252 seconds]
otisolsen70 has quit [Quit: Leaving]
brook has joined #beagle
brook has quit [Remote host closed the connection]
Guest4494 has joined #beagle
<Guest4494>
Can I used a 5v battery connected to the BBB's USB port (P4 I think) to powerup the BBB which would then trigger a relay that would supply power to the BBB via the barrel connector?
<Guest4494>
I.e., what happens if I connect two power sources to the BBB?
brook has joined #beagle
lucas_ has quit [Quit: Leaving]
lucascastro has joined #beagle
TuoDrable has joined #beagle
xet7 has joined #beagle
ikarso has joined #beagle
<jfsimon1981_b>
Hi
<jfsimon1981_b>
It's about 400 mA consumption
<jfsimon1981_b>
You could provided you regulate properly, there's no 5V battery, go for 5V +/- 5% approximately.
<jfsimon1981_b>
So you probably need a regulator, which is battery type ?
<zmatt>
Guest4494: usb and the 5v barrel jack are independent power inputs for the BBB, it will switch between them automatically
<zmatt>
jfsimon1981_b: given we're talking about usb here, presumably they mean a usb battery pack (with regulated 5v output)
<Guest4494>
zmatt, does the barrel have higher priority?
<zmatt>
not sure, although it's possible to force the selection using software
<Guest4494>
jfsimon1981_b, yes. The BBB controls a device that will provide power to the BBB, but not until the BBB closes a switch on the device.
<zmatt>
Guest4494: what's the goal of this arrangement?
<Guest4494>
So, my thought was use a 5v USB battery to start the BBB which would then toggle the device on which could then power the BBB, so the battery is only needed for the first minute or so.
<jfsimon1981_b>
Yes got it
<Guest4494>
The BBB is controlling an inverter in a temperature-hostile environment. We'll have some temp sensors also attached to the BBB. The inverter will power the BBB most of the time, but chicken & egg problem, it can't do so until the BBB has toggled the inverter on. So, I thought we'd start the BBB via battery, and then the BBB could switch to
<Guest4494>
the barrel jack power once the inverter is turned on by the BBB.
<Guest4494>
This way the battery only has to power the BBB for the first minute or two.
<Guest4494>
The question is once there's power on the barrel jack, will the BBB cease drawing power on the USB connector?
<zmatt>
and presumably also if a situation requires the BBB to shut off the inverter?
<zmatt>
(since if no such situation exists you wouldn't be having the BBB control it)
<Guest4494>
zmatt, yes, although in that scenario we anticipate intervention, too, (the BBB will send alerts via ethernet).
<zmatt>
it's possible to disable/enable the usb power input in the pmic through i2c writes, so you could disable it once you've turned on the relay and confirmed power via the barrel input is stable, and conversely you'd reenable usb power prior to disabling the inverter relay
<Guest4494>
Right. But I'm wondering if the BBB does that automatically, i.e., switch between power sources (?).
<zmatt>
the pmic will switch automatically but it's a bit vague based on what it will switch
<zmatt>
so I probably wouldn't rely on that
<Guest4494>
Ah, uncertainty! Just what we want. ;-)
<Guest4494>
Yes, if I can/must control it myself directly, that's fine. Just wasn't sure what the BBB needed.
<zmatt>
that would be the best way to ensure it won't drain the battery while the inverter is on
<zmatt>
there isn't even a status bit that shows from which of the two inputs it's drawing power, it only has a status bit for each of the two inputs showing whether power is available on that input
<Guest4494>
But I can explicitly tell it which input to use, right? IOW, I can give it direction but not ask it any questions?
<zmatt>
you can disable one of the inputs, thus forcing it to use the other one
<zmatt>
i2cget -f -y 0 0x24 0x01 shows 0x3f by default, which means both inputs are enabled
<zmatt>
i2cset -f -y 0 0x24 0x01 0x2f would disable the usb power input
<zmatt>
i2cset -f -y 0 0x24 0x01 0x3f reenables the usb power input
<Guest4494>
How do I determine if power on the barrel input is there/stable yet?
<Guest4494>
I could just wait x minutes but that seems to assume a lot.
<zmatt>
i2cget -f -y 0 0x24 0x0a bit 2 indicates usb power is present and stable, bit 3 indicates power is present and stable on the barrel jack
<zmatt>
(bit 7 is always set, bit 0 indicates whether the power button is currently pressed, the remaining bits are unused)
<Guest4494>
Does bit 0 remain on (1) once the power button is pressed, i.e., while it's powering down?
<zmatt>
bit 0 just shows the current status of the button, i.e. whether it's currently being pressed or not
<Guest4494>
Ok, that's fine. Shouldn't really need that (but good to know).
<zmatt>
the kernel driver also gets an interrupt when the button is pressed and generates a KEY_POWER event which, depending on configuration, may trigger systemd to perform a poweroff
<zmatt>
(or some other action)
<zmatt>
(and long-pressing the button causes the pmic itself to perform either a hard power-cycle or a hard power-off... it's supposed to be a power-cycle but due to the braindead design of the pmic it may end up doing a power-off instead, depending on how much current is being drawn at the moment it's doing this)
TuoDrable has quit [Quit: Leaving]
<Guest4494>
This will be mostly unattended, so there shouldn't be too many people around pushing buttons on the BBB.
<Guest4494>
Thanks for the help.
<zmatt>
you're welcome
Shadyman has joined #beagle
Guest4494 has quit [Ping timeout: 252 seconds]
DrPatater has quit [Ping timeout: 240 seconds]
Guest3742 has joined #beagle
<Guest3742>
I have been using BeagleBone Black Wireless and due to the lead times of 4+ months (currently Nov-Dec 2022), I am being forced to use BeagleBone Black (non-wireless). Our programming is hard coded to use GPIO_120 and GPIO_122 (Pins 30 and 31) on the P9 header. Is there an equivalent pair of pins that I can use on standard BeagleBone without
<Guest3742>
changing the code?
<zmatt>
uhh what, the black and black-wireless are completely equivalent in terms of their expansion headers
<zmatt>
those are not the gpio numbers of those pins though
<zmatt>
the only difference between the black and the black-wireless is that one has ethernet while the other has wifi and bluetooth
<zmatt>
and the wireless uses a micro-usb connector instead of mini-usb
<zmatt>
if I remember correctly
<Guest3742>
ok, when I checked the pin out diagrams, I found a different one from what was given to me by our dev team, so that's what is confusing to me
<zmatt>
the P9 and P8 expansion headers are completely identical
<zmatt>
like, 100% identical for all of the pins on those headers
<Guest3742>
I will check if I can get a link
<zmatt>
for a detailed overview of the expansion headers on the black/black-wireless, see the P9/P8 tabs of my spreadsheet: https://goo.gl/Jkcg0w#gid=1775283126
<Guest3742>
I am using a sparkfun Lumini 8x8 matrix, so Vdd and Ground are straightforward, I have been told to use GPIO_120 and GPIO_122 for DI and CI
<Guest3742>
These are pins 31 and 30 on BBBW, so I was expecting those to work the same for BBB
<zmatt>
those numbers are wrong (for both the BBB and BBBW)
<Guest3742>
Dang! :-)
<zmatt>
P9.30 is gpio 3.16, i.e. 3*32+16 = 112
<zmatt>
P9.31 os gpio 3.14, i.e. 3*32+14 = 110
<Guest3742>
ok that makes sense! Pin 30 on the BBB is listed as GPIO_112
<zmatt>
you can find the correct gpio numbers in my spreadsheet I linked earlier (which uses the X.YY numbering scheme where X is the gpio controller number and YY the gpio number of that controller)
<zmatt>
for the contiguous gpio numbers used by the kernel use X*32+YY
<zmatt>
or here's a list of named symlinks created for the gpios using a simple udev rule: https://pastebin.com/R5pP0jSQ
<Guest3742>
Ok, I think it's working fine! thank you for responding to me. I was worried that I will fry a precious board or something trying the original configuration based on the info that BBB and BBBW are separate! You literally saved me weeks worth of running around, my man! Thank you so much!!!
<zmatt>
(with such a udev rule in place you can entirely avoid having to know or care about gpio numbers)
<zmatt>
yeah no worried, BBB and BBBW are completely interchangeable w.r.t. their expansion headers
<zmatt>
(but beware that this is _not_ the case for the BeagleBone Green Wireless!)
<Guest3742>
Does the BeagleBone Industrial also interchangeable with the BBB and BBBW?
<zmatt>
yes
<Guest3742>
ok that's awesome, we deploy in Northern Alberta and in the Middle East, so hopefully will start using those when they come back in stock
<zmatt>
the Industrial just uses parts that are rated to tolerate sub-freezing temperatures
<zmatt>
but is otherwise the same
<Guest3742>
Thanks! have a great day!
xet7 has quit [Remote host closed the connection]
<Guest3742>
Sorry, I forgot to ask regarding BeagleBone AI, does that have the same interfaces as BBB and BBBW? I would love to use it instead of BBB/BBBW since it has 16 GB of storage. By the time I install updates on the BBB and BBBW, the 4 GB is nearly used up
<zmatt>
the AI is a completely different device with a different SoC (and the AI-64 is yet again a different SoC)
<zmatt>
if you run out of 4GB... try having less crap installed ;)
<Guest3742>
ha ha ha! Touche! I don't have ANY crap install, but I am usually required to update the OS image to 9.13 which is not possible with the onboard storage. So I put in a 32 GB Sandisk extreme card but I have had failures of those too at times.
<zmatt>
*update* to 9.13 ? debian 9 is ancient and obsolete
<Guest3742>
Yeah, I know, but we have some restrictions which I am battling
<Guest3742>
AM3358 Debian 10.3 2020-04-06 4GB SD IoT is that the latest stable image?
<Guest3742>
I would love to install one image which will leave about 500 MB of space out of the 4 GB so that I don't have to use an SD card
<zmatt>
yeah, but there are also minimal images available if you don't want all the crap that's preinstalled on the IoT images and are comfortable with just installing the packages you want/need yourself
<zmatt>
the image you just listed leaves way more free space than that I'm pretty sure
<zmatt>
while minimal images leave more than 3G of free space
<Guest3742>
ok thanks! So I am installing in a production environment in very remote locations only manned by construction workers usually and no IT support other than me supporting remotely. We don't make any changes for a couple of years once deployed. Will it be ok to install the testing images or is it just a risk that we have to weigh?
DrPatater has joined #beagle
<zmatt>
I mean, you should properly test your final system (including your own software) anyway
<zmatt>
if you want a more thoroughly tested kernel you could downgrade to the 4.19-ti kernel series
<zmatt>
debian bullseye itself is a stable release of debian
Patater has quit [Ping timeout: 252 seconds]
<Guest3742>
ok thanks! Your inputs have been very valuable!