**** BEGIN LOGGING AT Wed Oct 16 02:59:57 2019 Oct 16 06:31:21 zmatt, i've moved that bus open out of the loop Oct 16 06:31:24 no crashes, yet Oct 16 06:31:32 but will need to see this runnign for some time i guess. Oct 16 08:03:34 i have a SSD1327 OLED driver, on i2c.. i'd ike to use it with Pythinm. Oct 16 08:03:41 any good suggestsions for a sw module Oct 16 08:05:34 the first screen of search results when googling for "ssd1327 linux" included this: https://pypi.org/project/luma.oled/ Oct 16 08:07:29 its on my list Oct 16 08:11:52 lol I just remembered I once wrote a library for a similar device (ssd1308) in.... bash. not sure why I thought at the time that was a good idea :P https://pastebin.com/sBYx4LRS Oct 16 08:12:03 lol Oct 16 08:12:04 :-) Oct 16 08:12:26 still bangning my head on trying to choose a mic Oct 16 08:12:47 probably I just wanted to do a quick test of the panel and I let it get out of hand Oct 16 08:13:12 hmm, why is that such a difficult decision for you? what are the options? Oct 16 08:15:04 zmatt. time really! Oct 16 08:15:12 just had too many other things to do Oct 16 08:16:33 but I mean... are you trying to choose between i2s and pdm, or is it about the audio specs? Oct 16 08:18:11 i'll get the adafruit module ( I2s ) to have a play with Oct 16 08:18:40 yeah i2s vs pdm has a big impact on how you need to deal with it softwarewise Oct 16 08:18:53 in deed. Oct 16 08:19:05 i have another problem i need to resolve. Oct 16 08:19:13 how the bees will like or dislike it! Oct 16 08:19:36 they are very industrious at covering stuff they dont' like with propolis Oct 16 08:20:43 I mean... as long as it doesn't move, produce light (you may want to kill the leds... that can be done in software, even the power led!), and doesn't make sound... it's just an oddly shaped rock right? Oct 16 08:21:14 nah.. Oct 16 08:21:24 of course I don't actually know what "it" even is in this context, nor do I know anything about bees :P Oct 16 08:21:45 propolis is 'bee-glue' Oct 16 08:22:01 they stick stuff tiether with it Oct 16 08:22:06 ( as opposed to bee wax ) Oct 16 08:22:14 yeah I googled :) Oct 16 08:22:45 i'm hoping that it might be possible to listen to the hive a bit liek a doctor listens to a human Oct 16 08:22:52 stetoscope stle Oct 16 08:23:09 it might be possible to listen to the bee's hive from the outside Oct 16 08:24:47 the local adadruit distributor had 2 Adafruit I2S MEMS Microphone Breakout - SPH0645LM4H boards in stock Oct 16 08:24:59 i just ordered them Oct 16 08:25:14 adafruit is very very expensive to ship from to me Oct 16 08:26:06 a laser mic might allow you to listen in from a safe distance if the hive has a suitable surface to reflect the laser (or if one can be created without upsetting the bees) Oct 16 08:26:09 ;) Oct 16 08:26:59 I think i2s microphones are really rare... it may be easier to find a pdm microphone since those things are used in pretty much every device that has an embedded microphone Oct 16 08:27:37 "really rare" is maybe a bit overstated.. but much rarer than pdm microphones Oct 16 08:33:53 mems microphones are the new hotness, of course Oct 16 08:34:26 but yeah, not typically i2s, usually pdm Oct 16 08:36:41 zmat.. seems easy to buy them.. i just wanted to buy one on a pcb that was easy to use Oct 16 08:36:47 the mics are easy to buy Oct 16 08:36:53 PDM or I2C Oct 16 08:36:58 orry I2S Oct 16 08:37:32 digikey lists 19 pdm microphones, 6 i2s microphones, and 1 tdm microphone as "Active" parts available as cut tape. (the TDM one allows connecting up to 16 microphones on a single McASP data line, so if you'd use all data lines available for both McASP instances it would support a shitload of microphones without having to involve pru... if we ignore the little detail that alsa doesn't support more ... Oct 16 08:37:38 ...than 16 channels per audio device :P Oct 16 08:37:40 ) Oct 16 08:37:55 yeah but they're surface-mount of course Oct 16 08:39:26 surface mount is not really an issue to me Oct 16 08:40:05 oh wait "pdm" in the mouser catalog means something different from what I expected Oct 16 08:40:11 mouser suck Oct 16 08:40:13 lol Oct 16 08:40:17 sorry, digikey Oct 16 08:40:36 I don't know why mouser was in my head Oct 16 08:41:40 never mind, PEBKAC Oct 16 08:41:45 I selected the filter but didn't apply Oct 16 08:43:50 so... if "the mics are easy to buy" and "surface mount is not really an issue to me" then no need to buy an adafruit module :P Oct 16 08:48:08 actually I think you could probably also use McASP to capture a single PDM microphone, but it would require staring a bit at timing specs to see if one of the configuration options (for both McASP and the mic) happens to line up right Oct 16 08:59:46 zmatt.. easy to buy, and can deal to surface mount.. but i just wanted somethign that i could just plug into to have a mess with first Oct 16 09:03:36 fair :) Oct 16 09:15:09 i have 100,000 bees that i need to listen too. Oct 16 09:15:10 :-) Oct 16 09:17:45 hopefully not individually and simultaneously ;) Oct 16 09:18:53 zmatt: just what i thought too. Oct 16 14:37:30 m Oct 16 15:00:25 zmatt: you said that I need to compile the dtb and then configure it in /boot/uEnv.txt, does this just entail uncommenting the #dtb= line and adding my dtb after it? Oct 16 15:00:47 Going back to how to get the uio working on the BeagleBone AI Oct 16 15:35:58 Ok, I tried it and I think this is correct. I can now almost run one of the py-uio examples Oct 16 15:36:39 But basic-test.py give this error: FileNotFoundError: [Errno 2] No such file or directory: '/dev/uio/pruss/module' Oct 16 15:36:57 I do have the files /dev/uio/pruss1/module and /dev/uio/pruss2/module Oct 16 15:40:11 I changed the pruss = Icss( "/dev/uio/pruss/module" ) Oct 16 16:50:05 Ok, now another question. The beaglebone AI (and the X-15), does it support changing pin modes on the fly? Oct 16 16:50:30 With the BBB this is done with the config-pin function. Oct 16 17:16:21 hunter2018: I guess you skipped the "Copy the uio-pruss-default-instance.conf file to /etc/tmpfiles.d/" step in the README ? Oct 16 17:17:34 that would have created a symlink from /dev/uio/pruss to /dev/uio/pruss1 to allow examples (that don't care about which pruss instance is used) to work on both am335x and am57xx Oct 16 17:30:53 hunter2018: are you not yet aware of the pinmux issues on am57xx or does the issue just not matter for your application? the bone-pinmux-helper driver (used by cape-universal) is, despite its name, is target- and even architecture-independent Oct 16 17:31:54 so you should be able to ues it if you want to Oct 16 17:32:29 changing pinmux at runtime should be no more hazardous than doing so in DT Oct 16 17:35:14 though beware of changing iodelay at runtime... that can lock up the entire system (erratum i933) if some other initiator (dma or another core) is accessing the L4_PER2 interconnect (where the iodelay module is located) at the same time Oct 16 17:46:07 you'll have to create the pinmux helper nodes in your DT though... they're just virtual devices which let userspace select the pinmux state of the pinmux-helper device (from the list of states declared in the corresponding DT node) Oct 16 17:47:02 Thanks! I did copy the uio-pruss-default-instance.conf file to /etc/tmpfiles.d/, so not sure why that didn't make the link Oct 16 17:47:48 I am not aware of the of the pinmux issues on am57xx. What are you referring to? Oct 16 17:47:55 cape-universal creates a pinmux-helper device for each reconfigurable expansion header pin, and each such device has a pinmux state for each mode supported by the pin... but you can also create a pinmux-helper that switches a whole group of pins together Oct 16 17:48:01 huh, that's odd Oct 16 17:48:46 oh, you probably need to update your initramfs (so it'll include this config file) if you're using initramfs Oct 16 17:49:27 I'm not using initramfs (there's not much point, it mostly just slows down boot), so I didn't have that problem Oct 16 17:49:57 I'm just using debian, so I probably am? It isn't a big deal to me. I want to specify the PRUSS manually anyway. Oct 16 17:50:35 and look up erratum i869 and erratum i933 in the am572x errata: http://www.ti.com/lit/er/sprz429l/sprz429l.pdf Oct 16 17:52:11 yes the debian images use initramfs by default Oct 16 17:57:22 Can you point me to where I can learn how to use the bone-pinmux-helper driver and making pinmux helper nodes in my DT? Oct 16 17:57:59 I've never worked with device tree stuff before, as I always just used the config-pin utility on the BBB. Oct 16 17:58:16 Is the bone-pinmux-helper driver related to device tree overlays? Oct 16 17:58:46 in fact, the kernel packages have "Depends: initramfs-tools" (since quite some time ago)... even though they work fine without initramfs (on both bbb and x15)... as a workaround I created a dummy initramfs-tool package ( https://liktaanjeneus.nl/initramfs-tools_1.0_all.deb ) so initramfs isn't forced upon me Oct 16 17:59:00 no Oct 16 18:03:41 Interesting, does initramfs slow boot down that much that it needs to be removed? Oct 16 18:05:16 the bone-pinmux-helper driver is just a driver, and a very simple one as I just explained. overlays just a way to compile some fragments of a DT (instead of the whole thing) and then apply it to the main DT in compiled form... and nowadays that is done by u-boot (historically there was a kernel driver that applied the overlay to the kernel's representation of the DT) Oct 16 18:05:34 iirc it was quite significant yes Oct 16 18:06:59 since boot time on the BBB is dominated by reading data from eMMC. an initramfs usually contains a ton of extra crap that will unconditionally get loaded at boot time (since it's all packed together in one file), while if you don't use initramfs only the files you actually need during boot get loaded Oct 16 18:08:05 almost all the built-in hardware is built-in.. (pru = modules is about it.. for not built-in..) Oct 16 18:08:37 which is why you don't really need an initramfs Oct 16 18:09:35 the main reason to use initramfs is if the kernel can't mount your rootfs with just the drivers that are compiled into the kernel Oct 16 18:11:20 and it helped with old kernels that fucked up mmc host numbering and had unstable mmcblk device numbers, as initramfs lets you select the rootfs by UUID Oct 16 18:15:18 Gotcha Oct 16 18:16:13 It's surprising to me that you know the errata number of that pin glitch off the top of your headlol... Oct 16 18:16:33 I don't, I looked it up Oct 16 18:20:04 Wait... I see I thought there were at least 933 errata, but they aren't numbered sequentially. That's less impressive :) Oct 16 18:22:24 for omap socs TI had the convention of allocating erratum numbers across the entire family, so that an issue affecting multiple devices would have the same erratum number for all of them... and the am572x is omap5-derived hence continued the tradition Oct 16 18:23:28 So I googled pinmux-helper driver and didn't come up with much, but is this enables you do do things like root@beaglebone:~# echo '44' > /sys/class/gpio/export ? Oct 16 18:23:51 no, that's the gpio sysfs interface, that's part of mainline linux Oct 16 18:24:15 btw you normally don't have to export gpios manually since cape-universal already exports all gpios Oct 16 18:24:15 * what enables you to do things like... Oct 16 18:24:20 Ok got it Oct 16 18:24:57 I thought cape-universal was used on the BBB but not the X-15/AI? Oct 16 18:25:34 oh derp, sorry. so the bbai base DTS doesn't contain a gpio-helper to export the gpios for you? pfft Oct 16 18:26:21 I don't know? I can try looking through the base DTS, but I don't know what a gpio-helper looks like Oct 16 18:27:00 so, this is a beaglebone running a system that's still fairly close to the 2018-10-07 iot image (except I've e.g. updated the bb-customizations package iirc), with vs without initramfs: Oct 16 18:27:04 https://liktaanjeneus.nl/boot-initramfs.svg Oct 16 18:27:05 https://liktaanjeneus.nl/boot-noinitramfs.svg Oct 16 18:27:36 5 seconds is a substantial difference, especially since my beaglebones look more like this: https://liktaanjeneus.nl/boot.svg Oct 16 18:28:33 for an example of how gpio-helper works, see https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi Oct 16 18:30:05 here's the one from cape-universal: https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/univ-all-00A0.dts#L2484-L3026 Oct 16 18:30:47 (thanks to a patch of mine, specifying the gpio-name property is no longer required, it will default to the node name) Oct 16 18:33:25 hunter2018: this is how a bone-pinmux-helper instance is declared: https://pastebin.com/raw/8dwZKQei Oct 16 18:33:52 those pinctrl properties are exactly the same as the ones on other devices (for fixed pinmux) Oct 16 18:34:10 except most devices have only one pinctrl state, "default" Oct 16 19:49:54 Thanks! BTW, how did you make those pretty boot time graphs? Oct 16 19:50:07 systemd-analyze plot >boot.svg Oct 16 19:56:46 Cool! That is easier than I thought it would be, Oct 16 20:01:35 * zmatt zZzZ Oct 16 20:45:13 So I'm trying to process all of the pin mode stuff. Is the pinmux helper node what allows the config-pin command to work? Oct 16 20:48:15 So for instance if I run config-pin -l P9.30 Oct 16 20:48:51 However, if I try to set the mode to pruout I get the following Oct 16 21:19:32 Sorry, I got disconnected and I'm not sure my last question went through. Oct 16 21:19:47 I run the following and get: debian@beaglebone:~/bbb-iriggenerator/irigGenerator$ config-pin -l P9.13 Oct 16 21:20:02 So it makes me think I can set P9.13 to be a uart Oct 16 21:20:10 However, when I try I get the following Oct 16 21:20:20 debian@beaglebone:~/bbb-iriggenerator/irigGenerator$ config-pin P9.13 uart Oct 16 23:57:46 zmatt: are you happy with what i'm tying to do here: https://github.com/beagleboard/bb.org-overlays/blob/master/include/dt-bindings/pinctrl/dra.h#L469-L471 Oct 16 23:58:25 Halfway done, i'm thinking of dropping the "non-A" define, and always doing an *A, and have *B when it applies... **** BEGIN LOGGING AT Thu Oct 17 02:28:05 2019 Oct 17 02:28:32 Forget me. I was using local sampling for IO instead of remote. Yikes! **** ENDING LOGGING AT Thu Oct 17 02:59:57 2019