I have mostly given up on creating the cross compiler for MIPSEB-OpenWrt (or DD-WRT) platform.
Now, my plan B is to create a cross compiler (from x86 Linux) to ARM-Raspberry Pi

I know the default raspberry pi os is Raspbian which is a version of debian. If possible, I'd like to get a binutils toolchain for raspbian. If not, I will be happy to use one for ARM debian.

Anyone has experience in doing the above?

Thanks.

Dennis

You should better install the native port of lazarus & freepascal on the raspberry and connect the machine to a display/mouse/keyboard. Install latest raspian from http://www.raspberrypi.org/downloads

and here's a user-guide for installing lazarus/fpc: http://elinux.org/Lazarus_on_RPi

Then you can then use lazarus in exactly the same way as on your linux box, performance may not be stellar but you will have a working system in no time.

Doing crosscompiles and remotedebugging will add a level of complexity that will not justify the better performance of lazarus when using it on the 'real' linux box. At least not in the beginning of your journey.

Michael

Thanks.
I already successfully install Lazarus/FPC 2.6 on raspbian :-) If you say cross compiling and debugging is not worth the trouble, I will take your advice.

Dennis

Dennis Poon wrote

I have mostly given up on creating the cross compiler for MIPSEB-OpenWrt (or DD-WRT) platform.

That is a shame !

(When the time comes,) I would be very interested in a decently supported MIPS compiler and IDE-support, as the PIC32 series, that is based on a MIPS CPU, offers a lot of really nice and cheap chips and rumors say that there very soon will be even more, providing lots of internal RAM and FLASH.

Now, my plan B is to create a cross compiler (from x86 Linux) to ARM-Raspberry Pi

I don't understand why RPI (still) gets so much interest.

