01:19 <set_> @zmatt: Do you still goof around w/ librobotcontrol?

01:20 <set_> The reason I ask...https://pastebin.com/s5zSJv1H does no do anything. I am trying to configure something in C/C++ w/ LibRobotControl...

01:21 <set_> This is for someone on the forums but my C skills are minimal and I am not receiving too many replies just yet.

01:21 <set_> Silly? Yes. I understand. I am new to this outdated lib.

01:22 <set_> I figured I would try to help as usual. Oops!

01:38 <set_> I can try to type in C but I am not sure what exactly to enable w/ the PRU and the PWM channels on the BBBlue...

01:41 <set_> or...should I use config-pin?

02:31 <set_> I will check back later...

10:32 <zmatt> set_: I have never used librobotcontrol

12:50 <Bruno75> Hello,

12:50 <Bruno75> Sorry to bother.

12:50 <Bruno75> I have bought a Beagle Bone Black and I wasn't able to setup a desktop environment, as I need graphics for my application.

12:50 <Bruno75> I have a 32GB sd card, but I didn't find any image with a pre installed desktop environment for the beagle black, is there one available ?

12:50 <Bruno75> I've installed the latest debian one without lxqt but ran into a "no space left available on device" when I tried to install it.

12:50 <Bruno75> At this point I'm kind of lost. Any suggestion ?

12:50 <Bruno75> Thanks.

17:08 <zmatt> Bruno75: yeah modern desktop environments are kinda too bloated to fit on eMMC, certainly together with the other stuff on the IoT image, so you'd either need to just run from sd card (at a substantial performance cost) or install a minimal image and then manually install a desktop environment on top of that with apt (and pray you can keep it minimalistic enough to not run out of space)

17:08 <Bruno75> thanks ! Do you recommend an image to run from a sd card ?

17:09 <zmatt> they're also not going to run particularly well, the AM335x is an industrial processor, its very limited graphics capabilities are meant for simple touchscreen interfaces, not for using it as a desktop computer

17:09 <Bruno75> Yeah I think I'm going switch back to Raspberry Pi for this application, I need quite good graphics.

17:09 <zmatt> you say you need "graphics" for your application but that doesn't sound like you actually need a desktop environment

17:10 <Bruno75> No, running a full screen app in Full HD, 30fps is fine

17:11 <zmatt> well you definitely don't need a desktop environment for running a single fullscreen app, you may not even need X11 at all depending on what graphics sdk/toolkit you want to use, e.g. qt5 applications can run fullscreen directly on the framebuffer

17:12 <zmatt> (and if you don't need X11 you may even be able to use the 3d gpu for opengl es/es2, though it's a bit of a hassle to get it working)

17:13 <zmatt> (at least I'm assuming it still is, haven't really done anything with graphics on a beaglebone for a long time)

17:15 <zmatt> but yeah, depending on what exactly your graphics needs are and how they compare against your app's other needs it's possible a board from the rpi family may be better suited, as it uses a media SoC

17:17 <ds2> or look at the BBC's

17:17 <ds2> They use a media processor

17:24 <zmatt> Bruno75: oh and I just noticed the "full hd" ... 1920x1080 is definitely outside the beaglebone's comfort zone... iirc it does technically support it, but updating a gui at 30fps at that resolution would probably require some skillful optimization

17:25 <Bruno75> Thanks a lot.

17:27 <zmatt> Bruno75: the beaglebone does have bigger siblings with more powerful SoCs, but whether one of those or an rpi would be a better fit for your needs is of course hard to say considering without having some idea of what your needs are ;)

17:29 <Bruno75> To host this app, basically ;) https://www.youtube.com/watch?v=A3H04yo7U7Y

17:32 <zmatt> that looks very non-intensive, especially only tiny parts of the screen are being updated... though what's with that orange flashing? :P

17:33 <zmatt> and is it also doing the audio processing or is it just an interface that controls an external device e.g. via MIDI ?

17:38 <Bruno75> no audio processing, just midi

17:38 <Bruno75> the orange flashing is when the knobs are updated... or instable :D

17:38 <Bruno75> unstable*

