**** BEGIN LOGGING AT Wed Apr 13 02:59:57 2022
Apr 13 04:18:18 <pachenkov> Hi,
Apr 13 04:18:18 <pachenkov> I'm trying to use a couple of drv8871 dc motor drivers using the Beaglebone Blue and the robot control library.
Apr 13 04:18:19 <pachenkov> Each driver needs two PWM signals. I've only been able to pinmux the ehrpwm0A,B to the UART2 (GPS).
Apr 13 04:18:19 <pachenkov> However, as far as I can tell from the BeagleBone Blue Pin Table, neither EHRPWM1 nor EHRPWM2 can be pinmuxed to
Apr 13 04:18:20 <pachenkov> any GPIO port on the board.
Apr 13 04:18:20 <pachenkov> So... my question is... Is there any walk around to pinmux those PWM outputs to any GPIO port?
Apr 13 04:18:21 <pachenkov> I've identified that I might need to write my own PRU PWM firmware and use the PRU shared memory to generate the additional PWM outputs... any advice/resources on how to begin with PRU programming?
Apr 13 04:20:16 <zmatt> ah, I knew I had a doc about bbblue pwm: https://pastebin.com/0QQ7VaZu
Apr 13 04:21:59 <zmatt> does the drv8871 have benefits compared to the bbblue's integrated H-bridge drivers?
Apr 13 04:22:47 <zmatt> (I'm not super familiar with the blue, I've never actually worked with one)
Apr 13 04:26:31 <pachenkov> Yes, the integrated H-bridge drivers can be fed up to 12v. I'm using 24v dc motors
Apr 13 04:26:51 <zmatt> ah, yeah that's a good reason
Apr 13 04:30:13 <zmatt> so, as my pastebin shows you could still get a few more hardware pwm signals from the ecap modules, but yeah to go beyond that using PRU would be the logical choice
Apr 13 04:37:05 <pachenkov> ok, cool. I'll give it a try to the ecap modules
Apr 13 04:37:19 <pachenkov> thanks, zmatt
Apr 13 04:38:02 <zmatt> as for starting pru, there's a bunch of options
Apr 13 04:40:48 <zmatt> the current "official" way is using the C compiler, remoteproc-pru, and the rpmsg mechanism for interaction, but this all kinda sucks... using C negates many of the advantages of pru (such as its deterministic timing), afaik remoteproc-pru doesn't support shared memory (unless that's been fixed), and rpmsg is awful
Apr 13 04:42:30 <zmatt> uio-pruss is also still supported, which gives direct access to pru from userspace and in particular therefore does support shared memory.  it can be used with the ancient libprussdrv library (which can only load raw binaries as produced by pasm) as well as my py-uio library (which supports both raw binaries as well as ELF executables produced by clpru)
Apr 13 04:43:55 <zmatt> for writing programs in assembly (which is how PRU was originally designed to be programmed), I'd still prefer pasm over using clpru
Apr 13 05:09:56 <pachenkov> thanks zmatt :)
Apr 13 05:10:37 <zmatt> if interested, my py-uio library can be found here: https://github.com/mvduin/py-uio   it includes both asm and C examples
Apr 13 05:10:48 <zmatt> though (currently) only very simple ones
**** ENDING LOGGING AT Thu Apr 14 02:59:57 2022