A friend of mine just bought two BeagleBone "Black" boards for EUR 38.- (+VAT) each. With the extremely versatile and well supported TI 1 GHz chip (that is taken from TI's "AM..." series of devices for "embedded" use instead of for "cellphone" use), with 512 MB RAM and additional "internal SD-Card", and with a HDMI socket.

He is up to try to install and develop with FPC/Lazarus ASAP. (Please com back with any question on that behalf, I'm going to forward them.)

I definitively would use this board for my future "embedded" projects.

-Michael

Dennis Poon wrote

I will be happy to use one for ARM debian.

My Pal did some initial tests with the BeagleBone Black. Same comes with a Aengstrom Linux pre-installed in it's internal "Flash-Card". As he already has some experience with (PC-) Debian, he is going to move his BBB's to same.

Additionally, I learned that, for embedded use, the DaVinci distribution also often is recommended.

-Michael

Michael Ring wrote

Doing crosscompiles and remotedebugging will add a level of complexity that will not justify the better performance of lazarus when using it on the 'real' linux box.

It doesn't need to be!

Having tested Delphi XE4 recently with iOS and MacOSX development. I was simply amazed at how easy it was to develop for an alternative platform, including remote debugging and deployment - it fact developing for the iOS target was just as simple as developing for the Win32 or Win64 or MacOSX targets.

There is still a huge gap in FPC and Lazarus's usability when it comes to developing, debugging and deploying to alternative targets. I guess that is why Embarcadero can charge the big bucks.

Maybe Dennis can try CodeTyphon [http://www.pilotlogic.com/sitejoom/]. They are the only people I know that are trying really hard to get FPC cross-compiling to the masses.

Regards,
- Graeme -

I have successfully compiled my lnet+SSL program on Raspberry Pi. Due to its slow CPU, it took a while but everything worked :-) Good to know there are more low-cost easy to use ARM platform in the market.

Please do share your experience with BeagleBone especially on how to write OSless FPC applications on it. That should tremendously reduce the boot time. Currently Pi took 20 seconds to boot to text shell of the default OS Raspbian. Hear for ArchLinux, it takes 10. How long does BeagleBone take to boot to shell?

I suppose an embedded (OS-less) app shall boot very quickly.

Dennis

Does it have an fpu which supports exception handling?

No. The Am335x chip is vfpv3 without the -u. See
http://www.ti.com/litv/pdf/spruh73h

Thomas

(The rpi/ARM1176JZF-S is vfpv2 which supports these exceptions - but you probably knew that)

Thomas

So they support now native development on MacOS X as well? Or is cross compilation from win still the only way? Then this explains a lot: the mainly used development setup works always the best by far.

There is still a huge gap in FPC and Lazarus's usability when it comes to developing, debugging and deploying to alternative targets.

Cross compilation *to* win from any targets works very well with FPC. The problem are platforms like linux where linking is basically impossible without having the libraries of the target system available.

Florian Klämpfl wrote

So they support now native development on MacOS X as well?

No, all development is still ONLY done under Windows. You cross compile to OS X and iOS. You also remote debug to OS X and iOS.

I still think forcing a Windows licence for somebody that wants to develop for iOS only is bad. After all, Apple already forced you to purchase Apple hardware to develop for any of their platforms.

But what I was getting at is that Embarcadero made cross compiling and remote debugging a no-brainer. Trying to do the same thing with FPC and Lazarus IDE is a huge pita! I'm not saying its impossible, it's just not nearly at the convenience level Delphi does it. "right click on project and select 'Add target'; double click on new target to make it active; Ctrl+F9 to compile"

The problem are platforms like linux where linking is basically impossible without having the libraries of the target system available.

I consider Linux and OS X similar - both *nix type OS'es. Delphi manages it, though I don't know the exact details of how they do it. I believe they get around the linking problem (and remote debugging) by using the PAServer, and using XCode command line tools for the final step in building a project.

Regards,
- Graeme -

Native use of FPC+Lazarus on MacOS X is fine.
Even native use of FPC+Lazarus on Mac OS X cross compile to IOS is fine using the specialized Lazarus + FPC 2.7.1 + the packakge provided by www.pas4mobile.com

I have deployed an IOS app on my Ipod touch without problem (of course, you need to eventually spent a minute to use XCode to recompile the app and install it to ipod touch due to Apple's regulation).

You can even debug it line by line within Lazarus using the IOS simulator running on Mac OS X.

Dennis

Dennis Poon wrote

Please do share your experience with BeagleBone

I don't do anything myself on that behalf right now, butt I'll let you know when I hear success or fail stories from my friend Karlheinz.

especially on how to write OSless FPC applications on it.

Ooops. do you really want to run this kind of hardware without Linux ? You would need to configure all the hardware manually. Seems like a huge task.

That should tremendously reduce the boot time. Currently Pi took 20 seconds to boot to text shell of the default OS Raspbian. Hear for ArchLinux, it takes 10. How long does BeagleBone take to boot to shell?

I'll ask.

Karlheinz right now is doing some experiments with Debian and the original Angstrom Distribution.

After this he will try to install fpc and Lazarus.

-Michael

Florian Klämpfl wrote

Does it have an fpu which supports exception handling?

I am not aware of this special issue.

The CPU is a AM 335x by TI. A quick search of the nearly 5000 page Chip handbook did not reveal anything on that behalf to me.

-Michael

Karlheinz said on the Phone that the BBBB boots in some 10 seconds to the command line when using the original Angstrom Distribution and at least 20 seconds when using Debian.

-Michael

Yes, at 700 Raspbian boots in 20-22 seconds. With the maximum allowed - without loosing warranty - settings the latest Raspbian boots in about 12-14 seconds.
The discrepancy in these maths comes from the fact that the GPU is also overclocked to 500 (from 250) and the Raspberry Pi bootstraps from GPU, not CPU.

Thanks for your info.

For information, my Raspberry Pi running the ArchLinux boots within 16 seconds to the command line using an old class 4 SD Card. If running Raspbian, it boots to the graphical UI in 30 seconds using a new Class 10 SD Card.

Does BBBB have a stable stock supply?

Dennis

Dennis Poon wrote

** Does BBBB have a stable stock supply?

Note this response I saw to a question about the BeagleBoard/BeagleBone:

"Are we talking the "design" or the board? We will not guarantee continued supply of any version of the BeagleBone. We will change it as we deem necessary to make it better. Therefore if you put the BeagleBone boards in a product, you will find that a particular revision is no longer made and you cannot buy them. If you want to use the design in a product, that is fine. If you want to build the board yourself, that is fine. We are not in the business to crank out thousands of boards for someone to stick in their product., We want to use our production capacity to build boards that go to the community. If we determine that a distributor is selling the BeagleBone for commercial use, they will find their supply of boards will not be there. "

https://groups.google.com/forum/#!topic/beagleboard/yeX5GkEbqZc

So you might want to be careful about using them "straight from the mfg", but you can build your own from the design data all you like.

Jeff.

This is my point: cross-compilation works flawless because it is the only way to develop. Same for FPC: because cross compilation to win64/wince is the way how official releases are built, this way works perfectly, see below.

Of course, it is is the only way. Just try win32 to win64/wince cross compilation with FPC, it also "just works" because it is way our releases work and the mainly used way to build for those targets.

c:\fpc>fpc test.pp -Parm
Free Pascal Compiler version 2.6.2 [2013/02/12] for arm Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: WinCE for ARM
Compiling test.pp
Assembling program
Linking test.exe
2 lines compiled, 0.1 sec , 23216 bytes code, 540 bytes data

c:\fpc>fpc test.pp -Px86_64
Free Pascal Compiler version 2.6.2 [2013/02/12] for x86_64 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Win64 for x64
Compiling test.pp
Linking test.exe
2 lines compiled, 0.1 sec , 29792 bytes code, 1748 bytes data

c:\fpc>fpc test.pp
Free Pascal Compiler version 2.6.2 [2013/02/12] for i386 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Win32 for i386
Compiling test.pp
Linking test.exe
2 lines compiled, 0.1 sec , 25344 bytes code, 1612 bytes data

Same for lazarus: I just change the target and it works: the needed parts of the lcl are rebuilt, then the program is build.

Trying to do the same thing with FPC and Lazarus IDE is a huge pita!

Not with the windows targets.

Thaddy wrote

The discrepancy in these maths comes from the fact that the GPU is also overclocked to 500 (from 250) and the Raspberry Pi bootstraps from GPU, not CPU.

The BBB has an internal SD-Card alike chip. I learned that same has an 8 bit interface (instead of 4 bit SD-Card) and thus is a lot faster when booting from this chip. Karlheinz at the moment uses an SD-Card to boot Debian. So Debian Boot-speed might be close to Angstrom's when moving it to the internal flash.

-Michael

Dennis Poon wrote

Does BBBB have a stable stock supply?

The BBB (Beagle Bone Black - I typed one B to much )seems to be easily available from multiple resellers. It had been delivered the next day.

-Michael

DaWorm wrote

So you might want to be careful about using them "straight from the mfg", but you can build your own from the design data all you like.

The nice thing is that it's an open source design and you can have any decent component shop produce it for you, if you need a greater number.

With the Raspberry the RAM is soldered on top of the CPU, a very critical technology only a few shops can offer.

-Michael

Just to let you know:

Karlheinz did get Lazarus working on the BBB with Debian. He just installed the Debian package for Lazarus. He was able to edit, compile and debug a test program.

Compiling Lazarus does not work due to lack of memory (the BBB has 500 MB and no Swap configured), when the GUI (Gnome) is running. After stopping the GUI Lazarus can be compiled. So installing new Lazarus packages (he needs Synapse and maybe Indy) might be a little bit more work than on a PC.

-Michael

In the US it is $45 each plus shipping. Tax is added if you order from the same state. For someone who doesn't have the money for an HDMI monitor, it does have a RCA connector for NTSC (or PAL) video. It has access to GPIO but so does the BeagleBone so the only thing I can see that would have some value would be for those who cannot afford to buy a decent computer monitor or don't care how bad the picture can be. I got one of those to see what the big fuzz was about. If I had to choose between the two, it would not be my choice.

An odroid is much superior (2G of RAM). While on vacation in Québec I tried it out on a 50 inches HD TV. I was able to play movies with it, using Funtoo Linux. If you want hard disk the Mele A2000G might be a better choice, it has 1G of RAM, a connector for sata hard disk and includes wifi support plus more. I was able to create gentoo on it with no problem. It is not as nice to play video as the odroid which has a 4 cores arm device.

Michel

I 'd love to try this BeagleBone but its out of stock from which I live (using element14 HK).

Dennis

Hi Michel,

I was glad to see your AVR32 FPC releases on your web page: http://home.comcast.net/~mcatudal

Since your stuff is related to embedded stuff ("stuff" is one of my favorite technical terms) I plan to add a link to your page several places on my site when I next update it:
http://www.turbocontrol.com/

******************

How the BBB and RPi differ (a recent list subject to change/correction):
1) With the RPi the RAM is soldered on top of the CPU, a very critical technology only a few shops can offer.
2) The ARM1176JZF-S (RPi) is vfpv2 which supports floating point exceptions whereas the Am335x chip (BeagleBone) is vfpv3 and does not provide such support.
3) The RPi boots up via the GPU whereas the BBB boots up normal. This is one reason my linux-cnc friend (see below) gave up on using the RPi for his real-time stuff.

