[fpc-devel] Realtime systems using FPC

Mark Morgan Lloyd markMLl.fpc-devel at telemetry.co.uk
Wed Jul 3 15:35:37 CEST 2013

Michael Schnell wrote:
> On 07/03/2013 10:11 AM, Mark Morgan Lloyd wrote:
>> Do you have any URLs etc. for the BBB in this context? 
> This has close to nothing to do with the BeagleBone board: it's just a 
> processor feature. The BeagleBone board in fact supports it as several 
> pins of the chips that can internally be connected to the peripherals 
> that are in "vicinity" of the M3s "PRUS" (="Programmable Real-Time Unit 
> Subsystem"). In fact all peripherals are accessible by all CPUs and DMA 
> controllers, but there might be performance degradation when traversing 
> bus bridges.
> To learn more, you might want to read the "AM335x Applications Processor 
> Technical Reference Manual" by TI (4788 pages).

Or via 
I'm looking at the PRU Reference Guide 
which describes each of the 2x PRUs as having 8K of instruction memory 
and something like 20K of data memory (of which part is shared).

>> Could the realtime stuff realistically be coded in FPC, or would this 
>> effectively mandate a distinct target?
> I don't know if fpc can generate ARM M3 code. This might be possible. 
> You need to ask the compiler experts on that.
> I also don't know (yet) what development support is provided by TI for 
> the PRUS. Of course a gcc is available. I do hope that there is support 
> for GDB either vie JTAG or somehow via the main processor. In fact the 
> PRUS does include Ethernet hardware, so I suppose TI should provide a 
> TCP/IP stack for this purpose. Hopefully they have an Eclipse based IDE 
> to do PRUS development.
> I suppose in most cases you will need to do just very small programs to 
> run on the PRUS and provide the very hard realtime stuff. Thus extremely 
> comfortable development tools are not that critical.

It looks as though the PRU is a custom design (i.e. not an ARM 
derivative) which TI has also used in some of the OMAP series, it looks 
as though it might be a DSP derivative with multiply-accumulate etc. So 
particularly allowing for the limited instruction memory the code would 
probably have to be written in assembler. The loader could be written in 
Pascal, since it uses a kernel module for the dirty work.

Somebody on the debian-arm ML was being very rude about the PowerVR 
subsystem a few days ago, describing both the hardware and software as 
an unmaintainable mess.

Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

More information about the fpc-devel mailing list