C instantiable components and hal_pru_generic

[John Allwine]

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?

[b...@basdebruijn.com]

Hi John,

This is the best place I can find.

Bas

[John Allwine]

Thanks Bas, but I don’t think your link came through!

[b...@basdebruijn.com]

That was pretty silly,
Here it is: https://github.com/machinekit/machinekit-hal/tree/master/src/hal/icomp-example

[Charles Steinkuehler]

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

[John Allwine]

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. 

[mike Kennedy]

Hello All:

If it's ok that I can make a small suggestion? Please forgive me I am still learning Machinekit and mksocfpga so this may not apply.

I have noticed that the Terasic DE10-Nano-Soc Board was on "sale" due to Covid-19, link below. Please let me know if works for you.

http://mail.terasic.com.tw/epaper/2020/limitedtime.html

John: Would it be possible to use the DE10-Nano-SOC Board for your project? 

https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=205&No=1046

This board my help your IO problem as well as have a FPGA Fabric so you can implement multiple Motor controllers or custom HDL code if required.

Just a thought...

Thanks,.

Mike Kennedy.

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/50289540-1f4a-4903-912d-a9c27aed7839%40googlegroups.com.

[Charles Steinkuehler]

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.

>> cha...@steinkuehler.net <javascript:>
>>
>

--
Charles Steinkuehler
cha...@steinkuehler.net