**** BEGIN LOGGING AT Mon Nov 25 02:59:58 2019 Nov 25 08:02:16 what are the register conventions for the beaglebone black PRU? I don't really need to worry about playing nice with other code, but I'd prefer to start "nice" and degrade as I need to... Nov 25 08:04:37 for assembly it indeed doesn't matter really. when using pasm you should however change the call register from its default (r30) to something more sensible... for EABI-compatibility it should be r3.w2 Nov 25 08:05:01 e.g. in an include used by my py-uio examples I have https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/common.h#L3-L8 Nov 25 08:08:24 Ademan: https://pastebin.com/raw/XY7riamn here's an overview of EABI register use and all other special uses for registers Nov 25 08:10:17 zmatt: I did notice that about r3, thanks! Nov 25 08:13:08 the callee-save registers was exactly what I was looking for, thanks! Nov 25 08:17:05 can't quite fit everything I want in there... oh well, so much for being nice, not like I'm calling any code I didn't write... Nov 25 08:17:44 if you're not calling into C code it doesn't matter Nov 25 08:18:15 if you ever do want to call into C code, just save any non-callee-save registers on stack before the call Nov 25 08:18:25 or swap them out to a scratchpad Nov 25 08:18:52 but really, just save them to stack, since you're calling into C code hence performance evidently doesn't matter there ;) Nov 25 08:19:03 haha Nov 25 08:24:43 I wonder if TI's compiler has improved since last time I've looked at its code output quality Nov 25 08:28:11 Ademan: consider for a moment how you'd implement this in assembly: https://pastebin.com/Lhs0XFqG Nov 25 08:30:25 this is what it produced (at max optimization) last time I did some testing with clpru: https://pastebin.com/raw/UqDLUJJu Nov 25 08:34:47 while the C standard does require the uint16 to be upgraded to int in this case, making the >> an arithmetic shift right, I do feel like it shouldn't be overly burdensome to figure out that the argument can't possibly be negative in this case ;) on top of that, you really don't need 3 instructions to set bit 31 of a register Nov 25 08:36:22 I thought I was losing my mind with that fill+shift left by 31 bits hah Nov 25 08:36:50 and yeah, the SET instruction exists heh Nov 25 08:37:37 holy crap it's late, gonna be useless to the day job... Nov 25 08:37:41 night! thanks! Nov 25 08:37:42 this is probably just a generic sequence for arithmetic shift right that works for both immediate and register shift amounts Nov 25 08:38:03 good night! Nov 25 12:05:55 Hi all! I am a new Beagle Board x15 user! Nov 25 12:06:46 I am trying to work with a scientific GigE camera on the BBx15 but cannot make it work Nov 25 12:08:13 The first problem is I need to enable jumbo frames on one of the two eth interfaces. Anyone knows how to do it? I tried to config the mtu via ip command, but it doesn't work... Seems the value 9000 for mtu is not accepted Nov 25 12:37:01 hmm Nov 25 12:37:06 oh he left Nov 25 12:38:26 well for future reference: jumbo frames are not supported Nov 25 12:38:59 what about dumbo frames? Nov 25 12:52:43 ls Nov 25 12:52:47 whoops Nov 25 15:35:20 https://pastebin.com/DeYXA0PD Nov 25 15:36:19 Im trying to flash bone-debian-9.9-lxqt-armhf-2019-08-03-4gb.img latest debian fail Nov 25 15:36:33 but getting following error Nov 25 16:16:15 ugh, I don't get my hardware until friday, if I'm lucky... I could dig out my old rev A BBB but I still won't have the peripherals :-( Nov 25 16:57:50 Ademan_: womp womp Nov 25 17:25:53 Ademan_: I've gathered notes while exploring the MAC unit: https://github.com/dinuxbg/gnupru/wiki/Multiplication . You may find them useful. Nov 25 17:37:00 dinuxbg_: Cool. Thanks! Nov 25 17:41:58 dinuxbg_: awesome thank you! Nov 25 17:57:52 dinuxbg_: I found more interesting details Nov 25 17:58:56 for example the overflow-flag refuses to clear as long as accumulation is enabled and the most recent MAC operation had carry-out Nov 25 18:00:03 and some other timing curiosities... https://pastebin.com/raw/kVehXj8M Nov 25 18:02:48 (whoops, that first step of "fully reset" should be "0 or 2", not "0 or 1") Nov 25 18:04:58 (and a nop (or some other instruction) is required between the two writes for fully resetting the MAC) Nov 25 18:09:40 oh, since that doc doesn't mention it (anywhere that I saw anyways...) are all* instructions that don't touch memory (sbbo/lbbo et al) still 1 cycle? * Generally speaking. Might be some others that I'm forgetting about, but chiefly ldi, and integer addition,subtraction,bitwise ops, etc? Nov 25 18:10:14 *that doc = am335xPruReferenceGuide.pdf from the git repo containing pasm Nov 25 18:11:12 the only multi-cycle instructions are memory (lbbo/sbbo/lbco/sbco), slp, and in rare cases xin/xout Nov 25 18:12:16 simultanous xin/xout access to the same scratchpad by both cores will cause one of them to stall for a cycle (iirc core 1, check docs) Nov 25 18:12:17 thanks, I assumed as much, but you had mentioned a lot had changed from v0 (which I think all the docs I was looking at were referencing) Nov 25 18:13:26 and direct core-to-core transfer will synchronize the cores, hence one of them will stall unless they happen to execute their xin/xout on the same cycle Nov 25 18:15:46 so the 2 cores doing the same xin/xout can resolve themselves in the same cycle? Nov 25 18:28:54 good question, I'd assume so but never tested it Nov 25 18:39:41 ds2: tested it, no stalls Nov 25 18:40:47 ds2: assuming you mean what I think you mean Nov 25 18:41:35 one core doing xin 14 and the other core doing xout 14 on the same cycle will perform a direct core-to-core transfer that completes in 1 cycle (i.e. without stalls) on both cores Nov 25 19:26:23 Hello, my bbb revC is reading 3.45V from the 3v3 pin after I tried testing it (the wrong way) with a multimeter Nov 25 19:26:48 Is there any services that can repair it or should I just get another one? Nov 25 19:27:19 I verified the multimeter works fine on another voltage source (reads 3.29V on an Arduino 3v3 pin) Nov 25 19:27:35 uhh, I don't see any plausible way you could damage it in a way that raises the voltage... I think the 3.3V on the expansion header tends to be a little on the high side though for some reason Nov 25 19:28:06 though 3.45 does sound a bit high Nov 25 19:28:44 I ran a 1A current test with the multimeter between the 3v3 and GND pins Nov 25 19:29:04 that's definitely not smart Nov 25 19:29:09 briefly, for a few seconds, and it read like 400 mA Nov 25 19:29:18 -_- Nov 25 19:29:19 yeah you can't draw 1A from it Nov 25 19:29:46 And then I tried to do the voltage test but accidentally had the indicator reversed so it was on diode test Nov 25 19:29:52 ugh.... Nov 25 19:36:04 hm, 3.45 would definitely be out of spec for the LDO Nov 25 19:38:03 * zmatt grabs a multimeter to test some beagles Nov 25 19:39:28 what do you guys get from the 3v3 pin? Nov 25 19:43:51 3.40, 3.40, 3.41, 3.39, 3.39, 3.40, 3.43 Nov 25 19:44:04 those are a few beaglebones I tested Nov 25 19:44:33 Oh dang Nov 25 19:44:50 Also, I'm looking at the docs and it says the 3v3 rail can supply up to 400 mA Nov 25 19:45:02 Which is close to what I got on the current test Nov 25 19:45:34 thanks for your help btw Nov 25 19:46:23 this is odd though, based on the resistor values of the feedback voltage divider and the datasheet of the LDO, its output should be 3.33 V, maybe 3.35 V when very lightly loaded, but not 3.40 Nov 25 19:53:48 suppose my 3v3 pin is high, would the voltage values of the logic pins be high? Nov 25 19:54:34 I'll test that later when I'm home I guess Nov 25 19:54:39 nah the digital I/O use a different 3.3V supply that's more accurate Nov 25 19:55:11 oh ok Nov 25 19:55:20 the difference between 3.3V and 3.45V isn't large enough to cause problems anyhow Nov 25 19:55:20 well thats helpfull Nov 25 19:55:22 thank you Nov 25 19:55:42 (typically) Nov 25 23:57:42 zmatt: yes Nov 25 23:58:08 and reg the voltages - look at it on a scope t make sure you don't have a 0.15V ripple induced by something Nov 25 23:58:38 ds2: I've taken scope pictures before, VDD_3V3B was always noticably higher than VDD_3V3A Nov 26 00:00:45 e.g. https://photos.app.goo.gl/1jkt9ubbyBbK4csy2 Nov 26 00:00:46 yes but 0.15V in that case could be from noise Nov 26 00:01:41 that difference is not noise :P Nov 26 00:02:00 (before the shutdown sequence begins) Nov 26 00:05:24 these traces do look a bit fat Nov 26 00:08:23 sure, that part would be noise obviously, the scope was in normal mode, not hires mode Nov 26 00:09:09 what I was getting at is some DMM don't read realistic in the presence of an AC imposed signal Nov 26 00:12:50 perhaps, but the voltage on VDD_3V3B does actually seem to be too high Nov 26 00:14:06 this is also highlighted by the fact that the osd335x, which copied the power circuit from the BBB, actually *specifies* an output voltage of 3.4 V for that rail, presumably reflecting the actual behaviour observed (instead of doing the sane thing of fixing the bugs in the power circuit) Nov 26 00:14:52 heh... I don't bother using that rail on my OSD335x designs Nov 26 00:15:39 that's what I'd recommend too Nov 26 01:24:57 hey, I was interested in exploring the Beagle Bone AI. any suggestions on projects for gsoc Nov 26 02:54:54 https://youtu.be/iBMujYvswHY is the update to the BBBlue in "action" and the updated propeller config. That dang back-left motor turns on its own. Boo! **** ENDING LOGGING AT Tue Nov 26 02:59:57 2019