[fpc-devel] Realtime systems using FPC

[Mark Morgan Lloyd]

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 
http://blog.boxysean.com/2012/08/12/first-steps-with-the-beaglebone-pru/ 
I'm looking at the PRU Reference Guide 
https://github.com/beagleboard/am335x_pru_package/blob/master/am335xPruReferenceGuide.pdf 
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]