Intel vs Motorola microprocessor for instruments?
BRIAN LATTA
adventure. The production cost is going to be about $2,000 so the cost of
the microprocessor can be judged against this. An engineering summer
student convinced me to go with a Motorola 68000 although I wanted an Intel
so that PC background might be applicable. He has gone and the
microprocessor plus I/O board is not working yet. I am asking myself if I
should continue learning the 68000 or switch to spending my time learning
the Intel processor and related I/O.
Any general comments on comparisons would be appreciated by this
electronics novice.
Dr. Bryan Latta; Physics Professor; Latta Technologies Inc.;
Acadia University; Trans Polar Trading Co. Ltd. (Russian handcrafted
Nova Scotia, Canada; nested matrioshka dolls)
Tom WB7ASR
In article <latta.11...@ace.acadiau.ca>, <la...@ace.acadiau.ca> writes:
> I am asking myself if I should continue learning the 68000 or switch to
> spending my time learning the Intel processor and related I/O.
> electronics novice.
>
Of course, no question about it. You should spend your time learning the
Intel processor.
pjr...@uci.agh.edu.pl
>I am building some new test equipment as my first entrepreneurial
>adventure. The production cost is going to be about $2,000 so the cost of
>the microprocessor can be judged against this. An engineering summer
>student convinced me to go with a Motorola 68000 although I wanted an Intel
>so that PC background might be applicable. He has gone and the
>the Intel processor and related I/O.
>electronics novice.
>
>Dr. Bryan Latta; Physics Professor; Latta Technologies Inc.;
>Acadia University; Trans Polar Trading Co. Ltd. (Russian handcrafted
>Nova Scotia, Canada; nested matrioshka dolls)
Dear Dr. Bryan,
my 12 year experience in microcomputer design and teaching tells me that it has no
sense to give up - 90% of my students prefer Motorola (I am not fanatic fan). Dealing
with hardware details of Intel microprocessor is not so easy as programming PC
computer. If you tell me some details about your design (do you want to check your
schematic diagram ? - send it in Orcad or PostScript format file), software tools etc.
maybe I could help you to make your hardware running.
Kind regards
Roman Rumian
rum...@uci.agh.edu.pl
Steve Jacobson
>Subject: Intel vs Motorola microprocessor for instruments?
>Summary: What are the pros and cons?
>Keywords: Intel, Motorola, 68000, small instruments
>Date: Wed, 3 Aug 1994 12:44:39 GMT
> I am building some new test equipment as my first entrepreneurial
>adventure. The production cost is going to be about $2,000 so the cost of
>the microprocessor can be judged against this. An engineering summer
>student convinced me to go with a Motorola 68000 although I wanted an Intel
>so that PC background might be applicable. He has gone and the
>microprocessor plus I/O board is not working yet. I am asking myself if I
>should continue learning the 68000 or switch to spending my time learning
>the Intel processor and related I/O.
> Any general comments on comparisons would be appreciated by this
>electronics novice.
Go with the Motorola 68332 microcontroller. It is a high integration 68020
with almost everything (except rom and ram) on the chip. You can get it in a
20Mhz version. Motorola sells an evaluation board that comes with a debugger,
an assembler and a c compiler for about $1200 bucks.
-----------------------------------------------
Rgds Remember, half a wit is
Steve Jacobson better than none. :-)
sja...@maroon.tc.umn.edu
Hugh Shane
>>adventure. The production cost is going to be about $2,000 so the cost of
>>the microprocessor can be judged against this. An engineering summer
>>student convinced me to go with a Motorola 68000 although I wanted an Intel
>>so that PC background might be applicable. He has gone and the
>>microprocessor plus I/O board is not working yet. I am asking myself if I
>>should continue learning the 68000 or switch to spending my time learning
>>the Intel processor and related I/O.
Ahhh... The old debate. Haven't heard this one in at least a week /;)
But really, It depends on whether or not your application requires
real-time performance. If it doesn't, then an Intel platform (read PC)
is your best bet because of the availability of tools, operating system
(DOS), etc. However, if this is to be an embedded, real-time system, then
you don't want DOS anyway, so your options open up. In my experience
the segmented architecture of the Intel processors is a real pain
to deal with when you're programming in assembly language, which
you'll probably be doing if your widget needs to go fast. The
Motorola processors, on the other hand, are really simple to program.
Of course, if you're using a high level language much of this becomes
transparant anyway.
In either case remember that software is going to be your biggest cost
and that hardware will be secondary (unless you're building a zillion
of the things). Do whatever you must to keep software costs down and
you'll be way ahead of the pack!
-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Hugh Shane | 206 487 5909 (PST)
Motorola Wireless Data | N7UAX
sh...@mdd.comm.mot.com | "Ain't nobody gets outa here,
| without singin' the blues"
-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Petteri Jäntti
BRIAN LATTA <la...@ace.acadiau.ca> wrote:
> I am building some new test equipment as my first entrepreneurial
>adventure. The production cost is going to be about $2,000 so the cost of
>the microprocessor can be judged against this. An engineering summer
>student convinced me to go with a Motorola 68000 although I wanted an Intel
>so that PC background might be applicable. He has gone and the
>microprocessor plus I/O board is not working yet. I am asking myself if I
>should continue learning the 68000 or switch to spending my time learning
>the Intel processor and related I/O.
> Any general comments on comparisons would be appreciated by this
>electronics novice.
>
If both processor choices are providing all the necessary functions, the
choice is more a matter of taste. You should probably try to evaluate
whatever you need to do and compare the processors deciding which one
offers the best way of doing it. Personally, I would choose Motorola. My
choice (if the 68K architechture is appropriate) would most likely be
Motorola's 683xx series of microcontrollers. It depends on what you need
to get done. You can achieve suprising performance with just a cheap
68HC11.
--
Petteri Jantti \ GEEK CODE 2.1: GCM/CS/E d- H+ p2+ au+ a- w+ v
Hirsipadontie 3 E 25 \ C++(++++) US/UU++++$ P+>+++ L- 3 E---(E) N+++>N+
FIN-00640 Helsinki Finland \ K+ W--- M-- V-- -po+ Y+ t+ !5 j- R- G? tv+@
email: p...@ichaos.nullnet.fi \ b+>++ !D B? e* u+ h+(*)>h++ f r+ n---- y++
Jim Cathey
>Of course, no question about it. You should spend your time learning the
>Intel processor.
Yeah, right. Segments and all. And spend time trying to fight
development tools that aren't designed for embedded systems. The 68K is
a simple and honest CPU, and there are good tools out there for embedded
systems work.
I'd _never_ choose x86 for anything that didn't have to run some
of Microschlock's code.
--
+----------------+
! II CCCCCC ! Jim Cathey
! II SSSSCC ! ISC-Bunker Ramo
! II CC ! TAF-C8; Spokane, WA 99220
! IISSSS CC ! UUCP: uunet!isc-br!jimc (ji...@isc-br.isc-br.com)
! II CCCCCC ! (509) 927-5757
Jonathan Dale Kirwan
: But really, It depends on whether or not your application requires
: real-time performance. If it doesn't, then an Intel platform (read PC)
: is your best bet because of the availability of tools, operating system
: (DOS), etc. However, if this is to be an embedded, real-time system, then
: you don't want DOS anyway, so your options open up. In my experience
: the segmented architecture of the Intel processors is a real pain
: to deal with when you're programming in assembly language, which
: you'll probably be doing if your widget needs to go fast. The
: Motorola processors, on the other hand, are really simple to program.
: Of course, if you're using a high level language much of this becomes
: transparant anyway.
: In either case remember that software is going to be your biggest cost
: and that hardware will be secondary (unless you're building a zillion
: of the things). Do whatever you must to keep software costs down and
: you'll be way ahead of the pack!
Yes!!!
I'd put it this way, though. The sheer number of choices available for
the PC, the number of different tools, etc., all make it a good choice
with embedded applications when using C. If you are, you probably aren't
as concerned with raw performance as those insisting on assembly, so the
Motorola parts (even if they were faster per $) don't figure in. (There
is some need for start-up assembly coding, though, and writing this for
Intel will probably take more initial time and more maintenence.) So, if
you use a high-level langauge and have the memory for it, stay Intel.
But if you are programming in assembly, you probably need tight control of
your instrument, would like to reduce the program space to a minimum, need
as much speed as you can get, etc. Motorola parts tend to be, in my
experience, too slow, too costly, and I'm always adding something to get
the I/O I need (few bi-directional I/O pins, for example, when using
external memory is very very frustrating sometimes. (Easy to get samples,
though, and the support is good.)
Hitachi H8-330 OTP is about $10, has 16kbyte EPROM, can be programmed
with a normal EPROM programmer. It has 200ns (a year ago, anyway) 16-bit
adds, though more like 600ns for external memory. It has 50+ I/O pins
with controllable direction. A good programmer can do a lot with 16k.
Heck, a good programmer can do a lot with 2k.
But Motorola is a good choice. It is easy to find programmers that are
very familiar with these parts, and that fact is worth a lot.
Jon
Matt Albright
No, no, don't listen to him. There is no question about it. You should spend
your time learning the Motorola processor. :) :) :)
Michael Covington
: Actually, I dislike the design of Intel's chips passionately. And their
: heavy-handed, stuffy, and self-important behavior deserves a slap in the
: face. (That cash-cow 80x86 has kept them from living in reality.)
You could add to your cynicism by pointing out that all of Intel's
commercial successes -- 8088, 80286, 80386, 486, Pentium -- have been
successful only by being used in ways that weren't really want Intel
intended: 8088s running Lotus with expanded memory, 286s-386s and up
running in real mode, sometimes simulating the 8088's bank-switched
expanded memory!
Personally, I don't dislike the Intel design. But I do find it amusing
that PCs aren't much like what Intel designed these chips for.
--
< Michael A. Covington, Assc Rsch Scientist, Artificial Intelligence Center >
< The University of Georgia, Athens, GA 30602-7415 USA mcov...@ai.uga.edu >
< Unless specifically indicated, I am not speaking for the University. > <><
For information about any U.Ga. graduate program, email gra...@uga.cc.uga.edu.
Jonathan Dale Kirwan
Don't listen to Mot. Motorola died, just hasn't sunk in yet. Intel is
everywhere. Might as well face up to it, now, even if Intel's chips
have an impossible architecture design and lousy floating-point (until
the Pentium finally took heed.)
Actually, I dislike the design of Intel's chips passionately. And their
heavy-handed, stuffy, and self-important behavior deserves a slap in the
face. (That cash-cow 80x86 has kept them from living in reality.) But if
I have to suffer out here with these lousy things, I'd like some miserable
company to share my pain with.
Jon
Jonathan Dale Kirwan
: Jonathan Dale Kirwan (jo...@netcom.com) wrote:
: : Actually, I dislike the design of Intel's chips passionately. And their
: : heavy-handed, stuffy, and self-important behavior deserves a slap in the
: : face. (That cash-cow 80x86 has kept them from living in reality.)
: You could add to your cynicism by pointing out that all of Intel's
: commercial successes -- 8088, 80286, 80386, 486, Pentium -- have been
: successful only by being used in ways that weren't really want Intel
: intended: 8088s running Lotus with expanded memory, 286s-386s and up
: running in real mode, sometimes simulating the 8088's bank-switched
: expanded memory!
: Personally, I don't dislike the Intel design. But I do find it amusing
: that PCs aren't much like what Intel designed these chips for.
I do dislike them, not because others' comments about segments (Multics is
not necessarily a bad way to go), but because it has severely limited the
progress of compilers and other tools.
The design (finally usable starting with the 80386) has meant the
development of sophisticated code organizers and optimizers that deliver
little else than working code. The operating environments (I won't credit
them with the term 'operating system') started poorly, without
virtualizing anything, and now we're left with designing code around a
million software pot-holes that can't be fixed without voiding other
important and historical code. Some of that "hokeyness" is, I believe,
due to the lack of readiness of the junior achievement programmers that
poured into the PC market. Mix those 2nd year programmers, without a
lick of experience but a wealth of enthusiasm, together with a processor
that harkened back to a crystal palace design-concept called Multics and
we have what we have.
I don't blame Intel or any 1 person or group (though Microsoft deserves
much), but my experience with DSPs (TMS320 and ADSP-21xx), RISC computer
optimizers and O/S work (MIPS R2000, MIPS R3000, Mot. 88k), and various
small embedded processors has let me see rapid progress in compiler
technology -- and nearly completely side-step right on by the PC. Code as
good as hand-coded from the Pascal compiler on Apollo DN3000, trace-
scheduling algorithms, memory-reference disambiguation, colorizing, a
dramatic spread in various global optimizations, and ON AND ON AND ON.
But in the PC marketplace? Junk. Microsoft's C++ 1.5 compiler still
can't generate correct code to select overloaded routines robustly. And
Intel's architecture has contributed to the difficulties -- if the
compiler writers had less to cope with in segmentation and specialized
instruction/register screw-ups, they'd be in a far better position to
deliver other benefits. And these complexities buy nothing in terms of
performance, these days (it may have during the 8088 days.)
The PC market, as far as the quality of programming development tools
goes, has been a continual collection of screw-up on top of screw-up.
Microsoft's BASIC of the late '70s could handle nested FOR loops
properly, DOS started a whole marketplace while leaving nearly everything
to the developer to make work properly, Windows is a whole running joke
by itself, and the compilers (and I have most -- Watcom, Metaware,
Microsoft, Borland, Zortec, etc.) are stunning to me in their lack of
quality. Lots of sizzle and absolutely no meat. The market demands the
sizzle, no getting around that, but the designers would have been able to
give more meat if they hadn't had their brains scrambled by Intel's
tough-to-get-one's-mind-around architecture. The use of the new 32-bit,
small-model-only-and-forever, memory model will finally permit the use of
compiler technologies developed for simpler architectures. Of course,
we'll still have a legacy of important 16-bit programs to support and
that will greatly slow down the delivery, yet again, of quality tools
even for the 32-bit domain because those very programmers will be too
busy maintaining that crap environment.
Nuff said?
Jon
Hans Adams
Please reply to ad...@server.idd.maschinenbau.th-darmstadt.de, if
adams@idd.... fails
In article Newsgroups: sci.electronics
From: jo...@netcom.com (Jonathan Dale Kirwan)
Organization: New World Computing Services
X-Newsreader: TIN [version 1.2 PL1]
Distribution: na
Date: Fri, 5 Aug 1994 02:37:06 GMT
: In either case remember that software is going to be your biggest cost
: and that hardware will be secondary (unless you're building a zillion
: of the things). Do whatever you must to keep software costs down and
: you'll be way ahead of the pack!
> Yes!!!
As we refer to his FIRST larger project, as he pointed out, we should
keep away from sarcasm. Be warned, I am going to take your answer
serious.
> I'd put it this way, though. The sheer number of choices available for
> the PC, the number of different tools, etc., all make it a good choice
> with embedded applications when using C.
Indeed, but they were never designed to work in an embedded environment,
their runtime librariies are neither interruptable nor reentrant.
Did you ever consider the way the debugger hook (or kludge) was added into
the C-library of Turbo C and Borland C?
What about all the memory expanders etc. launched by runtime systems....
Have you ever read the sources of a BIOS...
> If you are, you probably aren't
> as concerned with raw performance as those insisting on assembly, so the
> Motorola parts (even if they were faster per $) don't figure in.
Even more interesting, but Motorola covers about 80-90 percent of the realtime/
embedded market. At least in Europe, most professional, micro processor
based systems are founded on 68k series, from combat aircrafts like Tornado
and Fighter '90 down to telephone circuitry .....
Have you ever wondered, how may laser printers are equipped with 80x86 ?
> But if you are programming in assembly, you probably need tight control of
> your instrument, would like to reduce the program space to a minimum, need
> as much speed as you can get, etc. Motorola parts tend to be, in my
> experience, too slow, too costly, and I'm always adding something to get
> the I/O I need (few bi-directional I/O pins, for example, when using
> external memory is very very frustrating sometimes. (Easy to get samples,
> though, and the support is good.)
Too slow ..., well to be agreed, if you want digital signal processing,
The 68xxx are not DSPs, this demand is satisfied by 5600x/9600x, the 56001
is not expensive, at all.....
16/32bit micro controllers for about 10$, the readers might judge on their own.
Bus not multiplexed, 4 chip select signals ready to go, 24 programmable I/O pins
and hardwired boots trap procedure are too difficult to use?
> But Motorola is a good choice. It is easy to find programmers that are
> very familiar with these parts, and that fact is worth a lot.
But even more PC hackers are around,
> Jon
adams
--
Please reply to ad...@server.idd.maschinenbau.th-darmstadt.de, if
adams@idd.... fails
Jonathan Dale Kirwan
: > I'd put it this way, though. The sheer number of choices available for
: > the PC, the number of different tools, etc., all make it a good choice
: > with embedded applications when using C.
: Indeed, but they were never designed to work in an embedded environment,
: their runtime librariies are neither interruptable nor reentrant.
Some of the library routines are, though. I've used PC compilers
(Lattice, Microsoft, and Borland) to develop years worth of embedded
applications. It can be done easily. Just takes knowing what you are
doing.
: Did you ever consider the way the debugger hook (or kludge) was added into
: the C-library of Turbo C and Borland C?
No. I haven't needed to use their debuggers. Haven't needed a debugger
in more years than I'd care to mention. But that could be an important
consideration for those that rely on such software to develop code. Please
expand this comment so I can learn.
: What about all the memory expanders etc. launched by runtime systems....
You have the start-up source, or should have, when you try to develop
embedded code. I can tell you I have had no problem understanding
what to do and doing it. With several compilers. For embedded aps,
you'd better know something about O/S's, memory management, etc.
: Have you ever read the sources of a BIOS...
Yes. I have several incarnations. I have not read them all entirely,
but I have taken leisure time to read through some of their content --
even when the information wasn't needed for a project. Just part
of my job to stay informed.
: > If you are, you probably aren't
: > as concerned with raw performance as those insisting on assembly, so the
: > Motorola parts (even if they were faster per $) don't figure in.
: Even more interesting, but Motorola covers about 80-90 percent of the realtime/
: embedded market. At least in Europe, most professional, micro processor
: based systems are founded on 68k series, from combat aircrafts like Tornado
: and Fighter '90 down to telephone circuitry .....
I can't comment on Europe, but Motorola figures very importantly here, too,
though not at the level you state given my experience. I would never
suggest that Motorola be ignored. It is widely supported and there are
many programmers available for it.
: Have you ever wondered, how may laser printers are equipped with 80x86 ?
No. None. They usually use DSP parts, these days. i960 parts figure
importantly here.
: > But if you are programming in assembly, you probably need tight control of
: > your instrument, would like to reduce the program space to a minimum, need
: > as much speed as you can get, etc. Motorola parts tend to be, in my
: > experience, too slow, too costly, and I'm always adding something to get
: > the I/O I need (few bi-directional I/O pins, for example, when using
: > external memory is very very frustrating sometimes. (Easy to get samples,
: > though, and the support is good.)
: Too slow ..., well to be agreed, if you want digital signal processing,
: The 68xxx are not DSPs, this demand is satisfied by 5600x/9600x, the 56001
: is not expensive, at all.....
Again, 68hc11 parts are fine. Programming talent is cheap and readily
available for them. Assemblers and compilers are easy to get. My
comment comes from my thrifty nature and my desire for the fewest parts
that are effective for the job.
I can always match each Motorola 68hc11 design with a cheaper, faster,
and smaller part-count design using someone else's chips. I have always,
always examined Motorola in every design attempt. They are too important
not to do so. I have always found a better part FOR THE APPLICATION AT
HAND, though. In every case! Since I am often the programmer, too,
software talent is NOT an issue for me. That's just my unique niche.
Other's will have their own considerations and may not come to the same
conclusions because of their own needs.
Motorola parts are pricey for what you get. Simple. They are good
parts, though, and most designs would work quite satisfactorily with
them. They are rarely the optimal choice, however, as I see it.
: 16/32bit micro controllers for about 10$, the readers might judge on
: their own.
: Bus not multiplexed, 4 chip select signals ready to go, 24 programmable I/O
: pins and hardwired boots trap procedure are too difficult to use?
Again, they are not hard to use! I like them. I like many of their
features. They are nifty parts. I have a bunch of A1's laying around
that I use for hacking. Would I choose them for a client's design? Yes,
if I couldn't find a better CPU. I've always done better, though -- so
far -- and mainly due to their pricing.
: > But Motorola is a good choice. It is easy to find programmers that are
: > very familiar with these parts, and that fact is worth a lot.
: But even more PC hackers are around,
True. Again, my point. There is a hurdle to overcome in using PC tools
for embedded applications. No doubt about it! Once that hurdle has been
paid for, you can march forward.
But I generally don't like using Intel 80x86-type devices for embedded
applications. I apologize for coming across as a supporter of using
80x86-like CPU chips in embedded designs. They make designs far too
complicated.
However, there are times when my clients needs have driven the design to
use them or to use small Intel-bases CPU boards from various vendors.
Embedded development, piggy-backing onto the tools sets available for the
regular PC programming environment, is definitely not very difficult. I
certainly wouldn't be frightened away by the minor struggles involved.
The only serious drawback I've encountered in this process is the
availability of re-entrant floating-point subroutines. No one, not one
compiler vendor, has been helpful in this regard. But there are
solutions even then.
Jon
Adam Felson
back to a 4 bit traffic light controller. They've maintained compatibility
all the way. (4004->8008->8080->8086->...)
Jonathan Dale Kirwan
: It's amusing that the 3.1e6 transistor pentium traces it's architecture
: back to a 4 bit traffic light controller. They've maintained compatibility
: all the way. (4004->8008->8080->8086->...)
The Pentium is compatible with the 4004?! It isn't even compatible with
the 8086 (look at the last segment's handling between the two and the
reason for the A20 line control in PC's at and after the AT.)
Jon
Henry Spencer
>: It's amusing that the 3.1e6 transistor pentium traces it's architecture
>: back to a 4 bit traffic light controller. They've maintained compatibility
>: all the way. (4004->8008->8080->8086->...)
>
>The Pentium is compatible with the 4004?! It isn't even compatible with
>the 8086 (look at the last segment's handling between the two and the
>reason for the A20 line control in PC's at and after the AT.)
He didn't mean pin-compatible; the pinouts are just a wee bit different. :-)
Like for example, the Pentium has about ten times as many pins...
It's actually incorrect to trace all the way back to the 4004, as I
understand it, because the 8008 was a sibling of, not a replacement for,
the 4004. However, the 8080 was a somewhat-upward-compatible upgrade of
the 8008, and the 8086 was a somewhat-upward-compatible upgrade of the
8080, and all the x86 machines since have been somewhat-upward-compatible
upgrades of the 8086. There was no binary compatibility between 8008 and
8080, or between 8080 and 8086, but there was a serious attempt to pretty
much preserve (assembler) source compatibility, so the general philosophy
of the instruction sets remained very similar. If the phase of the moon
was right, it just might be possible to take your old 8008 assembly source
code and convince an assembler running on a Pentium to accept it, perhaps
with a few minor tweaks.
--
"We must choose: the stars or the dust.| Henry Spencer @ U of Toronto Zoology
Which shall it be?" -H.G.Wells | he...@zoo.toronto.edu utzoo!henry
Kevin Burtch
> Intel processor.
>
> tom_...@ccm.hf.intel.com
Gee, this one isn't obvious is it? ;^)
kbu...@pts.mot.com
^^^
;^)
(sorry, couldn't resist!)
Jarek Lis
: You could add to your cynicism by pointing out that all of Intel's
: commercial successes -- 8088, 80286, 80386, 486, Pentium -- have been
: successful only by being used in ways that weren't really want Intel
: intended: 8088s running Lotus with expanded memory, 286s-386s and up
: running in real mode, sometimes simulating the 8088's bank-switched
: expanded memory!
: Personally, I don't dislike the Intel design. But I do find it amusing
: that PCs aren't much like what Intel designed these chips for.
Well, remember that 386,486,586,... are designed for speed, power, ... and
compatibility wit 8088.