**** BEGIN LOGGING AT Fri Jan 05 03:00:01 2018 Jan 05 05:01:40 hi Jan 05 05:10:17 I want to know how to speed up Beagle Bone Black SPI communication. Jan 05 05:10:46 It's not about clock speed Jan 05 05:11:08 It takes a long time between CS pins. Jan 05 05:11:19 Within 9ms, 9840 bytes should be read from the slave. Jan 05 05:11:34 You can read up to 164 bytes at a time. Jan 05 05:11:46 It takes 260us to read 164 bytes and it takes 15ms to read 60by 164bytes. Jan 05 05:11:55 It should read 150 bytes to read 164 bytes. Jan 05 08:24:27 Please help me to get beaglebone black wireless cape drawings. Jan 05 08:38:39 which cape? Jan 05 08:47:42 sp: lol... you are at TI... ask one of your coworkers! Jan 05 14:54:32 heh Jan 05 16:25:54 alo everyone Jan 05 16:54:37 hey Jan 05 16:54:50 I got my i2c issues sorted out, the module was fried Jan 05 16:55:58 yay! Jan 05 16:56:05 at least you weren't insane. Jan 05 16:56:36 yeah now I'm putting it all together into a python flask app. This weekend's mission. Jan 05 16:58:17 And then I started to use platformio to control my Arduino nano from the beaglebone. Very convenient, can do couch-based development now. Jan 05 17:18:16 fasle: pro-tip: prototyping typically goes better with non-fried components ;) Jan 05 17:26:48 Having a known-good reference circuit you can drop things into for a sanity check is invaluable. Jan 05 17:39:12 yeah I thought so as well, got a Arduino nano clone for 7$ and there is a lot less complexity to mess with. Now that it works I am porting the Arduino code over to python on the bone. Jan 05 17:40:47 Regarding that move: Would you rather use Adafruit_BBIO for everything, or go with individual python scripts that talk directly to smbus? Jan 05 17:41:35 does it make sense to get comfortable with Adafruit_BBIO as a whole so I'll be able to more easily use the built in ADC and so on once I do more complex stuff? Jan 05 17:41:41 I'm not sure what you mean Jan 05 17:41:52 I don't hold Adafruit_BBIO in particularly high esteem though Jan 05 17:42:59 but I may be biased... generally the only reason for me to look at any part of it is when people run into problems with it Jan 05 17:43:52 so I could do e.g. `from Adafruit_I2C import Adafruit_I2C` or I could just import smbus and do everything kind of manually, like this script for the TSL2561: https://raw.githubusercontent.com/ControlEverythingCommunity/TSL2561/master/Python/TSL2561.py Jan 05 17:44:09 for i2c I see no reason to use a BBB-specific module, I'm sure there's a generic python module too Jan 05 17:44:44 e.g. that Jan 05 17:45:18 ok then I'll go down the generic path thanks Jan 05 17:45:44 actually, Adafruit_I2C is deprecated according to its source code Jan 05 17:46:58 yeah now it is Adafruit_GPIO.I2C instead Jan 05 17:48:40 which itself is just a wrapper around Adafruit_PureIO.smbus Jan 05 17:49:19 which just seems to be Yet Another Python i2c/smbus lib Jan 05 17:50:05 Yeah the Yet-another-X is strong hehe. I'll get a coffee now and tackle that stuff :) Jan 05 17:50:56 looks very similar to python smbus2 Jan 05 17:51:30 although smbus2 looks nicer Jan 05 17:51:42 (based on a very quick glance at the source code) Jan 05 17:52:39 ok so what this means is that `import smbus` is not the worst way to go right? Jan 05 17:53:42 I haven't looked at python-smbus Jan 05 17:53:50 oh ok nevermind Jan 05 17:54:13 I just compared Adafruit_GPIO.I2C with the first google hit on python smbus, which was actually python-smbus2 Jan 05 17:54:22 which was apparently designed as a replacement for python-smbus Jan 05 17:58:05 finally found this page: https://eewiki.net/display/linuxonarm/BeagleBoard-X15#BeagleBoard-X15-SetupmicroSDcard Jan 05 18:12:30 I guess for my purposes (reading temp, humidity, lux) 1x per second, both libraries would do the job ... will look into it Jan 05 19:13:49 hello Jan 05 19:19:39 I am thinking about using a beaglebone black for a project I am working on, but I am not quite sure if it would be able to meet my requirements. Specifically regarding data acquisition. In this project I will have a 3 channels of 8 bit ADC running at probably 20 megasamples/s, and I would like to read that data into the beaglebone (parallel, over the GPIO pins) in real-time, but I am not sure if the PRUs would be up to the Jan 05 19:19:39 task of moving that much data. I have heard of a project where beaglebone is used as a 14-channel logic analyser at 100megasamples/s, so I guess it should be possible in terms of collective throughput, but I have not been able to find anything about how it performs on a larger parallel bus (in this case, 3*8=24 channels at 20 megasamples/s). Does anybody have some idea about or experience with using the beaglebone for this Jan 05 19:19:40 sort of application? If so, do you think the black is up to the task? Jan 05 19:21:22 Sylph-DS: Have a look at the PRUDAQ and the throughput figures they've managed. Jan 05 19:22:44 I just came across that, I believe they have 2 10-bit ADCs at 20 megasamples/s, which I guess is closer to my goal but still not quite there Jan 05 19:23:28 Do you suspect that PRUDAQ is pushing the envelope, so to speak? Jan 05 19:23:31 Yeah, you're pushing it. I don't know how much more you can squeeze out of it, or what your computational workload is like after you've acquired the samples. Jan 05 19:24:29 I feel like it's one of those things where, in thirty years, some demoscene coder will come along and hand-optimize some code that'll do things nobody initially thought possible with the platform. And the question is whether you want to invest that fanatical optimization. Jan 05 19:24:40 hahaha Jan 05 19:24:47 yeah, not really Jan 05 19:25:47 Can you interleave the samples and use the Beaglelogic code largely unchanged? Jan 05 19:26:06 There's an interesting idea Jan 05 19:27:34 that gains you some certainty about the throughput numbers, at least Jan 05 19:27:57 could probably add a 1-2-3 counter output to select the individual ADCs without affecting timing Jan 05 19:28:42 Yeah, I think I might give that a try. May even be taken care of by the ADC chip I am using. Jan 05 19:28:49 Or I will be using, have not ordererd it yet Jan 05 19:29:00 Thanks Jan 05 19:29:45 It'd be awesome if you could use a PRUDAQ unaltered, just pipe your signals into the mux chips, that would save you a ton of time Jan 05 19:32:15 hmm, well we probably want to choose our own ADCs, because we have some particular timing demands for it Jan 05 19:33:34 gotcha. Three is an interesting number, I can't help but try to speculate about what you're doing. Jan 05 19:33:42 haha Jan 05 19:33:59 R/G/B is the most obvious, or X/Y/Z perhaps, there aren't many other things that come in threes. Jan 05 19:34:41 it's neither of those Jan 05 19:34:45 I don't think there are 24 pru pins available Jan 05 19:34:47 not sure Jan 05 19:35:21 reasonably sure though, the 14 channels for beaglelogic is coming from pinout restrictions, not bandwidth restrictions Jan 05 19:36:14 aha Jan 05 19:36:28 I think that's for one pru core though Jan 05 19:36:41 I thought all gpio pins were accessible by either one or the other pru Jan 05 19:36:47 using both pru cores would increase the number of pins available, but makes offloading data more interesting Jan 05 19:36:50 well, yes and no Jan 05 19:37:13 is that pinout because of how the bone is designed, or would using a bare chip or octavo unit have the same restrictions? Jan 05 19:37:43 all gpios pins are accessible by both pru cores when going through the gpio controller (just like the cortex-a8 would), but this is much much slower than using dedicated PRU I/O, and it doesn't have deterministic timing Jan 05 19:38:06 ah Jan 05 19:38:22 that explains the somewhat arbitrary-seeming 14 pins Jan 05 19:38:34 myself: you can find an overview the PRU pinout options for the AM335x in general and BBB in particular on the PRU tab of my pins spreadsheet: https://goo.gl/Jkcg0w Jan 05 19:39:47 wooh data Jan 05 19:39:51 thanks Jan 05 19:40:21 each PRU core has 17 direct GPIOs available on the AM335x Jan 05 19:40:30 definitely not all of them available on the BBB Jan 05 19:46:34 are there any dev boards that make all those available without having to spin a board yourself? Jan 05 19:47:11 the BBB already makes quite a lot of I/O available Jan 05 19:48:40 I am counting 15 pru 1 inputs here in the sheet Jan 05 19:49:08 Sylph-DS: nope, both have 0-16 Jan 05 19:49:25 unless you mean on the BBB Jan 05 19:49:42 I mean on the BBB yes Jan 05 19:49:58 If it can be avoided, I'd like to not roll my own board ;) Jan 05 19:50:37 it does seem to have 15 rather than 14... I'm guessing they're not using input 16 since it would mean the bits need to be rearranged to be able to write it as a two-byte value into memory Jan 05 19:50:44 which would reduce the max sample rate Jan 05 19:51:07 that's possible Jan 05 19:51:59 yeah it would take 2 instructions extra per sample Jan 05 19:56:03 Right. Well, this has been very informative :) Jan 05 19:56:08 Thank you very much Jan 05 19:56:09 cutting the sampling rate from 100 MHz to 50 MHz would already make a lot more possible Jan 05 19:56:36 would it run well at something like 60MHz as well? Jan 05 19:56:59 Or is the 100MHz a specific function of some other clock Jan 05 19:57:14 the PRU cores are clocked at 200 MHz (max and default) Jan 05 19:57:41 Ah, so 100MHz is simply once every 2 cycles Jan 05 19:57:45 right Jan 05 19:57:49 yeah, it samples every other instruction Jan 05 19:58:29 that's also why they need the second core for offloading data to memory: the primary core simply can't perform any memory access at all since that would take more than a single cycle Jan 05 19:58:40 and it only has a single cycle to spare between each sampling Jan 05 19:59:07 wow Jan 05 19:59:15 they really pushed it Jan 05 19:59:18 yes they did Jan 05 19:59:29 beaglelogic is pretty crazy Jan 05 20:01:15 fortunately the pru cores have a really wide coprocessor bus that they can use to transfer any contiguous byterange of their register file between the two cores or between core and one of the three "scratchpads" Jan 05 20:01:20 in a single cycle Jan 05 20:02:50 so, the first pru samples and tansfers to the scratchpad, and the second pru transfers to the ARM cpu? Jan 05 20:03:04 to RAM Jan 05 20:03:10 right Jan 05 20:04:42 https://github.com/abhishek-kakkar/BeagleLogic/blob/master/firmware/beaglelogic-pru1-core.asm#L72-L104 main sampling loop Jan 05 20:05:16 (for 16-bit width) Jan 05 20:05:53 is the "scratchpad" the 12KB of shared RAM, or the 120-byte register banks? Jan 05 20:07:08 the 12KB is just one of the local memories. the three scratchpads are 120 bytes each Jan 05 20:07:18 ah Jan 05 20:08:07 so a pru core can load or store all of r0-r29 (or contiguous byte-range thereof) from/to any of the three scratchpads Jan 05 20:08:23 in a single cycle Jan 05 20:08:27 in a single cycle Jan 05 20:08:32 that's pretty amazing Jan 05 20:08:57 pru cores can also do indexed load/store into their register file :) Jan 05 20:09:20 so you can e.g. use part of the register file as a small stack Jan 05 20:12:03 PRU cores are pretty sweet Jan 05 20:12:12 looks it Jan 05 20:14:13 So, so I understand properly. The PRU that actually does the sampling can't push to RAM because writes to RAM take too long to happen in between the sampling? Jan 05 20:15:33 yes, iirc it's 1+n cycles to write n words (as long as the interconnect bandwidth isn't saturated) Jan 05 20:16:49 this holds for any writes to outside pruss Jan 05 20:17:54 reads take much longer than that, dozens of cycles, depending on the "ping time" to whatever it is you're reading from Jan 05 20:18:46 Yeah I figured that much Jan 05 20:18:53 have to actually wait for the data to get there :p Jan 05 20:19:08 writes are fortunately "fire and forget" Jan 05 20:21:32 Anyway, I should get going. Thanks a lot for all the information. I suspect I'll be able to use the BBB after all. Maybe I'll be back here again with more questions sometime in the next few weeks ;) Jan 05 20:22:15 See you around Jan 05 20:22:24 o/ Jan 05 21:23:04 Hey, I was looking at scripts, and one of them is flash BBB eMMC to uSD, it says I should be able to insert the uSD after boot, but when I do nothing happens. Jan 05 21:23:53 be more specific, what script are you referring to and what are you expecting to "happen" after inserting the uSD card? Jan 05 21:27:29 So the script is boot-scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh and the google groups link that says I should be able to insert the uSD after boot is https://groups.google.com/d/msg/beagleboard/DuLpDvzrmAE/vgpYQFjbAwAJ Jan 05 21:30:00 so, you're about step two "Insert SD card" Jan 05 21:30:03 *talking about Jan 05 21:30:48 I mean, yes, you should be able to insert the uSD card after boot. if you can't, you may want to inspect the slot to determine what's stuck in there that's preventing you from inserting a card ;P Jan 05 21:31:22 Yeah, if I insert it before boot it tried to boot off the card (so it is seeing it) if I insert it after boot nothing, not even anything in dmesg, was wondering if I needed to change something in uEnv.txt to enable the SD port Jan 05 21:32:03 no message in kernel log? that does sound odd Jan 05 21:32:13 and no, there's nothing you need to enable, it's enabled by default Jan 05 21:36:02 so, there's no /dev/mmcblk0 when the card is inserted? Jan 05 21:37:05 is mmcblk0 not the eMMC? Jan 05 21:37:12 eMMC is mmcblk1 Jan 05 21:37:26 at least, on any not-ancient kernel Jan 05 21:37:37 on older kernels it can be a bit unpredictable Jan 05 21:38:09 yeah the kernel might be quite old Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l GNU/Linux Jan 05 21:38:32 oh you're doing archeology, good to know Jan 05 21:38:56 in that case mmcblk0 is whatever the kernel detected first Jan 05 21:42:22 I can confirm the SD card works in a different system Jan 05 21:43:41 does /sys/kernel/debug/dynamic_debug/control exist on your 3.8 kernel? Jan 05 21:44:52 actually never mind, turning on mmc debug messages is probably a bit hazardous on a typical system, since it would most likely try to also write those to logs on eMMC and end up in a feedback loop Jan 05 21:45:29 it doesn't exist anyway Jan 05 21:45:43 I guess kernel is too old for that Jan 05 21:45:59 let me try and put uEnv.txt onto the sd and reboot the BBB Jan 05 21:46:21 uEnv.txt really should not have any influence over whether the kernel detects the card or not Jan 05 21:47:56 I mean, boot the eMMC from the uSD Jan 05 21:48:29 I understand what you're saying, but I don't see what it could possibly hope to accomplish Jan 05 21:49:16 maybe there's some kind of incompatibility between ancient kernels and sufficiently recent SD cards? similar to the issue that exists between older 3.8 kernels and sufficiently recent eMMC Jan 05 21:51:16 oh, possibly, so putting the uEnv.txt on the uSD let the BBB boot from the eMMC but the linux still doesn't see it. Jan 05 21:51:44 that's exactly what I expected Jan 06 01:07:27 Hey, I have a pocketbone that doesn't boot, bought 2 one boots fine, using the same sd card in the other one, windows pc see's it but it doesn't boot Jan 06 01:52:48 Is there a plan/thread on how beaglebone will patch the meltdown and Spectre incident? Jan 06 01:54:08 does it do out-of-order execution? Jan 06 01:56:55 I can't actually tell by looking up the cortex-A8 whether it could even be affected Jan 06 02:17:13 meltdown is intel only Jan 06 02:17:26 spectre is confirmed on a57 not sure about other arm chipsets Jan 06 02:27:09 https://developer.arm.com/support/security-update Jan 06 02:27:18 ("Variant 3" is Meltdown) Jan 06 02:27:44 oh, he already left Jan 06 02:28:35 myself: out-of-order-execution isn't required, branch prediction suffices Jan 06 02:29:01 Can I RMA a beaglebone or should I just DOA with mouser Jan 06 02:29:03 out-of-order-execution makes the window of opportunity a lot bigger though Jan 06 02:29:42 Jonnyw2k: if you ordered it via mouser, you should probably file your RMA request there Jan 06 02:29:59 Literally arrived yesterday Jan 06 02:30:07 so, short answer yes it's affected, wait for kernel patches like the rest of the world? Jan 06 02:30:54 myself: no, the short answer is: as shown in the table I just linked, the cortex-A8 isn't affected by Meltdown Jan 06 02:31:12 it is *maybe* affected by Spectre ("under review") Jan 06 02:31:46 but fixing Spectre is application-dependent and may just require recompilation once affected applications deal with it Jan 06 02:32:09 gotcha, ok Jan 06 02:34:12 Can I power a pocketbeagle straight off a 3.3v supply? Jan 06 02:34:37 myself: note that all this only matters if a malicious party can execute code on your system, so for many embedded applications it's probably not hugely relevant anyway Jan 06 02:34:51 Jonnyw2k: beaglebones run off 5v, not 3.3v Jan 06 02:35:01 pocketbeagle included Jan 06 02:35:34 I mean't bypassing the LDO onto a 3.3v pin Jan 06 02:36:26 ??? Jan 06 02:36:52 the power-management IC does not accept 3.3v input Jan 06 02:37:41 it requires at least 4.3 V to power up Jan 06 02:38:44 Hmmm, but it runs off 3.7v lipos which can go aslow as 3.2v safely Jan 06 02:41:22 if powered via the battery terminals (which has a lot of caveats) then the pmic will cut off around 3.3v iirc Jan 06 02:43:45 I'm not even sure if using the battery terminals is safe on the pocketbeagle Jan 06 02:47:01 it looks like it isn't. The SYS_VDD1_3P3V output rail of the OSD3358 should not be used when battery-powered, and it is on the pocketbeagle Jan 06 02:47:56 (the issue is actually slightly more subtle: it's still safe, as long as you never power down while battery is attached) Jan 06 02:48:25 zmatt: Definitely acknowledged about the embedded applications; that's a point I've been making in other venues too Jan 06 02:48:59 myself: Spectre also requires really specific instruction sequences to exploit Jan 06 02:50:10 the PoC for Spectre used JIT (specifically eBPF-JIT) to produce suitable sequences, but I don't think that would work on the cortex-a8 since you need a really tight sequence of instructions to exploit it Jan 06 02:50:34 that's where in-order/out-of-order execution makes a big difference Jan 06 02:51:47 I have no doubt that we'll see a lot of refinement of the attach techniques over the coming weeks Jan 06 02:52:03 and much more that we won't see Jan 06 02:53:11 sure, but e.g. on the cortex-a8 you can fit only a very small number of instructions in the speculative shadow of a branch misprediction Jan 06 02:53:24 everything you want to do, you have to do in that window **** ENDING LOGGING AT Sat Jan 06 03:00:02 2018