11

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.

student1
  • 762
  • 3
  • 8
  • 20

2 Answers2

9

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.

Clifford
  • 76,825
  • 12
  • 79
  • 145
  • 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? – student1 Nov 23 '14 at 20:05
  • 3
    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. – Clifford Nov 23 '14 at 20:20
  • 1
    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. – Clifford Nov 23 '14 at 20:23
6

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.

Freddie Chopin
  • 7,520
  • 2
  • 23
  • 49
  • 2
    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. – Clifford Nov 23 '14 at 19:42
  • 1
    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. – Freddie Chopin Nov 23 '14 at 19:44
  • @Clifford - take for example this link - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.prd29-genc-009492c/ch05s03s03.html . 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... – Freddie Chopin Nov 23 '14 at 19:49
  • On a modern PC, things like indirect I/O over bridged and arbitrated busses can limit hard real time regardless of software scheduler design. – Chris Stratton Nov 23 '14 at 19:59
  • @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? – student1 Nov 23 '14 at 20:02
  • @student1 - 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. – Freddie Chopin Nov 23 '14 at 20:05
  • @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". – Clifford Nov 23 '14 at 20:08
  • 2
    @student1 : 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. – Clifford Nov 23 '14 at 20:14