03:18 <pachenkov> Hi,

03:18 <pachenkov> I'm trying to use a couple of drv8871 dc motor drivers using the Beaglebone Blue and the robot control library.

03:18 <pachenkov> Each driver needs two PWM signals. I've only been able to pinmux the ehrpwm0A,B to the UART2 (GPS).

03:18 <pachenkov> However, as far as I can tell from the BeagleBone Blue Pin Table, neither EHRPWM1 nor EHRPWM2 can be pinmuxed to

03:18 <pachenkov> any GPIO port on the board.

03:18 <pachenkov> So... my question is... Is there any walk around to pinmux those PWM outputs to any GPIO port?

03:18 <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?

03:20 <zmatt> ah, I knew I had a doc about bbblue pwm: https://pastebin.com/0QQ7VaZu

03:21 <zmatt> does the drv8871 have benefits compared to the bbblue's integrated H-bridge drivers?

03:22 <zmatt> (I'm not super familiar with the blue, I've never actually worked with one)

03:26 <pachenkov> Yes, the integrated H-bridge drivers can be fed up to 12v. I'm using 24v dc motors

03:26 <zmatt> ah, yeah that's a good reason

03:30 <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

03:37 <pachenkov> ok, cool. I'll give it a try to the ecap modules

03:37 <pachenkov> thanks, zmatt

03:38 <zmatt> as for starting pru, there's a bunch of options

03:40 <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

03:42 <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)

03:43 <zmatt> for writing programs in assembly (which is how PRU was originally designed to be programmed), I'd still prefer pasm over using clpru

04:09 <pachenkov> thanks zmatt :)

04:10 <zmatt> if interested, my py-uio library can be found here: https://github.com/mvduin/py-uio it includes both asm and C examples

04:10 <zmatt> though (currently) only very simple ones