***************

An engineer who lives near to me recently got linux-cnc working on the BB and also the BB Black:
http://bb-lcnc.blogspot.com/

There are a few links for the RPi, BB, and Arduino near the top of this page:
http://www.turbocontrol.com/monitor.htm

Thanks,
Paul

Michel Catudal wrote

e same state. For someone who doesn't have the money for an HDMI monitor, it does have a RCA connector for NTSC (or PAL) video.

In fact, my friend found that its more comfortable to use VNC and attach to the Target as a remote GUI from his PC, anyway. So no additional Monitor necessary.

He researches on how to switch off the BBB's graphic hardware altogether and by this free the shared graphics memory for software use and avoid the unnecessary memory read cycles for the picture refresh.

(In fact the original purpose of the RPI was young students who perhaps don't own a PC, so this does not apply here.)

Michel Catudal wrote

An odroid is much superior

This of course is an excellent choice if you need the power and can live with the effects of not using a chip dedicated to "embedded" use, which is important if you plan to build you own series of hardware devices based ob the design.

-Michael

It looks like we agree to say that BBB looks nice for large deployment of embedded devices,
Odroid U2 sounds good for development/programming/debugging with Lazarus IDE

Jyv.

I find smaller devices like the AVR32 and PIC32 more appropriate for embedded system. ARM devices with Linux are more for use with video. The Pi is a bit slow on graphics so I came to the same conclusion as many that it is more usefull using ssh. I can run setedit nicely using ssh on the Pi.

Michel

I have played with this thing for a while and find it very impressive. It was nice to use during my recent trip in Québec. Quick to connect to the TV and as performant as a computer for what I wanted to do. I can see a future in these little devices as they get better and better.

One use I can see for the Odroid is a development platform for small embedded system. It is always a pain to carry a laptop or desktop in the lab. If it had gpio on board that would be nicer but then the Odroix X2 has that for a bit more money. Even the Odroid X2 is very affordable.

Michel

Michel Catudal wrote

I find smaller devices like the AVR32 and PIC32 more appropriate for embedded system. ARM devices with Linux are more for use with video.

I don't see it that , having a Linux OS is a great plus for embedded systems. This makes creating, maintaining and enhancing the user software much more comfortable and a developer can have a pool of easily reusable software snippets he can use in all his projects. Of course the support for multiple languages is a big plus, too. Moreover with the upcoming "!internet of things", support of standard software on embedded devices becomes more and more essential. The user want to control their appliances with a smartphone (or a PC) but directly attaching a monitor is not a decent option.

In the rather near past, hardware cost was a limiting factor for the use of Linux in small embedded devices. But as we see, this problem is vanishing. I recon, very soon we will see ARM chips with enough integrated RAM to run Linux (doing away with the hard-to-do "RAM soldered on top" technology the RPi uses). With that, doing a Linux enabled PCB will become easy for small shops (like ours).

-Michael

The problem there is that once you've got something with the complexity of the Linux kernel and a standard language's RTL, you're a very long way from being able to prove either the static or the dynamic correctness of a system. Now I obviously accept that strict proof-of-correctness of any realistic system is virtually impossible, but I don't think that adding subsystems and layers implementing features that are non-critical but have the capability of interfering with critical code is desirable in an embedded system.

Something like RTLinux with the equivalent of a PLC implemented at the core level is obviously one solution to this sort of problem.

That is obviously correct. But as millions of embedded devices successfully do run on Linux, I recon that you can choose a decent Linux distribution for the job. Here again, the BBB is advantageous, as it features a chip by TI and TI explicitly and actively does support embedded Linux on this chip.

Understandably.

Something like RTLinux with the equivalent of a PLC implemented at the core level is obviously one solution to this sort of problem.

This again is why I vote for the BBB. The TI CPU chip used, features two ARM M3 CPUs with their own additional memory space additional to the A8 main CPU. So you can ruin non-realtime Linux and at the same time use the M3 subsystems tor hard realtime stuff with lower guarantee-able latency than any realtime-Linux can provide.

IMHO_this_ (both providing a complex (Linux) System for communication and standard stuff plus very low latency hard realtime) is a very common request with modern embedded appliances.

-Michael

:-) :-) :-)
Of course "ruin" was a typo, but it's not that wrong again ... :-) :-) :-)

