**** BEGIN LOGGING AT Fri Nov 06 02:59:57 2020 Nov 06 15:59:40 anyone have any comment about how hot the bb ai gets/ Nov 06 16:00:00 my thought is that it's fine but i mean, how much margin is there? Nov 06 16:00:05 the ram gets pretty warm too Nov 06 16:00:14 the heatsink is pretty low profile which is obviously a consideration for capes Nov 06 16:00:33 are there capes trap too much heat too? i mean does a cape significantly insulate it Nov 06 16:11:51 I just know there's been a bunch of people with thermal shutdown issues... and I know that it matters significantly whether or not you have the TIDL firmware running (even if unused) Nov 06 16:22:08 oh there has been issues okay Nov 06 16:22:25 i figured there might be when i saw how hot is was running Nov 06 16:23:29 thats obviously pretty disappointing, but since i'm not a cape guy, i'm totally willing to put a fan on this thing Nov 06 16:24:05 and then i can carve out a square whole in any capes that i was urged to make Nov 06 16:25:53 holy shit zmatt someone says "check the 3pin debug connector next to USB C. Customers report solder bridges" Nov 06 16:25:56 sure enough Nov 06 16:41:56 between what and what? Nov 06 16:42:09 that sounds bad Nov 06 16:42:49 yeah theres a solder bridge on j4 which apparently according to this forum post is a debug header Nov 06 16:43:13 ahh but someone says the bridge is normal? it's ont he schema? Nov 06 16:43:35 its still very weird fora bridge to be there in that location, that's a real bridge not a dtrace, although if there was trace underneath it it would have been more likely to bridge Nov 06 16:43:55 might it be the ground pin? Nov 06 16:44:44 i mean the solder bridge is apparently acceptable, those pins are connected eitherway Nov 06 16:44:47 and the official recommendation is a fan Nov 06 16:45:21 okay so indeed the ground pin Nov 06 16:45:47 the whole ecosystems of SoC needs better thermal management Nov 06 16:46:02 well the bbx15 doesn't have thermal issues Nov 06 16:46:14 but it has a lot of surface area Nov 06 16:47:09 i mean it could just be better relief in the pcb itself then Nov 06 16:47:22 I guess it also depends on what you do with it.. like I said, the TIDL firmware makes a big difference because, as far as I could tell, it causes all four EVEs to be continuously running even when it's not actually doing anything Nov 06 16:47:23 the headsink looks a bit oversized Nov 06 16:47:36 I have no heatsink on my bbx15 Nov 06 16:47:49 so its just nice PCB then Nov 06 16:48:01 I guess? Nov 06 16:48:16 it's obviously a lot more spacious Nov 06 16:48:16 big ground planes and stuff connected to thermal relief vias provide a whole ton of heat relief Nov 06 16:48:21 it also makes them sooooooo much harder to solder Nov 06 16:48:34 i mean, without pre-heating the board Nov 06 16:49:12 and i do expect to run this device pretty hot, probably both c66's and nearly 100% cpu usage Nov 06 16:49:16 so i'm going to put a fan on it Nov 06 16:49:34 that sounds wise Nov 06 16:49:52 the antenna needs to be reposition though because i dont think i can have it sandwhiched between the cape and the board Nov 06 16:50:39 just plug one in with a longer lead Nov 06 16:51:35 interesting, the x15 is a 12-layer pcb... that seems like a lot Nov 06 16:52:17 probably a lot easier on the routers.... Nov 06 16:52:18 https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_StackUp.pdf Nov 06 16:52:24 never done more than 4 Nov 06 16:52:53 we went from 4 to 6 mostly to reduce EMI headaches I think Nov 06 16:53:03 i mean it makes a whole lot of sense to be honest Nov 06 16:53:14 nice big ground planes on the outside Nov 06 16:53:17 and 6 isn't that far fetched, like i still feel like your average pcb designer can move from 4 to 6 Nov 06 16:53:49 but i have absolutely no idea what doing a 12 layer board would be like, i mean i feel like sourcing the manufacturing and QC process is phenom more complicated Nov 06 16:54:06 12 layer with blind and buried vias :D Nov 06 16:54:19 judging by the stackup Nov 06 16:54:27 yeah i mean it just like feels like you're designing semiconductor layers at that point Nov 06 16:54:40 i have to NXP based SoCs kinda similiar in form factor and both get pretty hot and come with super beefy heatsinks Nov 06 16:54:47 I mean, it just maens more freedom... and a price tag Nov 06 16:54:51 the google one has a fan built through the center of the heatsink Nov 06 16:55:27 that sounds plain weird Nov 06 16:55:28 i have two invidias too and they have really big thermal control apparatus Nov 06 16:55:32 its nice actually Nov 06 16:55:46 it doesn't go through the heatsink entirely Nov 06 16:55:54 its more like there is a 50% depression to house the fan Nov 06 16:56:51 i have 5 different models of SoC up and I have 1 pi, 1 BB, 2 pocket beagles, 1 BB AI, 1 pi zero, and 2 potential busted pi zeros to put up Nov 06 16:56:58 its just a lot of SD cards to be honest Nov 06 16:57:12 i have the LAN ports :-) Nov 06 16:58:28 you could save the sd cards if you set up tftp boot and nfs root for the whole bunch ;-) Nov 06 16:58:56 well, dunno if the pi can do that Nov 06 16:59:04 almost certainly not now that I think of it Nov 06 16:59:11 since it doesn't have native ethernet Nov 06 17:00:48 there are some options for the pi Nov 06 17:00:57 i'm probably going to drive the pocket beagles over the network Nov 06 17:01:00 and use the sd cards for the pis Nov 06 17:01:06 i also need to source a fan now Nov 06 17:01:19 someone should stock these on tindie or something for the BBB Nov 06 17:01:21 i mean BB AI Nov 06 17:01:43 I thought jkridner had worked on a fan cape for the bbai ? Nov 06 17:03:21 good stuff Nov 06 17:03:54 you're actually going to fully netboot the pocketbeagle? cool, it's something I still want to experiment with. I've gotten as far as getting u-boot SPL then u-boot then FIT (kernel + initramfs + dtb) loaded via bootp/tftp Nov 06 17:04:58 its not my main concern, but id seen an ethernet cape for them so i figured id try Nov 06 17:05:09 i have a lot of side projects and there is no telling what is and isn't going to be actually completed Nov 06 17:05:12 you won't be able to boot from that Nov 06 17:05:36 i believe you Nov 06 17:05:38 lets not get into it Nov 06 17:05:39 i didn't have it working long, but i miss the pocketbeagle for some reason ... think i connected it to something with poor voltage regulation and ... poof. Nov 06 17:05:48 haha Nov 06 17:06:24 the only way to netboot a pocketbeagle is via usb: e.g. I have a server that will automatically bridge any usb network devices to the LAN Nov 06 17:06:53 https://twitter.com/AndrewPikul/status/1324760119297671175 Nov 06 17:07:10 i think at first i could *only* netboot the pocketbeagle ... but that was back when mainline u-boot support was very immature Nov 06 17:07:42 shadow selfie in my TV reflection there Nov 06 17:09:12 ayjay_t: the problem with an ethernet "cape" for the pocketbeagle is that neither of the AM335x native ethernet interfaces are available on the pocketbeagle's headers, so any ethernet cape will probably connect via SPI and in particular will not be supported by bootrom Nov 06 17:09:31 hence cannot be used as boot device Nov 06 17:10:04 oh man i had no idea Nov 06 17:10:19 is the pocketbeagle pin compatible to the bbb Nov 06 17:10:27 no its not Nov 06 17:10:28 huh Nov 06 17:10:32 not remotely Nov 06 17:11:10 https://www.newark.com/element14/6100310/beaglebone-ai-fan-cape/dp/50AH3704?gclid=Cj0KCQiAhZT9BRDmARIsAN2E-J1Jfn9NsCSSxowLcqaasYSsUolLijucj2_5cNvcpqHwz2a41jPUWUMaApbDEALw_wcB&mckv=sGvCA4I5z_dc|pcrid|434136793563|plid||kword||match||slid||product|50AH3704|pgrid|100464451626|ptaid|pla-1011143709834|&CMP=KNC-GUSA-GEN-Shopping-NewStructure-Embedded-Computers-Education-MakerBoards Nov 06 17:11:15 wow that is a terrible link Nov 06 17:11:16 but thats the fan cape Nov 06 17:12:16 alright i'm putting IRC away for a while so i can do what i need to do today Nov 06 17:12:20 https://www.newark.com/element14/6100310/beaglebone-ai-fan-cape/dp/50AH3704 non-terrible version of the link :P Nov 06 17:12:22 ill talk to you all later Nov 06 17:22:08 ayjay_t: but hey, the mii balls are all unused on the pocketbeagle, so maybe you can access them by drilling some extra vias ;-) Nov 06 17:22:18 currently the fan cape is available from Element14/Newark. a new one from Seeed will be available soon. Nov 06 18:28:35 mm302: you might find this interesting: https://github.com/mvduin/py-uio/blob/master/pru-examples/debugging.py Nov 06 18:29:47 it can single-step through a pru program (printing the instruction before executing it and any register changes after executing it), or you can set explicit breakpoints Nov 06 18:31:06 (it currently requires a .dbg output file from pasm) Nov 06 18:32:44 thank you Nov 06 18:33:53 that's very interesting, it's very useful to be able to debug. I do transfer data in memory at the moment and print it later from the host, but not as cool Nov 06 18:34:39 halting debug obviously won't be acceptable for all applications Nov 06 18:35:37 but it can be informativa Nov 06 18:36:00 basically it replaces the instruction ram opcode with halt to set a breakpoint Nov 06 18:36:38 yeah, which is how breakpoints generally work Nov 06 18:39:15 did you write that? Nov 06 18:39:18 yes Nov 06 18:39:40 (py-uio and its examples) Nov 06 18:39:54 cool Nov 06 18:42:01 one possible future idea maybe could be extending that to have a cli interactive debugging session, but I'm aware would be more work then expected Nov 06 18:42:33 I also saw there is a single step mode that would allow to run just one instruction at the time, a bit like gdb stepi Nov 06 18:43:05 yes, which I just mentioned my example supports :P Nov 06 18:43:49 ("19:29 <@zmatt> it can single-step through a pru program ...") Nov 06 18:43:59 just set single=True Nov 06 18:44:46 btw there's also this dusty project from someone: https://github.com/poopgiggle/prudebug originally for the omap-L1xx pruss I think, though someone has Nov 06 18:46:20 *has updated it for the am335x Nov 06 18:49:36 oh I missed that, yes I see setting breakpoints at each instructions works too, nice Nov 06 18:50:13 mm302: I guess it would, but that's just silly since it actually needs to single-step to step out of a breakpoint anyway Nov 06 18:50:23 (see stepping_out_of_bp) Nov 06 18:53:02 I'm not familiar with that Icss class, as I normally use prussdrv, but looks nice to do all that in few lines of code Nov 06 18:53:46 this is basically a pure-python replacement for libprussdrv, except it sucks less and has way more capabilities Nov 06 18:56:56 impartial opinion :-) really I believe you, prussdrv requires more effort to use it Nov 06 18:57:07 of course I'm biased :D Nov 06 18:57:20 I still want to make a good C/C++ replacement for libprussdrv too Nov 06 18:58:09 but anyway, the py-uio examples hopefully speak for themselves, which are summarized in the readme: https://github.com/mvduin/py-uio#uio_pruss Nov 06 18:58:54 unfortunately documentation is a bit sparser than I'd like Nov 06 19:01:04 among its nice features is that it can load both pasm binaries (like libprussdrv) and ELF executables (like remoteproc-pru) Nov 06 19:01:35 it's nice with very few lines of code you can write an app Nov 06 19:02:09 yep, and you can initialize a lot of things from python to minimize the amount of initialization you need to do in pru code Nov 06 19:02:56 and generally speaking program loading isn't exactly performance-critical so python is probably fine for that Nov 06 19:04:38 true, but certain apps require ongoing communication between pru and host, for example I'm working on a capture app that sends pruin values to the arm Nov 06 19:04:39 I still want to make an example of how to perform program loading/monitoring in python but spawn a C/C++ program to consume data from a ringbuffer Nov 06 19:04:46 heh Nov 06 19:05:04 like that ;-) Nov 06 19:07:19 one way would be sharing the external memory with external processes, but not sure if possible Nov 06 19:08:59 you can pass the uio fd, though this does give access to all of pruss unfortunately Nov 06 19:09:38 I mean like shm_open can share some memory between multiple processes, but I'm not sure if this can be done with this special pru_external_memroy Nov 06 19:11:04 multiple processes can open the uio device and map its memory Nov 06 19:13:52 I saw prussdrv opens /dev/uio* to read interrupt events from it, is this the same uio you use? Nov 06 19:14:42 yeah except I don't blindly assume /dev/uio0-7 are the correct devices (which is not true in general) Nov 06 19:16:03 you actually need to supply the path yourself, but my installation instructions include a udev rule that creates sensible symlinks Nov 06 19:17:06 actually to map the pru mem prussdrv seems to use other paths like /sys/class/uio/uio0/maps/map0/addr , I trust it works, too lower level :-) Nov 06 19:17:08 irq handling could still be cleaned up a bit (see intc-test.py and/or intc-test-asyncio.py) Nov 06 19:17:57 well that's technically not required to map it, but rather just to know its physical address Nov 06 19:18:06 though again, hardcoding "uio0" is just terrible Nov 06 19:18:53 uio device numbers are assigned sequentially by the kernel in whatever order they happen to get registered, so if you use uio for a bunch of things then there's absolutely no reason for pruss to be uio0-7 Nov 06 19:18:55 the interrupt code of the prussdrv is very confusing, I understood in the end Nov 06 19:20:08 (I just checked one of our beaglebones, there pruss is uio9-16) Nov 06 19:20:31 prussdrv requires a big one-time-setup table I think? Nov 06 19:22:06 py-uio's initialize() sets up flat 1:1 mapping from channel to output (which is fine for >99.9% of the use cases), and you simply route and enable events as you need them: https://github.com/mvduin/py-uio/blob/master/pru-examples/intc-test.py#L18-L22 Nov 06 19:22:11 yes, the idea is that you can open a uio that is normally 0 for events sent from pru0 -> arm, 1 for pru1 -> arm Nov 06 19:22:53 my example uses a single irq for events from both pru cores Nov 06 19:23:09 I don't see much point in using two file descriptors for that Nov 06 19:23:09 but this is just the default, but there are sysevt -> channel -> host? that is really uio mapping Nov 06 19:24:17 yeah the intc has 64 inputs (events) routed via 10 channels to 10 outputs ("host irqs") Nov 06 19:25:04 for almost all purposes it's fine to use a 1:1 mapping for channels to outputs, and forget about channels after that Nov 06 19:25:21 (and in py-uio such a 1:1 mapping is setup by pruss.initialize() ) Nov 06 19:26:10 the only advantage is if you have 2 separate apps running on pru0 and pru1 that send an event to the host, having 2 files maybe is better? Nov 06 19:26:19 2 of the outputs go to both pru cores (which can read them as bits 30-31 of r31) Nov 06 19:26:29 the remaining 8 go to the cortex-a8 Nov 06 19:27:08 but really in most cases BB is used by a single user and single app too :-) Nov 06 19:27:08 each of those becomes an uio device hence requires a separate file descriptor Nov 06 19:27:14 exactly Nov 06 19:27:33 which is why I'm not using multiple fds in my example Nov 06 19:28:11 but there are use-cases for it obviously Nov 06 19:28:17 that's reasonable, it's worth keeping things simple if possible Nov 06 19:28:43 it's also fairly trivial to adapt the example to multiple fds Nov 06 19:28:58 I'm going to have a break for dinner, cheers Nov 06 21:06:09 I'm not thinking about upgrading yet, but just to know are there other beagle devices with faster PRU/IO pins then the BBB? Nov 06 21:07:09 i.e. faster pru cores Nov 06 21:09:24 not substantially (they're already ridiculously fast on the bbb), but I think they might be 266 MHz on the bbx15/bbai Nov 06 21:09:37 vs 200 on the BBB Nov 06 21:14:20 BeagleBoard-X15 has a lot of other things as well, oh. I was just thinking let's say I'm going to capture at 1Msps with the BBB PRU, if I wanted to increase by 10, not sure what would fit that. Most little boards are not sold with fast microcontroller PRUs Nov 06 21:15:05 I mean, depends on what you mean by "capture" .. BeagleLogic captures pru inputs at 100 Msps Nov 06 21:15:50 (one core samples every other cpu cycle and transfers the data in batches via core-to-core xfr to the other core which writes it out to memory) Nov 06 21:17:26 I'm a bit skeptical it can be that fast Nov 06 21:18:06 why? there's nothing to be skeptical about, it's easy to see how the code works and count the cycles Nov 06 21:19:54 this is the sampling-core's loop for 100 Msps 16-bit mode: https://github.com/abhishek-kakkar/BeagleLogic/blob/master/firmware/beaglelogic-pru1-core.asm#L72-L104 Nov 06 21:20:55 I'm not sure the IOs are actually updated that fast, I saw some kind of 25MHz limit somewhere Nov 06 21:21:37 they're resynchronized, but afaik on the 200 MHz clock and not some subdivision thereof Nov 06 21:22:03 actually I'm quite sure they're resynchronized at 200 MHz and not some subdivision thereof Nov 06 21:24:24 I see, in my case I'll try to use SPI so it takes longer, I was kind of dreaming of building a little oscilloscope one day :-) Nov 06 21:26:00 I may get a speed of 1Msps if I'm lucky, but I will be happy if I make it work, I was wondering if I later could upgrade to let's say 10Msps Nov 06 21:26:44 10Msps means 20 pru cycles per spi clock cycle... what are you spending all that time on? Nov 06 21:27:04 or wait Nov 06 21:27:11 what do you mean by "Msps" in this context? Nov 06 21:27:19 what's the actual protocol? Nov 06 21:28:02 if you want like high-speed ADC you should look for something with e.g. 8-bit parallel output rather than high-speed serial Nov 06 21:31:03 samples per second, where a sample is a set of inputs measured, let's say 4inputs each 16 bits for example Nov 06 21:31:41 but I'm just speculating for now, I'll see more precisely the timings when I have something working Nov 06 21:32:16 most ADC chips seem to use SPI as the only protocol Nov 06 21:33:04 I'm pretty sure most times I've seen people here do things with high-speed ADC it was usually parallel Nov 06 21:35:39 16-bit seems rather high resolution Nov 06 21:38:15 like, I'm browsing analog.com's catalog of 10Msps+ ADCs with parallel output and they start at $2.40 for 8-bit, $2.78 for 10-bit, $25 for 16-bit Nov 06 21:38:54 yes, it can become expensive going faster and increasing bits Nov 06 21:46:01 with a suitable high-speed parallel converter I can see 50 Msps single-channel up to 12-bit being possible Nov 06 21:46:41 (utilizing both pru cores in an architecture similar to BeagleLogic) Nov 06 21:48:59 that's good, cheers Nov 06 21:49:25 see also https://github.com/google/prudaq/wiki Nov 06 21:50:45 looks like they made some different trade-offs Nov 06 21:52:13 excellent Matt, that's a great project I'll defentely look into it closer. Good to know there is room to collect samples faster on the BB with an extra attachment Nov 06 21:53:45 with a different adc you mean? Nov 06 21:54:53 anyway, bbl Nov 06 21:55:35 actually that will provide 2Msps with 4 channels 10bits each, but it's ok still interesting to look at Nov 06 21:55:56 good night Nov 06 22:53:12 i bought the cape for ease but i kind of regret it Nov 06 22:53:16 wanna just get a standalone screw in fan Nov 06 22:59:24 what cape? **** ENDING LOGGING AT Sat Nov 07 03:00:32 2020