Why are you still using 8 bit MCUs?

[dannyf]

it was "internet based".

CoIDE isn't but there are "internet based" mcu toolchains - I actually would have expected them a while back: someone could set up a compiler in the backend and with the front end being a brower or even an editor. All compiling is done "in the cloud".

Not sure if the licenses would allow that.

[garak]

However, the results from the PIC I used were more than acceptable so why the bloody hell would I use anything else?

For sourcing reasons? for certification reasons? for software reasons? ...

The PICs were already available, I checked this when I started the design. WE were the certification body (I built the kit, someone else in the company approved the calibration procedure and then a third person actually performed the cals). I used the software I knew and it worked fine, why change things that don't need to be changed?

[dannyf]

I used the software I knew and it worked fine, why change things that don't need to be changed?

Because the world can be far more complex and diverse than one's experience is.

[gibbled]

Because I have no lpc800's yet.

[free_electron]

why not ? use what fits the application.

[madshaman]

use what fits the application.

I think this is simple as anyone can put it.

[mtdoc]

Because I only have an 8 bit brain...

[c4757p]

I'm a fan of microcontrollers that have been around for longer because it's more likely that others will have some experience with them. It's also more likely that they'll be around for a long time to come, and development tools are often very easy to find, including third-party alternatives.

[free_electron]

Because I only have an 8 bit brain...

a byte visits the doctor.
Doctor asks what wrong
Byte says. i've been feeling sick
Doctors says i thought you were a bit off when you entered...

[nctnico]

use what fits the application.

I think this is simple as anyone can put it.

A bit too simple though. I make lots of different projects with different requirements. If I'd need to keep up with 10 different architectures I'd go crazy and never utilize one architecture to the fullest. So I (mostly) use one family of controllers which has a wide range of packaging, peripherals & memory options and an ARM CPU so it never runs out of steam. In some cases you just can't avoid working around some hardware limit using software. Not to forget about the ever changing requirements. A controller which barely fits today may not fit tomorrow when the new requirements come in.

[dannyf]

A controller which barely fits today may not fit tomorrow when the new requirements come in.

A controller which fully fits today may not fit tomorrow when the new requirements come in either.

[David_AVD]

Exactly.  Using a chip that's appropriate for the needs makes perfect sense.

Of course there's nothing wrong with using the larger (RAM, FLASH) version of a chip for several low volume projects.  That way you can buy in bulk and actually save money.

[Kjelt]

Well we have this discussion almost with each product in our company and if it is up to the hw/sw eng. Only it would be an Arm32. However as soon as TPL , marketing etc. Come in the famous BOM starts coming in. Then magic sales precasting figures ( that never get met BTW) of hundreds of thousands and millions fly by and then the choice for a 8 bit micro that also can handle the job saves $0,30 to $0,50 a piece per product, so saves millions 
 NRE is not calculated which is rediculous but hey thats the real world. 

[WarSim]

Exactly.  Using a chip that's appropriate for the needs makes perfect sense.

Of course there's nothing wrong with using the larger (RAM, FLASH) version of a chip for several low volume projects.  That way you can buy in bulk and actually save money.

I completely agree.  This is about money.  It is very possible to distribute the BOM cost across several low volume projects and save money.  I do something similar for my DIY projects also.  I select a generic part at three tiers and buy enough to save.  Then I use the parts when I can.  If I can't it is a unique project I get some for that project and a few spares.  If something new comes out I evaluate it as a replacement tier replacement.  Same with most other components when I foresee a continued use. 

Right now I have 5 tiers because new good stuff came out this year and the low tier is becoming used less.  PIC10, PIC18, PIC24F, PIC24E, dsPICF, and a few PIC32 samples are my current tiers.  I don't count the PIC32F as a tier because I haven't needed one for any of my projects yet, the all fit in PIC24 so far. 

I got a kick out of using the PIC10s in projects.  They are a SOT23-6 package and they make my peers scratch their heads when I show it to them.  Of course now they know about them so they are fooled a lot less now. 

[dannyf]

PIC24F, PIC24E, dsPICF

They are essentially the same.

[nctnico]

A controller which barely fits today may not fit tomorrow when the new requirements come in.

A controller which fully fits today may not fit tomorrow when the new requirements come in either.

That is not a problem if the same family of controllers offers a path from 32 pins/4kB RAM to >200pins with SDRAM support. All with compatible peripherals so code reuse is maximised. Time spend on writing software is what drives the costs where I live.

[dannyf]

That is not a problem if...

Those wonderful "ifs",

[nctnico]

I should have typed 'when'. NXP's LPC800, 1000, 2000 series of microcontrollers just does that. All ARM based and the peripherals are the same. Moving from one device to another is a piece of cake.

[free_electron]

what i meant with my post is : if you need to make a gizmo that reads two buttons and drives an led and a transistor .. an 8 pin chip will do... no need to cram in a 488 pin bga processor with 2 gig ddr5 ram running loonix ...

that is what i mean  : use the proccesor that fits the application.

if there are no arm cortex cpu's in 8 pin package : slap a pic or avr  in it.
most people program in a higher level language. all you need to learn is the peripherals. so what. that takes a few hours to figure out the first time.

[dannyf]

NXP's LPC800, 1000, 2000 series of microcontrollers just does that. All ARM based and the peripherals are the same. Moving from one device to another is a piece of cake.

That's marketing talk that they want you to believe.

Take a datasheet / reference manual / user manual and you will easily find differences.

[dannyf]

most people program in a higher level language. all you need to learn is the peripherals.

Absolutely true. The "cores" are really transparent to most of the programmers out there. Spending so much time talking about it is just silly.

[nctnico]

NXP's LPC800, 1000, 2000 series of microcontrollers just does that. All ARM based and the peripherals are the same. Moving from one device to another is a piece of cake.

That's marketing talk that they want you to believe.
Take a datasheet / reference manual / user manual and you will easily find differences.

I have been using these processors for close to 10 years now so I do know my way around them. IOW: its experience talking.

@free_electron: those few extra hours often cost more than just using a chip which is 50 cents more expensive. There is also time needed to teach the people from production to use different tooling for programming. All in all that quickly adds up to two extra days in labour costs ($1000) which need to be recouped before the break even point is there. So you'd need to sell 2000 units before making a profit. Besides that those two days are usually better spend on improving or creating new products. The most succesful companies I worked for steered their development department based on engineering costs.

[dannyf]

I have been using these processors for close to 10 years now so I do know my way around them.

I guess you haven't run into those numerous and obvious differences in your 10 years of using them.

[nctnico]

Not really. Then again to me a glass is never half empty. When I was still working for an employer I developed a networked product which got an upgrade from an LPC2103 to an LPC1768 (*). The PCB wasn't even redesigned from scratch. Just move some stuff to make room for a bigger part. UARTs, timers, SPI, I2C, GPIO, ADC work just the same. Some differences in setting up the clock, interrupts and I/O pins ofcourse. The biggest difference was going from a bit-banged ethernet MAC to a real MAC. Still both versions compiled from the same source (with some defines to differentiate between product and hardware platform) with the same compiler and the hardware got programmed using the same programmer and software.

(*) Actually the product was a hardware platform which could be used as 20 different products. It wasn't designed that way but it just turned out to be that versatile.

[dannyf]

Pick any device from the three families and I am happy to show you how some of the peripherals differ.