Michel Catudal wrote

I find smaller devices like the AVR32 and PIC32 more appropriate for embedded system. ARM devices with Linux are more for use with video. The Pi is a bit slow on graphics so I came to the same conclusion as many that it is more usefull using ssh. I can run setedit nicely using ssh on the Pi. Michel

If any, the Pi is NOT slow on graphics. (f.e. try my openvg bindings for Freepascal from the forum, my Open GLES 2 and OpenMax bindings will follow soon btw, or the Wayland/Weston demo)
The point is, that the community is currently working in opening up the GPU and the standard protocols.
What is slow at the moment are the X11 bindings which are atm accelerated, but only with VFP, taking up a lot of the CPU. This will soon change when the X11 bindings will be based on Xwayland. Also, at least two major browsers are being worked on to support the GPU for rendering, including html5 video.

The point being that the GPU is "a bit" overpowered and the CPU a bit underpowered, but usefull enough. As the omxplayer, the XBMC flavors and the GPU demo's demonstrate.

It is only that the bindings to the most common intermediate/high level layers are in embrionic state.

Basically, this whole discussion is a bit pointless.

Paul Breneman wrote

On 06/29/2013 08:58 AM, Michel Catudal wrote: > Le 2013-06-21 03:32, Michael Schnell a écrit : >> I don't understand why RPI (still) gets so much interest.

