[Machinekit] pru source code

Discussion:

'Marco Negrini' via Machinekit

2017-03-03 16:22:59 UTC

hi everyone,
i am studying machinekit, in particular on the BeagleBone, i' ve found that
in the CRAMPS.hal file it loads a file for the PRU called pru_generic.bin.
for what i've been able to see, the pru now controls stepgen and pwm
generation.
is there a manual for this libraries for the PRU?

in the directory /usr/lib/linuxcnc/xenomai i' ve found other files like
hal_pru.so or pru_decamux.bin...
searching i have see a manual of linuxcnc
<http://linuxcnc.org/docs/2.7/pdf/LinuxCNC_Manual_Pages.pdf>, i think it
explain something related with this files, does anyone know a more PRU
specific manual?

--
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.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

s***@btinternet.com

2017-03-03 16:36:29 UTC

Permalink

<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 03/03/17 16:22, 'Marco Negrini' via
Machinekit wrote:<br>
</div>
<blockquote
cite="mid:51443e7f-621b-4de1-a60d-***@googlegroups.com"
type="cite">
<div dir="ltr">hi everyone,
<div>i am studying machinekit, in particular on the BeagleBone,
i' ve found that in the CRAMPS.hal file it loads a file for
the PRU called pru_generic.bin.</div>
<div>for what i've been able to see, the pru now controls
stepgen and pwm generation.</div>
<div>is there a manual for this libraries for the PRU?</div>
</div>
</blockquote>
<br>
If you go to the correct site, (machinekit.io -- we are machinekit
not linuxcnc) and search for 'pru' you will find what there is<br>
<br>
The sources are here, you obviously only have a binary image<br>
<a class="moz-txt-link-freetext" href="https://github.com/machinekit/machinekit/tree/master/src/hal/drivers/hal_pru_generic">https://github.com/machinekit/machinekit/tree/master/src/hal/drivers/hal_pru_generic</a><br>
<br>
<blockquote
cite="mid:51443e7f-621b-4de1-a60d-***@googlegroups.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>in the directory /usr/lib/linuxcnc/xenomai i' ve found
other files like hal_pru.so or pru_decamux.bin...</div>
<div>searching i have see a <a moz-do-not-send="true"
href="http://linuxcnc.org/docs/2.7/pdf/LinuxCNC_Manual_Pages.pdf">manual
of linuxcnc</a>, i think it explain something related with
this files, </div>
</div>
</blockquote>
linuxcnc does not know anything about it<br>
<br>
<blockquote
cite="mid:51443e7f-621b-4de1-a60d-***@googlegroups.com"
type="cite">
<div dir="ltr">
<div>does anyone know a more PRU specific manual?</div>
</div>
-- <br>
website: <a moz-do-not-send="true"
href="http://www.machinekit.io">http://www.machinekit.io</a>
blog: <a moz-do-not-send="true" href="http://blog.machinekit.io">http://blog.machinekit.io</a>
github: <a moz-do-not-send="true"
href="https://github.com/machinekit">https://github.com/machinekit</a><br>
--- <br>
You received this message because you are subscribed to the Google
Groups "Machinekit" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a moz-do-not-send="true"
href="mailto:machinekit+***@googlegroups.com">machinekit+***@googlegroups.com</a>.<br>
Visit this group at <a moz-do-not-send="true"
href="https://groups.google.com/group/machinekit">https://groups.google.com/group/machinekit</a>.<br>
For more options, visit <a moz-do-not-send="true"
href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br>
</blockquote>
<br>
</body>
</html>

<p></p>

-- <br />
website: <a href="http://www.machinekit.io">http://www.machinekit.io</a> blog: <a href="http://blog.machinekit.io">http://blog.machinekit.io</a> github: <a href="https://github.com/machinekit">https://github.com/machinekit</a><br />
--- <br />
You received this message because you are subscribed to the Google Groups "Machinekit" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:machinekit+***@googlegroups.com">machinekit+***@googlegroups.com</a>.<br />
Visit this group at <a href="https://groups.google.com/group/machinekit">https://groups.google.com/group/machinekit</a>.<br />
For more options, visit <a href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br />

