Are there any PRU scratch pad examples (or source) out there?

GoogleGroups
1

I’m currently trying to us the scratch pad to do some PRU0<–>PRU1 communication. I cannot get it working and I’m worried I’m missing some crucial initialization step of some sort. I’ve got other things working (including interrupts being sent between the two PRU’s), but I can’t get XOUT (or XIN) to work.

Are there any examples or source code I can look at out there doing this successfully.

I’m using a Beaglebone Black if that should matter.

Thanks,
Kent

2

Those instructions work fine for me. I've got a working example in my
PRU code for LinuxCNC. I use the xout instruction to store the GPIO
addresses (which are only used once per task loop but take up four
registers) as part of system setup, the read them in a single
instruction cycle using xin.

Xout example:
https://github.com/cdsteinkuehler/linuxcnc/blob/MachineKit-ubc/src/hal/drivers/hal_pru_generic/pru_generic.p#L201

Xin example:
https://github.com/cdsteinkuehler/linuxcnc/blob/MachineKit-ubc/src/hal/drivers/hal_pru_generic/pru_wait.p#L69

Using the single-stepping debugger available with LinuxCNC, you can see
the instruction working properly.

NOTE: You do need to make sure you're using a version of pasm that
supports these instructions. The first version from TI didn't.

3

Thanks for the reply. I’m a big fan of LinuxCNC btw (use it on a couple of mills at my makerspace), so I think that’s a very cool project.

I should have stated in my post that I did get a newer version of pasm (pasm_2 I think it is) and until then the XOUT was creating an assembler error when it hit the opcode.

I see in your code you’re using scratch pad 0 (the 10 in your instructions). I’m trying to use the direct PRU to PRU version (14) and it’s not working for me. I just tried your approach (pad 0, AKA 10) and it works fine.

Am I wrong in thinking you could use 14 and copy registers directly between the PRU’s?

-Kent

4

I haven't tried doing direct PRU to PRU transfers. Note that it isn't
really in bold print in the documentation, but are you doing an XIN on
one PRU and an XOUT on the other?

If I'm reading things correctly (section 5.2.4.2, top of page 35 in
SPRUHF8A) the first PRU will stall until the other PRU performs the
matching XIN/XOUT instruction, or 1024 clocks go by. So if you're
getting pr1_xfr_timeout events (you should be able to check for this in
the status bits of the INTC, it's interrupt number 3), you're getting
timeouts from not having a "matched set" of XIN/XOUT pairs.

5

I tried doing the matching XIN/XOUT. At first I assumed the matching pairs were actually not required, but I tried it both ways when it did not work. I’m using interrupts between the PRU’s to let the other know when data is available to read, so it’s possible that the timing on these interrupts is making it take longer than 1024 clocks before I get to read.

FWIW, using the PRU’s to do 2D line drawing basically out to DAC’s. PRU1 will be using Bresenham’s line drawing algorithm (no div/multiply required: http://en.wikipedia.org/wiki/Bresenham’s_line_algorithm) between values read from DDR RAM while PRU0 will be bit banging SPI out to the two DAC’s. This should keep both of the PRU’s busy and streamline the process a bit.

Thanks again for the help.

-Kent

6

Kent:

  1. Can you share some code showing PRU0 - PRU1 interrupts?

  2. Did you get the XIN/XOUT transfers between PRUs to work, & can you share the code?