The point is that the RPi is a *coherent educational concept *as a whole
- software, hardware, planning, resources - that has to some extend been taken over by hardcore hacker loudmouths who always seem to be disappointed. And it took over 4 years to realize the concept, not just the hardware, that was easy, and a choice made based on price and availability in 2009.
Get the big picture and get the success of the concept (over 2.000.000 sold as per today) and you see why the BB, Odroids and the likes are by a long way not as successfull in the market.
I for one would be glad to see those hardcore complainers gone from the raspberry pi community. They are missing the point, any point..... basically clueless on what to do with it.

Well: there are no professionally written educational resources for BB and Odroid for example. All documentation is geared to professionals or hackers.
Instead of using their capabilities to enhance eand contribute the RPi's eco, all they can do is moan about something better. It isn't! there's no plan behind it, there's hardly a concept, you're basically on your own and the GPU alternatives often underperform compared to the RPi.

By all means, go ahead. But don't forget FPC is a viable compiler and Lazarus is a viable IDE for the Raspberry Pi. And the history of Pascal has a strong educational background.
And on the RPi it has about 2.000.000 times more potential to find Pascal converts then the measely sales figures from the alternatives ;)

Thaddy

That is exactly what I stated in the said contribution.

And of course this implies that it is not that well suited for embedded use (which is my interest and the target of most forum members).

