MCU choices

John S Gwynne jsg
Wed Nov 2 14:30:31 GMT 1994


--------

   In message <9411021014.utk5875 at PTD.intel.com> , you write:
 
| Hi all, I just subscribed to the list, so forgive me if this has been discuss
| ed
| before.  I plan to design and build an EFI system for my '56 Chevy 
| Pickup and I am wondering which Motorola microcontroller would be my best
| choice.  I have a lot of experience with the HC11, but I have not used the 
| 68HC16 and 6833X devices, which look quite useful.


This just came up a day or two ago in comp.sys.m68k. I'm forwarding
some of it for those that don't read that group.

============== cut here =================
Matthew P. Downs (mpd at adc.com) wrote:
: wj-wray at uwe.ac.uk (WJ Wray) writes:

: >Motorolas marketing pushes the 683** series as the top of the range
: >microcontrollers while the 68HC16 is an upgrade path for 68HC11 users.

HC16 is marketed as an upgrade path for HC11, however, there are enough 
differences to make the migration difficult. For example, any stack 
manipulation instructions will have to be re-coded.

: >Looking at the data the HC16 seems to spank the CPU32 on most counts,
: >particularly with the `DSP' features. On top of this it is cheaper,
: >sucks less current and the Z1 variant includes an ADC (also featured
: >on the '333 if you can <a> get your hands on one & <b> afford to pay).

I have used both HC16 and CPU32 based HC3xx. One thing that impress me 
about HC16 is that it is a very 'fast' CPU; most commonly used 
instructions are coded within 16-bit, therefore, needed only one memory 
fetch, coupled with the 'fast-termination' cycle and a 16,78MHz clock 
rate and a 3 instruction pipeline,  it profiled 119.2ns per instruction 
at very high percentage of the time!

The other major different between CPU32 and HC16 is that CPU32 cannot do 
non-align memory cycles properly.  Only the later version of HC3xx family 
which are based on a modified 020 core is able to do that. 

One interesting note is that the HC16 is about twice as fast as an Intel 
186 running at the same clock speed.

: >In short, on paper at least, the HC16 looks like the best choice for
: >most current products. So, beware the men from marketing...

If you guys are using C, beware of tools that was 'migrated' from HC11 
world; they generally do not handle the memory model properly.  HC16 uses 
segmented architecture, with each segment of 64K. However, the HC16 
architects are smarter than those Intel folks in that the segment (or 
bank) portion of the 20-bit address is automatically adjusted when 
crossing segments. So, no messy code to adjust segments when indexing. In 
fact, more than 64K can be addressed.    Some tools simply forget this 
feature , one example is Whitesmith C, which linker does not handle 
segment location automatically, you have to do it manual!  

: >  Will Wray

: Depends on what you're trying to do.....I have used the 68340, 302, and 
: now the 360.  I need to have much more processing capabilites than the HC16 
: allows.  Like the use of a commerically available real-time OS. and other
: options.  Therefore the HC16 is NOT the better choice....it obviously depends
: upon the application.

Depending on how you configure and what the application needs,  HC3xx is 
not necessarily faster;   remember that HC3xx are CPU32 based (32-bit) 
that fetch information off a 16-bit physical bus,  more bus cycles 
involved.   HC16 can mostly execute off a single bus fetch.  

On the point of RTOS support, there is no limitation; at least Embedded 
System (Used to be A.T.Barette) has RTXC and Nucleus has Nucleus Plus.  
If you use Introl C compiler, it comes with a kernel. BTW, both the above 
RTOS are targeted on HC3xx as well.

: Matt
============== cut here =================
In article <1994Oct25.140437.24662 at pat.uwe.ac.uk> wj-wray at uwe.ac.uk (WJ Wray) writes:
>Motorolas marketing pushes the 683** series as the top of the range
>microcontrollers while the 68HC16 is an upgrade path for 68HC11 users.

The HC16 is source code compatible with the HC11, providing a growth
path for existing HC11 applications that are running out of steam.
However the 6833X incorporates a 68020 core, therefore making it source
code compatible with the higher performance 68K family.  This is
important because more robust tools such as highly optimizing compilers
are available for the 68K.
I read that the 6833X should achieve approx. 2.5 MIPS and the HC16 
approx. 2 MIPS.

I have designed with them both, and believe the each have a place in the 
market.
============== cut here =================
>Chris Lucas (chris at atlanta.com) wrote:
>: In article <1994Oct25.140437.24662 at pat.uwe.ac.uk> wj-wray at uwe.ac.uk (WJ Wray) writes:
>: >Motorolas marketing pushes the 683** series as the top of the range
>: >microcontrollers while the 68HC16 is an upgrade path for 68HC11 users.

>: The HC16 is source code compatible with the HC11, providing a growth
>: path for existing HC11 applications that are running out of steam.

>Not quite true. HC16 asm is not quite a superset of HC11.

The hc16 is source code compatible with the hc11.  However, the HC16
is a completly new beast.  An HC16 is virtually a 6833X with a different
core.  The integration on an HC16(SIM, ADC, TPU, GPT, QSM) is exactly the
same as that found on the beefier 6833X.  These modules connect to the 
core via the Inter-Module Bus(IMB).  The 6833X utilizes the core from
the 68020, CPU32.  On the other hand, the core on the HC16(CPU16) had to be 
redesigned to be source code compatible with the HC11. What I mean by souce 
code compatible is the HC16's instruction set contains as a subset, the 
HC11's instruction set.


Chris
============== cut here =================


My thoughts: Someone (Coactive?) is working on a gcc port for the
HC16. When that's out it may not be a bad choice; that's assuming 
you do not want to spend money on a development system and software. 
The CPU32's, being based on the m68k family, can already use gcc
which would make it more desirable to me. Now the question is cost and
availability... 


                                       John S Gwynne
                                          Gwynne.1 at osu.edu
_______________________________________________________________________________
               T h e   O h i o - S t a t e   U n i v e r s i t y
    ElectroScience Laboratory, 1320 Kinnear Road, Columbus, Ohio 43212, USA
                Telephone: (614) 292-7981 * Fax: (614) 292-7292
-------------------------------------------------------------------------------



More information about the Diy_efi mailing list