Is a 32 bit or 8 bit MCU better for your application?

RE: Is a 32 bit or 8 bit MCU better for your application?

DAB — Sat, 10 Oct 2015 20:08:18 GMT

Nice post.

Over the years I have built some very impressive implementations using 8-bit microcomputers.

I used an old 8085 to control a 400 by 400 pixel display overlay for a FLIR camera on which I put real time helicopter attitude information.

I used a second 8085 to collect the data and calculate a full six degree of freedom control for the FLIR camera so that it was always following the flight vector.

Granted, I used an AMD math co-processor for the trig functions, but the system was perfectly fine for search and rescue work for my customer.

DAB

RE: Is a 32 bit or 8 bit MCU better for your application?

michaelkellett — Sat, 10 Oct 2015 07:38:33 GMT

Mark - do you work for Silabs ?

In any discussion of 8 v 32 bit micros you should at least mention Microchip (world's biggest player in 8 bit micros), Atmel (8 bit AVR is probably the best known modern 8 bit architecture) and the market leaders (ST, TI, NXP) in 32 bit ARMs.

Physical size is, for most applications, not a key determinant in processor architecture choice - you can buy an ARM from Freescale in a 1.99 x 1.94mm package (MKL02Z32CAF4R).

If I'm choosing a micro (or any other key component) for a project I start off with the things it must have to meet the project requirements, once I have a short list on that basis I can refine it on the basis of cost. time to market, reliability, other project "nice to haves" and so on. Processor core notional bit width very rarely appears directly in such considerations but may be a factor indirectly, for example: integer maths performance will be affected by register width which may matter in some applications.

RE: Is a 32 bit or 8 bit MCU better for your application?

johnbeetem — Sat, 10 Oct 2015 04:33:20 GMT

The NXP LPC1101LVUK and LPC1102LVUK (ARM Cortex-M0) have a 25-ball 2.17 mm x 2.32 mm package. That's the smallest I've seen for a 32-bit microcontroller.