**** BEGIN LOGGING AT Fri Jun 29 03:00:00 2018 Jun 29 03:21:15 e Jun 29 11:09:06 I'm trying to get an overlay to work on BBB 4.14. Its in uEnv.txt as uboot_overlay_pru. The overlay used to work under 3.8, but now throws a 'bus error'. Could that be caused by an attempt to read th eprom on the nonexistent cape? Jun 29 12:55:28 no Jun 29 16:28:54 I'm trying to use connmanctl to configure the ethernet interface (eth0) on a Beaglebone Black running Debian 9. But these connmanctl commands only seem to work when the device is connected to a network. Is there any way to configure the ethernet interface while off-line - without an ethernet connection? Jun 29 16:31:08 connmanctl can't configure ethernet when the link is down? lol Jun 29 16:31:36 honestly I don't really understand why connman is used as default network manager in the first place Jun 29 16:31:41 * zmatt is a happy systemd-networkd user Jun 29 18:31:43 What's this PRU thing people are talking about? Jun 29 18:31:50 ...some sort of coprocessor? Jun 29 18:32:44 yes. It a simple processor with very a deterministic (timing wise) instruction set Jun 29 18:33:38 it stands for Programmable Real-time Unit Jun 29 18:33:51 Does it have its own memory or does it run out of the ARM space? Jun 29 18:34:02 both Jun 29 18:34:28 they're two simple 32-bit RISC cores (200 MHz non-pipelined) put into a subsystem together with local memory and various peripherals Jun 29 18:34:40 it has its own memory Jun 29 18:35:28 Do people program those in assembly language? Jun 29 18:35:32 it can access the rest of the SoC, including all external memory, but reading from it is much much much slower than local memory and ruins deterministic timing Jun 29 18:35:54 often yes. it has a really nice instruction set and a fancy assembler (pasm) Jun 29 18:36:05 * lopta writes that down Jun 29 18:36:39 there's also a C/C++ compiler, but its output is that great and of course you lose the absolute deterministic timing you get when coding for PRU in assembly Jun 29 18:36:51 Are PRUs only on the most recent boards? Jun 29 18:37:19 the assembly language is really easy to get the hang of, even if you not terribly familiar with writing ASM in general Jun 29 18:37:20 all beaglebones and the beagleboard-x15 Jun 29 18:37:37 yeah it's a small and sweet instruction set Jun 29 18:37:52 (the beagleboard-x15 actually has *two* instances of PRUSS, i.e. four PRU cores total) Jun 29 18:38:58 thanks to PRU's deterministic timing and the fact that each core has a bunch of GPIOs wired directly into registers, PRU is especially useful for implementing custom external interfaces or protocols Jun 29 18:39:22 I've found that you absolutely have to write the asm for things require the deterministic timing, but the C compiler produces preferctly reasonable asm for everything else Jun 29 18:40:37 What C compiler is used for PRUs? Jun 29 18:40:45 (for non-deterministic use) Jun 29 18:40:45 I've seen the C compiler do pretty dumb things now and then. it also doesn't help that PRU's instruction set was never designed to be targeted by a C compiler. e.g. C tends to encourage the use of signed integers, while PRU lacks any support for them (e.g. no signed comparisons, no sign-extension) Jun 29 18:40:49 I'm using all 4 PRUs on an AM5728 to read/write several million samples/second from/to an radio front end IC Jun 29 18:41:05 clpru Jun 29 18:41:17 kickliter: SDR? Jun 29 18:41:20 yep Jun 29 18:42:34 the PRUs allowed us to avoid having an FPGA in-between the CPU and the front end Jun 29 18:42:45 note that if you want flexibility to choose between pasm and clpru, my py-uio python library is capable of loading both raw binaries produced by pasm and ELF executables produced by clpru: https://github.com/mvduin/py-uio/#uio_pruss Jun 29 18:43:14 kickliter: That's wonderful! Jun 29 18:43:19 before that your choices were: use pasm + uio-pruss + libprussdrv or use clpru + remoteproc-pru Jun 29 18:45:15 lopta: another good showcase of pru's abilities is beaglelogic, which uses PRUSS to turn a beaglebone into a 14-channel 100 Msps logic analyzer Jun 29 18:46:34 (without requiring external electronics, provided the signals you want to capture are 3.3v) Jun 29 18:47:26 As much as I like the PRUs, the lack of non-trivial examples and all the outdated documentation was a real turn-off. Jun 29 18:49:11 Honestly, if I had to do this again, I'd go down a differnet route Jun 29 18:49:20 making PRU more accessible to newcomers was the major motivation for me to make this python lib and its examples Jun 29 18:49:21 kickliter: It sounds as though people are putting them to use though. Jun 29 18:49:58 (making uio in general more accessible was the motivation for py-uio in the first place) Jun 29 18:50:24 yeah. maybe they know something I don't. Or maybe they just don't have as high throughput applications Jun 29 18:50:58 high throughput definitely makes things more complicated, at least if you want to get data out of and (especially) into the pru system at a high rate Jun 29 18:51:29 that's definitely something for which I still want to make a good non-trivial example some day Jun 29 18:53:27 RPMSG/VirtIO could have worked, but its buffers are hard-coded to be 512 bytes, which is a lot of interupts when you're streaming a lot of data. Jun 29 18:55:55 for fixed-rate stream I'd just use ringbuffers and have the ARM side run on a timer rather than exchanging any interrupts between ARM and PRU Jun 29 18:57:45 actually variable rate and/or variable size messages don't complicate things *that* much Jun 29 18:59:05 but I've heard that rpmsg first copies every message received by pru to pruss memory, which explains the message size limit but seems silly to me. such a copy should be left to the user Jun 29 18:59:59 there's also no need to send an interrupt per message. just one from sender to receiver when adding a message to an empty queue, and one from receiver to sender when consuming a message from a full queue Jun 29 19:00:16 silly was the first thing I thought when I noticed that. But reading through the code, it's not difficult to access the underlying virtqueue buffer and avoid the copy Jun 29 19:02:16 of course for getting data to pru, even better performance would be achieved by having the copy be done in the background by EDMA to avoid pru blocking for a lot time on DDR3 reads Jun 29 19:03:18 I really like the circular buffer of buffers that virtio uses. I've never seen that before, and have used that since Jun 29 19:03:50 why? it feels like pointless indirection to me Jun 29 19:05:12 the only potential benefit is that it may allow consuming messages in non-sequential order, but that does mean that the buffer space needs a real memory allocator Jun 29 19:05:50 you have to put the buffer back into the queue when you're done with it Jun 29 19:08:03 right, if all buffers are fixed-size then this allows out-of-order consumption without complicating memory allocation, but it seems like this feature is not likely to be useful for many applications, and it makes everything a lot more complicated than it needs to be Jun 29 19:09:39 for most purposes I'd just say: use one ring-buffer per direction and place messages (whether fixed or variable size) in it directly. in case of variable size, use a "null" message to skip the leftover bit at the end of the ringbuffer if it's too small for the next message Jun 29 19:10:32 this yields the simplest code, best performance, least amount of potential synchronization headaches Jun 29 19:12:23 Honestly, I haven't thought about this in a while, so I can't articulate what I liked about it. Jun 29 19:21:58 do you happen to have a link for the pru side of rpmsg? I'm kinda curious Jun 29 19:22:27 (source code) Jun 29 19:25:33 can't find it. for some reason TI likes to package their code in binary installers and makes it hard to find the source online. Jun 29 19:27:36 the code on this repo might be wildly out of date: https://github.com/PierrickRauby/PRU-RPMsg-Setup-BeagleBoneBlack/blob/master/Codes/Hello_PRU/lib/src/rpmsg_lib/pru_rpmsg.c Jun 29 19:31:05 binary installer is ok. I just didn't immediately find it in google for the reason you pointed out, and I figured you could probably tell me where to get it faster than I can find it ;) Jun 29 19:31:51 or is it part of "pru-software-support-package" ? Jun 29 19:32:00 (debian package) Jun 29 19:32:49 oh it is! Jun 29 19:32:51 never mind that Jun 29 19:34:10 I think at least Jun 29 19:34:34 pru_rpmsg.c and pru_virtqueue.c ? Jun 29 19:35:49 that's them. pru_virtqueue does the work, and pru_rpmsg is the part that prescribes copying + interrupts Jun 29 19:35:53 IIRRC Jun 29 19:37:58 I *think* the virtqueue lives in PRU's RAM for faster reads Jun 29 19:41:15 you mean they put the message queue in PRU ram while putting the message data in external ram? I really hope not, since that would very likely open up a race condition that could result in rare and nearly impossible to reproduce or debug corruption of messages Jun 29 19:41:15 and the actual buffers live in external ram Jun 29 19:42:15 I could be wrong. just going off my memory. none of this documented very well Jun 29 19:42:45 And I never used rpmsg for that reason (documentation) Jun 29 19:43:51 what race condition? something related to caching? Jun 29 19:43:59 in general, keep data pointers in the same memory (either pruss or external) as the data being pointed to Jun 29 19:46:21 in this sequence: sender writes data to A; sender writes data-pointer to pruram; receiver reads data-pointer from B; receiver reads data from A; there is in general nothing guaranteeing that the receiver's data-read request will arrive at A after the sender's data-write request Jun 29 19:46:29 s/pruram/B/ Jun 29 19:47:21 it usually will, but that's just relying on "usually requests on the L3 don't take long to arrive at their destination", not any actual ordering guarantees Jun 29 19:48:20 the sender's write to A may be stuck in heavy traffic, the data-pointer write (which has a different destination hence takes a different route) may overtake it Jun 29 19:49:00 the receiver's data read again takes a different route, and therefore can arrive while the original data-write is still waiting in some queue Jun 29 19:49:41 I hope this makes sense, a diagram would probably help Jun 29 19:49:52 ah, I didn't follow at first, but now it makes sense. like I said. I could be totatlly wrong here, but you're point makes sense. Now I wonder Jun 29 19:50:54 the main point to realize is that the L3 interconnect is just a packet-switched network, and only preserves ordering of messages if they traverse the same path Jun 29 19:52:13 I've never had a mental image of these interconnects until your comment. thanks Jun 29 19:52:57 here's a partial L3 diagram I once found (in some TI slides pdf) of a slightly older SoC that's fairly closely related to the AM335x: https://liktaanjeneus.nl/centaurus-partial-L3F.png Jun 29 19:53:37 I've always been wary of the fact that writes are fire and forget in the PRU. I've been assuming that there could be danger there but wasn't sure. Jun 29 19:54:03 PRU writes to the L3 interconnect are fire-and-forget yes Jun 29 19:54:36 same goes for most writes by the cortex-A8 to the L3 interconnect Jun 29 19:55:00 can the L3 have many 'packets' in flight at a time? Jun 29 19:55:21 yes Jun 29 19:56:23 I don't have any concrete numbers though Jun 29 19:57:21 it could be tested by doing N writes to a target followed by one read to the same target, and measure the typical latency of that read and how it depends on the number of preceding writes Jun 29 19:59:24 I've been pondering about ways to use performance measurements to infer the exact topology of the L3 interconnect, but haven't done anything concrete with it Jun 29 20:00:46 I do have a full list of L3 targets, the full address map from the cortex-A8's point of view, and a list of all L3 firewalls and which target coverage they provide Jun 29 20:01:03 obtained by semi-automated testing using a baremetal program Jun 29 20:02:19 is it a lot of work to get a bare-metal program running on these chips? Jun 29 20:04:07 not really I think, although there's an entry barrier since it can be hard to know where to begin probably :) ROM already initializes the SoC into a fairly sane state, so you don't have to do stuff like setting up the PLLs Jun 29 20:04:40 (link to AM335x L3 information btw: https://goo.gl/3cleN8 ) Jun 29 20:05:31 I actually made a tiny tiny example in pure assembly quite a while ago because someone asked for it: https://github.com/mvduin/bbb-asm-demo Jun 29 20:08:01 even with you saying "tiny tiny", that's way less code than I was expecting Jun 29 20:08:29 apart from that however, normally very little assembly is required. my baremetal code is mostly C++ (restricted subset) with some inline asm here and there. my only assembly source file is for the entrypoint (which sets up the stack) and some thin wrappers around the cpu exception handlers: https://liktaanjeneus.nl/start.S.html Jun 29 20:13:10 most of that asm demo is spent on initializing the gpio controller :) some of that would definitely have been more concise in C/C++ Jun 29 20:15:13 thanks. I gonna go read through this over lunch. Jun 29 20:15:17 in C++ I can actually do nifty stuff: https://liktaanjeneus.nl/iopin-test.cc.html Jun 29 20:17:46 hello can I sell my inventions that I make with the beagle bone legally Jun 29 20:18:09 what a strange question Jun 29 20:18:09 I've been using a lot of `constexpr` in my embedded code these days. I'm working on another uC project that's a mix C++ and Rrst Jun 29 20:18:11 Rust Jun 29 20:18:38 kickliter: constexpr is neat. having to slap it all over the place can get tiresome though Jun 29 20:19:13 I use it with static_assert to a form of compile-time unit testing also Jun 29 20:19:25 to do a Jun 29 20:19:27 but C++ has definitely made progress in making metaprogramming less painful. unfortunately not before SFINAE already became a thing /o\ Jun 29 20:20:23 I can't say I love C++, but I prefer it over plain c Jun 29 20:21:02 I think people who say they love C++ are insufficiently familiar with it Jun 29 20:21:59 or have never used other languages Jun 29 20:23:34 this is a funny moment: https://youtu.be/lkgszkPnV8g?t=29m45s Jun 29 23:26:12 @search books Jun 29 23:26:28 ehm Jun 29 23:26:59 #help Jun 29 23:28:32 #fail Jun 29 23:39:57 I wanted to use some XBee radios on the BBB for control via Python. Do you know of any tutorials/starter ideas on the subjects? Jun 29 23:40:47 I found XBee ideas w/ Python scripts but nothing w/ the BBB. I did find a book a while back on attaching XBee radios to the BBB for using AT commands. Jun 29 23:40:49 ... Jun 29 23:40:57 I misplaced the dang book. Jun 29 23:41:19 Send rations! Jun 29 23:43:38 https://elinux.org/ECE497_Project:_XBee is something I found today. Jun 29 23:43:42 It is nice! Jun 29 23:47:06 http://www.toptechboy.com/tag/xbee/ is another person that promotes testing on the BBB and XBee radios/modules. Jun 29 23:47:08 Yea! Jun 29 23:55:34 never mind...that toptechboy stuff is Ardionuno. Jun 30 00:05:42 probably anything for linux applies Jun 30 00:06:03 it's unlikely you're going to need beaglebone-specific instructions Jun 30 00:06:51 or at least, how do these modules interface? usb? uart? (maybe I should click one of your links...) Jun 30 00:09:26 okay, uart, and it's 3.3v, so that's no problem to connect to the bbb Jun 30 00:10:41 in that case you do need bbb-specific instructions to enable the uart, after that any linux software should work Jun 30 00:11:39 on recent images you'd use config-pin to configure the two pins of whatever uart you choose to use, and that's it Jun 30 00:28:15 Okay. Jun 30 00:28:28 zmatt: I messed up as usual. Jun 30 00:28:51 I added the battery in reverse by accident. Boy, did that radio get hot! Jun 30 00:29:45 The batteries are still hot. Luckily, the XBee cooled off. Jun 30 00:31:58 battery? I didn't see a battery involved in any setup I found while googling Jun 30 00:32:36 I am following along in this book instead. I found some ideas. Jun 30 00:32:54 "The Hands-on XBEE Lab Manual." Jun 30 00:33:14 Jonathon A Titus Jun 30 00:45:07 Something is going on! Jun 30 00:46:18 ... Jun 30 00:46:27 I am sending packets but not w/ the BBB yet and not in Python just yet. Jun 30 00:56:16 radios! Jun 30 02:26:49 No more fun w/ radios for tonight. No! Jun 30 02:50:44 Can someone please try this out? "cd /" and then type "touch me" Jun 30 02:55:42 Come on? Jun 30 02:55:44 Try it! Jun 30 02:56:10 Funny or no? **** ENDING LOGGING AT Sat Jun 30 03:00:03 2018