Hey guys,
As you know me and Junaid plan to develop the PyBBIO library this summer. We plan to add PRU support to PyBBIO so that the BBB can be extensively used even for real time activities and in IoT frameworks. I would like to know if there are any mentors who will be willing to help us out with the PRU library specifically. I have been spending a lot of time reading about the PRU and also had a look at the PyPRUSS library.
I’m quite confident about working about the PRU now, but it would be amazing to have some help in terms of mentorship and ideas!!
So, if there is any mentor who is looking forward to help in this respect, please do tell me 
Regards,
Deepak
As of now Alexander Hiam is doing a great job mentoring all PyBBIO related activities. But the goals list looks big enough for another mentor
So here’s my crazy idea for PRU integration into PyBBIO:
-Write a single general purpose event loop for the PRU
-Have a PRU library in PyBBIO with functions like:
-pru.setFrequency(gpio_pin, frequency)
- generates the given frequency square wave on the given pin (or maybe more similar to Arduino’s tone())
-pru.registerInterrupt(in_pin, event, out_pin, action)
- when event (rising/falling/high/low/change) on in_pin, do action (toggle/high/low/positive pulse/negative/pulse) on out_pin
…
So there’d only be a single PRU program, and there’d be a way to set up different events (like by writing to a file). That way you could do certain types of tasks on the PRU without having to write any assembly. It could also have the benefit of being multi-process safe, as long as there’s some sort of semaphore on the event registration mechanism.
I really like this approach and I'd be interested in sharing that same PRU
firmware load with the JavaScript framework. I've been particularly looking
at a handful of PRU and non-PRU firmware loads as a starting point for my
personal-never-get-any-time-side-project:
* https://github.com/mranostay/ws28xx-lighting-pru <-- Good framework for
PRU/ARM communication
* GitHub - ecto/duino: Arduino framework for node.js <-- Frequently used set of routines when
working with higher-level languages and an Arduino
* BotSpeak <-- A more general
interpreter that would need to be loaded with routines to run, but I
believe could work rather well with a loop that alternately handles pending
tasks and runs the next instruction in the virtual machine queue
A only-slightly more complete list of my thoughts on this can be found at
For me, ideally this would be build on a PRU library that was
Arduino-compatible such that the firmware was easy to extend. Of course, I
could really understand if someone wanted to keep it in assembly instead as
to only depend on open source tools and to be able to give the best
possible size/performance.
The other big question is to use UIO or Remote Proc. I've been trying to
push everyone to Remote Proc as "the way of the future", but the UIO stuff
seems to be already upstream and I've had quite a few contributions to the
loader at http://github.com/beagleboard/am335x_pru_package.
Wow, you’re way ahead of me! prudiono looks like an awesome start.
I love the idea of having a single event driven ‘user space PRU control’ firmware with an RPC interface (I’m with you on RPC) that would be trivial to wrap up into bindings for any language.
I guess this would probably need to be it’s own project, there’d definitely be a lot to do.
Wow, you’re way ahead of me! prudiono looks like an awesome start.
I love the idea of having a single event driven ‘user space PRU control’ firmware with an RPC interface (I’m with you on RPC) that would be trivial to wrap up into bindings for any language.
I guess this would probably need to be it’s own project, there’d definitely be a lot to do.
Yes, it seems to need to be its own project (with integration in the PyBBIO project), but I haven’t had students volunteering for it yet. Not quite sure why it doesn’t stand out to them as interesting. Any idea where we can find some students to encourage to write a proposal for this? Otherwise, it’ll be done “in my spare time”.
Deepak: would you be interested in focusing entirely on the PRU? (I know you have ton’s of other ideas as well)
Jason: you have more PRU and GSoC experience than I, any idea how many people we’d need to round up for this?
Deepak: would you be interested in focusing entirely on the PRU? (I know you have ton’s of other ideas as well)
Jason: you have more PRU and GSoC experience than I, any idea how many people we’d need to round up for this?
I believe the PRU firmware side is a single full-time student and 3 part-time mentors (mentors shouldn’t be putting as much work in as the student!). As far as PyBBIO, I cannot say.
For integration aspects, I’m interested in developing a test bench and some components on the node.js side that could help provide some thoughts on integration into the PyBBIO side. I could also provide a test bench related to Chris Rogers’ work.
Are we looking at something like firmata ?
This would be interesting! I’ll just have a thorough look at the possibilities I wonder how complex will it be to code the whole thing in assembly!
BTW my initial idea was to develop an interface similar but simpler to Core.py for PyBBIO, but only interface wise - not implementation. Basically python code that generates PRU assembly, and internally even the PRU assembler can be called, and even get the image loaded! All through a single python interface. – Just a crazy idea!
This is how I imagined it to be (vaguely though)
“”"
import pru
pru.startLoop(“Blink_loop”)
pru.pin(1, HIGH)
pru.sleep(10)
pru.pin(1, LOW)
pru.sleep(10)
pru.endLoop(“Blink_loop”)
“”"
Internally this will give us a pru assembly file. The program can be assembled and loaded too
pru.compile()
pru.load()
Basically something like this! But I don’t know how feasible it is.
Anyway I’ll play around with the PRU for a while and see how confident I am about working with it. [I know I can do small programs as of now, but developing a virtual machine requires a bit more thought!]
Alexander : Hopefully we can chalk out a plan.
Jason : I’ll have a look at all your links 
and I it seems Chris Rodgers is busy this summer [ I had contacted him a week ago ]
Looking forward to learn and work!
Regards,
Deepak Karki
Are we looking at something like firmata ?
This would be interesting! I’ll just have a thorough look at the possibilities 
I wonder how complex will it be to code the whole thing in assembly!
BTW my initial idea was to develop an interface similar but simpler to Core.py for PyBBIO, but only interface wise - not implementation. Basically python code that generates PRU assembly, and internally even the PRU assembler can be called, and even get the image loaded! All through a single python interface. – Just a crazy idea!
This is how I imagined it to be (vaguely though)
“”"
import pru
pru.startLoop(“Blink_loop”)
pru.pin(1, HIGH)
pru.sleep(10)
pru.pin(1, LOW)
pru.sleep(10)
pru.endLoop(“Blink_loop”)
“”"
Internally this will give us a pru assembly file. The program can be assembled and loaded too
pru.compile()
pru.load()
Basically something like this! But I don’t know how feasible it is.
My idea for the firmware is that it would include a loop that would execute higher level operations, not need the Python code to do low-level assembly generation. The idea is similar, but my concern was that providing a high-level API could be complicated if the Python needed to generate individual assembly instructions. However, if each of the higher-level operations is a macro, it might not be so bad.
Still, I am not done with the idea that a common firmware load can simplify things. If the PRU firmware accepts commands like is done with the Arduino in the Noduino applications, then the Python becomes trivial. For a lot of operations, this is all that is needed. The idea of running extra code loops provided by the script is the next-step to me, not the first step. Is this selling the capabilities short?
Core.Py does look interesting. If the individual instructions are higher level, like BotSpeak, it seems this is closer to to getting you a Python API that mortals can use.
Well yes, the idea was something macro based. I thought of this because people can write application specific PRU code in higher level python API! [ Infact it will make coding the VM on the PRU much simpler and maintainable ]
But I definitely agree that a generic firmware would be more comfortable for most developers And I love the idea.
I have handled things like Noduino; infact I done something similar for a hackathon - here. It’s a very scratchy implementation done in one day, but the idea is the same. You could blink an led (here) or rotate a servo (here) all without having to touch firmware. Communication is via bluetooth.
I’m a big thumbs up for this idea!
Just one doubt : will I work on this as a part of PRUSS integration for PyBBIO or will this be another project all together?
Regards,
Deepak
The python function to generate assembly macros is a neat idea, but I still think a single event loop firmware would be much more valuable, especially since it could be used just as easily from any language.
I was originally envisioning just having some simple commands that would set up predefined actions like “tone,GPIO1_17,500”, but I love the idea of a full blown VM that could run little scripts (like BotSpeak).
Now I’m imagining a server to handle loading and unloading scripts to and from the PRU firmware, and API’s would:
- generate scripts
- tell the server to load/unload scripts
- Ask the server what scripts are currently running
- Ask the server what scripts failed (?)
There’d be some nice benefits of having that server to manage tasks:
- It would be trivial to have some command line tools for task management
- You could then load/unload scripts with system tools like crontab
- If the scripts are sent to the server (as opposed to being saved directly into a dedicated directory), then scripts could be managed remotely through a REST API (I’m thinking a web page with an upload button, a list of running scripts, start/stop buttons, etc.)
Am I getting carried away here?
Deepak: If we went this route it would certainly be its own project, but of course we’d still need to test it, which we could do by at least starting on some Bonescript/PyBBIO APIs.