Recently, here, we had some interesting (though off topic) discussions on doing embedded projects using the "BeagleBone Black" hardware and fpc generated software.

Now using fpc to do software for the main processor (an ARM Cortex A8 running on Linux) is obviously possible and rather well supported. (In fact Lazarus can be used native on the BBB, and be controlled either by the local video subsystem hardware and a mouse/keyboard via USB or by running a VNC server on the BBB and using a normal PC as a GUI remote-control via Ethernet. Additionally See my mail in the Lazarus Forum regarding an Angstrom package.) (Cross development should be possible, too, but has not yet been made working.)

On top of this, the BBB (within the AM335x Chip by TI) provides two additional ARM Cortex M3 processors that are not supposed to run on a formal OS.

(How) Is it possible to create software for same using fpc ?

- Michael

Michael Schnell skrev den 05.07.2013 11:55:

Theoretically, yes. If it actually just is a standard Cortex-M3 core then it should work fine, and you would only have to add the RTL stubs, and compiler/arm/cpuinfo.pas+t_embed.pas entries for the cores.

However, I have a suspicion that it won't be that easy since it's a complex setup, and it's made by TI :)

Apparently there's a kernel module to handle the loading, but the sticking point might be that each coprocessor has a limited code space (8K?).

Theoretically, yes. If it actually just is a standard Cortex-M3 core then it should work fine, and you would only have to add the RTL stubs, and compiler/arm/cpuinfo.pas+t_embed.pas entries for the cores.

Reading the AM3359 Docu (this is the BBB's chip) it has an "Arm Cortex M3 Subsystem" (other then the predecessor AM17xxx that had a PRUS with a TI propriety CPU design). So it seems to be "a standard Cortex-M3 core".

Of course the RTL will need some squeezing to make it work for the PRUS.

However, I have a suspicion that it won't be that easy since it's a complex setup, and it's made by TI :)

here:

http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2

I found that there is software to set up the PRUS using the Linux device file system (and they tell us how to do software for the PRUS in ASM).

So this should be doable.

Thanks a lot !

-Michael

Mark Morgan Lloyd wrote

Apparently there's a kernel module to handle the loading,

Seems great. (see my other mail.)

but the sticking point might be that each coprocessor has a limited code space (8K?).

The PRUS features:
- 8 K instruction memory for each processor
- 8 K data memory for each processor
- 12 K shared memory (common for both processors)

So this of course is rather limited.

But the processors can access any memory address of the chip (internal and external RAM and peripherals) through bus bridges. I don't know if the M3s are strictly limited to fetch instructions from their instructions RAM or if this is just the fastest (zero wait states) source.

-Michael

To whomever is interested:

I finally found out the truth.

While it is correct that
- the 335x chip has a coprocessor system called "PRUS"
- the "PRUS v2" is greatly upgraded vs the AM17xxx "PRUS v1"
- a coprocessor in the 335x system is a Cortex M3

it is not true that the PRUS processor is a Cortex M3.

In fact it is a dedicated, propriety architecture by TI and can only be programmed in ASM. It is very similar to the AM17xxx PRUS but has more RAM and more closely coupled peripherals.

But the chip features yet another coprocessor which really is a Cortex M3. Same is used for power management.

I have no idea why you would use a 32 Bit processor just for power management, but seemingly the on-chip hardware of a Cortex M3 costs close to nothing and consumes close to zero power.

-Michael

Thanks for that, interesting. So the important point from the POV of the casual hacker or small business is that none of the BeagleBoard products have ARM-based PRUs.

Yep.

But maybe it is possible to do programs to run on the would-be power management M3 using fpc ;-)

-Michael

While we're on the topic of proprietary processors. I have been idly wondering how difficult it would be to port fpc to generate code for another processor. It's from parallax, and is an 8-core chip, running at 80MHZ, but can be overclocked to 100MHZ with another timing crystal which they also sell. It has two different types of programming languages. One is assembler for that particular brand of cpu, and the other one is a language that is kind of a cross between python and basic. They have ported gcc so it generates code for the propeller boards. Any idea how much trouble it would be to hack fpc to generate code for it?
It can be found at http://www.parallax.com for those who are interested. It's got quite a collection of sensors add-on boards, and the like to make it quite the usable board in hobby and even pro projects. I have to admit I'm not real thrilled with their programming choices, so if I could somehow manage to get fpc to generate code, I think I'd be extremely happy. :)
Just idle curiosity at this point, but if it turns out that it's relatively easy to do a port, I may attempt it.