Charles Steinkuehler

2017-03-03 16:51:01 UTC

Permalink

Post by 'Marco Negrini' via Machinekit
hi everyone,
i am studying machinekit, in particular on the BeagleBone, i' ve found that in
the CRAMPS.hal file it loads a file for the PRU called pru_generic.bin.
for what i've been able to see, the pru now controls stepgen and pwm generation.
is there a manual for this libraries for the PRU?
in the directory /usr/lib/linuxcnc/xenomai i' ve found other files like
hal_pru.so or pru_decamux.bin...
searching i have see a manual of linuxcnc
<http://linuxcnc.org/docs/2.7/pdf/LinuxCNC_Manual_Pages.pdf>, i think it explain
something related with this files, does anyone know a more PRU specific manual?

There are various TI manuals that cover the operation and programming
of the PRU, if that's what you are looking for.

If you are wanting documentation on how the PRU is used in Machinekit,
there isn't anything written up other than the code. You can find the
ARM and the PRU files inside the hal_pru_generic directory:

https://github.com/machinekit/machinekit/tree/master/src/hal/drivers/hal_pru_generic

There is a top level file for each side:

ARM: hal_pru_generic.c
PRU: pru_generic.p

...and each function (pwm, stepgen, encoder) has it's own PRU
"tasklet" (*.p file) and corresponding ARM side driver (*.c file)
which performs a specific function.

When loaded, the driver takes the command line arguments and builds a
task list in PRU memory to implement the desired function(s). This
list also contains any parameters and local storage required for each
"tasklet". The PRU runs through the linked list of tasks then waits
for a timer tick to start all over again. The code should be
reasonably easy to follow, but ask if you have any questions.
--
Charles Steinkuehler
***@steinkuehler.net

Charles Steinkuehler

2017-03-03 19:50:50 UTC

Permalink

Please keep replies on-list.

Post by Charles Steinkuehler
When loaded, the driver takes the command line arguments and builds a
task list in PRU memory to implement the desired function(s). This
list also contains any parameters and local storage required for each
"tasklet". The PRU runs through the linked list of tasks then waits
for a timer tick to start all over again. The code should be
reasonably easy to follow, but ask if you have any questions.

This sounds like a good general purpose method for running a set of
hard-realtime tasks that could be generalized to any uP that is
connected to a larger processor that runs Linux. Of course the
advantage of a PRU is the integration with the Ti ARM chip that you
already have it at zero cost.

Yes, a "main loop" is a very common strategy with micro-controllers
when you don't need a full OS or the complexity of multiple threads.

The configurable task-list and jump table is perhaps a bit novel, but
not particularly unique or original.

Are there any plans to generalize this? If I were doing it I'd use
an ARM Cortex M of some type and maybe SPI. The Cortex M is lots
cheaper then a Mesa FPGA card

I don't particularly have plans to generalize the code. Most of the
code is really either tweaked for the operating environment (see the
PRU step/direction generator for example) or relates to communicating
between the PRU and ARM (and would totally change if you didn't have
shared memory available), so I'm not sure how particularly useful the
code would be on an SPI connected Cortex M.

...and yes, a Cortex M is less expensive than a Mesa card, but you can
get some of the low-end parallel/SPI Mesa cards for $60-70, and they
are *WAY* more powerful than anything you can do on a Cortex-M unless
there's lots of specialized hardware already (like encoder inputs and
PWM outputs).

One question? What is the loop period in the PRU? I suppose one
might be able to adjust it based on the number of tasks that are
linked? But what's typical? I'm just curious about PRU
performance.

