
How to run C programs on the BeagleBone's PRU microcontroller - dwaxe
http://www.righto.com/2016/09/how-to-run-c-programs-on-beaglebones.html
======
AceJohnny2
> _How to compile C programs with Code Composer Studio_

Oh _god_! Ack, ew, _retch_.

I've had to use CCS a few years ago, and it was a buggy monstrosity. I don't
understand why silicon vendors have to wrap their dev tools into such horrid
IDEs. One reason I loved working with AVRs is that I could get a gcc-like
interface, so that I knew exactly which options and parameters were used
rather than some godforsaken IDE do some _magic_ for me and get in my way.
Having to hunt down options in modal windows and tabs is enough to make my
blood boil just thinking about it.

Embedded development requires very precise control and knowledge about what
you're doing, and IDEs more often than not get in the way of doing that.

~~~
david-given
For a while I worked with Bada, the Korean smartphone OS pushed by Samsung
which nobody has ever heard of.

(It was actually not bad; apps written in C++ with a Java-like class library
which all ran inside a single process, targeted at fairly small devices. Our
test hardware was this massive plastic brick with daughterboards poking out in
all directions all wrapped round this utterly gorgeous curved OLED screen.)

You developed on it using a custom IDE which totally wasn't Eclipse (despite
being Eclipse) which used gcc as the backend compiler and a bunch of custom
tools to generate the deployment packages. Naturally, we ignored the IDE and
just used makefiles, so that we could integrate the Bada build into our
existing build automation.

...then one update they removed the custom tools and moved their functionality
into Eclipse.

This meant that the _only_ way to create applications was to open Eclipse,
load the project, and then manually press the 'build' button.

Naturally, we complained, along with everyone else who used it, and never got
an answer. The platform died soon after.

~~~
ArkyBeagle
"...This meant that the only way to create applications was to open
Eclipse"...

Surely not. Now, this may have been much more trouble than it was worth, but I
very nearly guarantee there was a way to do it from a command line.

It's been a while since I Eclipsed, but I (probably erroneously) recall a
"generate Makefile" option on most adaptations of it.

~~~
yitchelle
I was also intrigue after reading that. I wondering if gcc and friends were
integrated directly into Eclipse? It is possible, but it would be a complete
waste of engineering resource.

~~~
Gibbon1
I think a problem is with a lot of eclipse based embedded studio's is the
driver and board support package code is generated from templates via an
eclipse plugin written in Java. Also good luck trying to figure out an Eclipse
project file without retching.

Eclipse + Embedded => Cancer

~~~
luca_ing
Currently doing that.

Retch indeed.

------
kevin_b_er
Since the author cares about a few cycles per check by using the interrupt
instead of directly reading the PWM register, they should look up how to
access the constants table (4.4.1.1).

The compiler can be coaxed, with some rather ridiculous clpru compiler-
specific variable definitions, into referencing addresses from the constant
table by a C number rather than loading up a general purpose register.

It is in the clpru compiler documentation under section 5.14.4 It is also
discussed in some TI slides (flash required) in part 18 [http://software-
dl.ti.com/public/hpmp/software/pru_compiler_...](http://software-
dl.ti.com/public/hpmp/software/pru_compiler_tips_tricks/index.html) PDF
slides: [http://software-
dl.ti.com/public/hpmp/software/pru_compiler_...](http://software-
dl.ti.com/public/hpmp/software/pru_compiler_tips_tricks/presentation_content/external_files/PRU_Compiler_Tips_slides.pdf)
(PDF page 28)

TI states in their slides that this constant register table access "Barely
counts as C code." I think they're right. It is, however, slightly faster.
When trying to do cycle-perfect timing, such micro optimizations start to
actually matter.

~~~
kens
Thanks for mentioning the constants table. In my case, saving a few cycles
isn't important but eliminating jitter is very important, which is why I use
interrupts.