Allowing that most users seem to be happy to use Parallax's proprietary tools, and that the assembler is very much geared to supporting their BASIC-like high-level language, and that the memory provision is fairly meager, it might be more trouble than it's worth.

Isn't there a new chip in the offing with more RAM space etc?

Indeed there is. The propeller 2 is well along in it's design, and as far as I know, could even be in preproduction, though I've not been watching the forums lately, so don't know where it's at in the cycle. The new version is supposed to have much more ram, and be considerably faster. It's the propeller 2 which I was actually wanting the fpc port for anyhow, since that's why they ported gcc in the first place. I'm not the least bit enthused with any of the proposed tools for prop 2 development, and wanted to get in on the ground floor with something more usable if possible.
I think adding fpc to the list of compilers supported by prop2 would be fantastic.

Mark Morgan Lloyd wrote

and that the memory provision is fairly meager, it might be more trouble than it's worth.

The Propeller is so short on closely coupled RAM that even to be able to use a decent C compiler, someone implemented a "virtual CPU" interpreter (i.e. "ZPU" architecture) to be run by the propeller core and create code for this architecture by a gnu c compiler that is provided by same.

So in fact it seems a lot more appropriate to port fpc to ZPU than to the native propeller core.

ZPU is a "zero register" 32 bit CPU architecture (it only has an up to 32 bit PC and an up to 32 Bit SP - less with memory space below 4 GB). Each instruction word is 8 bit wide. It is originally designed to be implemented in an FPGA, bus it also is excellent suited as a target for an interpreter.

The ZPU architecture description and the C compiler can be obtained here: http://opensource.zylin.com/zpu.htm

Infos on ZPU, including the Propeller virtual machine can be found t´in the mailing list

-Michael

Hmm. What with ZPU, LLVM, asm.js, Java bytecode, .NET CLI and no doubt others, what's needed is some universally-agreed meta-VM or at least a meta-representation. Tree-Meta, anybody?

I'm not at all sure about this, but I think there are two distinct GCC ports: one native (propgcc) and the other using the ZOG (ZPU) VM. I think we need to be careful here lest we rehash the PRU confusion.

Mark Morgan Lloyd wrote

Hmm. What with ZPU, LLVM, asm.js, Java bytecode, .NET CLI and no doubt others, what's needed is some universally-agreed meta-VM or at least a meta-representation. Tree-Meta, anybody?

Nice try. :-)

We also could agree upon a universal programming language and dump all at least 1000 others :-(

In fact, the target of those VMs seems to be rather different.

ZPU is especially small. It just defines an extremely simple processor with some 20 or so instructions.

IIRC, .NET CLI comes with an rtl definition that describes anything you can do with a computer including most of it's peripherals.

I feel that the big time of CLI already is over, even though I did like the idea of such an OS- and architecture- independent, fast executing (though lowly loading) byte code.

Java and javascript seems to be the winner, even though we seem to agree that the inventors of javascript should be publicly flogged.

I bow to the FireFox programmers who succeeded in creating their extraordinarily fast javascript VM and now are on the verge to some success with the FireFox OS for cell phones based on that engine.

-Michael
(who mostly does Pascal and C and thus hates PHP, which is unsimilar to either for no obvious reason.)

In fact I have no decent knowlage about Propeller. I just monitored the interesting discussion in the ZPU forum when Michael Rychlik started to do the ZPU VM.

BTW.: I once used another processor architecture with very limited directly accessible memory. Here the SDK provided a VM which emulated the processor itself, just with a different memory addressing scheme, and the normal C compiler for that arch could create code to run native and in the VM. Using the section attribute, could select visualization separately for each C function.

So I seemed to understand the reasons behind the Propeller ZPU VM.

-Michael