The loop period is programmable at load time. It defaults to 10 uS,
but that is very conservative. I typically run with a 2-3 uS period
(still very safe with my typical 3D printer mix of stepgen & pwm),
which allows step rates up to a few hundred KHz. If you need to,
there's a way to see the CPU load on the PRU via one of the direct
output pins (see the hal_pru_generic man page for details), so you can
make sure you don't set the cycle value too low.
--
Charles Steinkuehler
***@steinkuehler.net

Magnus Wiberg

2018-10-08 23:49:50 UTC

Permalink

Hi!
I'm looking to into the source code of hal_pru_generic to modify it to load
the pru code using python with py-uio (so it can work on BBX15), but I'm
having some trouble understanding the source code of the pru
driver/component. My plan is to first make it work with step/dir.

First: the component called hal_pru.c
in https://github.com/jadonk/machinekit/blob/master/src/hal/components/hal_pru.c
has to do with HAL_PRU_GENERIC. (and also, how are the files in machinekit
<https://github.com/jadonk/machinekit>/src
<https://github.com/jadonk/machinekit/tree/master/src>/hal
<https://github.com/jadonk/machinekit/tree/master/src/hal>/support
<https://github.com/jadonk/machinekit/tree/master/src/hal/support>/pru/
used?)

Second: it says in the code that stepgen.bin is loaded onto pru, is this
the compiled pru_generic.p compiled? (It cant be stepgen.c uploaded to pru
since it is not pru code, right?) And how is stepgen.c code used in
HAL_PRU_GENERIC?

Maybe you could tell me what parts of the code I might want to keep? I
guess I can keep the .p code and have to tinker a bit with the memory
sharing, and make the c-code run python program to load the pru code onto
the pru.

(Excuse me if these are stupid questions, but I'm new to programming in C,
especially in larger projects. :) )

Best,
Magnus

Charles Steinkuehler

2018-10-11 04:35:07 UTC

Permalink

In general, the *.p files are PRU assembly code and you will need to use
them (or the assembled PRU binary file). The *.c files are the HAL
driver files used to talk to the PRU, you will likely need to replicate
this functionality in Python if you want to talk directly to the PRU
from Python. The files in hal/support/pru are the pasm assembler
required to assemble the PRU code. There are several versions of pasm
floating around, so it was added to the source tree to make sure a
version with the required features is available.

The stepgen.bin file mentioned is a *VERY* old reference. The PRU code
is now named pru_generic.bin, since it can do more than just generate
step pulses. :)

NOTE: You don't mention what you're doing, but if you're OK talking to
the PRU via HAL instead of directly using Python, HAL already has pretty
great Python bindings. You can load the hal_pru_generic driver, create
nets, drive signals, etc. all from Python. If you really want to talk
directly to the PRU via Python you'll need to re-create the HAL side
driver code in Python.

Post by Magnus Wiberg
Hi!
I'm looking to into the source code of hal_pru_generic to modify it to
load the pru code using python with py-uio (so it can work on BBX15),
but I'm having some trouble understanding the source code of the pru
driver/component. My plan is to first make it work with step/dir.
First: the component called hal_pru.c
in https://github.com/jadonk/machinekit/blob/master/src/hal/components/hal_pru.c
has to do with HAL_PRU_GENERIC. (and also, how are the files in
machinekit <https://github.com/jadonk/machinekit>/src
<https://github.com/jadonk/machinekit/tree/master/src>/hal
<https://github.com/jadonk/machinekit/tree/master/src/hal>/support
<https://github.com/jadonk/machinekit/tree/master/src/hal/support>/pru/
used?)
Second: it says in the code that stepgen.bin is loaded onto pru, is this
the compiled pru_generic.p compiled? (It cant be stepgen.c uploaded to
pru since it is not pru code, right?) And how is stepgen.c code used in
HAL_PRU_GENERIC?
Maybe you could tell me what parts of the code I might want to keep? I
guess I can keep the .p code and have to tinker a bit with the memory
sharing, and make the c-code run python program to load the pru code
onto the pru.
(Excuse me if these are stupid questions, but I'm new to programming in
C, especially in larger projects. :) )
Best,
Magnus
--
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
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

