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]
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
