Hal_pru_generic was meant to be generic, not fast, which is why I put
"generic" in the name. :) I had generally intended to make a "fast"
version, but never needed to (the existing PRU logic can drive my 3D
printer step/dir drivers faster than they can accept pulses already!).
Probably the first step for improved performance would be getting the
HAL driver to support multiple PRUs, either using one driver, or perhaps
by making the driver an icomp so you could run multiple instances. This
would let you divide up the work across the PRUs so you could run a
faster cycle rate on each one since it's not doing all the work.
Next would be crafting some new PRU "tasklets" that are less generic
than what's currently implemented. Options would be to only support PRU
direct IO, only support one or two GPIO banks instead of 4+, possibly
unroll some loops to avoid branch/jump (eg: make a 5 stepgen tasklet
instead of using the stepgen tasklet 5 times). This might also be the
easiest solution if you think you can get the performance you need out
of a single PRU.
The final step would be dropping most or all of the existing PRU tasklet
framework and writing something that specifically does *JUST* what you
need, and spread that across several PRUs, eg: Run a 2 stepgen task
across 3 PRUs and get 6 step/dir outputs.
On 4/30/2020 6:14 PM, John Allwine wrote:
I'm not convinced of that. Since the register table is fully allocated it
would likely require swapping registers out to scratch pads and assigning
pin numbers that are larger than a byte (this would significantly affect
the SET_CLR_BIT and PINTABLE implementation) and at the very least adding
twice as many memory writes. I don't fully understand the ramifications of
making some of those changes, but it would certainly have a performance
penalty by writing to more registers, even if it is easy to implement. I'm
concerned with performance, so any modifications that slow down
hal_pru_generic I'd like to avoid. I'm trying to reach high step
frequencies with 5 different axes. I'm hoping to achieve them with
hal_pru_generic, so I'm thinking of even adding build macros so
hal_pru_generic could have access to PRU code that doesn't perform any
memory writes (but rather uses only direct outputs). I'm still testing
what's feasible, but being able to divide up that work between different
PRUs could also be key, so I like the idea of hal_pru_generic being
instantiable.
On Thursday, April 30, 2020 at 3:28:51 PM UTC-6, Charles Steinkuehler wrote:
I think it would be easier to extend the existing logic to simply write
to more registers, but an icomp version of hal_pru_generic could still
be helpful. With four PRU cores in the BBAI, I can definitely see the
benefit to having more than one PRU running either to divide the work or
to allow the PRUs to run with different cycle times.
On 4/29/2020 10:13 PM, John Allwine wrote:
Is there documentation on how to write an instantiable HAL component in
C? I’ve been making modifications to hal_pru_generic to work on the
BeagleBone AI. hal_pru_generic is implemented in such a way that only 4
GPIO ports can be used. The BBB only has 4 GPIO ports, so any pin on the P8
and P9 headers can be used on a single instance of hal_pru_generic. The
BeagleBone AI has 8 GPIO ports, so without significant changes to
hal_pru_generic, not all pins on the P8 and P9 headers can be accessed from
a single instance. The BeagleBone AI does expose many more pins as direct
outputs, but I’m unable to instantiate more than one instance of
hal_pru_generic in order to take advantage of certain pin configurations.
Is it possible to make hal_pru_generic instantiable?
--
Charles Steinkuehler
cha...@steinkuehler.net <javascript:>
--
Charles Steinkuehler
char...@steinkuehler.net
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/machinekit/49ad94d8-1d0d-2477-5980-ce50eeb80378%40steinkuehler.net.
