Reverse run on BeagleBone Black

Bosston88 wrote: I found where hal_init sits in LCNC: src/hal/hal_lib.c and hal_xinit in MK: src/hal/lib/hal_comp.c. I'll give it a try to add this function in hal_lib.c, but will it work...?

It's not going to be easy. The HAL engines in both Machinekit and LinuxCNC diverged quite a bit over the years after the fork and now the Machinekit one is quite reworked (with the multicore and instantiable components support, new HAL objects and whatnots). These Init functions are just tips on the icebergs and you will find yourself quickly in a rabbit hole.

The saner approach is to rewrite the actual PRU driver (however I think it uses constructs like ring buffers, so you probably will have to bend the logic).

Tower wrote: It's not going to be easy. The HAL engines in both Machinekit and LinuxCNC diverged quite a bit over the years after the fork and now the Machinekit one is quite reworked (with the multicore and instantiable components support, new HAL objects and whatnots). These Init functions are just tips on the icebergs and you will find yourself quickly in a rabbit hole.

Components written with .comp look exactly the same, though. (Not that the BBB drivers fit into that class)

I asked the hal_pru_generic author for his take on this:

"My guess is it would be dramatically easier to get the hal_pru_generic
driver running on LCNC vs. merging reverse-run into Machinekit."

Bosston88

What are you using as a power supply?

Where do we stand on reverse run if not using a beagle bone?
I found this on youtube:

andypugh wrote: Components written with .comp look exactly the same, though. (Not that the BBB drivers fit into that class)

That's true, but COMP is precompiled sublanguage. I think that it's there for backward compatibility reason as it was superseded by the ICOMP (instantiable components) and now is considered pretty much obsolete.

It probably has something to do with Michael Haberler's idea of not differentiating RT/USERSPACE components but RT/nonRT threads (which cannot be done under RTAI).

andypugh wrote: I asked the hal_pru_generic author for his take on this:

"My guess is it would be dramatically easier to get the hal_pru_generic
driver running on LCNC vs. merging reverse-run into Machinekit."

Well, that's it then. I would take Charles Steinkuehler opinion. He seems very competent.

BTW, is reverse run branch changing code run in RT threads or it is all in higher parts?

Tower wrote: BTW, is reverse run branch changing code run in RT threads or it is all in higher parts?

I don't know for sure, but I am pretty sure that reverse-run hooks in to the adaptive feed mechanism, and that is (necessarily) in the realtime layer.