Hacker News Reader

Comment by Taniwha | Hacker News Reader

I think the main thing to think about PRUs is that they are the way to do a class of things in software that you'd normally break out some custom logic or an fpga to implement. Sure they're hard to initially set up for but way less effort than breaking out the PCB design software

There is also a C compiler available, I haven't used it, but Tridge (of Samba fame) gave a demo at linuxconf a couple of years back in which he launched a plane (remotely) and ran the guidance software on a BB, with the PRUs doing all the servo/etc work coded in C ..... and compiled the linux kernel onboard at the same time ....

View on HN

Two things from my experience:

1) Read the fine print when it comes to processor manufacturers telling how much time something takes. Although PRU subsystem is deterministic and __most__ instructions take 5ns, there are quite a few cases which take an order of magnitude more time[1]. Sure, the access times might be deterministic but that doesn't make it easy to know how much something will take.

2) Remote-controlled airborne vehicles need a lot less computation power than I expected. PX4 runs it's "main loop" at just 400Hz and I've seen PX4 or ArduPilot devs (might even be tridge) saying that 50Hz would be enough. Sure, you need accurate timing for PWM outputs (~1us resolution) and most important: low jitter.

The first point has bitten me personally- I found it non-trivial to get reliable < 100ns interrupt jitter on Cortex-M4. It really got down to what was happening on the bus between CPU/memory/peripherals at the point interrupt was supposed to fire (e.g. getting the documented latency of 10-odd cycles when CPU is idle but a lot more when there is a DMA transfer in progress).

1: http://processors.wiki.ti.com/index.php/AM335x_PRU_Read_Late...

Tridge gives a good summary of the different timing requirements in a presentation he gave back in 2014 (page 8).

http://uav.tridgell.net/LCA2014/AP_Linux.pdf

The comparison to breaking out the PCB software is a touch misleading. You'd certainly also find it to be an onerous task to break out the PCB software and design a board for the Sitara SoC that sits on the Beaglebone. Realistically the comparison would be to use an FPGA devboard. Modern FPGAs often have an ARM processor build right into them, and if not you can use a Microblaze/NIOSII softcore processor in conjunction with the programmable logic. Such a setup will happily run linux, do your real-time tasks, and use all the typical peripherals that one of TIs soc's will.

I'm not saying that using an FPGA would be easier necessarily--indeed, likely not just because the tools a so terrible--but there are many options. Last I checked the documentation for the PRUs was pretty bad. Mostly a smattering of wiki pages and a couple powerpoints. And even that is a huge improvement over even just a year or two ago.

> I think the main thing to think about PRUs is that they are the way to do a class of things in software that you'd normally break out some custom logic or an fpga to implement.

I would turn to the Cypress PSoC stuff for that actually. http://www.cypress.com/products/microcontroller-mcu-and-prog...

They have just that little bit of programmable logic to catch whatever silly thing that just has to respond in 400nS, for example.

The PSoC 4 series also operates at 5V I/O levels. That is actually getting remarkably difficult to find, nowadays.

Reply on news.ycombinator.com