8 ms·
How to run C programs on the BeagleBone's PRU microcontroller
- sigjuice 10y agoJust curious if the PRU compiler is some sort of gcc variant or something proprietary.
- kens 10y agoThe 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 10y agoI 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 10y agoThe 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_Code_Generation_Tools http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#TI_PRU_... 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 10y agoI think a lot of my frustration stemmed from NOT using CCS. Maybe I should just bite the bullet and do that...
- AstroJetson 10y agoTexas Instruments provides Code Composer Studio (CCS). It's about $800 a seat (version that I have) but there is a free version to use with the Beaglebone. See here http://processors.wiki.ti.com/index.php/Download_CCS http://processors.wiki.ti.com/index.php/Download_CCS
- kevin_b_er 10y agoAlso you don't necessarily need the IDE to compile with the PRU. The compiler itself is freeware, and is some sort of fork of the compiler line they developed for their DSPs.
- codys 10y ago[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 10y agoThe 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 10y agoAh, 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 10y agoI 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 10y agoCortex-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).
- kevin_b_er 10y agoSince 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_tips_tricks/index.html http://software-dl.ti.com/public/hpmp/software/pru_compiler_... PDF slides: http://software-dl.ti.com/public/hpmp/software/pru_compiler_tips_tricks/presentation_content/external_files/PRU_Compiler_Tips_slides.pdf http://software-dl.ti.com/public/hpmp/software/pru_compiler_... (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 10y agoThanks 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.
- gregschlom 10y agoIf 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.
- AceJohnny2 10y ago> 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.
- NwtnsMthd 10y agoCCS has come a long way since version 3. Ever since TI started using Eclipse as the base for CCS things have been getting better. Out of all the IDE's I've used over the past 5 years CCS is my favorite. > 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. Embedded development requires precise control and knowledge about what you're doing, and that's precisely why you would want to use the manufacturer's recommended IDE. Have you ever tried managing development with an RTOS? Or streaming data out of RAM while your code was running? Or fiddling with the processor registers when debugging? IDE's make all that much simpler, you may want to give CCS an other chance, it's a really powerful IDE.
- AceJohnny2 10y ago> Have you ever tried managing development with an RTOS? Or streaming data out of RAM while your code was running? Or fiddling with the processor registers when debugging? Yes to all of the above, and had to script it too, which I couldn't do with an IDE at the time. I indeed haven't used CCS-Eclipse in years. Has it finally eliminated its lag and RAM usage? I was always amazed how it managed to continuously stay just ahead of Moore's Law in terms of resource usage.
- NwtnsMthd 10y ago
- kens 10y agoWhere 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 10y agoI would all be interested in such a place.
- deleted 10y ago[deleted]
- wtbob 10y agoI 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!
- rjsw 10y agoI would use an FPGA for this kind of project. One of the ARM+FPGA hybrids could be easiest.
- kens 10y agoI 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 10y agoIs 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 10y agoCarl 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/
- ArkyBeagle 10y agoIf you can use the PRU instead, that's a lower barrier to entry - in some ways. For stuff that needs to be more or less +/- 1 msec in latency, an Arudino or might be an easier choice, dependent on size, weight and power. Th real problem with the PRU is that its more or less single vendor.