17:39 <zmatt> yeah I figured it was to highlight changing parameters, but it seems a bit... excessive? it kinda looks more like a rendering bug because of how severely it flickers :D

17:39 <zmatt> at least it's hard to miss I guess

17:40 <Bruno75> yay it's a prototype... in the newer version there is only a border around the squares, less flashy

17:42 <zmatt> but yeah if it's this + MIDI (which just needs an uart that supports 31250 baud + a small bit of external logic) then using a more graphics-oriented board would probably be a more efficient use of your time than getting it optimized to run on a beaglebone

17:43 <zmatt> like, I'd be the kind of person who'd go for the latter option but that's because I'm very familar with beaglebones and would prefer to use one (plus I'm not a fan of the rpi's closedness)

17:46 <zmatt> this gui does looks like it would be relatively simple to optimize since it's fully custom (no graphics toolkit) and has very limited variety in graphical elements

18:00 <zmatt> oh ew, it doesn't seem like linux even checks the "use VCP driver" bits in eeprom to determine if it should use ftdi_sio, it just uses a hardcoded vid/pid table and some custom probing rules for some of them

18:23 <zmatt> whoops wrong window

18:26 <Silverside_Pete> Using a RotatingFileHandler for logging on our BBB Industrials is problematic: the first file logs correctly until maxBytes is reached. Then that file and all rotated log files contain exactly one line of logged output. This doesn't happen using the same code on other platforms. Is it a known issue and is there a fix aside from rolling our own log

18:26 <Silverside_Pete> file handler?

18:26 <zmatt> that sounds very odd

18:26 <zmatt> nothing about file handling is beaglebone-specific obviously, that's just the linux kernel

18:27 <Silverside_Pete> Agree that it's very odd. File handling works correctly on linux laptop, RPi, MacOS. Same code doesn't work correctly on BBB.

18:28 <zmatt> "and all rotated log files" .. like huh, existing logfiles are corrupted?

18:29 <zmatt> or maybe I'm misunderstanding what you meant

18:29 <zmatt> do you have a simple test-case?

18:29 <Silverside_Pete> No. if you catch it quick, first file gets rotated into blah.log.1. then blah.log contains exactly one line before it gets rotated into blah.log.1 and so on. No, sorry don't have a simple test case.

18:30 <Silverside_Pete> But since each rotated file rotates after logging one line, the original file quickly gets rotated into oblivion.

18:30 <zmatt> so you mean it rotates prematurely?

18:30 <Silverside_Pete> WAY prematurely.

18:30 <zmatt> so the problem is in RotatingFileHandler's decision-making on when to rotate?

18:30 <Silverside_Pete> Right. Works on most platforms, doesn't work on BBB.

18:31 <zmatt> so then the next question would be, how does it decide when to rotate?

18:32 <Silverside_Pete> That's undoubtedly buried in the guts of RotatingFileHandler. MY next question is, why does it decide to rotate differently on BBB than on other platforms.

18:32 <zmatt> well the former may shed light on the latter, since it's not going to be hardware-dependent so there will be _something_ different about the system's state or configuration

18:33 <zmatt> is the beaglebone's system clock set though ntp?

18:34 <zmatt> if your service starts before the beaglebone's system time has been synchronized, how does RotatingFileHandler react to the system time suddenly making a huge jump forwards?

18:34 <Silverside_Pete> How can it NOT be hardware dependent? Same code produces different output on different hardware. Good question about the system clock. The BBB is not connected to the outside world. Can the system clock access a time server?

18:36 <Silverside_Pete> All the systems on which the files rotate correctly have internet connectivity. The BBBs do not. Perhaps this is somehow related to the issue.

18:37 <zmatt> if the BBB has no network connectivity then it has no way to set the system date/time, nor does it have a way to preserve it across power cycles since there's no battery in the bbb

18:37 <Silverside_Pete> The timestamps in the single-line rotated log files appear to be correct.

18:38 <zmatt> well then it evidently does have access to an ntp server

18:39 <Silverside_Pete> The BBB is connected to the outside world by a USB connection to a laptop. Perhaps it syncs the time with the laptop. I don't think ntp access is the issue, although I will look carefully at it.

