Short of it: Plannning to write some software that will run on an ARM-based device running Linux. Also planing to write some software that will run on a standard x86 Windows machine, PowerPC Mac OS X machine and x86 Linux machine. This will be GUI-based and likely using a common GUI framework (probably using wxWidgets ).

We're looking at (obviously?) purchasing an ARM development kit, perhaps from Motorola. However, in the meantime, we'd like to start on some code and possibly (partially) test it using some other linux device. The issue here is that we're in the process of deciding what development hardware we'll need and what platform and tools to invest in (Metrowerks for instance). But we'd like to get started on code right away, because there's a fair amount of development to do.

Anyway, This can either be an emulator of some sort to run under Windows or x86 Linux or (preferably) Mac OS X. I was also thinking that it might be possible to run some portions of code on an empeg (I've got a spare) and/or one of the NAS boxes mentioned recently in another thread (a Kurobox/Linkstation). Or even some handheld running Linux I suppose.

I know people here develop all kinds of software on a multitude of platforms, so I'm looking for some advice. And from past experience I suspectt there will be a number of varried opinions.

Bruno

Dan Kegel's crosstool is where it's at for cross-development toolchains. Unless code density is your only god, you needn't bother with ARM Ltd's own tools, if targeting Linux or Ecos.

Depending on exactly what your software does, it should be possible to compile and run most of it on x86 Linux -- at Empeg we have some code (even onto bare Xt it's not that much code) that makes an X window appear to the device as its own display, so much of the software, and particularly its UI, can be written and debugged without so much as a sniff of target hardware. (In particular, you get to use valgrind on x86 Linux.) If you've got custom hardware on the target, you could write x86 Linux "dummy" device drivers that appear to your software to be that hardware. This can also make unit-testing and other automated tests easier than use of the target device. The ARM and x86 processors are pretty similar (endianness and so on), so unless you're intending to write much ARM assembler, it should be OK. (There are a couple of ARM/x86 gotchas -- it's possible to write C that gives different results on the two. One way is to shift an int by 32 bits -- but this is implementation-defined, so don't do it! Also the in-memory representation of 64-bit doubles is different -- the 32-bit words are in the other order.)

If you're starting this from scratch, you want to look at much newer versions of gcc, glibc, and the kernel than we used on the car-player -- this may affect your ability to run stuff on a stock car-player. (Or, conversely, affect your ability to run stock Empeg code on a player you've upgraded.) If you don't want to mess with a car-player, look at getting hold of a RiscPC (with StrongARM and Ethernet upgrades) from Ebay.

Peter