**** BEGIN LOGGING AT Sat Apr 06 02:59:57 2019 Apr 06 04:22:29 set_, what do you mean by bypassing the bbb? Apr 06 04:22:58 cdc acm creates a serial port over usb that the host can interact with Apr 06 04:24:34 though I think stock bbb sets itself up as usb ether + serial port (?) + mass storage, so you can either ssh in or serial in? Apr 06 04:25:01 so, like, there's no need to set it up manually since it's there by default, unless you're not running stock Apr 06 06:15:31 Kitlith: I'm pretty sure he's connecting a board to the BBB via usb Apr 06 06:20:17 Kitlith: yeah, an MSP-EXP430G2, which has an integrated TUSB3410 usb-to-serial converter Apr 06 06:23:23 d'oh. Apr 06 07:25:53 hm, would it be more efficient to transfer 32 bytes from source to destination or to transfer 4 bytes duplicated 8 times to destination w/ dma Apr 06 07:34:02 the former Apr 06 07:36:29 by a very large margin Apr 06 07:37:52 i am both unsurprised and very slightly disappointed. ah well, there are tradeoffs everywhere. Apr 06 07:38:18 like, the former would take 2 ping-times (one for read, one for write), the latter would take 9 ping-times (8 for read, 1 for write) Apr 06 07:39:08 read-ping-time is likely to be the bottleneck for edma Apr 06 07:39:11 is that behavior in case the src changes between the seperate reads? Apr 06 07:40:03 yeah, if you read the same 4 bytes over and over again, each time will use a separate read-transfer Apr 06 07:40:19 and each transfer controller can only have one read outstanding at any given time Apr 06 07:41:38 so it's probably just faster to have the pru copy them before dma Apr 06 07:41:58 *cough* premature optimization *cough* Apr 06 07:42:09 ;) Apr 06 07:42:20 hahahahaha Apr 06 07:42:27 fair Apr 06 07:42:28 fair Apr 06 07:42:42 pru copying would be *easier* too xD Apr 06 07:42:45 having said that, it's pretty trivial to just write pinmux for all pins into a buffer Apr 06 07:43:29 yeah, i'm just constraining it to the 8 that i'll actually need to change... and their pinmux will be identical. Apr 06 07:43:36 they're about the same I'd say... slightly (but insignificantly) more complicated pru code versus slightly (but insignificantly) more complicated edma setup Apr 06 07:44:07 actually, you might be able to get the best of both words Apr 06 07:44:55 you'll need to test it actually works, but you can probably use fifo mode for the source Apr 06 07:45:55 make sure the buffer is at a 32-byte aligned address (no idea why fifo mode has that restriction but it does), set the src_fifo flag, set fifo_width to 2 (meaning 4 bytes) Apr 06 07:46:17 and otherwise configure a 32-byte transfer Apr 06 07:46:53 with a bit of luck it'll use those 4 bytes to fill the entire transfer, but without performance penalty Apr 06 07:47:12 i swear I just need to archive all my conversations with you as notes for the future Apr 06 07:47:45 either that or the bridge from L3 to PRUSS will turn out to not support this mode and it'll give a bus error or bus lockup ;) Apr 06 07:48:05 if I had to guess though, I think it will support it Apr 06 07:49:10 (note: "fifo mode" aka "constant addressing mode" aka "streaming burst mode" will only work if the configured size matches the width of the L3 target port. In case of PRUSS that's 32-bit, so that's conveniently what you need) Apr 06 07:50:10 it's called fifo mode because it's meant to transfer words into / out of a fifo port, which is often just a single register you read/write repeatedly Apr 06 07:58:58 hm, pru assembly doesn't have any notions of variables in dram, does it. guess I get to manually allocate memory regions. Apr 06 07:59:04 eventually Apr 06 08:05:39 pasm indeed just concerns itself with code, it doesn't generate a data section at all Apr 06 08:05:42 clpru obviously does Apr 06 08:05:50 oh, fifo mode is literally just a bit set saying the address doesn't increment. will definitely give that a try once I actually pull out the beaglebone and am not in preliminary programming mode. Apr 06 08:06:03 clpru, k. Apr 06 08:07:00 ah, the c compiler is also a assembler, nice. Apr 06 08:08:33 well, it's a frontend that invokes the assembler for you (or for the C compiler's assembly output, whichever applies) Apr 06 08:10:25 that reminds me, there was a gcc port for the prus, wonder what the experience using gas for the prus is like. Apr 06 08:10:39 ~~if it's even a thing~~ Apr 06 08:13:58 I don't think anybody uses it Apr 06 08:23:29 i'm not surprised Apr 06 08:28:58 night Apr 06 13:20:35 Hello. Hope you don't mind my questions? Apr 06 13:22:18 Ok. Let's see. Does anybody own a BeagleBoneBlack? Apr 06 13:22:22 rule 1) don't ask to ask, just ask Apr 06 13:22:53 this channel *is* about the BBB, a lot of people here will own one or be familiar with it Apr 06 13:23:21 Next one would be. Does anybody have a BeagleBoneBlue? Apr 06 13:23:49 gee, is this a game or do you have an actual problem you are trying to solve? Apr 06 16:53:22 well, he was called MrQuestions ;) Apr 06 16:57:20 Kitlith: I thought that the software on the MSP430EXPG2 would just run w/out me having to connect to it via my src code on the BBB. Apr 06 16:57:34 If that makes sense. Apr 06 16:59:20 So, ---> BBB src code ---> USB connect ---> to MSP430EXPG2 ---> to src on the MSP430EXPG2 Apr 06 16:59:32 But...I came across complications w/ research. Apr 06 17:02:34 I connected before w/ a TI MSP board but w/ UART header pins and not w/ this USB gadget. TI MSP to BBB via USB... Apr 06 17:04:32 works exactly the same, except you use a different device name (e.g. ttyUSB0 instead of ttyS0. you'll need to check what the correct name is) Apr 06 17:05:01 Okay. Apr 06 17:08:24 it was /dev/ttyACM0. I am pretty sure. Apr 06 18:16:38 does anyone know why the i2c bus is unwriteable on the beagle bone blue? Apr 06 18:17:16 specifically I'm trying to initialize the IMU and I'm getting back a -1 when writing instead of 2 bytes Apr 06 18:20:17 so it's known I'm doing this through python and using the rcpy library. but either way I've exhausted my knowledge and search skills and don't know how to check wheather the correct I2C is even turned on. Apr 06 18:41:41 newbie_: the i2c bus itself should definitely be enabled Apr 06 18:43:26 zmatt: thank you for responding. I think it's enabled as I can detect 0-2 i2c devices using i2cdetect -y -r # Apr 06 18:44:28 so how exactly are you trying to interact with the imu? are you using existing library code for it, or are you trying to write your own? Apr 06 18:48:22 i'm using the rcpy library Apr 06 18:52:37 what I do to initialize is mpu9250.initialize(enable_magnetometer=True) and it fails there with errors of "ERROR: in rc_i2c_write_byte, system write returned -1, expected 2" Apr 06 18:53:30 I'm hypothesizing it's using a quick write vs. a write byte but I need to verify that. Apr 06 19:01:32 looks like it's using the stdio write function to the file descriptor Apr 06 19:29:13 for the MPU9250, maybe it's possible I just have a faulty chip? Apr 06 19:30:37 it's far more likely just a software issue Apr 06 19:31:43 I don't really have time to try to help right now unfortunately, but maybe someone else has. afk, back in an hour or so I think Apr 06 19:32:07 newbie_: oh wait, I do have one idea: are you booting from sd card or eMMC? Apr 06 19:32:45 eMMC Apr 06 19:32:54 zmatt:eMMC Apr 06 19:33:35 ok, just wanted to check quickly. afk now Apr 06 19:33:41 zmatt: and all good. I understand, thank you for the advice you have given me though! much appreciated **** ENDING LOGGING AT Sun Apr 07 02:59:57 2019