18:40 <zmatt> well it can't know the system date/time by magic

18:40 <zmatt> if the system date/time is set correctly, either the beaglebone can reach an ntp server or you've implemented something custom

18:42 <Silverside_Pete> I will talk to our hardware guys about that. Maybe they've done something tricky. I agree that the BBB must be getting its time from someplace.

18:42 <zmatt> anyway, the hypothesis that perhaps RotatingFileHandler is getting confused by a time-jump is easily testable: if you restart your service (the one that's using RotatingFileHandler) after the system has fully booted and the system date/time is correctly set (check using "date")

18:42 <zmatt> does it still happen then?

18:43 <zmatt> just for clarity, are you using RotatingFileHandler or TimedRotatingFileHandler ?

18:43 <Silverside_Pete> 'date' gives me UTC date/time that's completely incorrect - set to last year sometime. I tried both RFH and TRFH - same results.

18:45 <zmatt> okay so the bbb has no system time set... that doesn't completely rule out the hypothesis since the system clock will still jump forward during boot (from 1970 to a semi-recent one based on a saved timestamp)

18:46 <Silverside_Pete> I'll bet a dollar you're onto something. This looks promising.

18:46 <zmatt> are you using TimedRotatingFileHandler? because if you're actually using RotatingFileHandler which only rotates based on file size then that would be much much stranger

18:50 <zmatt> Silverside_Pete?

18:50 <Silverside_Pete> I tried both handlers. They both behaved in identical fashion. I set the TRFH to rotate at one minute intervals. The first minute, the log file filled up with data. The file rolled over - rotated file now has first batch of data. File rolls over again - first batch of data is in limbo, both log files now contain a single line of output.

18:52 <Silverside_Pete> But same thing happens using file-size-based RotatingFileHandler. Set it to log file size 10K, reaches its limit, rotates the old data into a saved file, logs a single line of data, rotates that into the saved file, overwriting the log data.

18:54 <zmatt> well that excludes any hypothesis based on system time

18:54 <Silverside_Pete> =(

18:55 <Silverside_Pete> Nevertheless, the fact that all the systems on which the files rotate correctly have had access to the internet is a major difference with the BBB.

18:56 <zmatt> system time is the only mechanism which would have explained why internet access might matter

18:57 <zmatt> so, I just tried this: https://pastebin.com/aZvvPPfi

18:57 <zmatt> and it rotates just fine for me, as I'd expect

18:58 <zmatt> writes 5 lines into each file (which is correct for the maxsize I gave) and then rotates

18:59 <zmatt> does this simple test fail to rotate properly for you?

19:03 <Silverside_Pete> Thanks! Rotates properly. Puzzling.

19:04 <zmatt> random thought: are you maybe setting the max log size based on total disk space or free disk space?

19:04 <zmatt> with the bbb having much less thereof than your other systems

19:06 <zmatt> also, just for reference, what system- and python-version are you using? ( cat /etc/debian_version /etc/dogtag; python3 --version )

19:08 <Silverside_Pete> That's why we're rotating the log files. The systems live several years unattended in the field and we don't want the file size to eat up the ~1GB of free space. python is 3.9.2, sside@BeagleBone:~$ cat /etc/debian_version /etc/dogtag

19:08 <Silverside_Pete> 11.3

19:08 <Silverside_Pete> BeagleBoard.org Debian Bullseye IoT Image 2022-05-10

19:09 <Silverside_Pete> Interesting that 2022-05-10 is the date shown in the log files

19:10 <Silverside_Pete> I've gotta break now. Many thanks for your help. I will be back on this on Wednesday.

19:10 <zmatt> that's not that interesting: I already mentioned that when the system date is completely uninitialized (1970) it gets fast-forwarded at least to some recent file timestamp

19:11 <zmatt> Silverside_Pete: maybe inspect what handler.maxBytes is actually configured to be

19:12 <zmatt> as an aside, you could also consider logging to journal, which is the main logging facility on modern systemd-based linux systems

19:13 <zmatt> (journal can be configured to be persistent (on disk) or volatile (in ram) with configurable limits)