aaaand Thesaurus boy!

I'd hope he only wore it at home (if at all).

Its a safe bet that this chip has DMA capabilities for most, if not all of its built in peripherals. Otherwise you're left to perform interrupt or polling based data transfers which just wouldn't let it get anything done.
I don't know this for a fact, but I'd say that all chips in this class have DMA capabilities. A few ARM chips now seem to have quite flexible DMA that allows for BitBlt operations which can be quite handy.

What about that whooshing sound... how much do you care about that?

Or maybe the cat didn't have a collar because the owner was worried about the risk of strangulation, which can happen even with elasticated collars. I don't think you can say that the owner didn't care about their cat because of the lack of collar.

I know this. My point is that in some cases the source is enough, because you can use knowledge of other visible aspects of the system (such as the bootloader) to create your own build environment.
Somewhere else in the comments people were complaining about the fact that although you can unpack some source and build it, the method needed to create the binary image suitable for flashing on to the device is a complete unknown if you don't have build scripts. I don't think this is necessarily the case if you're prepared to put it the work and have the relevant knowledge.

Anyway, as you said, its all about patching the binary if you're gonna do it properly!

Actually... I've seen a few commercial ARM compilers that are supplied with microkernels (Keil is one that springs to mind). And the Linux distribution I'm currently using from Texas Instruments for one of their ARM chips is supplied with a gcc cross-compiler compiled for Linux and Windows (and I think even OSX).

As much as not having the build environment (ie. scripts) can be an annoyance, companies seem to often use uBoot or RedBoot [yes, citation needed, I know... this is just what I've seen so I could be very wrong], meaning that if you have an upgrade image to pick apart, you can work out how you're meant to be building your own upgrade image.

So, err, how did you come across that picture then?

Strange how a British website is selling stuff in dollars

Ooh and with that unification think of the DRM possibilities!

'splain me how ARM can be 'the embedded processor maker' at the same time as not making any processors, please.

Not to be a pedant or anything (spare the thought!) but ARM don't actually make any processors. They own and control the core IP that is licensed by various processor and SoC manufacturers.

However, ARM processors do seem to be the most popular processors for embedded systems. Which I think is what you meant.

Fnarr fnarr!

Maybe you have to make a big show of pretending to throw stuff away. Maybe in front of some other, more modern hardware. That'll trick 'em!

Not much to say other than I have to disagree about Lua. Its so incredibly lightweight I've found it to work absolutely fine on an embedded (ARM based, 64MB RAM) system (ok, that is a fair bit of RAM I guess). I imagine if you wanted every library under the sun for it, then it might start to weigh in :-)
Don't know tons about Ruby but I'd imagine that might be a little too heavy for the same system though.

Oh and I've rebuilt busybox (and recreated of the rest of the root filesystem), but the initial system that came from the vendor comes with a seperate bash binary. I've kept it on the flash but I've found I haven't actually needed to use it for any shell scripts yet. Busybox's Bourne shell has been enough.
I love busybox. Lots.