Re: LPC2101-2-3, still preliminary?

Jim Granville wrote:
rickman wrote:

> Jim Granville wrote:

<snip>

>> ** Higher precision ADCs
>
>
> I certainly have not seen this. In fact, there are any number of 8 bit
> parts that have completely lousy ADCs that don't even have a reference
> separate from the Vcc rail, like *all* of the Motorola parts. There
> are any number of ARM MCUs that have very good ADCs. Check out the
> ADuC7000 parts from ADI.


Look at the ADuc8xx , SiLabs C8051F35x, TI, and Teridian all have 20+
bit ADC. Don't think ARMs have those yet... ?

>
>> ** Smaller packages
>
>
> If you only need 5 IOs maybe.


Smallest ARM I've seen is TQFP32, there are lots of 8 bit uC in the
package space below that : 28/24/20/18/16/14/10/8/6 pins.

There are ARM chips in LFCSP40 packages at 6 x 6 mm and 5 x 5 mm WCSP
packages. You don't have to give up functionality to get a small
package.


>> ** Lower power supply currents
>
>
> Only if you need virtually *no* processing. We just replaced an 8 bit
> AVR with a 32 bit SAM7 part because for the same amount of processing
> power the ARM is lower power consumption. We don't need full speed on
> the ARM, so we will clock it at AVR speeds and cut the power
> consumption compared to the old design. Of course trying to clock it at
> 32 kHz might work better with the AVR, but we don't build wrist
> watches. ;^)
>
>
>> ** Socketable packages
>
>
> Why is a socket an advantage? They are failure prone, large and not
> very practical when the socket costs $0.50 and the processor $2.00.


To some users, sockets matter. DIP/PLCC packages have not vanished,
like one might have expected.

Of course, if you still require ancient packaging or other out of date
technology, then you may have to live with the 8 bit MCUs. I'm not
saying there is anything wrong with 8 bit chips. I am saying there is
less and less reason to use them.


>> I believe Zilog ( who license the Arm9) are also about to
>> release a 16 bit ZNEO family, so they must believe there
>> is still room for 16 bit devices...
>
>
>
> Sure, there are companies that are sticking to their old line
> processors, but only for customers that don't have a problem using a
> sole source processor (other than the 8051 of course). One of the
> great things about ARMs is that when you want to change parts to one
> that has a better selection of prepherials or different features, such
> as lower power or higher processing speed, you don't have to change
> your code base or even switch tools. The only thing that changes is
> the BSP for the peripherals... much, much easier than switching
> processor lines.
>
> Check any publication that analyzes the market, The 8 bit parts have
> peaked, the 16 bit parts are not ramping up like they might have
> because people are switching directly to 32 bit parts, mostly ARMs.


It will be a long time in the future, before 32 bit uC hit 8 bit volumes

- but this is irrelevent anyway: designers will use the right tool for
the job.

Or course. My point is just that the advantages of squeezing your
design into a much more limited 8 bit MCU are fading fast. If you
consider what the 32 bit LPC2101 offers for just $2.50, I think you
will find that many applications that were clearly 8 bit are no longer
limited to that. I also think you will see the 32 bit chip volumes
taking off big time at these prices. Other than the ubiquitous
microwave and similar devices, I don't see a reason to use 8 bit chips
any longer.


> You won't see an ARM in your $50 microwave oven, but you will see tons
> of them in a lot of places that might have used 8 bit chips a couple of
> years ago.


Your original question was
"Is there any reason to keep the 8 bit MCU?"

and you can see, there are plenty of reasons.

Sure, the threshold is moving downward, but that's all.

Hmm, of course there will always be an application that requires the
lowest cost or other absolute optimization. That is why there are 4
bit MCUs when they have very little advantage over 8 bitters. But I
don't see that the use of 8 bit MCUs is at all compelling except for a
very limited range of apps. The threshold is dropping like a rock!

.

Relevant Pages

  • Re: PIC vs AVR vs ARM
    ... from PIC/8051 MCUs I was working with before to ARM chips to be very ... in ARM mode. ... chips in general). ... AVR studio was nice and would pop-up a message saying it noticed ...
    (comp.arch.embedded)
  • Re: Advice on system purchase
    ... about the question of ARM on the desktop, but a quick skim shows no ... obviously compelling reason why it won't ever happen. ... money and failed to drive adoption of their RISC chips in desktops. ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx ...
    (Debian-User)
  • Re: Advice on system purchase
    ... Stan Hoeppner wrote: ... about the question of ARM on the desktop, but a quick skim shows no ... obviously compelling reason why it won't ever happen. ... money and failed to drive adoption of their RISC chips in desktops. ...
    (Debian-User)
  • Re: ARM controller with integrated DAC
    ... we didn't consider an FPGA. ... Reason 1: familiarity ... I would be surprised if there are any chips (FPGAs or XMOS ... looks like there is no reason to not use an ARM. ...
    (comp.arch.embedded)
  • Re: [PATCHv8 00/12] Contiguous Memory Allocator
    ... Russell King - ARM Linux wrote: ... this restriction lifted from the architecture specification, ... hardware that avoided speculation where there ... With regard to specific chips (i.e. current ones, ...
    (Linux-Kernel)