Re: 68332 vs. ARM or other easy to use CPU?

TPU. A *very* clver piece of kit.

I find ARM to be one of the easiest and most regular 32-bit devices to program, but YMMV. You might look at Hitachi H8S and H8 Tiny - they're simple, have good code density and there's EVBs out there.

pete

But, really, how much of most 32-bit projects is written in assembly language?

I wouldn't describe ARM as difficult to program in assembly language. But most people don't need a lot more asm than some simple hardware init and bringing things up ready for the C run-time to take over. If you would like, I'll zip up all the sample sourcecode from my book (I keep meaning to put it up on the web anyway... :) and send it to you.

IMHO, ARM is a more future-proof core to learn.

There are ARMs with integral FPU though. And an XScale at 400MHz, even without FPU, is going to blow a 16MHz 68881's flops figures out of the water on a much smaller board area.

ARM's instruction set is even simpler to learn, but it's harder to write cycle-exact code (and there are more things to worry about; e.g. the MMU and Thumb - but you don't HAVE to use them, of course).

If obsolescence is a concern for you, then don't waste time on 68000.

The TPU is a processor by itself, with its own assembly language.

Please be warned that there are at least two different standard programs in the TPU's and they function very differently. I got once bitten by that - there is one letter near the mile-long exact part marking dependent on the TPU microcode. Luckily, the TPU can be booted at start with whatever microcode needed, and the Motorola website had the standard codes available.

I changed from Intel 80C186 series to Motorola 68332's, when it became apparent that Intel's only interest is in CPU's for Windowses.

Later, as soon as the Atmel AT91's (ARM7TDMI) became available, I changed to them and have not regretted the switch. The GNU tools (GCC, binutils, GDB) work beautifully with the ARM's.

The current trend is to RISC processors due to the good performance / silicon area and performance / supply power ratios. All of them have a common trait of PITA (pain in the ... lower back) assembler code. ARM is probably the easiest RISC processor, e.g. no delay slot instructions. For comparison, see e.g. Sparc or MIPS documentation.

One reason for the popularity of the RISC processors is that they are not intended to be programmed in assembler, there are very good C compilers for the code. Of course, there are places where only assembly code will do, but my experience (a couple of hunderds of kilobytes of tight embedded ARM code for AT91's) is that they are very few and far apart.

With the same clock frequency, you'll get nearly the same performance with a RISC processor and software floating point as a CISC with a FPU (and at a tiny fraction of price and supply power).

Get an AT91 development board and the GNU toolkit hosted on your Linux.

HTH

Tauno Voipio tauno voipio @ iki fi

No actual numbers - just a feeling after changing same applications from MC68332 to AT91's (ARM7TDMI).

For code, get the GCC sources and look at the FP library code. On 32 bit processors, single-precision IEEE floating point is pretty simple to handle. It's a totally different story with 8 bit micros, as the calculations have to be performed to 32 bits.

Tauno Voipio tauno voipio @ iki fi

How do you like the EP7312?

Motorola have been having lots of more or less serious bugs in their chips during the past 5 years or so.. I have been using Motorola (HC11, HC05, HC12, HC16, 68xxx, MCore) for ages, but the ARM land looks promising and I want to get rid of Motorola (their chips just cost me too much because of the bugs).

-jm

Since it's a hobby project I didn't got that far but I liked, what I've tried. The serial boot-loader for example is a nice feature (Motorola has that too). My biggest issue is it seems to be impossible to get it in small quantities now. So I'm seriously tinking about switching to the Sharp device. It would mean a complete HW and SW redesign but (again, hobby project) that's part of the fun anyway.

Andras Tantos