8051 vs. 68K

[J.D. McEachin]

At 02:13 PM 11/15/96 -0800, Richard Martin wrote:

>Anyway, I've been following the discussion about microcontrollers for patch
>storage and midi stuff and I thought I'd throw in my $.02.
>
>8051:	1.  Cheap (<$10 for some of the EPROM parts in volume)
>	2.  On board UART, parallel I/O, RAM
>	3.  Stone-age 8-bit instruction set that gets the job done

How stone-age?  There's a compare and jump if not equal (cjne), but no
compare and jump if equal - this sucks!


>68000:	1.  More expensive
>	2.  Have to add ROM, RAM, and possibly I/O ports
>	3.  Reasonably elegant and modern 32-bit instruction set.

The 68000 designers were striving for what is known as a "symetrical
instruction set", otherwise known as "do whatever the hell you want with
whatever register you want".  This is nice when writing compilers.


>As far as programming goes, the 68K wins hands down.  There is really
>no contest as far as ease of programming in assembly language.  Also, if
>you want to, you can program the 68K in C.  There are a few C compilers
>available for the 8051, but the 8051 architecture isn't really optimized
>for C.  The GNU C compiler, which is free, supports the 68K family well.

But C means overhead, and overhead is bad when doing realtime stuff.  Still,
I once did a seriously realtime satellite/radar dish control embedded app w/
dsp algorithms for braking damping on a 68000, mixed between C and assembler....


>You should also consider ease of debugging.  The normal way to debug 8051
>code is with an in-circuit emulator.  With the 68K you can use the GNU
>debugger and do source level debugging over an RS-232 line.

Call me "not normal" then.  Europa is being debugged by sending 1 byte
messages out MIDI....

>One drawback I forsee with the 68K in a DIY project is that some of the
>more interesting parts in the 68K family are only available in surface
>mount.  On the other hand, I haven't seen DIP 8051's in a long time either.

They're readily available.  Newark is probably your best source.  We've got
tubes of them...

>The synth programmer project might be simple enough software-wise that
>you could code it for an 8051 in assembly and debug it by trial-and-error.
>For something more complicated, like a midi-cv converter, I would prefer 
>to use a 68K.

Depends on how good you are.  You'd better be pretty good to debug w/o an ICE!


t 04:31 PM 11/15/96 +0100, Matthew S. Padden wrote:

>Just to stick my oar in; all the ideas we've had about programmers are 
>great, but there's a niggling little worry in my mind which won't go away. I 
>think it's basically to do with the zipper noise that was discussed 
>previously; so many synths I've used (digitally-controlled analogue AND 
>digital) have audible side effects of using 8-bit controls. The filter 
>cutoff is a good example; generally things at higher pitches seem to suffer 
>more (Just try quick pitch bending over an octave at the top of the keyboard 
>on a digital synth). Continuous (ie analogue) controls seem to have far more 
>purity, again particularly at high pitches. I know that 12 or 16 bit control 
>is going to be more expensive in terms of cost and implementation, but it 
>would make a LARGE difference to the sound quality of the system as a whole.
>
>	Maybe I'm wrong and I'm getting confused between resolution and realtime 
>response of the uP... Still, as we're designing it, we might as well try it!

12 and 16 bit ADCs/DACs once cost hundreds of dollars.  They just aren't
that expensive anymore - only a few bucks more than an 8 bit.  Don't be
stupid, go for higher res.


At 05:47 PM 11/15/96 +0100, Magnus Danielson wrote:

>Besides, for doing just the CV storage things with no extreme things I can do
>the assembly by hand, just like in the old days.

To quote Monty Python - YOU'RE LOONY!

I think I can supply C source for a decent 8051 assembler (Neil fixed it so
it will even tell you what line a forward reference falls on).  

>This way you will not depend
>on some software tool that only runs under a distinguished system (no names) :)

C source means you can compile it for whatever distinguished system you prefer.

>>>   OTOH, half of the group seems inclined towards the 8051 line. If this
>>   thing can run a Jupiter I'm sure it can do what we're trying to do. If
>>   poeple who can actually do the design are more comfortable with this IC,
>>   then that's probably where we should stay. I believe this chip is used in
>>   my Fatman - yes? It's probably a cheaper and simpler alternative.
>
>Well, the 68000 line was probably my idea (or fault :) but I have no trouble
>with any of them. I think that there is about the same trouble with both CPUs
>even if the 68000 may be a little too much for just a CV storage unit.

I agree - it's pretty much a tossup.


>For this specific project would much out of the 8051 features be unused anyhow.
>Maybe only the timer/interrupt would be the extra that isn't really in the
>68000. The timer/interrupt would be used to generate timely interrupts to 
>preform steady read/updates in a strictly timed fasion.
>The 8051 also has some onboard RAM, but since we probably have enougth SRAM 
>outside anyway we migth use some of that to do the same work for the 68000
>solution.

128/256 bytes isn't a lot...

>The 8051 can do MIDI really easy with just initiate a few registers properly
>and have the standard CMOS/TTL to MIDI level conversion. An 68000 would need a
>external serial chip (like a 6850) do to similar things.

Right - just look at the JP6 schematic for an example interface.

Just remember - you DON'T want a CPU w/ built-in EPROM for development.
It's better to have a dozen cheap, fast EPROMs on hand so you can burn 'em
and cook 'em quickly...

If I could contribute code, I'd recommend the 8051, as I have a lot of
applicable code.  However, my business partner won't let me give you the
code, so I have to say, it's a tossup - either family will work.

JDM
Synthcom Systems, Inc.
http://www.synthcom.com/