Adding PRU support for scripting languages

Google Summer of Code
1

Hi,

While scanning through the list of GSoC organizations, I noticed that Beaglebone is also among it. I have some experience with that board (although I never really used the original BBB firmware). In a university project, I worked (with 3 other people) on writing a Multi-Server system for the Beaglebone Black using the L4 Mikrokernel as base platform and writing GPIO, MMC and Network servers from scratch.

For my GSoC project I would want to work a bit more with Linux (I have experience cross-compiling Linux and with driver development). The PRU is an element of the BBB that always bugged me a bit because those two processors are just two too many to waste.

I scanned through the Ideas list and could not really find what I was looking for. Some ideas seem to overlap and some are not really new (I have a CNC machine running on linuxcnc/BBB in my basement).

The main problem with the PRU is, in my opinion, the lack of easy access to it. Writing assembly for it is difficult, there is a C compiler from TI but it is yet an other compiler, and so on. What we would need is a simple option to use the PRU to do specific tasks.

I like the idea of prudoino here, which aims to be a library that provides basic functions. This would also require us to have an easy way to communicate with the PRU, so therefore this requires the PRU bridge project (although pruduino already has this implemented)

My questions so far about this:

  • Should it be possible to include logic in the PRU itself? It would be nice to have the emergency-stop switch working if the CPU freezes ;-).
  • Is a scripting framework for the PRU itself needed (like a simple interpreter or a primitive ‘compiler’ that combines the assembly code on the fly, not as powerful as gcc)
  • How real time does it have to be? Especially adding custom
  • Are there any applications (besides CNC) that should be implemented?

My current solution would be to add a new node.js based framework. It would be possible in this framework to describe tasks and their relation to each other (sort of an state machine). I don’t know about the syntax yet, but I opt for something object-oriented so that the object structure is then mapped to a PMU code.
A possible scenario would be:

Entry point:
Turn the LED on.
1s later: label1

label1:
Branch if the key is pressed.
yes => 1s later: label1
no => 1s later: label2

label2:
Turn the LED off.
Wait for key to be pressed
Go to Entry point.

All blocks would be compiled to assembly instructions doing that specific action. We might introduce local, static variables. Time should be based on the start of that state, so that even better timings should be possible. Communication with the PRU might be possible by either message passing (a simple FIFO buffer) or shared memory between PRU and CPU.

What are your thoughts on this. Can this be combined into a GSoC project?

Regards,
Michael Zangl (KIT, Karlsruhe, Germany)

2

Have you seen pruspeak? Do you think it could be extended easily for machine control with steppers and PID loops? Do you think it could be integrated with Machinekit and ROS? Just trying to bring you into some more recent work.

3

Hi Jason,

Thanks for the reply and pointing to those projects.

I have seen pruspeek but did not have a deeper look at it.

Machine control with steppers does not require a high frequency, so it might even work with the current features. What might be missing is the ability to schedule the commands at a fixed rate. Since you do not know how long commands take to execute and don’t have an external reference (like the cycle counter), this makes step generation more difficult and would have to be added. Of cause, this would be software step generation.

A software PID loop should not be that difficult. The main problem I see is controlling 6 steppers in this environment, since writing a program for pruspeek to interpret would only allow for low step rates.

This is why I proposed to write sort of an on-the-fly compiler that can then add such basic tasks (like step/bus data generation and input capturing) in the code in a way that it is regularly checked (like every 40 cycles => 5MHz). The normal program interpretation would then be interleaved with those commands (e.g. each interpreter step taking 30 cycles and each capture taking 10, using fast enough data structures and separate registers)

That way, it should be possible to specify signals (like: High for 1ms, low for 2ms, repeat 100 times) and capture events. We might also add some special, optimized commands for PID computations, if they get too slow in the interpreter.

Integration in Machinekit should be possible, although they already have a PRU step generation (which looks pretty good on an oscilloscope). I don’t know about ROS, I never have worked with it before.

Michael