**** BEGIN LOGGING AT Sat May 30 02:59:59 2020 May 30 03:07:50 New error! May 30 03:09:25 https://pastebin.com/ezyuAdW7 is nothing special unless you know what I just went through w/ this visvis lib. May 30 03:10:27 I actually rendered a screen w/ a black fourth on the entire Tkinter widget. May 30 03:54:39 so like you didn't need anything for ffmpeg then? May 30 03:56:00 Not yet. May 30 03:56:08 But. I will use it in the future. May 30 03:57:28 just don't repeat something like the SN4 starship static fire test like Spacex did today. May 30 03:58:01 Okay. May 30 03:58:23 Do not fret. I am just "reverse engineering" visvis to make it so there are fewer error prone issues. May 30 03:58:48 Everything I am trying to do on the BBGW gets an error from visvis. May 30 03:59:18 First, I got a simple issue. This "simple" issue turned out to be a whopper of an item. May 30 04:00:18 ah snot queens husband (buger king) :D May 30 04:02:07 What? May 30 04:02:12 He died? May 30 04:02:37 He looks good for 97! Lucky, burger king. May 30 04:05:59 Hmm for now at least. May 30 04:06:30 Back to OpenGL stuff. I thought I had figured out the loop. dang it. May 30 04:07:11 It is not easy trying to reverse items of interest, e.g. already "done" source like visvis. The package is broken and the updates might never show up. May 30 04:07:26 Some of it is OpenGL stuff, too. I am guessing! May 30 04:08:06 Oh well. I will remember tonight as a lost fight w/ brokedness. May 30 04:08:07 Ha. May 30 04:17:45 All I did was get rid of the shader effect, GLSL, and remove all instances referring to them. May 30 04:19:15 are you working with video streams or openGL? May 30 04:21:16 videoStreams w/ OpenGL. May 30 04:23:07 supposedly, this "4D", the libs. I am using are supposed to copy the video stream as a imprint and save to file while streaming. May 30 04:23:48 But...I think this fellow got hired by Google and moved on b/c I have not seen any updates since 2012 on this source. May 30 04:24:09 The library has been active just three years back but w/ small updates. May 30 04:41:14 OpenGL has a very looped wrapper for wrapper.py. Yikes. May 30 04:56:46 line 650 has my error but I cannot find it. May 30 04:56:53 Dang. May 30 11:29:48 ok, single node red flow with 5 charts and 1 gauge and minimal processing sucks up over 80% of cpu time. May 30 11:30:00 lol May 30 11:30:24 it's the modern way May 30 11:30:44 this is just stupid May 30 11:30:52 also the modern way May 30 11:37:55 but in other news, my "virtual" pps thingy works May 30 11:38:15 what did you end up doing? May 30 11:39:05 I could only realize one half of it for now. The external pps output needs more thinking and maybe a bit of extra hardware May 30 11:41:15 but the dmtimer based kpps works fine. I'm basically using the compare function to generate a pps event every 10000000 cycles, and the capture function of the same timer to timestamp the GPS timesignal May 30 11:41:39 then I compute the difference and use it in my gpsdo controller to align the virtual pps to the actual pps May 30 11:43:18 the idea is, if the gps coverage is out, I still have the 10MHz reference clock while the gpsdo is in hold-over mode, which drives the timer through tclkin, which means I still get good quality pps events May 30 11:44:11 of course the ocxo will eventuall drift away, but it should be good for at least a couple of hours May 30 11:53:18 the main obstacle for a 1pps output is that the dmtimer seem to be unable to make the match event externally visible May 30 11:56:18 also, they apparently cannot trigger each other... May 30 11:57:45 dmtimer can most definitely make the match event externally visible, that's how it's used as PWM output May 30 11:58:07 zmatt: yes, but not without involving a counter overflow, it seems May 30 11:59:55 so either in toogle or pulse mode, I will always get either a toggle or a pulse when the counter overflows May 30 12:00:25 ah yeah, it can't trigger on match without also triggering on overflow, you're right... they should used those two bits for separate "trigger on overflow" and "trigger on match" instead of a 2-bit mode with one unused code May 30 12:01:04 pulse on match would have been fine. May 30 12:01:19 that'd have given me a nice 100ns 1pps pulse May 30 12:01:28 stm32 timers are way more flexible here May 30 12:03:09 but so wait, the 10 MHz clock for tclkin isn't one that's already GPS-synchronized? then what was the point of all this? May 30 12:03:32 zmatt: no, the tclkin is gps-synchronized May 30 12:03:43 then why do you need pps output from it? May 30 12:03:55 *have the bbb produce a pps output from it May 30 12:04:05 it would have been handy for hold-over May 30 12:04:43 also, a 1pps generated from the 10MHz will have _way_ less jitter than what the GPS delivers directly May 30 12:04:53 just make the period of the timer 10 million cycles and use pwm mode May 30 12:05:33 yes, that could be a way May 30 12:05:58 or some integer multiple of 10 million cycles, and use pulse on match or overflow May 30 12:06:00 and use a second timer clocked from tclkin as the system clocksource May 30 12:06:18 why would you need a separate timer for that? May 30 12:06:44 hm May 30 12:07:04 because I need to formulate a bit mask for a continously counting clocksource, no? May 30 12:07:16 it's even simple enough to emulate a full 32-bit counter from one that has a lower period May 30 12:07:18 and I cant if the clock period is 10000000 May 30 12:07:31 ah May 30 12:07:33 right... May 30 12:07:39 that I could to. May 30 12:07:42 using the overflow interrupt May 30 12:09:16 yeah, whenever you want to read the virtual counter update it based on how much the real one has advanced since last update, and update it twice per second (on match and on overflow, assuming you match on the midway point to create a 50% duty cycle pps) May 30 12:09:34 *update it at least twice per second May 30 12:10:21 or using overflow only is possible too but requires a bit more care to ensure there's no race condition May 30 12:19:44 the counters are always up-counting, right? and overflow always happen on transition from -1 to 0 May 30 12:22:12 -1 to reload-value May 30 12:24:53 right. May 30 12:25:00 I also found some old notes on what the output looks like for various values of the match register: https://pastebin.com/raw/4UdVi5pu May 30 12:25:27 so the pulse on overflow acts like a match on -1 May 30 12:26:27 (while setting match to the reload value will cause it to trigger one timer cycle after the overflow triggers) May 30 12:35:07 hmm, trm says there shoud be at least 2 units difference between reload and match... May 30 12:35:19 I wonder why May 30 12:36:21 because it was less effort than trying to clearly describe the behaviour under edge-cases? May 30 12:37:19 note this was tested on the dm814x, not the am335x, but it seems unlikely that that would matter May 30 12:58:55 the math to calculate time differences get a bit tricky if the counter range and uint32_t don't match any more... May 30 13:17:08 your compiler doesn't have uint_notquite32_t? May 30 13:35:56 counters are sometimes in the "WTH is this" register size category? May 30 14:03:52 mru: no, but it does have % May 30 14:06:48 fun fact: uint32_t is optional in the C spec May 30 17:08:32 hi guys May 30 17:11:25 just bought a BBB, need to wipeout everything on eMMC and just keep uboot, now there is uboot+elinux... May 30 17:12:10 someone knows how to do ? thanks May 30 17:13:28 overwrite it with whatever you want May 30 17:14:44 i don't know if i can just tell uboot to not boot linux somehow May 30 17:16:43 cause i'm connecting within minicom but i get linux console and i need uboot one May 30 17:17:45 press a key to interrupt u-boot May 30 17:17:52 like the prompt says May 30 17:25:37 it is just linkek through a usb cable and when minicom is connected linux is already booted May 30 17:26:19 you need to use the real serial port for u-boot May 30 17:29:06 so u-boot doesnt have usb stack, it makes sense :') May 30 17:29:20 my bad heheh May 30 17:32:31 u-boot has usb May 30 17:32:44 not sure if it has serial gadget though May 30 17:34:04 even if it did, you'd barely have time to fire up the terminal emulator and hit a key May 30 17:34:16 the actual serial port is much more practical May 30 17:35:12 gonna buy a serial-usb adapter so May 30 17:35:29 it's a useful thing to have May 30 17:36:24 yeah May 30 17:38:51 need to do a baremetal os, actually just copy paste thing that i learnt in lessons. need to able to answer the questions about it so better get some practise May 30 17:41:14 thanks guys, irc rocks (y) May 30 19:35:04 mru: I don't think I've ever seen code that actually uses (u)int_leastN_t or (u)int_fastN_t for portability to really weird architectures that lack standard-size integers ;) May 30 19:37:06 I have May 30 19:38:00 cool :D May 30 19:41:31 I also wonder what architecture(s) might still motivate doing so today May 30 19:42:48 the _fast32 types can benefit from being 64-bit on some machines May 30 19:45:15 yeah that was my first thought, but thinking about it I started to question whether that's really true.. as in, for data in memory using smaller types will typically be faster (by reducing average cache pressure), and for local variables I think it will rarely if ever matter if your compiler doesn't suck May 30 19:46:14 depends on the machine and the situation May 30 19:46:24 I guess May 30 19:46:39 a variable that doesn't ever hit memory can surely benefit from being a full register May 30 19:46:53 yes but it'll be kept in one anyway May 30 19:47:14 if it saves an explicit masking after every op, it's a win May 30 19:47:47 not relevant on arm64 May 30 19:47:48 but it'll rarely need explicit masking after every op May 30 19:50:07 like, (((x & mask) + (y & mask)) & mask) == ((x + y) & mask) and ditto for subtraction and multiplication May 30 19:50:26 and bitwise ops May 30 19:50:55 sure, but you'll have to mask before many comparisons May 30 19:51:14 comparisons and division yeah May 30 19:51:44 I guess it could matter May 30 19:52:18 how about (u)int_leastN_t ? ever seen those in the wild? May 30 19:53:18 there's less reason for those May 30 19:53:19 I know one modern CPU whose memory is (32-bit) word-addressable instead of byte-addressable, but it has no C compiler anyway May 30 19:56:51 the only other modern cpu I personally know that lacks some important support for basic integer types (but weren't designed to be targeted by a C compiler anyway) is PRU with its complete lack of support for signed integer types, which isn't something you can cover with int_fast/leastN_t :D May 30 20:04:05 lots of DSPs have weird sizes May 30 20:05:43 yep, I was referring to Analog Device's sigma300/350 core that's in their adau145x/adau146x DSPs May 30 20:06:30 *Devices' May 30 20:07:41 the TI C5x series had limited options too May 30 20:07:59 I don't really know much about those other than that they exist May 30 20:08:27 C6x has the usual 8/16/32 May 30 20:08:29 and also 48 May 30 20:08:32 40 May 30 20:08:34 not 48 May 30 20:09:30 on their old ABI "long" was actually 40-bit, although in the newer ABI ("EABI") you have to use int40_t to get it May 30 20:09:42 too much stuff broke with a 40-bit long I guess :P May 30 20:10:23 right, 40 bits May 30 20:10:32 still, not one of the usual ones May 30 20:10:38 I do wonder how it was represented in memory... I assume padded to 64-bit since it can't load/store 40-bit **** ENDING LOGGING AT Sun May 31 02:59:57 2020