Reading the PWM register took 5 cycles, so I ended up with 25 nanoseconds of
jitter, which caused bit errors in my Alto Ethernet emulator. Polling
interrupts take 1 cycle, so I end up with no jitter. (Does anyone else think
it's bizarre that TI calls them "interrupts" when you need to poll them?) You
might think 1 cycle would cause 5 ns jitter, but the timer uses the same clock
so everything is synchronized.

I considered using the constants table if I needed to shave off some cycles,
but as you point out the code required is pretty hideous. And you also need to
define all the constants in the linker file too? That's just crazy.

------
kens
Where do all the PRU programmers hang out? Is there a forum to ask questions?
Based on this HN discussion, there seem to be lots of people using the PRUs.

~~~
bitewhite
I would all be interested in such a place.

------
gregschlom
If you're doing anything big with the BeagleBone's PRUs, it's also worth
checking LEDscape
([https://github.com/osresearch/LEDscape](https://github.com/osresearch/LEDscape)).

It provides a good reference on how to do complex tasks on the PRU.

------
sigjuice
Just curious if the PRU compiler is some sort of gcc variant or something
proprietary.

~~~
kens
The PRU compiler (clpru) is a TI proprietary compiler, free but licensed. It
is pre-installed on BeagleBones. There's also a gcc compiler‡, but I don't
know anything about it.

‡ [https://github.com/dinuxbg/gnupru](https://github.com/dinuxbg/gnupru)

~~~
cushychicken
I didn't know about this! My last experience messing around with compiling for
the PRUs was really frustrating - I gave up after about three days' screwing
around with freeware tools that didn't work.

Could you point to where the PRU compiler is located on the BeagleBone file
tree? I'd like to try this out!

~~~
kens
The TI PRU compiler is at /usr/bin/clpru on my BeagleBone (from Adafruit, with
Debian). If it's not on your BeagleBone, you can download it here:
[http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#TI_PRU_...](http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#TI_PRU_Code_Generation_Tools)

I'd recommend using the CCS IDE (as I describe in the article) rather than the
command line compiler, but it's up to you. You'll still probably encounter
frustration - it's not an Arduino experience for sure.

~~~
cushychicken
I think a lot of my frustration stemmed from NOT using CCS. Maybe I should
just bite the bullet and do that...

------
wtbob
I played with the idea of implementing a little Forth for the PRU, but wasted
a weekend looking for fast multiply and divide algorithms (IIRC, it can only
do addition, subtraction & left/right-shift). It's a neat little platform, but
at the end of the day I've not found any really pressing need to use it.

That doesn't mean others haven't, of course — I'm very much a software guy
these days. Kinda wish I'd had a BeagleBone back when I was a kid, designing &
soldering my own stuff: I bet it'd have been awesome. Can't even imagine what
Forrest M. Mims could come up with using one of them as a platform!

------
codys
[Edit: see child comments, this isn't right]

Rather than using CCS, one can use gcc or clang targeted to cortex-m3 (gcc
target: arm-none-eabi + `-march=cortex-m3`, clang:thumbv7-eabi) to build the
code (with the usual caveats that you're targeting a bare metal system).

The PRU is just a cortex-m3 core which is connected in interesting ways to the
cortex-a8 on which linux runs. Nothing too exotic.

~~~
kens
The PRU is a proprietary TI architecture that is totally different from the
Cortex M3. The PRU is a low-level deterministic real-time 32-bit
microcontroller, while the Cortex M3 is a "real processor" with interrupts,
memory management and so forth. The instruction sets and architectures have
nothing in common.

Maybe you're thinking of the Cortex M3 that's on the chip for power
management?

~~~
codys
Ah, you're right, it does look like that's the case. It's a shame it's not
something better supported (like a cortex variant).

~~~
zokier
I think newer chips have the option for CortexM companion. This goes bit
beyond my skillset, but I think the point of proprietary PRU ISA was that they
could ensure super specific and regular instruction timings, every instruction
being executed in single cycle with no pipelining or other stuff that can make
real-time programming more tricky. That is something that afaik you simply
can't do with Cortex M cores.

~~~
TickleSteve
Cortex-R series is the equivalent to the PRU.

'R' for realtime.... in-order scheduing, highly optimised for determinism over
performance.

(Having said that.... 'M' series is pretty good too really).

------
rjsw
I would use an FPGA for this kind of project. One of the ARM+FPGA hybrids
could be easiest.

~~~
kens
I looked at FPGAs, but that's not just a learning curve, but a whole new world
to learn. I started reading about Verilog and decided that an FPGA was
overkill for what I wanted to do (essentially controlling a few signals at
5.9MHz for an Ethernet emulator). On the other hand, for the Xerox Alto disk
emulator, Carl (on the restoration team) is using an FPGA.

~~~
abbeyj
Is the disk controller using an FPGA because that's what Carl was most
familiar with or is there a technical reason? Does data come in too fast for
the PRU to keep up or are the timing requirements too stringent?

~~~
kens
Carl is using a FPGA because that's what he is most familiar with and he's
built disk emulators with FPGAs before. The Alto's Diablo disk provides data
at 1.6 MHz, so the 200 MHz PRU could probably keep up. The FPGA can make the
timing more exact, and Carl likes to make sure all the signals have precise
timing. A complication with disk as compared to Ethernet is there are a lot of
signals to deal with (track address, sector address, status signals, read
clock, read data, write data, unit select, etc). He goes into details at his
blog: [https://rescue1130.blogspot.com/](https://rescue1130.blogspot.com/)

