I’ve implemented a forth language for the PRU to facilitate one of my own projects. It is available for others to use on github in hopes that someone may find it useful.
https://github.com/biocode3D/prufh
Prufh will allow you to write code for the PRU in Forth. This has the advantage of easier coding and debugging. Because of the way it uses data memory (and the nature of Forth) it also may allow you to write larger programs than would be feasible in assembly language. The potential disadvantages are that code will usually be somewhat slower and it is more difficult to calculate execution times.
Depending on how you need to use PRU, it may well be easier learn the basics of the Forth language in order to use prufh than to write everything in assembly. But if there is anyone out there that already knows forth and needs to use the PRU subsystem, I’m sure you’ll like it.
Yes, of course, a C compiler would be useful to more people; but I’m not capable of writing a C compiler in ~500 lines of perl 
I've implemented a forth language for the PRU to facilitate one of my own
projects. It is available for others to use on github in hopes that
someone may find it useful.
GitHub - biocode3D/prufh: Programming language for the Programmable Realtime Unit Subsystem found on TI ARM processors. (BeagleBone black)
You are my hero! I love Forth and figured the PRU would be perfect for
a small Forth environment! 
Yes, of course, a C compiler would be useful to more people; but I'm not
capable of writing a C compiler in ~500 lines of perl 
...and there's already a C compiler available. You just have to e-mail
Jason Kridner and ask to get the "beta" copy since it hasn't been
officially released for some reason.
I also am interested in C compiler for PRU.
Can you let me know how to contact Jason Kridner?
Nice job John, although I have to admit I have never heard of Forth( and have been programming since the early 90’s ). Nice to learn something new, and I will have to give the Language a look-see to see if I like it.
Jason, if you’re paying attention I would also like a copy of the C compiler. I am based in the US, and do have an account on TI.com.
Forth is awesome. Last time I had a paying gig in Forth was about 1985, I think. It was to control a big lighted display board (and garage heater!). So it was basically a 160 x 32 monochrome graphics editor with fonts and wipe effects, done on an Apple II (8-bit 6502 processor, 1 MHz, 32k of RAM). No other language squeezes into tight spots like that.
I also am interested in C compiler for PRU.
Can you let me know how to contact Jason Kridner?
Really surprised you haven’t seen my email around here?
Nice job John, although I have to admit I have never heard of Forth( and have been programming since the early 90’s ). Nice to learn something new, and I will have to give the Language a look-see to see if I like it.
Jason, if you’re paying attention I would also like a copy of the C compiler. I am based in the US, and do have an account on TI.com.
A direct email with “PRU Compiler” in the subject is easiest for me to track.
No other language squeezes into tight spots like that.
Forth comes in lots of different flavors: The tiniest one I ever used (for a 6502-based industrial air pollution monitoring device) was cross-compiled on a minicomputer to generate 8-bit tokens for the program ROM. So each “call” of a Forth function just took a single byte!
The ARM/PRU combination is a perfect fit for a cross-compiled Forth. All of the compilation functions (“immediate words” in Forth) run on the ARM but lay down code in PRU-space. PRU-resident native code or lists of Forth function calls would just be the PRU application itself, plus the tiny bit of code needed to implement the Forth interpreter. Should be interesting to see what John has implemented.
Forth comes in lots of different flavors: The tiniest one I ever used (for a 6502-based industrial air pollution monitoring device) was cross-compiled on a minicomputer to generate 8-bit tokens for the program ROM. So each “call” of a Forth function just took a single byte!
The ARM/PRU combination is a perfect fit for a cross-compiled Forth. All of the compilation functions (“immediate words” in Forth) run on the ARM but lay down code in PRU-space. PRU-resident native code or lists of Forth function calls would just be the PRU application itself, plus the tiny bit of code needed to implement the Forth interpreter. Should be interesting to see what John has implemented.
Your description is very close to the way it works. In this case it has 16-bit addresses so instructions cost 2 bytes. The “compiler” doesn’t run on the ARM however. I considered that but it was far easier to implement it on the host computer. Among the reasons is that I would have had to implement a PRU assembler in Forth. Not too terribly difficult but still more work, and it would take up ARM program space. Against that I didn’t see any advantage to having a full forth interpreter on the ARM. Most times a headerless forth is just fine on an embedded processor and that is the way I saw this project. (Sorry for the Forth jargon.)
Before I started this I saw mentions of a C compiler but all the links appeared to be dead. I guess I should have asked here!
Forth comes in lots of different flavors: The tiniest one I ever used
(for a 6502-based industrial air pollution monitoring device) was
cross-compiled on a minicomputer to generate 8-bit tokens for the program
ROM. So each “call” of a Forth function just took a single byte!
The ARM/PRU combination is a perfect fit for a cross-compiled Forth. All
of the compilation functions (“immediate words” in Forth) run on the ARM but
lay down code in PRU-space. PRU-resident native code or lists of Forth
function calls would just be the PRU application itself, plus the tiny bit
of code needed to implement the Forth interpreter. Should be interesting to
see what John has implemented.
Your description is very close to the way it works. In this case it has
16-bit addresses so instructions cost 2 bytes. The "compiler" doesn't run
on the ARM however. I considered that but it was far easier to implement it
on the host computer. Among the reasons is that I would have had to
implement a PRU assembler in Forth. Not too terribly difficult but still
more work, and it would take up ARM program space. Against that I didn't
see any advantage to having a full forth interpreter on the ARM. Most times
a headerless forth is just fine on an embedded processor and that is the way
I saw this project. (Sorry for the Forth jargon.)
Didn't Robert put your Forth compiler into the latest release to run
on the ARM anyway? The assembler was already there on the ARM. It
would be great if you could check it.
Before I started this I saw mentions of a C compiler but all the links
appeared to be dead. I guess I should have asked here!
Can you tell me where you found broken links mentioning the upcoming C
compiler? BTW, I've been given internally a release date that is
within a week, so hopefully no more private beta.
Didn’t Robert put your Forth compiler into the latest release to run
on the ARM anyway? The assembler was already there on the ARM. It
would be great if you could check it.
http://beagleboard.org/latest-images
I don’t see how he would have known about it. This was my first public announcement.
Before I started this I saw mentions of a C compiler but all the links
appeared to be dead. I guess I should have asked here!
Can you tell me where you found broken links mentioning the upcoming C
compiler? BTW, I’ve been given internally a release date that is
within a week, so hopefully no more private beta.
Sorry, I don’t remember. It was 6 months ago. I can’t even be sure we’re talking about the same compiler. I just remember seeing mentions of a C compiler (one of which was somewhere on the TI site) but I was unable to track it down.
It was also very last minute for me.. Didn't even have a spare second
to hack a "make install"..
But it sounded cool..
Regards,
I just tested, and what you've got seems to work OK, although the pasm
assembler is required to build the PRU binary. I've got this installed
and built on my Machinekit images (since I have to assemble PRU code as
part of the Machinekit build), but I'm not sure about yours.
Yep, it’s there in /opt/sources. pasm is installed and working, so it should work, but I’ve been unable to test it since I’m using the beta kernel and haven’t really wrapped my head around DTBs yet, so I don’t have the pruss drivers working.