**** BEGIN LOGGING AT Thu Jul 19 03:00:02 2018 Jul 19 03:01:10 sudo show-pins -vv resulted in show-pins command not found. Jul 19 03:01:52 ... did you follow the installation instructions? Jul 19 03:05:23 yes, when i used the installation isntruction it showed "wget:unable to resolve host address 'raw.githubusercontent.com' Jul 19 03:05:51 * zmatt sighs Jul 19 03:07:51 come on, show *some* independent problem-solving ability please. that obviously means your beaglebone doesn't have any internet. if you don't have a wifi to connect it to, just download the file on your computer and transfer it to the beaglebone in some other way Jul 19 03:12:36 sorry, I did not realize that it is not connected to wifi. I connected it earlier but did not recognise that it needs to be connected to wifi every time when it is powered on. Jul 19 03:13:00 that's odd, I'm pretty sure it's supposed to remember the wifi connection and connect automatically Jul 19 03:13:32 but I don't use connman myself so maybe I'm wrong Jul 19 03:18:55 the show-pins -vv command showed P9.42 104 fast rx dwon 4 mmc 0 wp Jul 19 03:20:04 well, then you've configured the pin wrong Jul 19 03:20:35 May I know how to configure the pin to SPI_CS1 Jul 19 03:22:50 you said you've seen my spi1 example in overlay-utils... but clearly you're not *using* that example, or even looked at it to determine the correct configuration, since it shows spi1 cs1 requires mode 2, not mode 4: https://github.com/mvduin/overlay-utils/blob/master/spi1.dtsi#L21 Jul 19 03:28:19 I am sorry to bug you. I am not really sure what are the next steps to be performed in order to use that file. Jul 19 03:32:52 sorry, I'm done with you Jul 19 05:40:45 DO WE HAVE RELIABILITY REPORT OF BEAGLE BONE BLAC Jul 19 06:04:11 ... Jul 19 06:14:36 helo Jul 19 08:29:25 jkridner, zmatt: Hi, few days ago you helped me with manufacturing issue of EEPROM, that makes the WIFI in BB-Blue doesn't work. I bought another board, it's working and the EEPROM is correct. Jul 19 08:29:58 We bought the boards from Digi Key in german. Jul 19 08:42:24 sheena: maybe you should have ordered them in english instead ;-P Jul 19 09:07:06 lol Jul 19 16:50:29 hi Jul 19 16:51:20 i want to about dwc3 usb ip used in beagle board x15 Jul 19 21:42:20 where can I found information about using EDMA in Linux? Jul 20 00:09:57 CoffeeBreakfast: the authoritive reference is of course the TRM, but I think it sometimes explains things more confusing than they need to be, and the official register names look like you smashed your head into the keyboard, so I chose to pick sane names myself while making my headers for edma => https://liktaanjeneus.nl/edma3.h.html Jul 20 00:11:34 I also have quite some amount of comments in there. you may actually want to start by following the link to edma3-tc.h and read at least the bit at the top and the description of a transfer request Jul 20 00:14:42 CoffeeBreakfast: wait, what exactly do you mean by "using EDMA in Linux" ? using EDMA directly from linux userspace, or using edma in kernel code? Jul 20 00:15:09 since in the latter case you just use kernel's dma api Jul 20 00:29:14 MPU: temp reset IMU[0] 5717 0 could mean what? Jul 20 00:29:28 I have been searching for this idea for the BBBlue and arduCopter. Jul 20 00:29:37 I have came up empty so far. Jul 20 00:33:46 yo set_ Jul 20 00:36:49 Hello! Jul 20 00:36:52 GenTooMan! Jul 20 00:37:02 Long time, no beans? Jul 20 00:42:17 zmatt: Maybe I'm thinking in the MCU way, again. I need to trigger a DMA transfer (mem to spi) periodically, every 1 ms Jul 20 00:42:21 hello set_ Jul 20 00:43:25 Coffee! Jul 20 00:43:27 Hello. Jul 20 00:43:31 CoffeeBreakfast: simply doing an spi transfer via the spidev interface every 1 ms is not accurate enough? Jul 20 00:51:14 zmatt: I need to output a pulse, every 1ms, with a max jitter about 15ns (or as best as the reference oscillator of the BBB can), and send SPI data between each pulse Jul 20 00:55:37 you can get much less jitter than that I think for the pulse, but I don't understand the relationship with spi since 15ns is less than even a single bit-time at max clock speed. it sounds like the pulse is a trigger, e.g. for data capture, and subsequently the captured data is transferred via spi... but then the spi transfer itself isn't really timing-sensitive, only the pulse is (which can be made ... Jul 20 00:55:43 ...in hw) Jul 20 00:59:54 It is a arbitrary wave gen (with the AD5676) with 8 channels. The pulse is for synchronize the 8-channels spi data at once. So, the wave gen will have the jitter of that synchronization pulse Jul 20 01:00:22 an arbitrary* Jul 20 01:02:40 set_ well you could say the ethernet card on my pc died in a lightning storm and I found my apple USB network adapter only recently and got it working. Jul 20 01:05:45 CoffeeBreakfast: so the pulse is for LDAC right? (I'm quickly skimming through the datasheet) Jul 20 01:06:14 yes Jul 20 01:08:01 so it's exactly like I said: after the pulse you can transfer the next set of values via spi at your leisure? as long as it's done within 1 ms Jul 20 01:08:17 I suppose it would be more elegant to use dma for this Jul 20 01:08:43 but for a handful of bytes every 1 ms it's certainly not a hard requirement Jul 20 01:11:28 Can a timer start a DMA req? Jul 20 01:14:56 yes, though I think all of them have the slightly annoying requirement that a write to the eoi register of the peripheral is necessary to rearm the dma event, so you need to add a chained dma transfer for that Jul 20 01:16:33 it might actually be simpler to use pru to generate the pulse and transfer the data, but I guess that's a matter of preference Jul 20 01:18:42 I have a somewhat similar piece of code that abuses an eHRPWM peripheral to generate a ws2812 signal by having edma update the pwm's duty cycle every period Jul 20 01:19:23 (yes, with 20/20 hindsight I should *definitely* have used PRU for that instead. I don't know what I was thinking... well, I had no experience with PRU yet I guess0 Jul 20 01:19:26 ) Jul 20 01:20:13 interesting Jul 20 01:20:47 myself: My IMU keeps reseting the temp when I run arducopter and try to connect. Jul 20 01:21:23 I change addresses and the new IMU setting is something different. Jul 20 01:21:43 brb Jul 20 01:23:59 I guess I just need to set up config-pin on the BBBlue, if this makes sense. Jul 20 01:24:07 i.e. MPU: temp reset IMU[0] 5907 0. Jul 20 01:24:38 that required a transfer every 1.25us which has to be done within 0.35 us after the timer event (start of period), so my timing constraints were a bit tighter ;) Jul 20 01:26:08 so, for the IMU, I need to reconfigure 23/24. Jul 20 01:26:16 bbl. Yikes! Jul 20 01:26:19 set_: what are you talking about?! Jul 20 01:26:51 MPU: temp reset IMU[0] 5907 0 is what prints out on my terminal when I run my arducopter program. Jul 20 01:26:58 ... Jul 20 01:27:09 I thought I needed to reset the config-pin utility of the IMU. Jul 20 01:27:28 how on earth do you draw such a conclusion? Jul 20 01:27:34 No idea! Jul 20 01:27:40 Oh. Jul 20 01:27:42 Hold on. Jul 20 01:27:42 the IMU is a fixed part of the blue, there's no user-configurable pin setup involved Jul 20 01:27:49 Oh. Jul 20 01:27:50 Boo! Jul 20 01:27:50 also, if the pins were wrong, you wouldn't be able to communicate with it at all Jul 20 01:27:59 Oh. Jul 20 01:28:20 Is it necessary to change the config of the IMU for any reason? Jul 20 01:28:23 while, based on a quick glance at the source code, that error apparently means there are fifo sync problems Jul 20 01:28:35 Heh? Jul 20 01:28:39 WHere did you look? Jul 20 01:28:47 I googled the error Jul 20 01:28:51 Me too. Jul 20 01:28:51 first hit Jul 20 01:28:58 I only got odd suggestions. Jul 20 01:29:06 https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_InertialSensor/AP_InertialSensor_Invensense.cpp#L420 Jul 20 01:29:09 there's the error Jul 20 01:29:18 Oh yea! Jul 20 01:29:20 Hold on. Jul 20 01:29:22 zmatt: so far, choosing the timer way, it is better from userspace or kernelspace? I think is better kernelspace, with DMA mem reserved (from DT maybe?) Jul 20 01:29:24 and another one elsewhere in that file Jul 20 01:30:16 set_: and the comments above _check_raw_temp indicate the only reason they're reading the temperature sensor is to detect fifo sync issues Jul 20 01:30:41 Oh. Jul 20 01:31:11 well okay, not the only reason, they do use the temperature too Jul 20 01:31:13 it seems Jul 20 01:33:01 What kind of IMU does the BBBlue use? Jul 20 01:33:22 6050 or heh? Jul 20 01:33:45 b/c I get different reads when I change specific software cmds. Jul 20 01:35:00 brb Jul 20 01:36:51 CoffeeBreakfast: using dma in such a way would basically mean having to make a weirdass custom driver for the spi peripheral and timer (or eCAP probably) combined. I'd probably lean toward just setting up the eCAP as pulse generator via uio and on its periodic event perform the transfer via spidev Jul 20 01:37:13 CoffeeBreakfast: if that turns out to be too slow or unreliable, I'd probably use pru Jul 20 01:38:50 pruss conveniently has a local eCAP instance Jul 20 01:42:26 eCAP isn't for capture only? Jul 20 01:42:48 no it can be configured into pwm mode too Jul 20 01:43:13 timers4-7 are likewise either pwm or capture Jul 20 01:46:01 both use a 32-bit counter, but the timers run on the 24 MHz main oscillator while the eCAP instances run on a 100 MHz clock from the core pll (in both cases with optional predivider) Jul 20 01:47:26 9-axis but what is the kind? Jul 20 01:48:08 set_: schematic says MPU-9250 Jul 20 01:48:45 MPU-9250. Oh. Thank you. I found that my schematic only showed 9-Axis. I will keep looking. Jul 20 01:49:23 I got it!@ Jul 20 01:49:37 It was a mixup w/ ideas. Jul 20 01:49:46 zmatt: okay. you mean spidev.h? Jul 20 01:51:28 I mean the appropriate /dev/spidev* device, and yeah linux/spi/spidev.h contains its definitions. you can no doubt also find a bit higher-level wrappers Jul 20 01:53:30 I'm looking for a spi-dma example.. not luck Jul 20 01:53:42 dma wouldn't be used Jul 20 01:54:24 (spidev will automatically use dma for sufficiently large transfers, but that doesn't apply here) Jul 20 01:54:41 oh. right Jul 20 01:55:09 that intel is good (for a MCU guy) Jul 20 01:56:18 you'd simply perform a small transfer every milisecond after the pulse fires Jul 20 02:00:40 so, the thing is, setting a listener for the eCAP event Jul 20 02:00:52 uio Jul 20 02:01:40 no clue :( Jul 20 02:01:45 you probably don't want to use python for this, but nevertheless you may want to look at https://github.com/mvduin/py-uio/blob/master/other-examples/ecap-pwm-test.py Jul 20 02:01:52 doing the same in C isn't much harder Jul 20 02:03:30 though the more I think about it, the more attractive the pru option is getting Jul 20 02:03:49 but in the end there are lots of ways to do this... it's more a matter of finding whatever method you're most comfortable with Jul 20 02:06:03 I'm comfortable with C Jul 20 02:06:31 you can program pru in C if you want Jul 20 02:07:07 I will try both approaches Jul 20 02:08:44 if you're going to bitbang spi on pru then C might give a bit unpredictable transfer rate, but that really doesn't matter in this case. (bitbanging the spi is only one option, the alternative is using an spi peripheral) Jul 20 02:12:48 Ready to Fly! Jul 20 02:13:00 myself: I am ready to fly! Jul 20 02:14:20 https://pastebin.com/PZDLC68G is what printed out. I should be ready except for connections. Jul 20 02:14:58 zmatt: I will learn the PRU's assembly. And, the .py you gave me, is for the ws2812 you mentioned? Jul 20 02:15:14 lol no Jul 20 02:16:29 it's just setting up eCAP in pwm mode (but configured reaeaaaaly slow), and it receives its irqs and prints them (which is why I configured the pwm so slow) Jul 20 02:19:40 One more question: the equivalent in C of "ti.pwmss"? Jul 20 02:21:18 so, some DT declarations are needed to make the ecap peripheral use the uio_pdrv_genirq driver, and one udev rule later you'll have e.g. /dev/uio/pwmss2/module (for the pwmss register space) and /dev/uio/pwmss2/cap (for the irq) Jul 20 02:22:32 you open the first one to mmap() it, the second one is for irqs Jul 20 02:24:40 https://github.com/mvduin/py-uio/blob/master/dts/pwmss2.dtsi this is an example overlay (for use with my overlay-utils) that turns all subdevices of pwmss2 into uio devices, but you can just remove the qep and pwm sections Jul 20 02:25:38 you also need etc/modprobe.d/uio.conf and etc/udev/rules.d/10-of-symlink.rules from this repo Jul 20 02:27:23 once the python example works, you could actually just use py-uio to configure eCAP to generate the desired periodic pulse and irq, and only use C to receive the irq and do the spi transfer Jul 20 02:30:32 i.e. https://pastebin.com/gcCzXSQa Jul 20 02:31:19 wait this is wrong Jul 20 02:31:46 no you still need to map the registers since you need to clear the irq in eCAP.. meh Jul 20 02:36:51 thank you zmatt :D Jul 20 02:37:58 to clear after uio_wfi? Jul 20 02:45:37 CoffeeBreakfast: https://pastebin.com/CKEK5xb8 Jul 20 02:52:09 great Jul 20 02:53:30 so there are two irqs you can get in pwm mode, one for the rising edge and one for the falling edge. I don't know which is which, but you'll want to enable the right one ;) Jul 20 02:53:44 although if you're going to make a crazy short pulse then it won't matter anyway Jul 20 02:58:07 8ns min :P Jul 20 02:58:27 10 ns is the shortest you'll get from ecap Jul 20 02:58:41 hi can i know where can i get usb registers data book for beagleboard x15 Jul 20 02:58:42 good enough **** ENDING LOGGING AT Fri Jul 20 03:00:01 2018