**** BEGIN LOGGING AT Sun Sep 22 03:00:26 2019 **** BEGIN LOGGING AT Sun Sep 22 05:19:40 2019 Sep 22 05:59:12 has anyone done a simple (and open) CIC filter on the PRU? Sep 22 10:36:56 ds2: Check https://github.com/dinuxbg/pru-gcc-examples/tree/master/beaglemic Sep 22 10:56:04 frequency response of CIC filters looks pretty meh... Sep 22 11:04:54 but their simplicity is neat **** BEGIN LOGGING AT Sun Sep 22 13:01:20 2019 Sep 22 21:52:16 dinuxbg: THANKS! Sep 22 21:52:51 exactly what I want to avoid the whole pinmux I2S and ADC disasters Sep 22 22:33:24 ds2: "the whole pinmux I2S and ADC disasters" ? Sep 22 22:46:17 zmatt: yes, the am33 has no muxing options for ADC (plus it is 1.8V only) ; I2S is a scarce resource on the AM33 Sep 22 22:46:33 maybe not so much a muxing issue for I2S Sep 22 22:48:50 i favor having plenty of McBSPs like on the AM/DM35 Sep 22 22:54:21 I don't think they're *that* scarce... one mcasp with 4 serializers and one with 2 serializers allows for interfacing with up to six devices, but you're right they're not as bountiful as they are on many other TI SoCs Sep 22 22:55:10 oh one of those six conflicts with using the on-board audio osc, that's a shame Sep 22 22:57:11 yeah it's not great, but it's not like the rpi which has a single interface with one input line and one output line Sep 22 23:01:30 yes but the functionality is simple enough to move to the PRU Sep 22 23:01:47 the PRU is pretty much designed for this kind of thing Sep 22 23:04:50 just wish the SW interfaces people are pushing is more geared toward this... rpmsg/rpoc is just a PoS for doing soft peripherals Sep 22 23:05:11 oh yeah rpmsg looks horrible Sep 22 23:05:48 also, iirc the pru side code looked like it will break the moment the compiler ceases to be complete shit at optimizing stuff Sep 22 23:05:51 rpmsg is like having a nice corvette with a big U-haul trailer welded onto it Sep 22 23:06:31 sending PRU data to userland is idiotic Sep 22 23:06:57 anyways. I gave up arguing that a long time ago Sep 22 23:07:07 nothing is forcing you to use rpmsg Sep 22 23:07:52 no so much forcing as diverging code Sep 22 23:08:09 direct raw access is slowly being obsoleted Sep 22 23:08:57 we just use a ringbuffer of messages for pru->arm data (located in ddr), with pru writing (a copy of) its write-pointer also to ddr3 and arm writing (a copy of) its read-pointer to pruss memory Sep 22 23:08:59 and all this is wasting time - we need to have a standardize way to offload real time data to a kernel driver... something like a ASOC-DAI for PRU, etc Sep 22 23:09:24 well then make it happen Sep 22 23:09:39 too many projects :D Sep 22 23:10:09 i have hacked up a PRU video interface...still waiting to get that to spit out v4l2 instead of to a /dev char device :D Sep 22 23:10:32 oh actually my ringbuffer is in ocmc, not ddr Sep 22 23:10:44 keeping it out of DDR is a good thing Sep 22 23:11:25 the DDR access is going to be slammed if GPGPU is also going Sep 22 23:12:20 well I think I do that mostly because I know how to reserve a chunk of ocmc in DT and would need to figure out how to reserve a chunk of ddr in DT. I then use uio_pdrv_genirq to a userspace-mmap()able device out of that chunk of memory Sep 22 23:12:33 gpgpu? on the am335x? Sep 22 23:12:40 sure Sep 22 23:12:49 GPU is just another processor Sep 22 23:13:01 an annoying limited instruction vector processor Sep 22 23:13:19 and you'd have to program it using shaders or something Sep 22 23:13:28 I don't see why the PRUSS, SGX, M4 and A8 can't all be put to work Sep 22 23:13:29 is its performance even worth the effort? Sep 22 23:13:49 I agree with you conceptually, but I mean in practice using the available sgx drivers Sep 22 23:13:58 yes, all shader code....the DDR slaming would be transfers Sep 22 23:14:26 I started the work on GPGPU... wish I could have found a GSoC student to finish it up Sep 22 23:14:46 the SGX driver doesn't need to do much Sep 22 23:15:00 so far I'm just using neon for my math needs, and I still have plenty of cpu power to spare Sep 22 23:15:08 so I'm not strongly motivated to try to get gpgpu to work Sep 22 23:15:46 especially since I often want >32 bits of precision and i suspect it won't do that Sep 22 23:16:22 (e.g. a common primitive for me is a dot product of two vectors of 32-bit integers with 64-bit result) Sep 22 23:16:41 I suspect it won'treliably do floating either Sep 22 23:16:50 but some things can be done with fixed point Sep 22 23:18:10 floating-point would be fine too, but it'd have to be double-precision in certain cases Sep 22 23:18:28 an interseting to find out is what is the optimal size to minimize latency for say an SDR app Sep 22 23:18:51 parse error Sep 22 23:18:57 the AM5 is nice but all the reports of heat :( Sep 22 23:19:31 for SDR, processing can happen in chunks of samples... how big of a chunk would be needed to overcome the texture transfer latency Sep 22 23:19:44 below a certain size, it'll be a total waste of time Sep 22 23:19:50 ah Sep 22 23:20:38 and yeah, I can touch the am5 on my x15 for a bit, but it gets painful after a second or so Sep 22 23:20:47 PRU for data acq, A8 sends it to the SGX for initial filtering/decimation, comes back to A8 for final demod Sep 22 23:20:48 and it's basically idle Sep 22 23:21:14 (I have no heatsink or fan) Sep 22 23:21:24 wonder if something is wrong with the SW... its cousins are more manageable Sep 22 23:21:33 maybe Sep 22 23:22:08 I don't think the jetsons get that hot Sep 22 23:22:28 need to get a BB AI to run some comparisons with the jetson for stuff like YOLO **** ENDING LOGGING AT Mon Sep 23 02:59:57 2019