BeagleBone - PRU questions

Question

I will be using at least one programmable real-time unit (PRU) to send pulses to a stepper motor driver but before I begin, I am trying to lay out the structure of my programs.

I am using this library PRU Linux API for loading assembly code into the PRU instruction memory but there doesn't seem to be much documentation other then whats at that wiki and the source: github-pru-packageh

My c program will be calculating the position of the sun using an algorithm and executing the assembly/writing a pulse count to the PRU(s) data memory so they can just switch on/off a gpio at my desired frequency and for the number of pulses required to turn a stepper the appropriate number of steps. I am not even sure if this is an acceptable method but I am pretty new at this and it seems like a simple way to accomplish my task

My Questions regarding the library functions are:

1. Is there a significant performance difference between using prussdrv_map_prumem or prussdrv_pru_write_memory to give the PRU(s) access to the pulse count?
2. Would it be better halt the PRU assembly program after has completed the tasks for each pulse count then re-execute it with new values, or keep the PRU program running and poll for a new pulse count to be written in?

I plan to send a pulse count every 10 seconds or so.

Any suggestions on revisiting the whole structure and logic are welcome as well.

Answer 1

I liked your choice for using BBB for your stepper motor driving project. BBB is the best open source hardware currently available to accelerate your stepper motor speed to upto 200Mhz precision which is like 15 Times faster than what we can get from Arduino or 12MHz Microcontroller. I used PyPruss python Library for my PRU based project where I coded my PRU program in ARM Assembly Language and generated the binary .bin file using PyPruss python Library. Here is an article which best suits for your project Accelerate Stepper Motor on BBB using Pypruss.

You can use the same thing using C++ PRU library, here are some example Assembly code which I wrote for my project:

1. C++ code to send PWM values to the shared memory (Memory shared by processor and PRU's).

2. Assembly code to read values from shared memory and generate realtime PWM values using PRU

Feel free to explore the repository.

Answer 2

I am not familiar with PRU or the PRU Linux API, however, I can give you some general advice.

1. Is there a significant performance difference between using prussdrv_map_prumem or prussdrv_pru_write_memory to give the PRU(s) access to the pulse count?

Most likely yes. If I understood correctly, prussdrv_map_prumem gives you direct access to the PRU memory while prussdrv_pru_write_memory not only does that through a function call, but also has to decode the function arguments at least to know which memory in particular you are writing to.

To know the performance difference, you can put your write operations in an infinite loop, and then for example each 1000 times toggle a GPIO pin. Measure the difference in toggle times with an oscilloscope to see how long 1000 writes took (note that this includes the constant for loop, counter increment, if and gpio write as well). This should give you some measure of which method is faster and by how much.

But you should note two things. First, if you are controlling once every 10 seconds, performance is very likely not an issue for you. Second, you should be aware of any peculiarities with writing to the PRU memory. It is possible (again, I don't know PRU and I'm talking in general) that certain actions need to be taken in a certain order for the write to happen correctly. If you call the library-provided write function, you can be sure they took care of those peculiarities. If you plan on direct memory access, read the datasheet to know if there are any peculiarities and what they are. You can also look at the source code of the prussdrv_pru_write_memory function if available.

2. Would it be better halt the PRU assembly program after has completed the tasks for each pulse count then re-execute it with new values, or keep the PRU program running and poll for a new pulse count to be written in?

If you are planning on doing something useful every 10 seconds, then it's very very energy inefficient to poll instead of halt. Whenever you can halt and be sure somebody will wake you up, by all means do so.