<dkaiser>
during the debian installation, I remember be offered both ti_cpsw and ti_cpsw_new
<vagrantc>
oh
<dkaiser>
In the "no network interface found" dialog, I tried selecting each of these (individually) and the installer could not successfully find the network card.
<zmatt>
rcn-ee: has the davinci_mdio_update_dt_from_phymask() hack been updated to match the new cpsw yet?
<rcn-ee>
zmatt, nope...
<vagrantc>
it's got ti_cpsw_switchdev enabled as a module
<zmatt>
rcn-ee: then again it sounds like they're testing mainline kernels so they're missing that fix anyway
<rcn-ee>
zmatt, in theory, with a mainline u-boot, it should be fixed...
<vagrantc>
yeah these are debian kernels, pretty much mainline
<zmatt>
has u-boot been updated to support the new cpsw structure?
<rcn-ee>
(aka u-boot updates the device-tree..
<rcn-ee>
but i'm 0/2 with bbb's coming up with eth0....
<zmatt>
hey guys, remember when the rhetoric from kernel devs was that DT is supposed to represent the hardware, not OS-specific stuff like drivers? ;)
<vagrantc>
i've tested with u-boot 2021.10 and 2021.01
<rcn-ee>
zmatt, yeah they lied..
<vagrantc>
i could also probably test 2022.01~rc4 once it is done baking
<vagrantc>
rcn-ee: which version of u-boot, or is that a dead end ?
<rcn-ee>
vagrantc, so i'm on 2020.10
<rcn-ee>
i really have one main patch... assume everything is BBB... (i'm not really supporting ethernet in u-boot anymore..)
<rcn-ee>
correction... 2021.10
<dkaiser>
Does it seem clear that to you all that the current debian build cannot be fixed to support the BBB ethernet device (i.e., without a kernel rebuild)?
<rcn-ee>
okay, 0/3 on cpsw with v5.15.x my only board that works in the Green Gateway, but that has a musb bases smsc95xx
<rcn-ee>
dkaiser, mainline changed something on AM335x to support a new driver, and broke it for AM335x...
<vagrantc>
dkaiser: seems you've found a rather pesky problem
<vagrantc>
i can't recall if i had it working on earlier 5.10.x kernels
<CoffeeBreakfast>
zmatt: who needs ethernet when you can put your telephone handset on top of an acoustic coupler
<dkaiser>
we can go back to passing around punch cards (or tape)
<vagrantc>
can't find my coupler, or a landline, time to get ham cdertified
<dkaiser>
I've also tried two USB devices (1 wired, 1 wifi) and they both fail to load...
<vagrantc>
rcn-ee: that commit appears to only be in 5.15.x and wasn't backported to 5.10 as far as i can tell "ARM: dts: am335x-bone: switch to new cpsw switch drv" c477358e66a3a6db4f1799b7415068d6660c95c3
buzzmarshall has quit [Quit: Konversation terminated!]
vagrantc has quit [Quit: leaving]
<dkaiser>
rcn-ee: based on vagrantc's last comment here, do you still think that reverting the commit will fix the problem?
<zmatt>
I just realized, -517 is not an actual error, it's EPROBE_DEFER
<zmatt>
which happens when a device gets probed before some other devices it references are probed, so EPROBE_DEFER means the driver asks the kernel to try probing it again later
<zmatt>
so a single -517 from a driver in the kernel log typically means it got successfully probed on the next attempt
<zmatt>
(most drivers explicitly avoid printing any message on EPROBE_DEFER)
<dkaiser>
rcn-ee: I dtc'd am335x-boneblack.dtb into am335x-boneblack.dts and it looks like this file is prior to the commit that you reference above.
<dkaiser>
rcn-ee: Any other suggestions for fixing the current installation?
<zmatt>
I've successfully run a 5.10 kernel on my bbb
<zmatt>
so whatever is causing problems must be some difference between mainline 5.10 and rcn's 5.10-ti kernel (specifically the kernel I've run is 5.10.65-ti-r23)
<zmatt>
at least I assume it ran successfully, I still have it installed on the bbb and don't remember a failure (and I'd surely have removed it immediately if it didn't boot or didn't have ethernet)
<Guest31>
Is this the right place to ask about beaglebone?
<zmatt>
Guest31: sure
<zmatt>
dkaiser: there's no metapackage for "latest 5.10-ti kernel" or such though, you need to explicitly install the specific kernel package you want
<Guest31>
I was facing a issue while compiling the blinkInternalLED.pru0.c using gcc, located at /var/lib/cloud9/PocketBeagle/pru
<Guest31>
It is giving the err, pru_cfg.h file not found
<Guest31>
I searched about this issue but could not find anything significant of my help
<zmatt>
Guest31: heh, looks like these makefiles are extremely crufty
<Guest31>
zmatt in the makefile provided there, there's just one line of code
<zmatt>
looks like "make TARGET=blinkInternalLED.pru0" does work.... but EW it doesn't merely build the executable but also immediately runs it, who thought that was a good idea
<Guest31>
thanks that works
<Guest31>
I had seen that thing prev, but I forgot '=D
<zmatt>
oh it doesn't merely run it but also installs it such that it'll get run again at boot, wtf
<zmatt>
I was a happier person before knowing this makefile existed, lol
<Guest31>
really?
<zmatt>
I'm joking, but this makefile *is* kinda gross
<Guest31>
...
<Guest31>
bitflip.pru0.c doesn't runs though
<zmatt>
like, when you type "make" you expect it to build the various executables, not do nothing unless you specify a build target through some environment variable, and then proceed to implicitly install and execute that target
<Guest31>
if you follow same suite
<Guest31>
zmatt yes exactly
<Guest31>
oh sorry bitflip works
<Guest31>
so if any pru is working it won't be shown in htop/top right? neither it will be shown as a system job
<zmatt>
no, it runs completely independent of linux
<Guest31>
can we run a RTOS there? something like freeRTOS?
<zmatt>
it has 8KB of program memory per core
<zmatt>
2048 instructions
<zmatt>
generally speaking you'd just run a dedicated program, not attempt to run an OS
<zmatt>
it also doesn't have interrupts
<Guest31>
so, there is no button interrupt example for this?
<zmatt>
(it does have an interrupt controller, but its outputs just go to two status bits in r31 that software can test if it wants to)
<zmatt>
it has no interrupts therefore no there cannot exist an interrupt example
<Guest31>
so what is its use? I mean practically where can we use this?
<zmatt>
anything that has strict real-time needs and isn't too complicated, especially things like custom I/O protocols
<zmatt>
its extremely simple and determinstic instruction timing along with having dedicated gpio wired directly into registers allows for generating signals with single-cycle (5ns) accuracy
<Guest31>
so can it access any of the SoC's peripherals? like timers, counters and so
<zmatt>
"beaglelogic" uses pruss to turn a beaglebone into a 12-channel 100Msps logic analyzer, with one pru core sampling its inputs every other cycle and the other pru core writing it out to a ringbuffer in ddr3 ram
<zmatt>
yes pru can access everything
<zmatt>
pruss also has local peripherals for timers, you'll want to use those in preference to the SoC ones
<Guest31>
so like can we make a kernel module which can access the PRUs and make it do things?
<zmatt>
I guess? I've only ever worked with it from userspace (via uio rather than remoteproc)
<zmatt>
we currently use pru to get accurate audio timestamps, since the timestamps from alsa are utter trash
<zmatt>
people also use pru to drive large led matrices
<Guest31>
that project is very well documented
<Guest31>
thanks for that
rob_w has joined #beagle
<dkaiser>
zmatt: Anything more I can do to assist in testing/troubleshooting the BBB ethernet issue?
<zmatt>
Guest31: py-uio? surely you're joking, it (regrettably) has almost no documentation... it's still kinda on my to-do list
<Guest31>
Atleast there's a good readme
<Guest31>
that's enough
<Guest31>
zmatt can you explain the concept of far pointer with regards to your program
<zmatt>
most examples are in assembly since PRU was really designed to be programmed in that rather than C... a C compiler was eventually created (many years after pru was introduced) but pru's instruction set really isn't well-matched to being targeted by a C compiler and the code output quality is... mediocre
<Guest31>
I saw one in test.c
<zmatt>
marking the variable as "far" causes it to be placed in a different section (.fardata/.farbss/.rofardata rather than .data/.bss/.rodata), and the linker script will place that in a different memory (the pruss "shared" memory at 0x10000 - 0x12fff rather than the core's local memory at 0x0000 - 0x1fff in the core's memory view)
bzyx has quit [Ping timeout: 256 seconds]
bzyx has joined #beagle
<zmatt>
generally speaking "far" and "near" also applies to pointers where "near" means the pointer can be represented in 16 bits by virtue of the thing being pointed to being within a specific data region, I haven't actually checked if that's also the care for clpru
<zmatt>
i.e. far pointers can point to any memory while near pointers can only point to near variables (which is the default unless explicitly marked as "far")
Guest31 has quit [Ping timeout: 256 seconds]
<zmatt>
I don't think clpru supports near pointers
<dkaiser>
zmatt: Thanks again for all your help. Please let me know if there is something more I can do to help with testing...
<zmatt>
yeah it doesn't support applying far/near to pointers, only to variables
<zmatt>
dkaiser: not really anything I can think of... if you want a quick fix, install a known-working kernel
CoffeeBreakfast has quit [Quit: Client closed]
dkaiser has quit [Quit: Leaving]
<Daulity>
zmatt: I had CONFIG_DEBUG_AM33XXUART=y but it was still wrong, the reason to use earlyprintk was because i had that working earlier but I will look into earlycon soon (i hope).
<Daulity>
zmatt: i need them because I had a situation where there the kernel crashed before serial was up and running :)
<zmatt>
Daulity: CONFIG_DEBUG_AM33XXUART only sets the default for the physaddr/virtaddr, so if you already have it wrong your config then setting the right default with CONFIG_DEBUG_AM33XXUART=y no longer helps
<Daulity>
oh
<Daulity>
then i do not know where the wrong defaults came from
<zmatt>
at least that's what the Kconfig looks like to me
<Daulity>
my config is based on an older config though and it might have been wrongly configured in the past and migrated to the new config in some way
<Daulity>
that is still something i really want to do start from scratch with the config because I have ran against this kind of thing before.
ikarso has joined #beagle
florian has joined #beagle
Shadyman has quit [Remote host closed the connection]
RossSchulman[m] has quit [Quit: You have been kicked for being idle]
Guest31 has joined #beagle
<Guest31>
how do chats happen here?
<Guest31>
If you get disconnected, your chats are gone
frostsnow has quit [Ping timeout: 256 seconds]
frostsnow has joined #beagle
Guest56 has joined #beagle
<Guest56>
hi
<Guest31>
hello
<Guest56>
how are you
<Guest56>
can u help me i have problem
<Guest56>
with beaglebone black
<Guest31>
sure, if I can
<Guest56>
i try to login beaglebone
<Guest56>
through it's ip
<Guest56>
(192.168.7.2)
<Guest56>
i tried the default authencation
<Guest56>
but
<Guest56>
give me invaild
<Guest56>
so what should i do
<Guest56>
??
<Guest56>
it connect but didn't allow me to
<Guest56>
login
<Guest31>
are you doing a ssh to the board or using cloud9?
<Guest56>
ssh to board
<Guest56>
through putty
<Guest31>
u need to ssh to debian@192.168.7.2
<Guest31>
and give pass temppwd
<Guest56>
i tried this solution
<Guest56>
but it didn't help
<Guest31>
whats the err you are getting?
<Guest31>
or you are simply unable to login?
<Guest56>
password is incorrect
<Guest56>
how to reset it
<Guest56>
to default
<Guest31>
pass is temppwd
<Guest31>
if none works, flash a new image
<Guest56>
may be the one used this board before me changed it
<Guest56>
so how i reset it
<Guest56>
??
<Guest31>
If you can't login, u can't reset
<Guest56>
flash new image i'm new to embedded linux
<Guest31>
oh, same here
<Guest56>
so may be this solution is big deal for me
<Guest56>
how to reset it
<Guest56>
?
<Guest31>
well, I would have given direct solution
<Guest31>
but I insist you search a bit
<Guest56>
did u try to reset it
<Guest31>
on how to flash a new image onto your board
<Guest56>
i searched before
<Guest56>
some say the solution is to rset
<Guest56>
reset it
<Guest31>
yea reset it
<Guest31>
and search how to do that
<Guest56>
i come here to ask professional people who tried this solution before
<Guest56>
can i have your email or anything to communicate with u if i faced any issue
<Guest31>
am not any offcial guy here
<Guest31>
I joined today
<Guest31>
anyone here tried to use JTAG with the board?
<Guest56>
no problem just give me any way to connect u if i faced any problem
<Guest56>
?
vd33 has quit [Ping timeout: 256 seconds]
<Guest31>
u use telegram?
<zmatt>
Guest31: most people use irc clients other than the web client, which typically maintain scrollback, and there are also public logs here: https://libera.irclog.whitequark.org/beagle/
<zmatt>
btw you can change your name to something other than Guest-something using the /nick command (e.g. "/nick desirednamehere"), as long as it's not yet in use (on this irc network)
Guest31 is now known as ark_38
<ark_38>
yeah
<zmatt>
I have an old beaglebone with jtag header soldered on that I used for some baremetal experiments, but generally speaking there's very rarely any reason for people to use jtag
<zmatt>
on the beaglebone
<ark_38>
I also don't have a good reason
<ark_38>
just wanna do
<zmatt>
also, that link is really really old
<zmatt>
they're talking about Angstrom
<ark_38>
somewhere they might have mentioned debian
<ark_38>
all u need to do is uncomment a line, that's all
<zmatt>
the instructions are wrong too, the S2 button (boot button, which they call "user button") usually isn't needed at all, and if you do use it you can let go once the power led turns on, there's absolutely no reason to hold it until all 4 leds light up let alone for seconds longer
<zmatt>
that part is no longer necessary either, you can just download a pre-made flasher image from the "Flasher Debian images" section of https://beagleboard.org/latest-images
<zmatt>
flash onto SD card (preferably using Balena Etcher, except version 1.7.1 where they broke shit) and boot from it, and it'll automatically proceed to reflash eMMC
<ark_38>
oh, so that's why its called flasher, cause it's instantaneous
<zmatt>
no it's called a flasher because it flashes to eMMC
<ark_38>
yea, I meant that ... like instantaneouls flashes without any commenting or anything
<zmatt>
the only difference is still that line in /boot/uEnv.txt, downloading the flasher image just saves you from having to manually modify a standalone image into a flasher
<zmatt>
btw, assuming that was the same Guest31, you asked about near vs far earlier... here's more (some might say excessive) details, including how it affects performance: https://pastebin.com/CU1zCM9V
<ark_38>
yea I read that
<ark_38>
from the logs
<zmatt>
this has more details though
<zmatt>
possibly more than needed, but I thought I'd share
<ark_38>
thanks for that
<ark_38>
Any good reference from where to learn these C attributes?
<zmatt>
in the py-uio code I just use "far" to put variables into shared memory
<zmatt>
(though technically any core can access any of the memories)
florian has quit [Quit: Ex-Chat]
ikarso has quit [Quit: Connection closed for inactivity]
<ark_38>
so you read that entire doc?
<jrmu>
btw, thanks to the beaglebone team, I'm super happy with my beaglebone
<jrmu>
openbsd is running nicely
<ark_38>
I tried arch
<ark_38>
failed even to boot
<jrmu>
I've never tried arch but openbsd works on beaglebone black rev c
ark_38 has quit [Ping timeout: 256 seconds]
<Guest56>
ya
<Guest56>
i have one
<Guest56>
+201289085503
Guest56 has quit [Quit: Client closed]
Mahmoud has joined #beagle
Guest56 has joined #beagle
Guest56 has quit [Client Quit]
Mahmoud has quit [Client Quit]
Mahmoud has joined #beagle
<Mahmoud>
hi every one
<Mahmoud>
??
<Mahmoud>
??
<Mahmoud>
?
<jrmu>
hi Mahmoud
<Mahmoud>
if i have any question what's average time of response
<Mahmoud>
??
<Mahmoud>
cause most of time i stick with problems
<Mahmoud>
?
<Mahmoud>
stuck*
<Mahmoud>
?
<Mahmoud>
?????
ikarso has joined #beagle
<jrmu>
Mahmoud: the developers/staff here seem very friendly
<jrmu>
IRC often requires you wait a few minutes, sometimes a few hours, but they will reply
<jrmu>
they may be asleep right now
<jrmu>
but they will answer you if you wait
<Mahmoud>
okay thank you
<Mahmoud>
thank you very much
<jrmu>
they answered me about 3 hrs ago
thinkfat_ has joined #beagle
CoffeeBreakfast has joined #beagle
Guest31 has joined #beagle
Guest31 is now known as ArK_38
Mahmoud has quit [Quit: Client closed]
thinkfat_ has quit [Ping timeout: 250 seconds]
florian has joined #beagle
ArK_38 has quit [Ping timeout: 256 seconds]
Guest31 has joined #beagle
<Guest31>
hi
ark has joined #beagle
<ark>
hi
<ark>
okay so now its working
<ark>
I was just testing out irssi on cli
<Guest31>
and we are same guy
Guest31 has quit [Client Quit]
<ark>
clear
ark has quit [Client Quit]
ark has joined #beagle
<ark>
clear
ark has quit [Quit: leaving]
thinkfat_ has joined #beagle
Guest18 has joined #beagle
Angel_Sosa has joined #beagle
<Angel_Sosa>
Hello I have been doing development on the BeagleBoard X15 and just started to work on the BoneScript in regards to GPIO programming ususage, Is there any documentation out that shoes how the expansion headers map to bone script? I ahve been trying for days and all that comes are details for the Beaglebone Black
Daulity has quit [Quit: leaving]
thinkfat_ has quit [Ping timeout: 240 seconds]
florian has quit [Quit: Ex-Chat]
<rcn-ee>
Angel_Sosa, Bonescript is not maintained, just use sysfs..
<rcn-ee>
vagrantc, and found a third regression on v5.15.10... atleast ethernet is fixed, stil trying to fix a usb issue.. but now i have a fun lockup! ;)
<dkaiser>
What is the process for these changes making it into mainline and the "standard" debian builds?
<rcn-ee>
dkaiser, rcn-ee and vagrantc talk, vagrantc sends email to debian kernel team. ;)
<vagrantc>
someone emails patches to appropriate kernel lists and deals with issues raised ... and then gets them backported to older kernels
<vagrantc>
hah
<dkaiser>
vagrantc and rcn-ee, how reasonable is it to expect that the debian builds "just work" on BBB? Or, should one generally use a build based on rcn-ee repositories?
<vagrantc>
dkaiser: they used to work fine, so anytthing that doesn't work is generally a bug that needs to be fixed
<vagrantc>
the beagleboneblack is what got me neck-deep in arm stuff, for better or worse :)
<vagrantc>
i was maybe only in to my ankles or knees up till then ...
<rcn-ee>
dkaiser, it only broke as someone decided to write a new cpsw driver, and none of use really nocticed..
<dkaiser>
vagrantc, I may end up deeper than I had anticipated...
<rcn-ee>
dkaiser, normally, am335x is at a point, everything is really mainline, so it should just work... unless someone decides to rewrite something, and we don't properly handle the transition.. Normally am335x is kinda boring every merge cycle. ;)
<dkaiser>
originally, I had not planned to start studying the sources for the kernel network stack...
<vagrantc>
dkaiser: you might be able to install buster still, and then upgrade to bullseye using the older kernel
<vagrantc>
dkaiser: kind of ugly but if you don't want to fall down this particular rabbit hole...
<vagrantc>
or just use the beagleboard.org images...
* vagrantc
shrugs
<rcn-ee>
you should be able to install debian kernel on beagleboard.org images. ;)
<dkaiser>
My end goal is to be testing OpenCPN (maritime chart plotter + multiple functional plug-in modules) on various debian stable releases.
<dkaiser>
I had hoped that it was simply matter of downloading and installing ready made debian release images.
<dkaiser>
But, this is fun...?
<rcn-ee>
dkaiser, which version do you need, stretch, buster, bullseye, etc?
<dkaiser>
I wanted to start with bullseye, and then look backwards at least one release (maybe more, if it is not too much work...)
<vagrantc>
dkaiser: try with buster at this point, we'll get the other issues fixed eventually
<vagrantc>
dkaiser: i *hope* not, but would be good to findout
<dkaiser>
vagrantc, it might have just been earlier releases of bullseye, however. I don't remember for sure.
* vagrantc
checks
<rcn-ee>
dkaiser, was it my version? there was a lot of churn to convert from connmanctl -> systemd-networkd.. espically with usb0/usb1, that's been fixed now..
<dkaiser>
vagrantc, how are you set up to check so quickly?
set_ has quit [Ping timeout: 240 seconds]
<vagrantc>
ouch, buster kernel OOPSes
<dkaiser>
rcn-ee, no I was working with the "straight" debian builds
<vagrantc>
dkaiser: i have a machine plugged in with remote power cycling and serial console
<vagrantc>
dkaiser: and testing network booting from u-boot
<vagrantc>
only if i get a broken u-boot installed do i have to deal with the physical board directly :)
<vagrantc>
and a machine on the network that supports network booting off of stretch, buster, bullseye, and the daily debian-installer builds ...
<vagrantc>
or rather, a tftp server ...
<vagrantc>
it's been a while since i've tried, but never had any luck with mainline u-boot on the beaglebone-ai either ...
<vagrantc>
and havne't been running the beagle-x15 lately...
<vagrantc>
and fried my pocketbeagle a while back ...
* vagrantc
is not really doing a great job with the beagles
<rcn-ee>
i fried a prototype last week.. luckly have 2 more units... but disappointed wiht my self..
<dkaiser>
ouch
<zmatt>
it happens
<mattb0ne>
i am on board 7 if it makes you feel any better
<mattb0ne>
fortunately i do my BBB work late at night so people do not hear the yell when the computer lets out the chrip of death
<rcn-ee>
mattb0ne, ouch! i was close to that with BeagleBone Blue's.. Got one to smoke really nice..
<zmatt>
lol
<zmatt>
we got a whole stack of dead BBBs
<vagrantc>
they don't call them blue for no reason
<rcn-ee>
zmatt, you should re-sell the TPS's.. there's a nice market right now for them..
<zmatt>
rcn-ee: hah
<rcn-ee>
vagrantc, blue... darn usart0 doesn't have any protection... accsdently hit a key with on console over usb-ftdi.. = fried blue.. just takes one keystroke..
<vagrantc>
it's cheaper that way
<rcn-ee>
trick is to leave the battery plugged in all the time, only protection..
<zmatt>
the blue's power scheme also looks like an accident waiting to happen... e.g. the GPS header provides an always-on-5V supply for the GPS module, which also means that gps module wlil drive its uart output high even when the am335x is powered off
<vagrantc>
hah, this machine still has images leftover from debian jessie :)
<vagrantc>
dkaiser: fwiw, the stretch image appears to boot and detect network ... 4.9.x
<rcn-ee>
zmatt, i think the blue designer, wanted to sell boards endless..
<mattb0ne>
what would cause your swap to be used before memory
<mattb0ne>
my code keeps blowing up
vagrantc has quit [Quit: leaving]
<zmatt>
nothing, it just means your code ran out of memory hence the kernel started to use swap
<mattb0ne>
but my memory was at like 15% and increasing but swap is at 100%
<mattb0ne>
the program will go until OOM
<mattb0ne>
i guess there is something glaringly wrong with my code
<mattb0ne>
i put the camera on a thread
<zmatt>
then whatever you're using to determine those numbers is probably wrong
<mattb0ne>
i am releasing the image in the camera thread
<mattb0ne>
i am not even saving in this one
<mattb0ne>
i should trim hold on
<mattb0ne>
this is a calibration run
<mattb0ne>
which only displays the image in the qt form and does not interact with the BBB
<mattb0ne>
so my issue is just with how the camera works with asyncio I guess
<mattb0ne>
asyncio and QT
<zmatt>
first of all, probably unrelated to your memory leak but don't use queue.Queue to transfer images to your main event loop
<zmatt>
.get() on these queues will block your entire main event loop (i.e. all asyncio stuff and your GUI)
<mattb0ne>
ok
<mattb0ne>
i saw it as a way to getting the data out of the thread
<zmatt>
in general, any interaction between a thread and anything else requires a great deal of care
<mattb0ne>
how can I have it produce images to be consumed in my main thread
<zmatt>
blocking on the images produced by the thread makes the entire thread pointless
<mattb0ne>
true
<mattb0ne>
they have an asyncio queue
<mattb0ne>
i could use that
<zmatt>
nope
<mattb0ne>
ok
<mattb0ne>
lol
<zmatt>
can't use asyncio stuff from a thread
<mattb0ne>
grrr
<mattb0ne>
so how do I get the images out
<zmatt>
unless the function explicitly says you're allowed to
<mattb0ne>
also how do I reset my swap it is still full according to my system monitor even though I stopped my prgam
<mattb0ne>
program
<zmatt>
so, last time I asked what exactly you were doing with the images, you did not mention this part of it, you just said you wanted to save it together with data from the bbb
<zmatt>
memory from other applications that got swapped out will get swapped in again automatically when it's accessed
<zmatt>
no need to worry about it
CoffeeBreakfast has quit [Quit: Client closed]
<zmatt>
also, your queue doesn't have a size limit hence can grow without bounds, causing an OOM, if the consumer consumes images slower than the image producer is producing them
<zmatt>
also, "await asyncio.sleep(0) # required to allow GUI to update" ... no, that's just a side-effect of you blocking the entire event loop with image_queue.get()
<mattb0ne>
so i do not need it
<mattb0ne>
i can take out and I can specify a size on the queue but I am getting rid of it right ?
<zmatt>
you are yes
<mattb0ne>
what should I replace it with
<zmatt>
though I'm not sure what's the replacement
<mattb0ne>
i see
<zmatt>
especially since I don't know what kind of threadsafety this pylon SDK has
<zmatt>
if any
<zmatt>
it's possible it's unsafe to share pylon images between threads entirely
<zmatt>
I'd consult the sdk documentation, except none is available on the web
vd33 has quit [Quit: Client closed]
vd33 has joined #beagle
<zmatt>
in general, don't assume anything is safe to share between threads unless you have explicit confirmation that it is
buzzmarshall has joined #beagle
<zmatt>
also, a hazard of submitting save_image to a thread pool is that if that in fact images can't be saved as fast as they're being captured, you'll run out of memory as jobs accumulate in the thread pool queue
<zmatt>
the only way to prevent that is by tracking the number of images "in flight" and limiting that by refraining from capturing more images if necessary
<zmatt>
the bookkeeping to do so is non-trivial, especially with all the threadsafety issues
<zmatt>
also your QImage code is a crash waiting to happen
<mattb0ne>
hmmm
<mattb0ne>
i could not image continuously and ask for an image one at a time
<zmatt>
I'm honestly also not sure I'm in the mood to ponder this mess right now, sorry
Alex93 has joined #beagle
<Alex93>
Hi all:) Does anyone know how to can run wireshark on the beaglebone to analyze activity on its USB ports?
<zmatt>
google "usbmon"
<mattb0ne>
ok\
<zmatt>
(though running wireshark on the bbb sounds painful, I'd be more inclined to use commandline tools and if need be transfer a packet trace from the bbb to my laptop and analyze it in wireshark there)
vd33 has quit [Quit: Client closed]
vd33 has joined #beagle
<zmatt>
afk
<Alex93>
Thank you for the reply zmatt. I am using the beaglebone on virtualbox ubuntu (I have wireshark running here). So I have tried capturing packets using tcpdump to view them on Ubuntu, but tcpdump is not available on my beaglebone ...
<vagrantc>
dkaiser: well, managed to get it working with stretch's kernel ... 4.9.x
<dkaiser>
vagrantc, thanks for the update.
<vagrantc>
going to upgrade the userspace and install all the various kernels to see...
ikarso has quit [Quit: Connection closed for inactivity]
<Alex93>
rcn-ee & zmatt: I am using a beaglebone green and I cannot install tcpdump. Do you guys have any idea why I cannot install this? debian@beaglebone:~$ sudo apt install tcpdump
<Alex93>
Reading package lists... Done
<Alex93>
Building dependency tree
<Alex93>
Reading state information... Done
<Alex93>
The following NEW packages will be installed:
<Alex93>
tcpdump
<Alex93>
0 upgraded, 1 newly installed, 0 to remove and 312 not upgraded.
<Alex93>
Need to get 377 kB of archives.
<Alex93>
After this operation, 796 kB of additional disk space will be used.
<Alex93>
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
<Alex93>
debian@beaglebone:~$ ^C
<Alex93>
debian@beaglebone:~$
<zmatt>
I mean, if the bbb doesn't have an internet connection it's not going to be able to install packages off the internet
<zmatt>
also, debian stretch is really ancient
* vagrantc
chuckles as vagrantc has installed stretch twice today :)
<rcn-ee>
Alex93, oh fun, any reason your still on stretch?
<vagrantc>
it's the most recent version of debian where debian-installer works on the beagleboneblack :)
<vagrantc>
pretty sure it worked ok earlier in the buster and even bullseye release cycles...
<rcn-ee>
Alex93, is your Green, connected thru the network on the USB cable or ethernet?
<Alex93>
rcn-ee, I am basically developing drivers on ARM Cortex4 and after debugging, I am only using the beaglebone to analyze transmission packets from the ARM UART (through RS232 to USB) into the beaglebone USB pot. The beaglebone is currently connected to the host ubuntu computer which can control via ssh all beaglebone installations and updates and so
<Alex93>
far all periferal seem ok. I can even control the beaglebone through Node-red.
<rcn-ee>
Alex93, okay, temporary connect the Ethernet cable and install tcpdump
<Angel_Sosa>
Does anyone have any sample code or a link I can reference on setting and manipulating GPIO pins on the expansion headers for a Beagle X15
<Angel_Sosa>
Does anyone have any sample code or a link I can reference on setting and manipulating GPIO pins on the expansion headers for a Beagle X15 using C or C++
<Angel_Sosa>
I would really appreceate it
rob_w has quit [Read error: Connection reset by peer]
mattb0ne has quit [Remote host closed the connection]
Alex93 has quit [Quit: Client closed]
<vagrantc>
dkaiser: well, interesting news ... installing with debian-installer from stretch, and then upgrading to buster, and then upgrading to bullseye, the network seems to work
<dkaiser>
vagrantc: quite the process!
<vagrantc>
but at least it means the kernel works; there's something missing in debian-installer
<vagrantc>
same for the 4.19 kernel from buster (although running on bullseye, didn't test booting part-way through)