-Michael
*
*

In our previous episode, Michael Schnell said:

That is exactly what I stated in the said contribution. And of course this implies that it is not that well suited for embedded use (which is my interest and the target of most forum members).

Any device whose I/O is not galvanically isolated and shortcut proof is not suitable for true embedded usage.

And afaik these are all development boards, and none of them are isolated, making them basically only suitable to low power PC replacements tasks (like filer or home entertainement)

Hi,

Can this discussion about the pros and cons of various ARM-based boards please be moved to fpc-devel? This discussion is completely unrelated to developing FPC itself.

Thanks,

Jonas
FPC mailing lists admin

Jonas Maebe wrote

Can this discussion about the pros and cons of various ARM-based boards please be moved to fpc-devel? This discussion is completely unrelated to developing FPC itself.

You mean "to fpc-other" or "from fpc-devel", right? ;)

Regards,
Sven

Yes, thanks :)

Jonas

Agree.

Actually you can add some hardware to take care of the isolation. The Pi can be very usefull for command line use or thru ssh. Graphic is a bit too slow, if you are used to a 4 or 6 core AMD64 you will be unhappy with the low graphic performances. Unfortunately the odroid doesn't have this but you could use their USB IO interface and add proper protection needed for your control on that.

For very fast access I have no trust in a system with an operating system that sometimes acts like a trojan. I see these devices with OS only usefull if I need some video. Let's says that you must retract a window if a tiny little finger is in the way as you are closing the window, response must be extremely fast, you cannot afford to have an operating system in charge. If I had to do this with a board with Linux I would have a PIC or AVR on a separate board doing those things or bypass the operating system with interrupts. Without a separate board you need something like RT linux or remove the OS entirely. A bit of work there though.

Michel

OK

Marco van de Voort wrote

Any device whose I/O is not galvanically isolated and shortcut proof is not suitable for true embedded usage.

That is why the BBB is done as a "mezzanine" (piggyback) board./

-Michael
/

Jonas: please excuse this, I'm trying to keep it relevant.

Do you have any URLs etc. for the BBB in this context? Could the realtime stuff realistically be coded in FPC, or would this effectively mandate a distinct target?

Noting Michel's "Linux is a trojan" comment, would the developers be confident using the FPC RTL in a (single-threaded) safety-critical application? What about the FCL?

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).

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.

-Michael

So there's a (slight) risk that a careless kernel on the main CPU could mess up something safety-critical, or at least (as you've said) could have a small effect on timing.

To learn more, you might want to read the "AM335x Applications Processor Technical Reference Manual" by TI (4788 pages).

That I'll leave to the colleague who hassles me on this sort of thing :-)

So something like a ladder logic interpreter would be entirely viable, even if the guts had to be written in C.

Mark Morgan Lloyd wrote

So there's a (slight) risk that a careless kernel on the main CPU could mess up something safety-critical, or at least (as you've said) could have a small effect on timing.

Not at all if you only use the PRUS vicinity hardware interface. If you use other peripherals you need to take the possible delays into account. I did not investigate so deeply that I should know about priorities of the bus accesses.

Please let me know about the your plans and solutions you come up with. Of course you / he can send me a private email with questions and comments.

-Michael

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).

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 wrote

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,

Nope while the AM17xxx processors dud use a custom design for the coprocessors, the AM335x uses ARM Cortex M3

e.g. Page 226 of the AM335x Manual says:

"Table 2-5. M3 Processor Memory Map"

-Michael

Just to let you know:

My friend Karlheinz (with a little help by myself) did manage to get the newest svn versions of fpc and Lazarus compiled and running as well on the BeaglBone as on the Ondroid U2.

He is inclined to write a detailed Howto.

Is there any interest to post same here and/or in the Wiki ?

-Michael

I'd suggest the wiki, and link to it from the "Native ARM Systems" page.