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)