**** BEGIN LOGGING AT Sun May 20 03:00:03 2018 May 20 03:13:02 Are people dealing w/ the BBB and audio right now? May 20 03:13:07 I have not found the buzz yet. May 20 03:13:49 Rev. B audio Cape is out of date. I found Bela on GitHub.com May 20 03:18:11 Any recognized by the BBB.org people? May 20 04:08:16 evening May 20 13:49:02 set_: well we make audio products that embed beaglebones... I don't see any particular need to be "recognized by the bb.org people" May 20 16:44:54 can any body tell me the login password for debarin image May 20 16:46:14 jass: http://lmgtfy.com/?q=beaglebone+password May 20 21:28:18 Hello all. I have a question about the SLOTS env variable. I searched it for a while and I have almost nothing. I mean, what is it used for? What process reads/writes those values? May 20 21:31:53 uhh what? May 20 21:32:10 what are you talking about? May 20 21:32:40 I don't think I've ever seen or heard of an environment variable by that name May 20 21:34:20 what gives you the impression that such a thing exists? May 20 21:37:20 I think I found it... If I'm right, Capemgr uses that env variable May 20 21:37:54 not as far as I know May 20 21:38:13 capemgr is typically configured via variables in /boot/uEnv.txt May 20 21:38:43 or in former types via a 'CAPE' variable set in /etc/default/capemgr I think May 20 21:38:46 *times May 20 21:39:33 from derekmolloy: root@beaglebone:/lib/firmware# export SLOTS=/sys/devices/bone_capemgr.9/slots May 20 21:40:03 he's just setting that environment variable for his own examples, not for any software on the beaglebone May 20 21:40:19 also that path changed years ago May 20 21:40:31 also the bone_capemgr driver is deprecated entirely May 20 21:41:33 I see... May 20 21:41:37 (overlays, whether for capes or not, are nowadays loaded by u-boot and applied to the main device tree before passing it to the kernel) May 20 21:42:13 I don't understand why he'd use an environment variable there in the first place, presumably a shell variable would have sufficed May 20 21:45:21 Thanks, you saved me May 20 21:46:06 note that if you want to use various peripherals, you typically don't really need overlays anymore to begin with May 20 21:46:44 you can just do e.g. config-pin P9.11 uart to configure that pin to its uart function (uart 4 rxd) May 20 21:48:22 So, overlays are more suitable for custom capes? May 20 21:49:07 there's stuff you can do with overlays that you can't with config-pin May 20 21:50:13 plus overlays are still used to make capes work plug and play May 20 21:51:12 note that when overlays are loaded (whether automatically due to cape autodetection or by manually configuring one in /boot/uEnv.txt), the universal overlay is automatically disabled, so config-pin won't work on the remaining pins May 20 21:56:18 Thanks. One more question: How "direct" is controlling gpio with /sys/class/gpio? Is it suitable for fast/real-time switching? May 20 21:57:38 "fast" and "real-time" are very different things May 20 21:58:24 real-time: probably as good as the rest of your process is going to get May 20 21:58:33 fast: not really, depends on your definition May 20 21:59:37 if you want fast gpio access (at the expense of some safety and portability), use /dev/mem to directly mmap() the gpio controller's registers May 20 22:00:32 if you want even faster gpio along with real-time capability that's orders of manitude better than what you're going to get on linux (even -rt kernels), use the PRU subsystem May 20 22:01:09 That's because there is a driver interfacing writes to /sys/class/gpio? May 20 22:01:32 yes, the userspace<->kernel transition takes time May 20 22:02:39 when using the memory-mapped registers, you can sample, clear, or set any subset of the 32 pins of one gpio controller with a single load/store instruction (the times it takes it the "ping time" to the gpio controller, which iirc is around 150 ns) May 20 22:03:19 the pru cores have gpios wired into registers, which means they can sample or update their gpios every cycle, i.e. 5ns May 20 22:07:03 If I want to use /dev/mem, I'm tied to use a C/C++ program right? May 20 22:08:28 not at all May 20 22:09:25 perl, python, node.js .. all of them have mmap modules May 20 22:09:51 shell scripts? May 20 22:10:02 if you're writing a shell script, performance is irrelevant anyway May 20 22:11:02 Right May 20 22:11:11 but sure, you can use https://github.com/taviso/ctypes.sh if you want ;-) May 20 22:11:18 (scroll down to the end of the readme) May 20 22:13:37 awesome May 20 22:16:46 (in case it's not obvious, this wasn't a serious suggestion) May 20 22:18:09 I was using cint. May 20 22:18:49 And that was fun May 20 22:18:53 o.o May 20 22:19:00 ... but why? May 20 22:20:38 I mean the C interpreter May 20 22:20:51 yes that's what I found when googling May 20 22:22:37 It was fun while playing around when I was learning C programming May 20 22:22:41 fair enough **** ENDING LOGGING AT Mon May 21 03:00:04 2018