Why do you need a Programmable Real Time Unit (PRU) while you can have an RTOS?

Question

The beaglebone Black processor includes two independent Programmable Real Time Units (PRUs). Hobbyists and professionals are excited about possible use of these units for real-time applications, which is understood. However, if you can have a RTOS (whether for the beaglebone or the raspberry pi), why would you need the PRUs?

EDIT- For information, the BBB has an ARM Cortex A8 running at 1 GHz, with 1.9 DMIPS / MHz. The PRUs are simple RISCs running at 200 MHz.

Cantu

Answer 1

Linux, even with the real-time scheduler is unsuited to many critical hard real-time tasks with response requirements at the microsecond level, on the other hand it provides or enables a great deal of functionality in terms of UI, connectivity and filesystem support. These things are either not available in an RTOS or are provided at significant cost in high end RTOS, and with much more limited hardware support.

So if you have a system that has hard-real time constraints, but needs more general purpose computing features such a networking, filesystem connection to commercial-off-the-shelf (COTS) peripherals etc., then the PRU provides a solution to that.

On the other hand I can't help but think that this is a marketing exercise on the part of TI to sell more chips. A similar solution has always been possible (and indeed common) using one or more processors to perform time critical tasks, possibly running an RTOS, while UI and connectivity are handled by a single processor with the necessary hardware and memory resources but without the real-time constraints. The PRU device does have two 32 bit cores, but XMOS xCORE devices have as many as 16 cores - with 16 communicating cores, you may not even need an RTOS.

To answer the question...

[...] if you can have a RTOS [...], why would you need the PRUs?

... directly; you probably wouldn't need them in that case, but you would loose Linux - and your application may need that. It is just one of many solutions to real-time applications using Linux. You pays your money, and takes your choice.

Rabblerousing

Let's stick to the BB case. So your point is that running timing-critical tasks on the PRU will, in general, be better (in terms of short response time) than having an RTOS on the main processor doing that, did I understand you correctly? – Cantu

You asked that same question in response to a comment to the question - my response there applies, but to reiterate, on Linux, response occurs when the OS gets around to it - it is non-deterministic. A processor dedicated to a single task will generally respond faster and more deterministically (i.e. same time, every time). An RTOS will enable the BB perhaps to respond fast and deterministically enough for most tasks, but if you then loose all the stuff that Linux brings, is your application still viable? If you don't need Linux, you probably don't need a BB either. – Rabblerousing

My point about not needing a BeagleBone is that it has than much memory resource so that it can run Linux. If you don't need Linux you can get away with far less. – Rabblerousing

Answer 2

Most likely the processor in BeagleBone or RaspberryPI is too "heavy" for real time - after all, you could run RTOS on your PC, but it will not be very responsive entirely deterministic, even when it's faster than your typical microcontroller (I guess that these PRUs are some sort of microcontrollers with a new fancy name). In such high-level application processor as found on these boards you rarely have direct access to hardware or interrupts, which are essential for real time applications that actually do something time-critical.

Bandwagon

If you run and RTOS on a PC it will have hard real-time deterministic response. It is the RTOS that ensures that, not the hardware. In fact it is not that uncommon before QNX Neutrino, QNX was exclusively an x86 RTOS. It is the Linux general purpose OS (GPOS) on these platforms that prevents real-time performance. – Rabblerousing

The response will be deterministic, but not necessarily short... I guess any MCU can be faster in these matters than an application processor with huge caches, long pipelines and external memory. There are cases where 8-bit chip enters interrupt handling routine faster than an ARM MCU. Compare that with a typical application processor and you'll see what I mean. – Bandwagon

@Rabblerousing - take for example this link - infocenter.arm.com/help/index.jsp?topic=/… . It says that the latencies are in the order of "hundreds" of cycles. On a Cortex-M3 microcontroller it is an order of magnitude smaller, and these chips are not super fast (for an MCU) in that regard... – Bandwagon

On a modern PC, things like indirect I/O over bridged and arbitrated busses can limit hard real time regardless of software scheduler design. – Disconnection

@FreddieChopin, The BBB has an Arm Cortex A8, with 1 MHz clock and ~ 2 DMIPS/MHz. Are you saying that running an embedded linux on it won't be as "fast response" as using the 200 MHz PRU? – Cantu

@Cantu - yes, I think it is safe to assume that a microcontroller will respond to some physical input (enter an interrupt handler) much faster than an application processor. – Bandwagon

@FreddieChopin : I last used x86 with an RTOS (VxWorks) of a 80486 industrial PC with a proprietary bus architecture (STD32). A regular off-the shelf PC may have hardware optimised for desktop and server tasks (data throughput performance) rather than RT response. It is true that data throughput optimisation is intrinsically less deterministic. I think the "not be very responsive" remark however should perhaps be "not entirely deterministic". – Rabblerousing

@Cantu : A Linux system performa many tasks in a time-sliced scheduler. It is not real-time because you cannot guarantee when any particular task will be scheduled. Yes if you run an RTOS on it it will probably be suited to most real-time tasks, but a processor dedicated to one task and with zero interrupt latency will respond faster, but more importantly deterministically; not after an indeterminate number of time slices. – Rabblerousing