--
Charles Steinkuehler
***@steinkuehler.net

Magnus Wiberg

2018-10-11 15:12:04 UTC

Permalink

I've got a Beagleboard x15 for which there's no uio driver setup, only ti's
remoteproc_pruss, thus the existing HAL_PRU_GENERIC driver won't work as
is. I'm planning to use py-uio (
https://groups.google.com/forum/#!topic/beagleboard-x15/MfB-GMl0UYA ) to
get a UIO for the pru. I thought that I could use the py-uio to load the
*.p code and then communicate to it with the *.c code. My understanding is
that the *.c code communicates with the pru by flipping bits at different
addresses in the arm-processors memmory which are mapped to the pru memory.
If I can get the *.c code flip bits by using the py-uio, It should work
with not too much work, no?
https://github.com/mvduin/py-uio/wiki/Memory-access

It is not that I necessarily want to use python, I just thought using
py-uio might be the easiest way to get pru io working with machinekit.

Also one thing that pusseled me when looking at the code: Is there a limit
to 8 pru channels in the code? I'm asking because I see that in
hal_pru_generic.c
<https://github.com/jadonk/machinekit/blob/master/src/hal/drivers/hal_pru_generic/hal_pru_generic.c> it
says:
// Maximum number of PRU "channels"
#define MAX_CHAN 8
Is there any reason for this, or is 8 just an arbitrary number? I can't see
it being used in the code anywhere. is it even used? (I'm asking since I
will need 12 channels)

Best,
Magnus

Charles Steinkuehler

2018-10-12 12:13:38 UTC

Permalink

The practical limit on the number of PRU channels is the available PRU
memory and how long it takes the PRU to process each channel.

The MAX_CHAN value comes from the software pwm driver and is not
currently used. It is somewhat misnamed, as it does not represent the
number of PWM channels, but the number of PWM timebases available.
Each PWM timebase can have as many channels as you want, but they will
all operate at the same frequency.

If you're not specifically wanting to use Python, I don't think py-uio
will be of much use. What you need is a UIO device-tree definition
for the PRU, which should be easy enough to port over from the BBB.
You can then use the prussdrv library, although it might need a bit of
tweaking if you want to support both PRU subsystems available on the
X15. Another probably easier alternative would be to use libuio,
which would be like using py-uio, except you wouldn't have to recode
everything in python:

https://github.com/Linutronix/libuio

...but I think getting the device tree entries created and using
prussdrv would be the easiest.

Post by Magnus Wiberg
I've got a Beagleboard x15 for which there's no uio driver setup, only ti's
remoteproc_pruss, thus the existing HAL_PRU_GENERIC driver won't work as
is. I'm planning to use py-uio (
https://groups.google.com/forum/#!topic/beagleboard-x15/MfB-GMl0UYA ) to
get a UIO for the pru. I thought that I could use the py-uio to load the
*.p code and then communicate to it with the *.c code. My understanding is
that the *.c code communicates with the pru by flipping bits at different
addresses in the arm-processors memmory which are mapped to the pru memory.
If I can get the *.c code flip bits by using the py-uio, It should work
with not too much work, no?
https://github.com/mvduin/py-uio/wiki/Memory-access
It is not that I necessarily want to use python, I just thought using
py-uio might be the easiest way to get pru io working with machinekit.
Also one thing that pusseled me when looking at the code: Is there a limit
to 8 pru channels in the code? I'm asking because I see that in
hal_pru_generic.c
<https://github.com/jadonk/machinekit/blob/master/src/hal/drivers/hal_pru_generic/hal_pru_generic.c> it
// Maximum number of PRU "channels"
#define MAX_CHAN 8
Is there any reason for this, or is 8 just an arbitrary number? I can't see
it being used in the code anywhere. is it even used? (I'm asking since I
will need 12 channels)
Best,
Magnus

--
Charles Steinkuehler
***@steinkuehler.net