search

machinekit / machinekit

http://machinekit.io
Other
410 stars 181 forks source link

Fix PRU support on modern kernels #839

Open mhaberler opened 8 years ago

mhaberler commented 8 years ago

The BB PRU support is currently tied to the legacy TI PRUSS driver which has been superseded by the mainstream remoteproc facility

Currently we still use the PRUSS driver on the BB xenomai 3.8 kernel.

As PRUSSv2 is being phased out in favor of remoteproc, we need to adapt the PRU support to remoteproc so we can switch to higher kernel version numbers, for instance to support the BeagleBoard X15 - which we currently cannot, as we are stuck with the 3.8 kernel.

Affected code: mostly hal_pru_generic (stepgen, pwmgen, encoder etc): https://github.com/machinekit/machinekit/tree/master/src/hal/drivers/hal_pru_generic

Rough outline:

Prerequisites:

Effort:

Potential coaches: @cdsteinkuehler @mhaberler (possibly @RobertCNelson, did not ask yet..)

MicroTransactionsMatterToo commented 4 years ago

What's going on in regards to this? The BeagleBone Black and similar devices have a considerable value in the PRU. I still need to look through the code for Machinekit and LinuxCNC, but it seems like it'd be most valuable to make use of the PRU to execute queued move commands, and handle processing of programs on the kernel side, although I seem to remember LinuxCNC doesn't queue much, and works on the fly. The PRU is primarily communicated with through signals and a couple of shared registers, the reference for the assembly is in the Texas Instruments Technical Reference Manual. I'd be eager to take this on as a side project, although I lack the hardware necessary to test it, so I'm not sure how much I could contribute.

cerna commented 4 years ago

@MicroTransactionsMatterToo

(...)but it seems like it'd be most valuable to make use of the PRU to execute queued move commands, and handle processing of programs on the kernel side, although I seem to remember LinuxCNC doesn't queue much(...)

No, it does not and currently the framework for this is missing. But I think that this is on par with @the-snowwhite idea of Machinekit FPGA HAL execution stage as a first citizen neighbour to current threads discussed on the forum.

Kind of problem is that the code changes needed seems huge. And it really needs some principal examples for the use-flow to change. There was multicore support in Machinekit for some time (true, not 100%, but still), but the style of building systems didn't change much. In other words, you would need to provide complex examples for people to start using it.

(...)I'd be eager to take this on as a side project(...)

Please do. I (probably) won't be able to help with PRU programming, but will try with other parts.

MicroTransactionsMatterToo commented 4 years ago

@cerna Right, thanks. I'll have to take some time to look through the codebase first. Any useful docs I could read to help understand the structure of the project?

cerna commented 4 years ago

@MicroTransactionsMatterToo , sorry, but there is none. There are some videos on Youtube (for example there), but that pretty much is it. Only code then. And be aware, some comments in the API code - mainly these 10 years and older - are not to be trusted, as they describe situation from bygone (LinuxCNC) era.

MicroTransactionsMatterToo commented 4 years ago

@cerna @ArcEye Right, having taken a closer look and getting the program to build, I gather the issue is that the Xenomai kernel flavour still uses a deprecated library to interface with the PRU chip. My main question is whether this affects all the kernel varieties, and how, given that there are distributions for the BeagleBone Black above kernel 3.8, those versions are running fine. This is my first time interacting with a project like this. I have a BBB I can run stuff on, although I can't verify the outputs of pins externally or test it with actual CNC machinery. I guess my questions are basically as follows:

darenschwenke commented 4 years ago

I had a freshly downloaded version up and running (generating steps/pwm) on a Beaglebone Green as recently as about a year ago, and I currently run a fully loaded version from about 2016 driving 9 steppers and 5 pwm channels on my Beaglebone Black.

The only issue I have had is occasionally (once every few months), the userspace code reading the ADC stops reporting. The device files that code is reading also stop responding so the problem is deeper than the userspace code. Not sure that ever got fixed, and for me at least, is barely worth looking for.

I will try to get a fresh copy downloaded and test it out for you, but it will be a week before I can get to that.

On Tue, Feb 4, 2020, 11:56 PM Ennis Massey notifications@github.com wrote:

@cerna https://github.com/cerna @ArcEye https://github.com/ArcEye Right, having taken a closer look and getting the program to build, I gather the issue is that the Xenomai kernel flavour still uses a deprecated library to interface with the PRU chip. My main question is whether this affects all the kernel varieties, and how, given that there are distributions for the BeagleBone Black above kernel 3.8, those versions are running fine. This is my first time interacting with a project like this. I have a BBB I can run stuff on, although I can't verify the outputs of pins externally or test it with actual CNC machinery. I guess my questions are basically as follows:

  • How applicable is the discussion from 2015-2016 to the current state of Machinekit
  • Was uio_pruss ever integrated?
  • Is the issue still the same as initially described, given the amount of time that has passed

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/machinekit/machinekit/issues/839?email_source=notifications&email_token=AAYJEQRZZ3S4ZRQEKQHM5STRBJBHLA5CNFSM4BXBBIVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK2EPWA#issuecomment-582240216, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYJEQQVLVZ2C7ZUTSSJTNDRBJBHLANCNFSM4BXBBIVA .

MicroTransactionsMatterToo commented 4 years ago

@darenschwenke Right, thanks. That'd be really useful for me. I have a few steppers lying around, and at least 1 spare driver chip, but outside of that have no external hardware

MicroTransactionsMatterToo commented 4 years ago

Anyone have a suggestion for a cape for the BBB I could use to drive some steppers for testing? I might pick one up if it seems worthwhile

darenschwenke commented 4 years ago

If you are really, really careful, you don't actually need a cape. For the record, the Beaglebones are like five times more sensitive to everything than your average Arduino. Any over voltage or mis-wiring and they are toast. Immediately. But.. they do directly drive step sticks and logic level mosfets just fine. There are a couple capes available for the BBB at least. I personally used the CRAMPS board for that. For the BBG/BBGW there was nothing 100% pin compatible. The early boards made for the BBW came close. All of the above share the trait of not having HDMI, and so those pins/profiles can be used. There was still 2-3 pins which I needed to comment to use those configs. For the BBG/BBGW I committed the mortal sin of directly driving mosfets and stepsticks. In the process of screwing around, I did burn up two of them. Once I stopped making stupid mistakes though, they worked fine until repurposed/shelved.

On Wed, Feb 5, 2020, 6:24 PM Ennis Massey notifications@github.com wrote:

Anyone have a suggestion for a cape for the BBB I could use to drive some steppers for testing? I might pick one up if it seems worthwhile

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/machinekit/machinekit/issues/839?email_source=notifications&email_token=AAYJEQTCJI4A33KD4JLCQDTRBNDEBA5CNFSM4BXBBIVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK5LL2A#issuecomment-582661608, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYJEQWNNNWBOFNWXBXYTIDRBNDEBANCNFSM4BXBBIVA .