buzzmarshall has quit [Quit: Konversation terminated!]
Shadyman has joined #beagle
vagrantc has quit [Quit: leaving]
ikarso has joined #beagle
rob_w has joined #beagle
otisolsen70 has joined #beagle
otisolsen70 has quit [Remote host closed the connection]
thinkfat_ has joined #beagle
otisolsen70 has joined #beagle
xet7 has quit [Quit: Leaving]
otisolsen70_ has joined #beagle
otisolsen70 has quit [Ping timeout: 240 seconds]
otisolsen70_ has quit [Quit: Leaving]
florian has joined #beagle
thinkfat_ has quit [Remote host closed the connection]
thinkfat_ has joined #beagle
Daulity has joined #beagle
<Daulity>
hey
<Daulity>
Question Trying to enable early_printk but the kernel seems to just hang after u-boot i have enable early_printk in the kernel options after the option DEBUG_LL also these are my bootargs: "setenv bootargs console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait earlyprintk"
<Daulity>
man that sentence construction xD
<Daulity>
I mean I enabled the kernel option early_printk after I enabled DEBUG_LL
<Daulity>
as soon as I remove earlyprintk from bootargs it works again I think I have something miss configured :)
ft has quit [Quit: leaving]
ft has joined #beagle
xet7 has joined #beagle
mattb0ne has joined #beagle
<mattb0ne>
does the bbb need a nameserver to use the shared internet? Trying to set up another board under windows cannot get it to use the shared connection
<Daulity>
hmmm I have access to a system where i have earlyprintk working :) been looking through /proc/config.gz but not sure what I changed :)
<zmatt>
mattb0ne: if you connect the bbb via ethernet it should work plug and play
<zmatt>
Daulity: I've dug into earlyprintk and earlycon before, though I don't quite remember the conclusions... other than that earlyprintk is kinda gross. iirc earlyprintk also hardcodes the uart to be used into the kernel (while earlycon uses the uart selected as console by u-boot)
<zmatt>
and iirc earlyprintk has kind of a glitchy transition to normal console
thinkfat_ has quit [Ping timeout: 252 seconds]
<Daulity>
i got it to work eventually
<Daulity>
i had to set the uart_phys and uart_virt addresses correctly
<Daulity>
for somereason they are/were different
<Daulity>
trouble is i really shot my self in the foot here xD not documenting that i had to do that
<zmatt>
Daulity: any reason to use the brittle earlyprintk rather than the (afaict) more sane earlycon ?
<zmatt>
why do you need either anyway? does the normal serial console really appear that late? are the relevant drivers compiled into the kernel or did you build them as modules?
<zmatt>
Daulity: looks like earlyprintk should use the correct uart if you have "Kernel low-level debugging port" set to "Kernel low-level debugging messages via AM33XX UART1", i.e. CONFIG_DEBUG_AM33XXUART=y ... note that contrary to what the config var name and help message claim, that's actually UART0 (/dev/ttyS0)
<zmatt>
that sets CONFIG_DEBUG_UART_PHYS=0x44e09000 and CONFIG_DEBUG_UART_VIRT=0xf9e09000
jrmu has joined #beagle
<zmatt>
in contrast, earlycon just requires CONFIG_SERIAL_EARLYCON=y and "earlycon" in the kernel parameters
rob_w has quit [Ping timeout: 256 seconds]
lucascastro has quit [Quit: Leaving]
<mattb0ne>
when I try to ping 8.8.8.8 it fails immediaetly
<mattb0ne>
i was used to it at least trying to reach out
<mattb0ne>
does the latest image use conman to control internet?
<mattb0ne>
my /etc/resolv.conf is blank too
<mattb0ne>
the one chance I did was uncomment iface eth0 inet dchp line in my /etc/network/interfaces file
<mattb0ne>
didnt work obviously
<mattb0ne>
i can reflash i guess
<mattb0ne>
hope for the best
<mattb0ne>
but I feel you did tell me to do something to get the internet sharing going on the bbb
<mattb0ne>
zmatt:internet sharing is plug and play
<zmatt>
mattb0ne: do not put anything in /etc/network/interfaces
<zmatt>
that will just break things
<zmatt>
mattb0ne: the only thing required on the bbb to have internet working when plugged into ethernet is just not breaking what works out of the box
<zmatt>
it works unless you mess it up
set_ has quit [Ping timeout: 256 seconds]
vd33 has joined #beagle
CoffeeBreakfast has quit [Quit: Client closed]
<mattb0ne>
ok
<mattb0ne>
let me comment out interfaces
<mattb0ne>
much of the BBB literature is so out of date
<zmatt>
has there even been a time where bb.org debian images _didn't_ use connman? if so that would be before my time
xet7 has quit [Quit: Leaving]
rcn-ee has quit [Remote host closed the connection]
rcn-ee has joined #beagle
<mattb0ne>
auto lo is ok though right?
<mattb0ne>
and "iface lo inet loopback"
<zmatt>
yes that's in there by default
<mattb0ne>
connect: Network is unreachable
<mattb0ne>
if I try and ping 8.8.8.8 it is like immediate like it is not even trying
<zmatt>
there's no internet available on ethernet, something must have gone wrong with internet sharing
<zmatt>
a 169.254.*.* IP address is a self-assigned link-local address, which means no DHCP server was found on ethernet
florian has quit [Quit: Ex-Chat]
<mattb0ne>
hmm
<mattb0ne>
so you think it is a problem on the host
<zmatt>
yes
<mattb0ne>
let me play with windows
<mattb0ne>
arg
<zmatt>
it's not sharing internet to ethernet
<mattb0ne>
this was much eaiser on linux
<zmatt>
iirc it's easier on windows than on linux
<zmatt>
I rarely use windows but I don't recall having ever had any problems with windows internet sharing
<mattb0ne>
i share the connection that is actually providing the internet
<mattb0ne>
i was hoping it was that simple
<mattb0ne>
also I was going to ask you if I am processing data to slow using your code would that cause a memory leak in python
<mattb0ne>
I ask because I get an OOM error
<mattb0ne>
i am wondering how I can fix
<mattb0ne>
right now I deliberately throttle to block blow ups
<zmatt>
??
<zmatt>
you really need to clarify what you mean. "throttling" processing makes no sense to me, that would make any kind of problem worse
<zmatt>
are you talking about the client or the bbb?
<zmatt>
if the client is unable to keep up with the data being sent then... well first of all fix the client, it really isn't that much data, but second yes if that situation goes on long enough that will obviously make either the client or the bbb run out of memory if you didn't put in any checks
<zmatt>
I recall that in my example server code (for the bbb) I had a comment about exactly that
mattb00ne has joined #beagle
<mattb00ne>
the bbb runs fine
<mattb00ne>
issue is client side
<mattb00ne>
i guess by throttling i mean having the client do MORE stuff. If I just have the client try and save it blows up. If I have it do somethings like updating the GUI and save it will run
<zmatt>
??
<mattb00ne>
so the BBB is sending batches to the client
mattb0ne has quit [Ping timeout: 240 seconds]
<zmatt>
no, the BBB is sending lines to the client
<mattb00ne>
ok the client is receiving lines in batches
<zmatt>
whether or not these were sent in batches is invisible and irrelevant to the client
<zmatt>
the client is receiving lines, and my version processes those in batches as a performance optimziation
<zmatt>
*optimization
<zmatt>
(by waiting until at least one line is available, and then processing all complete lines in the input buffer in one batch)
<mattb00ne>
right and those batches get parsed and some of that data is sent to the rest of the program
<mattb00ne>
so I tried running with nothing else really happening other than saving the image as a npy
<mattb00ne>
i can confirm I do not have a HW bottleneck as the sdd can handle 1.2GB/s in sequential write via DD
<mattb00ne>
I do get around ~25 images a second
<mattb00ne>
but I can only do so for 1 minute
<mattb00ne>
before I get an OOM
<zmatt>
what exactly does this image-stuff have to do with the data being sent from the bbb ?
<mattb00ne>
i watched during system monitor and on the client side something is not getting cleared
<mattb00ne>
nothing really the BBB is fine
<zmatt>
that's not what I asked
<mattb00ne>
i am just wondering if there is anything to watch out for on the client side and python in general to get that sort of behavior
<mattb00ne>
i am going to flash this 2nd beagle
<mattb00ne>
i must of done something
<zmatt>
your internet issue is not on the bbb
<zmatt>
and your memory leak question is too vague to be answerable... yes if you keep using more memory you'll eventually run out of memory...
<mattb00ne>
well windows is saying unidentified network or something
<mattb00ne>
on the memory question is there a way to force python to release memory
<mattb00ne>
kind of like C
<zmatt>
so just to be clear: on your internet connection you enabled internet sharing, and as "home network" in that sharing popup select ethernet
<zmatt>
python will release memory once it's unreferenced
<zmatt>
it can't release memory that's still referenced since then you'd crash
mattb0ne has joined #beagle
<mattb0ne>
ok bridge connection does not work
<mattb0ne>
I am on Win11
<zmatt>
bridge is not the same thing as internet sharin
<zmatt>
g
<mattb0ne>
and the sharing option does not have a drop down to specify a specific connection to share with
<mattb0ne>
it was a shot in the dark
<mattb0ne>
definitely windows though you are right. when I click on the ethernet port it says no connectivity Ipv4 or Ipv6
mattb00ne has quit [Ping timeout: 240 seconds]
<mattb0ne>
i suppose a static IP would not help
<zmatt>
normally windows will set that up
<zmatt>
okay no idea what microsoft did with internet connection sharing in windows 11
<zmatt>
I'm not getting any useful results so eh... good luck with that I guess?
<mattb0ne>
yeah i will just update the board on my linux box
<mattb0ne>
damn windows
<mattb0ne>
on the memory thing
<mattb0ne>
more important anyway
<mattb0ne>
is there a python release memory command
<mattb0ne>
or calling the garbage collector manually
<zmatt>
you're asking the wrong questions
<zmatt>
if you're leaking memory, your code is keeping that memory referenced
<zmatt>
which means that memory _cannot_ be safely released, in any programming language
xet7 has joined #beagle
<mattb0ne>
is oom the same as memory leak
<zmatt>
oom is the result, memory leak is the cause
<mattb0ne>
ok how could i go about finding where the issue is in my code
<mattb0ne>
do I need a 3rd party tool
<zmatt>
also, are you still doing things with that qt image api? I seem to recall it had some memory allocation caveats as well but I'd need to check again (and I don't remember what you were using)
<mattb0ne>
i assumed that was not the problem since I stopped all QT activity. I was going to try do a very barebones program where I just save nothing else and see if I run into the issue
<mattb0ne>
and then slowly add stuff back in.
<zmatt>
well if you're not doing anything with qt then the problem is presumably not there
<mattb0ne>
like you said think systematic
<mattb0ne>
so first let me see if I can save that fast
<mattb0ne>
I do the multiprocessing thing with 5 workers
<mattb0ne>
not sure that should matter but maybe it does
<mattb0ne>
then I will add the beagle communication
ikarso has quit [Quit: Connection closed for inactivity]
<mattb0ne>
brb
mattb0ne has quit [Remote host closed the connection]
Guest97 has joined #beagle
<Guest97>
Hi, is this the Beaglebone chatroom?
<zmatt>
yup
<zmatt>
(or more generally the chat for users of beagleboard.org products)
<Guest97>
Cool! This is my first time using IRC, so I am kinda unsure :D
<Guest97>
Does anyone here know if it's possible to get a screen working on a pocket beagle? I mean it has SPI..
<zmatt>
I mean, you kinda answered your own question there... small screens that connect via spi (or i2c) will obviously work on any board that has spi (resp i2c)
<Guest97>
Yeah, I was just not that sure because I read somewhere that there is no way rendering a desktop
<Guest97>
Thank you, that's basically all I wanted to know!
<zmatt>
I mean, if the spi display has a kernel driver then I guess you could theoretically run X11 on it
<zmatt>
whether you'd _want_ to is a different question ;)
<zmatt>
given the size and performance limitations
<Guest97>
Well, it would be for a small DIY smartwatch (with the Octavo SIP, not with the pocket beagle). Plan would be running X and start a TKinter script right after booting
<Guest97>
No animations or anything fancy is needed--
<zmatt>
would probably be more appropriate to use a graphics library that can directly use the framebuffer instead of running X11
<zmatt>
also, if you're using the octavo sip directly you obviously also have access to the lcd controller pins
<zmatt>
though it's possible for a smart watch an spi display is more appropriate
<zmatt>
(lcdc also supports various bus protocols commonly used by displays with embedded framebuffer, though I don't think there's a kernel driver for that mode)
<Guest97>
Yeah, that's my intend. Don't get me wrong, I don't know much about embedded systems, but I am a CS student and I am able to design a PCB and solder BGA, with this Prerequisites I think it would be possible for me to create a fun device.
<Guest97>
I think SPI is pretty comfortable regarding the kernel as far as I have researched...
<zmatt>
the osd335x certainly makes it easier by integrating the particularly tricky bits related to power supplies and ddr3 memory
<zmatt>
yeah for spi you just use one of the spi controllers, not lcdc
<Guest97>
Good to hear! I initially found the OSD32MP15, but then discover the pocket beagle which would be the ideal development board...
<zmatt>
lcdc is normally used for digital parallel video (aka display pixel interface), though like I said it has some other modes (e.g. for HD44780) but those modes aren't well supported in software
<Guest97>
Because you mentioned it before: Are there any major disadvantages with X11 compared to a graphic libarary?
<zmatt>
I mean, the pocket beagle is only ideal if you don't need any of the many pins it _doesn't_ pin out on its expansion headers... otherwise the beaglebone black, black-wireless, or green would be better for prototyping (avoid the green-wireless)
<zmatt>
performance
<zmatt>
overhead
<zmatt>
also the general awkwardness of having to setup X11, arrange for auto-login, have your program launched automatically on login
<zmatt>
versus just starting your app at boot and it directly rendering graphics to the framebuffer
<Guest97>
I looked up the pinout and found that I don't miss any pins on the pocket beagle
<zmatt>
well, it lacks the lcdc pins for one
<Guest97>
Of course, but I don't think I need them
<zmatt>
if you've already decided to use an spi display then true
<Guest97>
Regarding X: One thing I didn't told you before was, that I want multiple apps running and thus a graphic library would be not that useful as far as I understand. Btw, sorry for my improper spelling and phrasing, I am from Europe...
<Guest97>
Of course, if it's that bad with X, I could make ONE app and integrate all the functionality there...
<zmatt>
perhaps I'm overly pessimistic about X11... or I might be pessimistic by a perfectly appropriate amount, I guess you'll have to try and see ;)
<Guest97>
I would structure it like a real desktop and have a app launcher like you would have it when you don't use a complete DE in Linux. From there starting apps without borders in openbox (or any other lightweight WM). Closing would be a hardware button.
<Guest97>
I mean I would like to not use X, it bothered me quite some time when setting up arch, and I can only imagine how annoying it would be to set it up on a circular screen ...
mattb0ne has joined #beagle
<zmatt>
lol
<mattb0ne>
?
<mattb0ne>
must of broke something, after reflashing it is working now
<mattb0ne>
yay
vagrantc has joined #beagle
Guest97 is now known as a3x05
<a3x05>
Thanks for your help! I will probably be back soon in this channel when I got the beagle^^ have a nice day all
behanw has quit [Quit: Connection closed for inactivity]
nslu2-log_ has joined #beagle
nslu2-log has quit [Ping timeout: 256 seconds]
nslu2-log_ is now known as nslu2-log
Konsgn has joined #beagle
Konsgn has quit [Client Quit]
a3x05 has quit [Quit: Client closed]
<mattb0ne>
zmatt: have you used the multiprocessing module
<mattb0ne>
I think i have an issue with thread cleanup
<mattb0ne>
i am not sure how to fix it though
<mattb0ne>
from python docs "We can use a with statement to ensure threads are cleaned up promptly
<mattb0ne>
"
<mattb0ne>
i am not sure how to do this in my use case
CoffeeBreakfast has joined #beagle
<zmatt>
mattb0ne: I tested submitting working via asyncio's loop.run_in_executor() and that does not require cleanup or leak memory
<zmatt>
you don't need to clean up worker threads, that's the job of the ThreadPoolExecutor (in my tests I just used the default one provided by asyncio)
<zmatt>
however, your code seems to be creating a new thread pool for each image
<zmatt>
which completely defeats the purpose
<zmatt>
like, your code creates a thread pool, submits a single job in it (assuming grab succeeded), and then implicitly wait for that job to have completed as part of the thread pool cleanup that happens at the end of the with-block, overall doing the exact same thing you did without threading except with a lot more inefficiency
<zmatt>
also, when I google that camera library you're using, the first example I see ( https://github.com/basler/pypylon#getting-started ) contains an explicit release of the grabbed image: grabResult.Release() ... I'm not seeing that in your code
vd33 has quit [Quit: Client closed]
vd33 has joined #beagle
<zmatt>
also, this binding looks kinda horrid
<mattb0ne>
lol
<mattb0ne>
could i get away with just creating a thread and Thread.start()
<mattb0ne>
i know i read that creating threads and destroying them is not efficient
<zmatt>
it's more work, more complexity, and less efficient... why exactly would you want to do that?
<zmatt>
I'm more concerned about how to integrate this pylon crap into the overall application, since it looks like it's synchronous and blocking
<mattb0ne>
well i just did a simple version where I just create a thread and assign it and repeat the loop
<mattb0ne>
all I use it for is the image grab
<mattb0ne>
maybe inserting the release is what I need once I have it in a numpy array I am done until next image
<zmatt>
you'll probably want to have a dedicated image-grabbing thread (if there's no better way to deal with pylon)
<zmatt>
you definitely don't want to use multiple threads for image-grabbing, that will make a giant mess (if not outright crash, depending on whether pylon is threadsafe)
<zmatt>
how to best structure the processing of the grabbed images is a non-trivial matter and will depend a bit on what you intend to do with those images other than just save them
<mattb0ne>
basically my loop is: 1) get image 2) get data from BBB and 3) save image
<mattb0ne>
i would want a thread pool for all this?
<zmatt>
that description of the loop is ambiguous, since you don't "get" an image or data from the BBB at your command, the camera provides images at its own pace, and likewise the BBB provides its data at its own pace
<mattb0ne>
right that is what is hard
<zmatt>
a thread pool is for asynchronous execution of stuff like saving images
<zmatt>
right, which is why you need to explain better what exactly you're trying to do
<mattb0ne>
so a single separate thread for the image grabbing
<zmatt>
looks like pylon kinda forces you to do that yes
<mattb0ne>
ok
<zmatt>
or, well, based on the examples anyway, since there doesn't really seem to be API documentation on the web
<mattb0ne>
this will take a pretty sizable restructuring
<zmatt>
how is your program structured right now?
<mattb0ne>
its a mess
<mattb0ne>
lol
<zmatt>
isn't this a gui program with asyncio? how do you even fit this in?
<mattb0ne>
yes
<zmatt>
a threaded blocking API fits into an event-driven gui program like a chicken fits into a keyhole
<mattb0ne>
i am learning how true that is
<mattb0ne>
i guess i am not sure how to have a thread that just spits out images
<zmatt>
I'm also not sure that's what you want
<zmatt>
if you want a camera image that's close in time to the measurement data from the BBB, then you don't want images to be queued
<mattb0ne>
right ideally i want it matched up as close as possible
<zmatt>
though I'm still just guessing here what it is you want exactly since you haven't clarified
<zmatt>
and you're trying to do that for every image from the camera? or some specific interval? or something triggered by the BBB measurements?
<mattb0ne>
every image coming from the camera
<mattb0ne>
as I get an image back I look at the latest value coming from the BBB and then save them together
<zmatt>
hmm
<zmatt>
I guess you could have the main thread put the latest BBB values somewhere, have the camera grabber thread grabbing images in a loop and after obtaining an image grab the latest measurements from whereever the main thread saves them (the GIL makes this safe if you're careful) and then submit the np.save to a threadworkerpool
<zmatt>
for really tight synchronization you'd want a way to trigger the camera and simultaneously take a measurement sample, but that's probably a bit too complicated
<zmatt>
(or a way to get timestamps on camera images combined with a way to relate these to BBB measurements)
<zmatt>
anyway, afk
<mattb0ne>
ok
<mattb0ne>
thanks for the suggestion
<mattb0ne>
i will give it a shot
Shadyman has joined #beagle
bzyx has quit [Quit: No Ping reply in 180 seconds.]
bzyx has joined #beagle
mattb0ne has quit [Remote host closed the connection]