Why are you still using 8 bit MCUs?

[john]

Why would anyone, today in 2011., choose an 8 bit microcontroller for his project?
There are lots of small, very cheap, low power 32 bit devices on the market (like for example Cortex M0 series). I don't mean just 32 bit ARM CPUs, but also all others like AVR32, TMS320C2000 series, PIC32, and many others...

What's wrong with you people? 

[Lance]

Because a lot of those are overkill for smaller projects. There's no point to using something that powerful unless you actually need it. Just because it's 8 bit doesn't mean it's useless.

[red_mamba]

And sometimes you have to look at components price

[john]

I heard that excuse couple of times, and I think it's a quite a lame excuse...
How do you define "overkill"? What do you get when you use 8 bit instead of 32 bit? Many 8 bit CPUs are actually more expensive than 32bit, so cost is not the issue (and even if it costs 2-3$ more,  it's hardly an issue for hobby projects)... So, what is?

When you write software, there is no such thing as "too fast" CPU  

[qno]

A lot of designers grew up with 8 bit and know the settings.
With a new one you have to set a zillion bits to get it working.

Also a new development environment and a lot of silicon errata decrease time to market.

If you do not need it why use an 32 bit when you can do it with 8.

[jahonen]

I think there are two reasons, one is that 32-bit MCUs tend to come only in modern IC packages (no DIPs) and another is that most people are reluctant to change to another modern MCU family (there are still people who insist on 8051 cores what they have learned in the 80's ). Also, there is huge amount of code and documented projects for AVRs and (8-bit) PICs available on the Internet, not so much for ARM (although that will probably change as time passes).

Regards,
Janne

[john]

I agree on packages issue, most (if not all) 32bit MCUs I've worked with are 0.5mm QFP, and there are also more and more BGAs coming... However, unless you use MCU to blink LEDs, many other chips are also coming in small pitch QFPs these days, and even worse, there are more and more LGAs. Try finding accelerometer or gyroscope in some decent, easy to solder package...   

[FreeThinker]

Then of  course there is the support issues, most 8 bit software is free or very cheap and you need a programmer too so while the 8 bit may not be the cheapest chip if you have to spend x amount extra to support it then you need a good reason to migrate

[Zero999]

I heard that excuse couple of times, and I think it's a quite a lame excuse...
How do you define "overkill"? What do you get when you use 8 bit instead of 32 bit? Many 8 bit CPUs are actually more expensive than 32bit, so cost is not the issue (and even if it costs 2-3$ more,  it's hardly an issue for hobby projects)... So, what is?

What a load of rubbish.

Suppose you want a simple timer. Push a button to turn on a light for 10 minutes, push it at any time ro turn the light off and reset the timer. This can be done with the cheap six pin 8-bit PIC10F200 why would you want a more powerful MCU than that? Maybe it you needed more accuracy you'd use the PIC12F508 which can use a crystal but any more processing power is a waste of money.

There are 100s of project which only need a cheap low power 8-bit processor to replace a few logic gates, counters and 555 timers.

If I were your employer and you wasted my money by using a 32-bit MCU for something so simple, you'd be out the door so fast your sorry arse wouldn't touch the floor!

[Mechatrommer]

john, can you point to any pin compatible or closest in size that is cheaper but the same (or more will be preferable) in capability than 8bit soic atTiny13a? if you can, than i will accept that i'm wrong and willing to jump in your 32bit boat. if not, then i think something wrong with you.

[john]

Your example is valid, but a bit extreme...

But, lets take for example ATMEGA32/64, or PIC16 series... These MCUs are neither small, nor dirty cheap (like your PIC10/12)...

@Machatrommer
Take a look at LPC1100 series, like LPC1111. These 32bit MCUs are cheap, small, much faster and have MUCH more memory...
Yeah, I know, it's not SOIC... 

[jahonen]

Then of  course there is the support issues, most 8 bit software is free or very cheap and you need a programmer too so while the 8 bit may not be the cheapest chip if you have to spend x amount extra to support it then you need a good reason to migrate

Good thing about most ARMs is that they contain a boot loader for programming the flash memory which can be used with just an RS-232 level converter (or USB-to-serial transceiver), so no big issue there. Boot loader uses RS-232 in normal way, so no bit banging friendly hardware is required. Software is also free, FlashMagic for example. I'd say that programming is even more simple than with most PICs. Of course, if you want to debug seriously, one obviously needs a JTAG adapter.

There are 100s of project which only need a cheap low power 8-bit processor to replace a few logic gates, counters and 555 timers.

If I were your employer and you wasted my money by using a 32-bit MCU for something so simple, you'd be out the door so fast your sorry arse wouldn't touch the floor!

I think we have done this evaluation many times at my work and then came to conclusion that for most needs what we do, 32-bit MCU is the most cost effective option, even if it feels an overkill. Of course, the application is usually a bit more complex than just lighting leds etc., so comparison would probably be something like to PIC16F etc.

Regards,
Janne

[Mechatrommer]

Take a look at LPC1100 series, like LPC1111. These 32bit MCUs are cheap, small, much faster and have MUCH more memory...
Yeah, I know, it's not SOIC...  

the datasheet is here http://pdf1.alldatasheet.com/datasheet-pdf/view/345419/NXP/LPC1111.html
dev kit here http://cgi.ebay.com.my/Mini-development-board-ARM-Cortex-M0-LPC1114-Z-/160517506659?pt=LH_DefaultDomain_0&hash=item255f96c663
only in qfn, not a problem for factory, more problem with hobbiest.
still bigger, will be a problem if "small size project does matter"

price at digikey compared to attiny here
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=568-4957-ND
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=ATTINY13A-SSH-ND
for order 100qty, lpc is 60cents more expensive, more quantity (1000+) will be price competetive.

imho, from my short search, overall the lpc is suitable for professional mass production, not so for hobbiest unless 50MHz speed and more pins matter. for a person who have learnt pic and atmel a bit like me, lpc is a new to study and to buy the programmer, enhance my soldering skill or need to buy/build a reflow machine.

pls give me reason why i should upgrade to 32bit if all i want is few pins (2-4), very small, easy to solder, and already know how to program and have the programmer. if i need the 28pins and 50MHz, sure i will look into 32bit Cortex M0. is atTiny13a has something wrong?

[john]

for a person who have learnt pic and atmel a bit like me, lpc is a new to study and to buy the programmer, enhance my soldering skill or need to buy/build a reflow machine.
pls give me reason why i should upgrade to 32bit if all i want is few pins (2-4), very small, easy to solder, and already know how to program and have the programmer. if i need the 28pins and 50MHz, sure i will look into 32bit Cortex M0. is atTiny13a has something wrong?

First, you don't need a programmer, most of the 32bit chips can be programmed through serial port, although, getting a JTAG for debugging is very handy.
I don't accept "need to learn new stuff" as a good reason. Why? Because, sooner or later (probably sooner), you will do some project that will require more powerfull MCU. And then what? You'll probably try to squeze your application in a poor little fellow, instead of using a decent MCU...
This is exacly why I think that working with 32bit parts for hobby projects is actually better, because once you master 32bit chips, you can do both simple and complex project with the same architecture, without need to learn new stuff...

But as I agreed above, nice package like DIP or SOIC is a very good reason to use those 8 bit chips...

[slburris]

For myself, I rarely use PICs or AVRs anymore.  I *used* to struggle with
designs that outgrew their memory and/or program space.  Now days
I just use the LM3SXXXX TI (formerly Luminary Micro) chips.  Nice
Cortex ARM chips with plenty of everything, and the cost is pretty much
a wash.

I have friends trying to fit things into 2K of RAM or 8K of flash, and when
they start mumbling about switching some of their code to assembly,
I just ask why they are still using such chips?  The economics of trying to
squeeze every possible byte out of something just don't make sense anymore.

And I'm a big proponent of slapping a small $6 FPGA on every design as well,
and that gives me the ultimate flexibility to decide what to do in hardware and
what to do in software.  But you do have to climb the VHDL/Verilog learning
curve.  But none if this is beyond the capability of a hobbyist.

Scott

[Psi]

For myself, I rarely use PICs or AVRs anymore.  I *used* to struggle with
designs that outgrew their memory and/or program space.  Now days
I just use the LM3SXXXX TI (formerly Luminary Micro) chips.  Nice
Cortex ARM chips with plenty of everything, and the cost is pretty much
a wash.

Thanks for that, the LM3SXXXX series actually looks quite good.
Built in serial flash loader looks great, I'm sick of using the lpt port

[john]

Thanks for that, the LM3SXXXX series actually looks quite good.
Built in serial flash loader looks great, I'm sick of using the lpt port

If you are looking for something powerful, you can also take a look at TMS320F28335. It's 150Mhz MCU with FPU. Serial flash loader, free c/c++ eclipse based IDE, reasonably priced jtag (79$). But other than that, they are crap (no 8bit data types, very funky when you need to pack a structure and send to a serial port, poor docs, etc...) and worst of all, they are so damn popular that you can't buy them, out of stock for last six months or so...  

@slburris
Where did you find $6 FPGA? Cheapest I could find so far (large enough to put soft core CPU and some peripherals, and NOT BGA) are Cyclone3/4, 20k+LE for 30$-40$.

[slburris]

@slburris
Where did you find $6 FPGA? Cheapest I could find so far (large enough to put soft core CPU and some peripherals, and NOT BGA) are Cyclone3/4, 20k+LE for 30$-40$.

Xilinx XC3S50A-4VQ100C $5.75 qty 1 at Avnet:

http://avnetexpress.avnet.com

Large enough to put in several PicoBlaze soft cores, not sure about bigger soft cores
since I don't usually do that.  I haven't done much with Altera's chips, but I know of
no cheap FPGA from them.

At the very least, it's stupid to have to implement UART, SPI, I2C, etc in software
with associated timing constraints, when in a $6 chip like this I can easily create 20
such peripherals and run it on SPI back to the main processor.  No bit-banging needed
here!

Or for a big chip not in BGA:

Xilinx XC3S500E-4PQG208C but that's about $24.

Scott

[mikeselectricstuff]

@slburris
Where did you find $6 FPGA? Cheapest I could find so far (large enough to put soft core CPU and some peripherals, and NOT BGA) are Cyclone3/4, 20k+LE for 30$-40$.

Xilinx XC3S50A-4VQ100C $5.75 qty 1 at Avnet:

http://avnetexpress.avnet.com

FPGA pricing is strange - 'published' prices at places like Digikey are a lot higher than what you can actually get them for. e.g. I was recently quoted GBP2.80 (~USD4.20) for XC3S50A in QFP144 in low-100 qty. I've had comparable pricing on similar Lattice EC1 parts. I'm told that a reason is the manufacturers consider FPGAs need a lot of support from the distributor and want to tie customers in to a distributpr to recoup support costs so you have to go through the pantomime of the disti applying to the manufacturer for 'supported pricing'.
With  FPGAs you also have to consider the additional costs - config memory, core voltage regulator, oscillator and the fact that routing on 2 layer boards can be tricky due to the number of power/ground pins needed even if you don't actually want to use many pins. Board area is also a significant issue - QFP100 is generally the smallest non-BGA package, and by the time you've added the  support parts and decoupling you're talking a fair size and.or double-sided assembly.
I don't think there are many situations where you'd use an FPGA for an app that a micro was capable of - it would lose out on at least some of power, cost and space considerations.  

As regards why still use 8 bit, there are a number of reasons, but most of the low-end ARMs have limitations - typically no onboard EEPROM, and 3.3V-only operation being common reasons I choose a PIC or AVR over an ARM for some applications.
The only reason 32 bit costs are approaching 8 bit is they're made on newer processes that probably aren't worth the 8-bit families' manufacturers' investing in. For a given process, 8 bit will always use less die area and less power than 32 bit except maybe for the few  applications that can really make better use of the extra bus width.  

As it has always been, an always will be, it's a case of 'different horses for different courses', there are just a few new types of horse out there, but the old nags aren't going to keel over anytime soon. Some people are still using 8051 based MCUs !

It would  be nice to see NXP's tiny little ARM in something like a SSOP-16 though...!
  

[EEVblog]

Why would anyone, today in 2011., choose an 8 bit microcontroller for his project?
There are lots of small, very cheap, low power 32 bit devices on the market (like for example Cortex M0 series). I don't mean just 32 bit ARM CPUs, but also all others like AVR32, TMS320C2000 series, PIC32, and many others...

What's wrong with you people? 

Price and simplicity.
And they are NOT "small"

The cheapest in-stock 32bit micro from Digikey in 1-off qty is the LPC1111FHN33/102,5
$2.02 in a 32-VQFN package.
Hardly cheap, nor the friendliest package to use.
And that's the smallest 32bit micro package.

8 bit on the other hand.
Cheapest in stock part is a PIC10F200-I/P
$0.58 1-off qty 8 pin DIP package
Smallest package is SOT23-6 and plenty available in DIP etc.

Easily capable of doing the many small tasked required of a micro.

What's wrong with people who don't understand horses for courses! :-P

Dave.

[mkissin]

Something else which is often a consideration in the high-power electronics that I work with is the operational voltages.

8-bit micros are very simple to obtain with a 5V operating voltage, but the same isn't true of 32-bit micros which generally run at 3.3V or lower. That 1.7V drop can make a huge difference in an electrically noisy environment. Limiting yourself to a 5V micro greatly restricts the number of >8-bit chips available.

[Mechatrommer]

Price and simplicity.
Cheapest in stock part is a PIC10F200-I/P
$0.58 1-off qty 8 pin DIP package

got it. just look how cute they are... 10f200 and tiny13a

[EEVblog]

Something else which is often a consideration in the high-power electronics that I work with is the operational voltages.

8-bit micros are very simple to obtain with a 5V operating voltage, but the same isn't true of 32-bit micros which generally run at 3.3V or lower.

Good point.
Many in fact need lower rails and have built in low drop regs to power the core that need an external cap.
Is there a 32bit micro at all that runs from 5V? Off the to of my head I can't think of one.

Dave.

[slburris]

It all comes down to what your needs are.  I stand by my
point that it's silly to spend hours these days trying to squeeze
into a small micro if your problem space is really bigger than
the chip you choose.

On the other hand, if the problem easily fits, go for it!  I had
a problem recently where I needed a fairly precise reset sequence,
i.e. a signal changed state and I needed to reset a couple other
things in sequence for a certain number of microseconds.  How did
I do it?  I programmed a little PIC10 to do the right thing.  Worked
like a charm.

Sure I could probably have done the same thing, with less precision,
using a 556 or a couple 555's, but this took up far less board space
and performed easily within the timing criteria I needed.

Re 5V designs.  I really don't do many of those anymore.  Mostly
I work at 3.3v.  The FPGAs I work with can use 3.3v for both I/O
and JTAG, so I just need a little LDO to generate 1.2v, so the multi-voltage
thing really isn't that hard.  But yes, I concede routing can be
a pain, especially with 2 layer boards.  But a little planning ahead
on the pin layout can go a long way.  I do realize my FPGAs everywhere
philosophy is in the minority :-)

The other way to go is with something like the Propeller chip, where you
basically have cores to waste doing cycle counting to generate signals
and you can run the main software on cores not doing cycle counting.

Scott

[Lance]

It all comes down to what your needs are.  I stand by my
point that it's silly to spend hours these days trying to squeeze
into a small micro if your problem space is really bigger than
the chip you choose.

On the other hand, if the problem easily fits, go for it!  I had
a problem recently where I needed a fairly precise reset sequence,
i.e. a signal changed state and I needed to reset a couple other
things in sequence for a certain number of microseconds.  How did
I do it?  I programmed a little PIC10 to do the right thing.  Worked
like a charm.

Sure I could probably have done the same thing, with less precision,
using a 556 or a couple 555's, but this took up far less board space
and performed easily within the timing criteria I needed.

Re 5V designs.  I really don't do many of those anymore.  Mostly
I work at 3.3v.  The FPGAs I work with can use 3.3v for both I/O
and JTAG, so I just need a little LDO to generate 1.2v, so the multi-voltage
thing really isn't that hard.  But yes, I concede routing can be
a pain, especially with 2 layer boards.  But a little planning ahead
on the pin layout can go a long way.  I do realize my FPGAs everywhere
philosophy is in the minority :-)

The other way to go is with something like the Propeller chip, where you
basically have cores to waste doing cycle counting to generate signals
and you can run the main software on cores not doing cycle counting.

Scott

Agreed. Find what fits your needs. 32 bits micros aren't friendly to newcomers. Just because one is simpler doesn't make it useless. 

[frank26080115]

By now I have a really good collection of various 8 bit AVR chips and a lot of experience with them. The time I save on each project by knowing what I'm doing is more valuable.

For individual devices, some 32 bit MCUs can certainly compete with their 8 bit MCUs in terms of price. But for a kid like me who needs new tools and a carrier board, it can be expensive to make the switch since JTAG debuggers and dev-boards are very expensive compared to the DIP chip plus a ISP.

DIP packages are too important for inexpensive prototyping, or even inexpensive products. I have sold one-off products for around $40 and I was only able to achieve that price by using off-the-shelf through hole components and perfboarding. A PCB would have added at least $12 more plus 3 more weeks worth of waiting.

I'm not refusing 32 bit MCUs, in fact, my latest project is based around a AT91SAM7XC512, I soldered up my PCB already and got SAM-BA to work like a charm over USB. I just got my Bus Blaster V1 JTAG debugger too. However, this is one of the few projects that actually might require 512KB worth of flash memory, I also might want to mess with .NET Micro Framework.

I'm also getting a mbed (LPC1768) really soon to act as a new 32 bit swiss army knife to replace my 8 bit swiss army knife (the ATmega328P on a USnooBie and Teensy++). It has an ethernet PHY on board and USB host capabilities, unknown territories for me.

[john]

Price and simplicity.
And they are NOT "small"
8 bit on the other hand.
Smallest package is SOT23-6 and plenty available in DIP etc.

So you are basically telling me that you all use 8-bit micros only at 5V and in DIP/SOT packages? That's fine reason, but somehow it is hard for me to believe that no one is using larger 8bit parts,  QFP packages or 3.3V 

Simplicity? Simplicity my ass... I've been using 8051 MCUs for years, and yeah, I could say that they are simple... But it's not MCU itself that's the problem, it's the peripherals! If you have some powerful CAN controller, or even complex PWM module, it doesn't really matter if it is 8 bit or 32 bit MCU, it does require lots of work to configure it properly...  And for startup routines, they are usually autogenerated in IDE or copy/pasted so no real difference there...
It actually gets more ugly on smaller parts, because you often don't have 32 bit registers, and then for example you have to fight with 8 or 16 bit timers, trying to merge several together to get decent resolution when you need it. Or you don't have enough peripherals and there are propably still some guys that would rather do bit banging than use proper MCU... Go figure...

[Mechatrommer]

i sure to keep my option open (with calculated risk ) to this 32bit stuff when i go into more complicated mcu. at least, thanx john for reminding me of this. about the 5V, for me, it gives me more option on what voltage should i use. if say, i have other hardware that needs 3.3V then i can use 3.3V on 8bit mcu, but if its 5V, then i also can use 5V without extra hardware to drop the voltage to 3.3V just for the processor.

[mikeselectricstuff]

Something else which is often a consideration in the high-power electronics that I work with is the operational voltages.

8-bit micros are very simple to obtain with a 5V operating voltage, but the same isn't true of 32-bit micros which generally run at 3.3V or lower.

Good point.
Many in fact need lower rails and have built in low drop regs to power the core that need an external cap.
Is there a 32bit micro at all that runs from 5V? Off the to of my head I can't think of one.

Dave.

Yes - http://www.fujitsu.com/global/services/microelectronics/product/micom/roadmap/industrial/fm3/#a3
From a quick skim of the  datasheet it looks like a 'proper' wide voltage range, not just a cludged-on internal regulator - e.g. all IO and analogue runs on the full supply. Doesn't even look like there are seperate VCCIO pins. Even has an external bus I/F, so you could use old 5V microprocessor peripheral chips - 8255 anyone?
I still think manufacturers are missing a trick by not offering larger pitch lower pin-count devices - onboard voltage reg and 5V IOs would also be really useful - only then will they really be competitive with 8-bit MCUs at the lower end in a lot of applications like white goods.

[Simon]

I heard that excuse couple of times, and I think it's a quite a lame excuse...
How do you define "overkill"? What do you get when you use 8 bit instead of 32 bit? Many 8 bit CPUs are actually more expensive than 32bit, so cost is not the issue (and even if it costs 2-3$ more,  it's hardly an issue for hobby projects)... So, what is?

So your saying you can get me a 32bit MCU in an 8 pin package for less than £0.70 ?

When you write software, there is no such thing as "too fast" CPU  

not neccesarily, infact I totally messed up a project because I did not think that the MCU (at just 4MHz) would easily get ahead of a car engine. I have actually had to put in a delay that lasts vastly longer than the program cycle itself.


On another note, what is this crusade all about ? why do you suppose to tell us what to do ? who are you ?

[mikeselectricstuff]

When you write software, there is no such thing as "too fast" CPU  

Correct, but there are such things "too much power consumption due to unnecessarily fast CPU", as well as "Too high EMI emissions"

[Alex]

Here is an appropriate video

On another note, what is this crusade all about ? why do you suppose to tell us what to do ? who are you ?

Worryingly, John represents a new, ever increasing, breed of engineers entering the field. The phenomenon is much broader.

On the other side of the spectrum, Silicon Labs does 100 MIPS 8-bit MCUs with max core frequency of 100 MHz. They are sucking 65mA at 3.3V. You need to have a good reason to use an 8bit MCU at 100MHZ.

[mikeselectricstuff]

They are still used because it economically makes sense. You may think that 30 cents per micro is nothing but if you are mass producing something in the thousands or millions it doesn’t take long to add-up. So if you spend an extra couple hours in making it work with say a PIC16F690 vs a LPC1111FHN33 that’s more money in your pocket.

Likewise, if you're developing a low volume product, it's often not worth the time to learn a new device if there is a familiar one you can use, even at a higher part cost.

[Simon]

Here is an appropriate video



Worryingly, John represents a new, ever increasing, breed of engineers entering the field. The phenomenon is much broader.

On the other side of the spectrum, Silicon Labs does 100 MIPS 8-bit MCUs with max core frequency of 100 MHz. They are sucking 65mA at 3.3V. You need to have a good reason to use an 8bit MCU at 100MHZ.

Oh dear are we talking about the same breed of engineer that works for microsoft and other software houses that turn out software that gets slower by the hour ? 

Seriously: I have a small automotive project and I have to fit it in a set small space, so I have to use 8 pin nothing any larger than neccesary makes sense, my choice of 8 bit pic as I mentioned earlier has all the speed I need and it may be something i sell, why should i pay over a pound for a larger 32 bit mcu when I and quite happy doing the same job with a £0.70 mcu while saving board space and the grief of having to setup an mcu that has like 10x the peripherals i need and all that.

I could think of some usese for a 100 MHz 8 bit mcu, they might be misuses but if the solution were competitively priced with the correct alternative why not, after all John advocates I should use 32 bit over 8 bit just because it's feasable and he says so  , I'll find you an overkill use for a 100 MHz mcu that probably costs more than the correct part for the job !

[TheDirty]

I don't use 8bit MCU's anymore.  I tend to use MSP430's (16bit) for the simple things and LPC11xx, LPC13xx and LPC17xx for more complex things.

Even though I don't use 8bit MCU's anymore, I can still see why they are used by many.  I use the MSP430 just because it's so simple to use and program.  No worrying about turning on internal peripheral clock modules and such.  Also, development tools and programmers for ARM are locked to code limited versions unless you go to GCC/Eclipse and setting that thing up was way too much work for me.  I use a Olimex JTAG with CrossConnect SWD adapter and Crossworks personal license now, but even that cost is more than what a casual hobbyist is going to want to throw down at the beginning.

[apex]

Some companies even use 4-bit µCs.
Hey, with a 6-pinned ATTiny12 or PIC12Fsomething, I can build a SMPS-controller.
And you want to use 32-bit µPs, just because they have more power.

The controller in my washer has enough calculating power to run windows.
My microwave has an internal ethernet-port.

What are these designers thinking?

The washer is waiting most of the time for the water to heat up.
"My delay loop runs more iterations than yours!!!"
I could build a washing machine with an ATTiny13 (or if program space runs out, with an ATTiny25 /45 /85).
There have been mechanical microwaves.

Why does everyone want more POWER?

Low-power is cheaper, easier to use and more environment-friendly.

If I use an LPC something on my board, I have to use at least two layers.
If I sit down a while thinking and then use a small microcontroller and an more intelligent program, I can use a single-sided board.

Look at what you can do with Arduinos.

I don't need a clock that can run Crysis. It should just display the time!!!

Which company are you working for, john? LPC?

apex

[Psi]

perhaps we should start a new thread
"Why is everyone using 32bit mcus when an 8bit would do the job"

Then we can all argue the opposite 

[Jon Chandler]

Slightly aside, on another forum that shall remain nameless, the "experts" always recommend to newbies that they start programming with a PIC16F628A or maybe a PIC18F1320 if they're radicals.  Why start with a micro with limited port pins and memory?  An 18F2520 or the new 18F25K22 has plenty of memory and port pins or even go to a 40 pin package with an 18F4520.  Spend a buck or two more at the start so that you're not handicapped by memory or port pins right from the start.

[Alex]

I started with the 18F452, now 4520 several years ago.

Microchip targeted this MCU to universities and are therefore offering more than the average level of documenation for this MCU.

[apex]

If you don't have the hardware power to make something, you have to think.
That is the secret behind all the hacks.
You can do something fast by using really big tools.
Or you can do something cheap by thinking a bit.

I won't mind if you use a 32-bit MCU for really really hard things since I'm really lazy to.
But some applications are like using an arduino to blink an led, while you could do it with an 555 timer.

Somewhere in the hackaday comments I found this one:
"What price would I get if I made an Arduino out of 555 timers and the make it blink an led?"

apex

[Ferroto]

And I'm a big proponent of slapping a small $6 FPGA on every design as well,
and that gives me the ultimate flexibility to decide what to do in hardware and
what to do in software.  But you do have to climb the VHDL/Verilog learning
curve.  But none if this is beyond the capability of a hobbyist.

Scott

Heh try explaining to some MBA manager why you choose a $6 FPGA for a project where a $0.75 microcontroller would be antiquate for the job.

Now say for example 50,000 units were produced. Your decision to use a $6 FPGA over a $0.75 8-bit MCU just cost the company $262,500.

At this point the MBA manager will come to the realization that it would be more cost effective to fire you and hire someone who possesses knowledge on a more diverse range of components. and they will do it because MBA managers are cold minded robots that view the efficiency of the company as paramount and everything else a means to that end.

Dave did a blog awhile back about the whole atmel vs avr issue where he stressed the importance of keeping your options open with regards to components.

[Alex]

No wonder engineers that understand the business concepts wrapped around a product are highly sought after; they are the ones in the best position to take, and justify, such design decisions.

[saturation]

There's no reason to build something that can cost less,  if the designer knows other ways of doing so.  All things being equal in a product, price becomes the only issue.

Having just one skill in one type of uC makes one dependent on the manufacturer.  What if the project deadlines require supplies of chips that are not available for one uC but plenty from another?

Flexibility is key, and the more you know and can use, the more valued you are.

[Mechatrommer]

engineers have to comply to company's vision, quality or cost. whether they like it or not.

[Simon]

infact I think many engineers never get to do it their way due to "costs"

[Alex]

Just make sure you mention the word 'Roadmap' in review meetings 

[Simon]

Just make sure you mention the word 'Roadmap' in review meetings 

yees and moving forward, or is it taking this forward..... and all the other office jargon. Hearing some poeple makes me sick, i need to get out before it's too late 

[apex]

Why would you want to replace an ATMEGA32 oder 128?
It is just the more of pins you have, compared to an ATTiny13 (and some bonus functionality).
You don't need external program memory.
You don't need external ram.
You don't need two or three voltages.
You don't need a 4-layer board.

If you just want to build a keyboard (for the PC, not the instrument) and it's not highest-end, you could use an ATMEGA with V-USB.
No struggeling finding board space for all the external components.

A microcontroller is a bit like a standalone platform.
A microprocessor, like an ARM, is part of a powerful system.

It's right, you don't always need microcontrollers.
For example, I don't know why ATMEL made the AT32UC3 series of 32-bit microcontrollers AND the ATSAM series of 32-bit ARMs.
You could also argue about the ATXMEGA, but they are a different field.

But if you put some though in it, you'll find most problems on earth are quite easy to solve.
It just depends on the way and the possibilities if you succed.
For example, let's say, the lamp example further above, I just would use a 555 or 7555.
No problem with foil caps and good resistors.

But for calculating the flight curve of a wing that breaks off an airplane, you'd need power.
And you'd also need power to calculate how to stabilize the plane.
This is, where I'd use an ARM.

Its not that I don't like ARMs.
I love them!
I've used them and will use them again.
But just think of the "THE RIGHT TOOL FOR THE JOB"-Video!

apex

[TheDirty]

^ I'm not certain what ARM chips you are talking about, Cortex-M3 and M0 don't need any  of those things you mentioned.  Any ARM's we design with, even up to ARM7, and ARM9 are still microcontrollers, not microprocessors.  Something like an LPC1xxx series is actually a pretty modest microcontroller.

[House91320]

because it is stupid to us a arm cortex m3 to flip a bit

[the_raptor]

This sounds like "fresh out of university" syndrome where the new kid whose teachers have exclusively used all the new stuff tries to convert the old hands. When I did IT a decade ago it was Object Oriented programming (Java will rule the world!!!!1111) and OO design (which was going to allow us to write software with diagrams instead of code, yeah that took off lol) where we spent 10x the effort doing something than it could be done via procedural programming.

You use the right tool for the job period. If you only know how to use one tool you are a technician not an engineer.

I don't think hardware costs have reached the point where you can use the Python philosopy (that computer power is cheaper than programmer salaries, so it makes economic sense to use inefficient but easy to code systems to reduce programmer cost) for hardware design.

[Wim_L]

I don't think hardware costs have reached the point where you can use the Python philosopy (that computer power is cheaper than programmer salaries, so it makes economic sense to use inefficient but easy to code systems to reduce programmer cost) for hardware design.

That would depend on the task at hand. If you're going to mass produce a gadget, or if you're making a scientific instrument of which only a few will be made, the balance between development effort and production costs is inevitably going to shift.

For some things like hobby projects that will be assembled by hand, other practical matters also enter the picture, and you would usually avoid using some extremely fine pitch SMD package (or worse, BGA), and many of the high performance chips, while affordable, are only available in such "inconvenient" packaging.

[Trigger]

KISS principle of engineering and elegance of design. 8 bit micros are also more robust when it comes to operating in noisy environments, and are generally more energy efficient for battery powered devices.  There are some exceptions though.  I use Energy Micro's EFM32 ARM Cortex-M3 Gecko chips in a lot of projects because they're incredibly power efficient.  That's what they were designed for.  I also really like the PIC32s, but I'm not going to use one in a power restricted scenario.  I don't throw those 32 bit chips at everything.  If I can get away with an 8 bit 8 pin PIC or AVR for a task then that's what I'll use.

Use the micro that best fits the application don't try to fit the application around the micro.

[vlad]

I use an  ARM mbed, and it is wonderfull for fast prototyping:

- 32 bit
- 96 MHz
- 40 pin DIP
- ARM Cortex
- 3.3 to 15V input
- mini USB for programming

Doesn't need anything else than a computer with Internet access to program, lots of libraries, C++, I just Love it!!

And for production you can still target to the same MCU....    well if you wanna know more:  http:\\mbed.org

[Simon]

hat would be really useful for a very simple design I'm doing at work, ahem yes a 32bit micro with goodness only knows how many pins just to take two ADC readings, an enable input and drive a H bridge. They'd be really impresse if i took in a 40+pin IC with just 6 lines used 

seriously, different things have different jobs. And before you argue prototyping, why should I prototype something big when I'm going to make it small ? I need to immediately work on the parts my final design will use.

8 bit MCU's have their place and always will. even if they stop making them !

[alm]

And before you argue prototyping, why should I prototype something big when I'm going to make it small ? I need to immediately work on the parts my final design will use.

Because you may not know the exact requirements (like memory) in advance? Because you need extra pins for debugging? When developing, you usually want a MCU with on-chip debugging (eg. JTAG). In production, you'll probably want to skip this to save costs. Lots of production designs don't have the spare pins JTAG needs.

Software is usually easy to port from large to small parts as long as they're in the same family. Porting from the LPC1768 to smaller LPC17xx should be trivial. Porting to a small LPC11xx Cortex M0 should also be straightforward as long as this was planned for during development (eg. no use of peripherals the LPC11xx doesn't have, like USB or ethernet).

8 bit MCU's have their place and always will. even if they stop making them !

Always? No way. Maybe for our generation. But always is a really long time. Think back a hundred years, and consider how much devices which were critical back then are completely obsolete and only found in museums? Now think back thousand years. Or ten thousand years.

[Frangible]

8 bit MCU's have their place and always will. even if they stop making them !

Always? No way. Maybe for our generation. But always is a really long time. Think back a hundred years, and consider how much devices which were critical back then are completely obsolete and only found in museums? Now think back thousand years. Or ten thousand years.

Maybe there will continue to be fans who insist it won't work right unless it's 8-bit, kind of like tube-philes who refuse to acknowledge sound whose electrical constituents haven't traveled through a vacuum.

[Simon]

I go back to my example. I have deasigned a small water valve controller, an 8 pin 8 bit micro does the job nicely, all pins are used up and it works. why should I put a 32 bit one in with lots more pins and board space used if i don't really need it ?

[Rufus]

Always? No way. Maybe for our generation. But always is a really long time. Think back a hundred years, and consider how much devices which were critical back then are completely obsolete and only found in museums? Now think back thousand years. Or ten thousand years.

So by now we really ought to be using cars with 6 wheels and in the future we will have cars with 8 or 10 or 12?

We currently and in the future will continue to use whatever gets the job done at least cost. More bits need more silicon and will cost more money, the future isn't going to change that. The only thing overriding that is economy of scale and I don't see the volume of simple tasks 8 (and 4) bit micros can get done falling to a level which wont justify production of optimally sized processors.

[alm]

So by now we really ought to be using cars with 6 wheels and in the future we will have cars with 8 or 10 or 12?

Nah, we'll become spiders with eight legs soon. Thirty-two in the future, and maybe sixty-four eventually. Dancing class is going to be fun!

We currently and in the future will continue to use whatever gets the job done at least cost.

But the relative costs can shift dramatically. For example, a 74HC00 quad NAND gate is likely cheaper than building two NAND gates from discrete MOSFETs if you factor in assembly, and may also be smaller.

If you think the current cost structure will remain forever, I feel that you lack any imagination. A hundred years ago the electronics industry didn't exist, how can you expect that something so recent will remain the same forever?

If all life on earth dies, is there still a place for 8-bit MCUs? If we stop using electricity? If we switch from digital to analog computers again? If we want to network every single piece of electronics and control it from our iPhone 42? If the packaging of semi-conductors or the assembly becomes so expensive that it dwarfs the silicon costs?

8-bit PCs are gone from commercial distribution, because the demand is so small that it's cheaper to buy a PC with an overpowered 64-bit CPU than building a PC perfectly suited to the job at hand. We're not there yet with embedded applications, but that doesn't mean we'll never get there. Another example is that large amounts of RAM tends to be cheaper in 32-bit MCUs, because they use more advanced processes compared to the ancient processes used in many 8-bit micros.

[westfw]

But it's not MCU itself that's the problem, it's the peripherals!

I think you're in danger of contradicting yourself.  If an 8-bit CPU has peripherals that do what I want, why should I convert to a 32bit CPU with brand-new overly complex peripherals "documented" by providing some bloated vendor-provided (and controlled, and maybe supported) library?

There is interesting stuff happening along these lines in the Arduino-compatible space.  There are now a couple of 32-bit Arduino equivalents (Maple, using ARM, chipKit using PIC32, Firebird on Coldfire.)  They have varying degrees of SW compatibilities, and about the same prices as an (8bit AVR based) Arduino.  They're not gaining wild acceptance; it seems that most projects fit in the 8bit AVR just fine.  Peripheral libraries seem to be a problem; I know chipKit has incompatibilities introduced by using the Microchip-provided peripheral libraries, and IIRC Maple tried to use the CMSIS  libraries and had problems.  It really is NOT a "feature" when accessing your peripherals becomes so complex that you have to rely on someone else's code.  (for instance, the core chipKit code ends up being bigger than most Arduino AVR sketches.  Not that that really matters, given that it has so much additional code space.) (The AVR Arduino libraries are written on top of bare metal.)

That said, there's an increasingly broad range of applications (eg networking) where the solution for 8bit CPUs is an external network processor with capabilities far exceeding the CPU (the first ethernet interface for Arduino used a Lantronix XPort, which is an x86 class CPU almost capable of running linux (newer XPorts DO run linux!)  That doesn't make sense either.

In some sense Arduino exists because desktop CPUs became "too powerful" and disconnected from the physical world that people wanted to access; 32bit microcontrollers are in danger of going the same way.  Sure, I can get a $100 board with lots of MIPS, USB and Ethernet peripherals, but the $10 of a stripped-down AVR board (home assembled) isn't really there yet.

It's also hard to tell how much things really cost; too many "development boards" are subsidized by manufacturers.  You can get a mass-produced ARM linux system (wireless router, pogoplug, etc) for $50, but how much will it cost to get 100 or 1000 of a board based on a 32bit cpu?  (and yes, a lot of "products" are built in that sort of quantity.)

[Zero999]

Desktop PCs have been overpowered for many applications for years. To a large extent, a lot of it is down to marketing by Intel and Microsoft working together to convince people they need more powerful hardware when they don't.

Yes, we no longer have 8-bit and 16-bit PCs but there's still a large market for 32-bit in phones and embedded applications so it's unlikely everything will become 64-bit any time soon.

Some MCU families have already died out, how many 4-bit or 16-bit MCUs are there around today? 4-bit is too limited to do much and 32-bit is certainly more cost effective to use for more complicated applications.

No I can't see 8-bit MCUs dying out any time soon. It just sounds crazy to use a 32-bit MCU in something like a timer, combination lock or LED controller, just because of the pin count, if nothing else: a 6 pin MCU could be use as a timer or to flash a few LEDs or as a timer, using anything larger is silly.

Of course who knows what could happen in the future? Maybe a 32-bit 6 pin MCU will be released with two pins which can either be used as a high speed serial bus to interface with cheap I/O modules, ADCs,  DACs etc. or just used as normal I/O pins so one can buy a cheap/small MCU and add as many peripherals as desired or just use just the few I/O pins it comes with.

[RCMR]

Desktop PCs have been overpowered for many applications for years. To a large extent, a lot of it is down to marketing by Intel and Microsoft working together to convince people they need more powerful hardware when they don't.

Actually -- they do -- but mainly because the likes of Microsoft have created some *horrendously* bloated and slow code in their efforts to make our PCs more user-friendly and powerful.

If you ever get the chance, fire up an old 4MHz Z80 CP/M based computer and have a play with the software of the era.  You'll be surprised at how sprightly an 8-bit computer running with a clock speed that is three orders of magnitude slower than today's desktop computers can be.

However, like yourself, I thought all this "bigger, faster, better" hype was silly -- and then I got into video production.  Now I curse the fact that my PCs aren't faster.  I tire of waiting for a few minutes of video footage to render into the latest and greatest hi-compression video format.  An order of magnitude more speed would be wonderful -- when it comes.

[Simon]

I remember our dos computers at school, they were fast at 40MHz (or maybe less). We used pcb software on them and it worked just fine.

but if you want all the fancy graphics you need something to handle them and of course screens keep getting bigger. I'm always happy for computers to get faster. But software needs to be efficient too.

[Zero999]

However, like yourself, I thought all this "bigger, faster, better" hype was silly -- and then I got into video production.  Now I curse the fact that my PCs aren't faster.

You're right, there are applications which need a lot of power, such as some complex mathematical problems which require an exponential increase in computing power to solve at twice the speed i.e. the travelling salesman problem.

  I tire of waiting for a few minutes of video footage to render into the latest and greatest hi-compression video format.  An order of magnitude more speed would be wonderful -- when it comes.

Surely there will come a point when computers are overpowered for that too? I remember when you needed a relatively powerful PC for image editing and desktop publishing but now even a mediocre PC is fast enough. And you mention compression, maybe in the future that won't be necessary if the latest format can store a few TB of data.

[Mechatrommer]

duh... Why are you still using 8 bit MCUs? because i still can!
i'm going to learn how to program a 32bit arm and highly probably will like it. and then i will still back and forth programming 8bit pic or atmel, and highly probably i will. so what? as long as i'm happy.

[alm]

Not sure if I agree that a mediocre PC is fast enough for graphics work, RAW processing is still far from instantaneous, as is image editing on high-resolution images. Being able to apply a tool interactively as opposed to a filter that needs a number of seconds to run makes a huge difference. Many algorithms are tuned to achieve a compromise between quality and performance.

I'm currently working on data analysis that will take a little under a week of processing on a fast Core i7 every time I tweak the algorithm, I would love for this to be reduced to a few minutes. So three orders of magnitude of performance improvement would be quite welcome as far as I'm concerned.

[Mechatrommer]

I'm currently working on data analysis that will take a little under a week of processing on a fast Core i7 every time I tweak the algorithm, I would love for this to be reduced to a few minutes. So three orders of magnitude of performance improvement would be quite welcome as far as I'm concerned.

this is a classic problem that will never end. theory (and capacity requirement) in data processing will always several magnitude ahead/larger of current practical achievement. meaning, there will be a newer theory that needs alot faster machine that is not exist yet. now you want it to be few minutes faster, next year you want it to do only in seconds. so, faster and larger (bit, memory, storage) will always be welcomed. but that doesnt mean slower processors should be banned from existence. an old 486 processor will be way overkill for a simpler quadcopter project or even led flashing. but as i said, if we still want to, then who's going to stop us? as long as we are happy. there's broad of thinking schools i can see in this forum here, from professional, hobbiest, hackers and enthusiasist, or even people that try to prove they can do the job of a 32bit chip programmed by someone else with a simpler 8bit chip (code monkey?), so ymmv.

[hisense999]

I'm currently working on data analysis that will take a little under a week of processing on a fast Core i7 every time I tweak the algorithm, I would love for this to be reduced to a few minutes. So three orders of magnitude of performance improvement would be quite welcome as far as I'm concerned.

OpenCL and computing on the graphic cards this is good option, is pain in the ass and long weeks but then with simple quiet cheap hi-end power sucking ATI cards for most of algorithm things going from weeks into few hours sometimes algo which take weeks on i7 goodly tweaked on OpenCL can take few minutes but also all depend on algorithm type.

About 8bits someone must be masochist if still try to fit modern code in PIC etc. MCU's this things are for nothing more than for blink blink projects and something really simple, especially when quiet good 8bit MCU's which can be used for something bigger PIC and AVR try to selling now more expensive than modern cortex ARM MCU's - 1.5USD I pay for cortex-M3 72MHz, 64Kb flash (in reality 128Kb they only don't speak about it) USB 2.0, ADC, DAC, Timers PWM, and everything more than even is needed for most of projects of course can be found even more cheap cortex MCU's as M0 cores.

[RCMR]

About 8bits someone must be masochist if still try to fit modern code in PIC etc. MCU's this things are for nothing more than for blink blink projects and something really simple, especially when quiet good 8bit MCU's which can be used for something bigger

Actually, there are a lot of applications where 8-bit PIC stuff is perfectly good.

I've just finished a small run of helicopter rotor alarms that have a surprising amount of functionality but all the code fits into 2K of Flash and a 4MHz clock-speed is more than fast enough.  8-bit means smaller package, easier design, easier fabrication and perfectly adequate results.

Remember, faster processors simply wait more quickly when used in an application where a slower processor is adequate. 

[Mechatrommer]

8-bit means smaller package, easier design, easier fabrication and perfectly adequate results.
Remember, faster processors simply wait more quickly when used in an application where a slower processor is adequate. 

the problem is people arguing, there's 32bit chip thats smaller and cheaper (and probably for low power app). i'm yet to full study on this, but if its true then 32bit chip should be the way to go for me in the future even if it has to do alot of waiting/idling/nop'ping. i dont have your experience of easier design in software side for lower 8 bit PIC chip. as i currently working in assembly for both pic10f206 and pic16f690, i have to keep in mind that pic10f206 doesnt have return and banksel instruction. a good example for easier software design is avr core, pretty consistent throughout chip family. i heard (and i believe) cortex also the same. so whether you are IDE developer or circuit designer, there should be no problem, for software design consistency.
ps: please note i bolded the IDE developer, they are the one who translate higher level language such as C into machine/assembly code.

[Bored@Work]

ps: please note i bolded the IDE developer, they are the one who translate higher level language such as C into machine/assembly code.

No, these are the compiler developers and to some extend the library developers. IDE developers just provide the decoration.

[Simon]

as i currently working in assembly for both pic10f206 and pic16f690, i have to keep in mind that pic10f206 doesnt have return and banksel instruction. a good example for easier software design is avr core, pretty consistent throughout chip family.

program in Basic or C then and the compiler takes car of bank selects

[hisense999]

About 8bits someone must be masochist if still try to fit modern code in PIC etc. MCU's this things are for nothing more than for blink blink projects and something really simple, especially when quiet good 8bit MCU's which can be used for something bigger

Actually, there are a lot of applications where 8-bit PIC stuff is perfectly good.

I've just finished a small run of helicopter rotor alarms that have a surprising amount of functionality but all the code fits into 2K of Flash and a 4MHz clock-speed is more than fast enough.  8-bit means smaller package, easier design, easier fabrication and perfectly adequate results.

Remember, faster processors simply wait more quickly when used in an application where a slower processor is adequate. 

Everything depend on the design I also mentioned this before for simple things 8bits are enought for you but all is about design and if 8bit is enought and can decrase cost then of course is much better to go with 8bits. 

Personally I hate PIC, hate AVR same as I hate OpenSource But anyway I used PIC many times in my old days also in my last project I was forced to use it and nothing good I can say about PIC.

B.R.

[Mechatrommer]

ps: please note i bolded the IDE developer, they are the one who translate higher level language such as C into machine/assembly code.

No, these are the compiler developers and to some extend the library developers. IDE developers just provide the decoration.

yes thats what i meant, i just sum them all as IDE. your description is more precise.

as i currently working in assembly for both pic10f206 and pic16f690, i have to keep in mind that pic10f206 doesnt have return and banksel instruction. a good example for easier software design is avr core, pretty consistent throughout chip family.

program in Basic or C then and the compiler takes car of bank selects

i work in basic for pc app. i work in C for higher efficiency and complicated app. and i work in asm for super efficiency but simple app. i'll mix them all if i have to.

But anyway I used PIC many times in my old days also in my last project I was forced to use it and nothing good I can say about PIC.

yeah sometime this "funny reality" happened

[BBQdChips]

I just read this thread from start to finish.  What great entertainment.  You guys are too funny.

My favorite line in the whole thing:

I don't need a clock that can run Crysis. It should just display the time!!!

I loved the references to all of us having 64bit PCs/OS's cause the old 486s weren't enough.  Omg, please don't get me started on software nitwits turning great hardware into a boat anchor. 

We've got one guy who says he does graphic and video editing work and he is waiting for when pc's are 10x as fast as today...  I wanted to ask, do you have any clue how fast the PC is you're sitting in front of?  Any comprehension at all?  Want it to go faster? Get rid of the abortion OS you're running.  If things are going slow, it's cause your software is written by some nitwit who thinks your x64 processor is plenty to make up for him programming video software in Visual Basic.  You only think faster hardware is the cure  because new hardware is the only bandaid available for you to buy.  There is multiple orders of magnitude more performance to be had with a change in software, not that you'll ever have a chance to buy it. 

Yes, let's move to the next series of u-processors for all applications.  Lets see if a newer chip with an order of magnitude more power, is enough to make up for a designer with an order of magnitude less brains.

[IanB]

I wanted to ask, do you have any clue how fast the PC is you're sitting in front of?  Any comprehension at all?

Case in point, I was just recently timing some complex number crunching code involving thousands of double precision computations. Running the code on a recent, but not latest and greatest, P8800 CPU. Do you know how long it took to do those thousands of computations? It took 40 microseconds. That's not milliseconds, that's microseconds.

So yes, the machine sitting on your desk is most likely unbelievably fast. If you tried to run the benchmarks that were usual for a 50 MHz 486 on such a modern machine they wouldn't work, the benchmark would be over before you had finished pressing the enter key.

One of the fundamental laws of programming is that programs expand to consume the available resources as fast as the hardware improves. If your computer gets 1000x faster, your experience will remain 1x faster, the same as it was before.

[NiHaoMike]

Actually -- they do -- but mainly because the likes of Microsoft have created some *horrendously* bloated and slow code in their efforts to make our PCs more user-friendly and powerful.

If you ever get the chance, fire up an old 4MHz Z80 CP/M based computer and have a play with the software of the era.  You'll be surprised at how sprightly an 8-bit computer running with a clock speed that is three orders of magnitude slower than today's desktop computers can be.

I optimized my PC at work today and it's amazing just how much faster it becomes. First, I turned off all the unnecessary Windows effects. That made a great improvement but it still felt a little slow. Then I went into the BIOS and found a "high performance mode", which seems to force the fan to full speed and change some clock settings. It appears to default to only allowing the higher clocks for a short time, but turning on "high performance mode" lets the CPU run at the highest clock for an unlimited time if it needs to. I'm not sure why that option even exists, but I think it's a failed attempt to save energy without making the computer feel slow.

You're right, there are applications which need a lot of power, such as some complex mathematical problems which require an exponential increase in computing power to solve at twice the speed i.e. the travelling salesman problem.

Assuming your problem is limited by clock speed, doubling the clocks (assuming same basic architecture) will cause the problem to be solved twice as fast unless something else becomes the bottleneck. It is true, however, that many algorithms need more than twice the clock cycles when the data set is doubled.

[Zero999]

The hard drive seems to be the greatest bottleneck in most common tasks on modern PCs. If you want performance, try upgrading from 7200rpm to 10,000rpm and if that's too slow, consider a flash or hybrid drive.

[alm]

I loved the references to all of us having 64bit PCs/OS's cause the old 486s weren't enough.  Omg, please don't get me started on software nitwits turning great hardware into a boat anchor. 

Of course software gets more bloated as the hardware gets faster, it's just not economical to spend labor to improve the speed beyond what's necessary for current hardware. Don't forget that modern software does a lot more than old software. Compare for example modern webbrowsers (which use a lot of RAM and CPU) with the ones that used to run on a 486. The latter will barely have javascript support, the rendering will be very primitive, no cascading style sheets that can transform the look of the page, very limited history, and so on. People also tend to idealize old stuff, and remember it faster and more functional than it really was.

We've got one guy who says he does graphic and video editing work and he is waiting for when pc's are 10x as fast as today...  I wanted to ask, do you have any clue how fast the PC is you're sitting in front of?  Any comprehension at all?

Just because you couldn't use more power doesn't mean that no-one else does.

Want it to go faster? Get rid of the abortion OS you're running.

If your OS is using a significant amount of CPU when it's not booting or updating, your computer is either too slow for the OS or something's wrong. Even a stock Windows install will usually idle at a very low CPU usage. Of course installing crap like some virus scanners doesn't help.

There is multiple orders of magnitude more performance to be had with a change in software, not that you'll ever have a chance to buy it. 

The largest gains usually come from changes in algorithms. But there's only so much you can do, at some point the hardware has to take over. Some applications just weren't feasible before faster computers came around, even with careful programming, or are still not feasible today.

[Mechatrommer]

The hard drive seems to be the greatest bottleneck

i was confused this with hard drive "size". with majority of "blind pc performance" community around me, RAM is major bottleneck here, not hdd. i believe i can easily find a PC running Win7 with 512MB RAM around here (or maybe 1GB only), due to sellers want to compete cheap PC price, they reduced the RAM size. so 8GHz 8 core pentium running XP is no better than my 2GHz 4 core pentium. yes, my system bottleneck is HDD i think. my friend used to tell me to upgrade to 64bit machine, i dont know, he used to exagerate things, i prefer to stay with the majority, 32bit

[BBQdChips]

Of course software gets more bloated as the hardware gets faster, it's just not economical to spend labor to improve the speed beyond what's necessary for current hardware.

My entire point was that the guy wants more speed, and a programmer worth their salt could give it to him.  All the hardware needed is sitting there in front of him.

Don't forget that modern software does a lot more than old software.

Yes it does.  Like, checking a jpg to see if there is something in it to execute so a virus has a way to become a reality.  Ever hear of "Data Execution Prevention"?  Wtf is there in "DATA" that needs executed?  Want a good example of wasted cpu cycles, don't read a data record from an SQL DB table and then check the contents to see if there's an exe header in there, then worse yet, act on it.  IT IS DATA.  What are we looking at that for?  Anyone want to answer that?  Ahhhh, yes, we do that so some dumbass doesn't have to remember that EXEs are executables.  They can type whatever errant syntax they want and 'something' will run.  Now we even check arbitrary data files for content that doesn't belong just in case... whatever...

Call up a "Folder" in Windoze.  Why does it read every single file in that folder to get an icon from it.  If there are 20k files in the folder, then it takes an hour to get the folder contents on the screen.  I have done programming in C and done my own "directory" accesses.  It does not require pretty pictures.  Nobody cares about an icon that's 12px sq and was resized from an image 150px square, just to show what type of file it is in a folder listing.  Alphabetize and forget it.

Compare for example modern webbrowsers (which use a lot of RAM and CPU) with the ones that used to run on a 486. The latter will barely have javascript support, the rendering will be very primitive, no cascading style sheets that can transform the look of the page, very limited history, and so on. People also tend to idealize old stuff, and remember it faster and more functional than it really was.

My memory of Cascaded Style Sheets appears better than yours.  They were and still are extremely powerful formatting tools, that worked at light speed on ANY platform.  Truly, I think you are discussing software performance with the wrong guy.  My guess is that you may even believe that the pretty little rounded edges on your windows do not cost a fortune in system performance, no?  That's a lotttaaaa matthhhh, unnecessary mathhhh.  Transparency, translucency, all this pretty window crap.  For what?  Did you really think you became more productive on your Win7 system because of that pretty window rubbish?  I think not.  Would everyone be happier if their system went faster?  I think so.  But, that would put a big damper on hardware sales.

Just because you couldn't use more power doesn't mean that no-one else does.

All I'm saying is I know where the wasted power is at...

If your OS is using a significant amount of CPU when it's not booting or updating, your computer is either too slow for the OS or something's wrong. Even a stock Windows install will usually idle at a very low CPU usage. Of course installing crap like some virus scanners doesn't help.

My new system is as clean an install as I can make it. No virus software, no anti-spyware crap, nothing of the sort.  Not even running windoze firewall.  I type this now on an Ubuntu system here at work. I have 5 pcs, all with different OS's.  XP, 7, FC14, U11.04 and FC7.  FC and U have many the same problems with disk as does windows.  Just open a window with /usr/bin and you'll get the picture.  Wth is all that reading about, display the damn folder already. More reading of shit I don't care to see.  Nor does anyone else.  But I would like to see the folder contents before retirement...

The largest gains usually come from changes in algorithms. But there's only so much you can do, at some point the hardware has to take over. Some applications just weren't feasible before faster computers came around, even with careful programming, or are still not feasible today.

Well, I guess you needed to spend a little time on an old IBM 360 mainframe to really get the idea what performance per/hz means. 

Efficiency of software is a very achievable goal.  The trouble with algorithms is that they were already figured out years ago to be as efficient as they could.  Its the platform upon which they are used today that slows them down.  See, folks years ago were not nearly as inept as some today would like to believe.  They could do math years ago too.  Maybe a bit better than folks of today I might add.  I hate to sound the way i'm coming off, but honestly, you have demonstrated unfamiliarity with many of the facts.  I'll just close with this and hope it gives some frame of reference.

Google.  Go do any search.  Take a look at how many results there are.  Consider the time it took to do the search.  Consider the archive of data that was just parsed.  There were millions of hits on just the words you chose.  Go page through them, see if they don't actually apply to what you asked.  It isn't black magic.  No Voldemort involved.  This is an efficient data processing system.  And, while were on the subject of perspective, consider that you're not the only person using google today.  Search for images once.  Search for anything.  Do you not think they are dealing with more data than a video file?  A day or so from now, maybe a few hours, you can search on an exact line of the text I've just typed and IT WILL probably FIND IT.  Might have to do an advanced search to get it, but, it's hard to comprehend. 

They did not achieve this by asking Billybob to code up some bloatware OS.  You might say, well, it doesn't pay to do worthwhile coding cause nobody needs it with todays hardware.  Well, evidently by the responses above, oh yes they do.

Mechatrommer, you need to pick up a SSD and you'll see where the bottlenecks are in a system.  "The weakest link is the strength of the chain".  Spinning HDDs have seek times well in the ms, not ns.  My new system for instance has an OCZ Solid III Sata3 SSD. 500MB/Sec sustained read, 475MB/Sec sustained write.  It will make an order of magnitude change in a system having something like this, and my CPU is a Phenom II Quad 980 at 3.7Ghz. Not overclocked. Plenty of CPU.

[westfw]

thousands of double precision computations. ... It took 40 microseconds.

Yeah, now run that on each pixel of an a 1080p display (about 2e6 of them), for 30 fps of 2 hours of video, and you'll really want a faster computer.

There's a lot of crappy software out there, but not all of it is subject to "orders of magnitude improvement."  For the software that's really slow, there are people willing to PAY BIG BUCKS for orders of magnitude improvement.

If you do have the speed (and memory, etc)e, you might as well spend it making your UI look pretty.  I remember when you could easily put together a really zippy linux system on a pretty minimal system.  Most of your interaction was via a shell in a B&W X-window, though, and not many people wanted to use them.  A modern linux (KDE, Gnome, etc) is nice enough to give to mundanes, but it's also almost as bloated and slow as windows/etc...

[alm]

My guess is that you may even believe that the pretty little rounded edges on your windows do not cost a fortune in system performance, no?  That's a lotttaaaa matthhhh, unnecessary mathhhh.  Transparency, translucency, all this pretty window crap.  For what?  Did you really think you became more productive on your Win7 system because of that pretty window rubbish?  I think not.  Would everyone be happier if their system went faster?  I think so.  But, that would put a big damper on hardware sales.

Meh, gives the GPU something to do. Until the GPGPU stuff really takes off, there's not a whole lot to do for the GPU with typical desktop applications. Yeah, it will probably increase power usage slightly (though less than doing the non-translucent straight corners in the CPU). I'm sure you can easily turn it off if you're so inclined, but unless your app consists of drawing tons of windows on the screen, this is hardly a big deal.

Wth is all that reading about, display the damn folder already. More reading of shit I don't care to see.  Nor does anyone else.  But I would like to see the folder contents before retirement...

When people are talking about orders of magnitude improvement in performance, it's usually the heavy loads, like rendering a video. The small delays in daily use are merely an annoyance, in my opinion. ls is usually fast enough unless the filesystem is the botteneck (eg. 100k files).

Well, I guess you needed to spend a little time on an old IBM 360 mainframe to really get the idea what performance per/hz means. 

How responsive were photo editing applications on that mainframe? How many HD video streams could they play at the same time?

Efficiency of software is a very achievable goal. The trouble with algorithms is that they were already figured out years ago to be as efficient as they could.

Assuming they already existed back then. For example, some image processing algorithms are fairly recent for the simple reason that digital images became abundant only recently. Sure, all of the basic math stuff like FFT was figured out many years ago. Many people use a library like fftw for this, which provides a fairly efficient implementation.

Its the platform upon which they are used today that slows them down.

How do translucent windows and thumbnail images in folder views slow down the FFT?

I hate to sound the way i'm coming off, but honestly, you have demonstrated unfamiliarity with many of the facts.

Facts? Where?

Google.  Go do any search.  Take a look at how many results there are.  Consider the time it took to do the search.  Consider the archive of data that was just parsed.  There were millions of hits on just the words you chose.

This is a completely different problem they're trying to solve. Of course their algorithm and implementation is extremely optimized. They also throw as much hardware on it as necessary, since they consider performance one of their prime targets. They can pre-process the data, since they spend much more time querying it than collecting new data. They have many servers and many queries, so they can spread the load and avoid peak loads. If your query takes ten times as much processing power, they can easily provide it as long as not everyone else is executing a query of similar complexity at the same time. If you need ten times more processing power to edit your video, you can't just borrow 9 CPU's from your neighbors. Not saying they're not solving a very hard problem, but it's not the same problem that requires a fast desktop PC.

They did not achieve this by asking Billybob to code up some bloatware OS.

They run the same OS that takes half a minute to display the contents of /usr/bin.

[Mechatrommer]

My guess is that you may even believe that the pretty little rounded edges on your windows do not cost a fortune in system performance, no?  That's a lotttaaaa matthhhh, unnecessary mathhhh.  Transparency, translucency, all this pretty window crap.  For what?  Did you really think you became more productive on your Win7 system because of that pretty window rubbish?  I think not.  Would everyone be happier if their system went faster?  I think so.  But, that would put a big damper on hardware sales.

let me join in! that cost millions of people lose billions of dollars to bill gates for win7. productive? yes psychologically to the millions people out there (with proper neck tie and skirt). if not then tell me... what are you going to do with GHz of CPU and GPU? GB of RAM and HDD? NASA or CERN Simulation? statistic saying, computer do alot more waiting for us (not me not you, the tied guys and the skirted girls) to press the next key on the keyboard. call that a waste? well, its millions of waste. not to mention the kids watching porno.

[BBQdChips]

I wont bother with a boatload of quotes...

@Westfw.
First, you don't need to do those sorts of computations on 1080 video.  You get a stream of data from a blu-ray, send it unchanged to a GPU that has HD video decoding in hardware, and it sends the stream to the display after uncompressing it.  The compression is very rudimentary, it's not fixed, there's actually fuzzy logic in the process.  One decoder will actually generate a different image than another.

The rest of your post tells me you've given in like the others to thinking that there is some tradeoff that has to be made. Some "bargain with the devil" if you will, to get the system to go faster.  There isn't.  Your last statement is exactly the mindset of the programmers both doing lazy PC Os work, and wasteful microcontroller work.  "Well, here's all this power, let's waste it...  What else are we gonna do with it?"   Well, there's no reason you can't "Have your cake and eat it too".  The desktop can be just as pretty or very nearly so, and still go fast. 

I could use the same reasoning you guys are using, but apply it to developers/programmers.  Well, we've got all these out of work software developers, maybe they ought to get off their duffs and write some decent code and they wouldn't be out of work.  Here they sit unemployed, let's just waste all this programming talent cause we've got lots of it.  Same thing isn't it?  Sort of ironic I say.  Here in the US, there's an epidemic of unemployment for software developers and high tech jobs of all sorts.  Yet, all of them are looking for ways to develop things so wastefully in so little time, they are now out of work.   Hmmmm.. food for thought.   I bet right about now there's a whole bunch of designers of both hardware and software who wish they had some work in Assembly code or 8 bit mcu's to do...

@alm

Meh, gives the GPU something to do. Until the GPGPU stuff really takes off, there's not a whole lot to do for the GPU with typical desktop applications. Yeah, it will probably increase power usage slightly (though less than doing the non-translucent straight corners in the CPU). I'm sure you can easily turn it off if you're so inclined, but unless your app consists of drawing tons of windows on the screen, this is hardly a big deal.

Yes, you can choose a windows classic desktop or linux theme that does not have those rounded corners and turn at least that stuff off.  As to it not being a big deal, your system draws the same windows all the time, and yes it is very much a big deal. Very noticeable, as mentioned also by another poster way above here.  There is a huge performance increase just in the "Performance" tab of system properties by turning off many of the UI effects. I bet 80% of those are not even noticed by any user (speaking aesthetically now).  I leave on a few, but they either have value, or no cost in performance.  I use the Translucent Selection window.  Full Window Drag.  Clear Type Text.  There may be 1 or 2 others, but I turn off everything else.  Makes a huge difference in everything you do.

Next ppg.
Again, I disagree.  I would say for large loads, depending on the data handling, there is less steady state performance to be gained than there is misc gain in all these little wasteful UI processes going on.  But unfortunately, those are killing that large workload and keeping it from doing what it should (which is complete the big job).  I don't think you're aware of how much this pig UI is crippling even the more efficient parts of the system. 
Another comparison.  Back in the Win98 days, you had "Smartdrv.exe".  A configurable disk cache.  It could make disk transfer order of magnitude faster.  It is gone now, and there is nothing like it.  Now, we have enough ram unused that it is equivalent to the HD size we had then.  But, we can't use it for disk cache.  Why?  Go copy a 1080 Mkv video file from one hard disk to another.  With adequate free space, any cheezy hd will read or write 65MB/sec.  I can transfer 130MB/sec over my home network.  (actually a cheat cause I can move data over the network from pc to pc faster than I can from one drive to another in the same pc).  No raid...  a 30G file will take eh, 4 to 7 minutes depending on what throughput you get.  But, now copy one file, and start a second simultaneous copy.  Now, due to the drive access method, the speed will drop and it will alternate between jobs.  Now those two files instead of taking 8-14 minutes will take 3-5 hours.  Inefficient...  Not hard to fix at the OS level. Impossible to fix at the user level.  Oh, and this happens while we have 6.5GB of free ram in the system that is sitting idle instead of being used for disk cache.  And to add to that, we have 6.5GB of free ram and the OS is still hitting the swap file every second.  Go ahead, explain that reasoning to me. 

How responsive were photo editing applications on that mainframe? How many HD video streams could they play at the same time?

Unbelievably responsive.  yes, they did image work, and in fact, if you look at your current copy of windoze, it'll still have reference to Wang Labs rights to imaging algorithms, very much in use then and now, both on mainframes and pcs.  Actually, I worked on a 370 system at a local community college that had a CAD system on it, 32 dumb terminals via sna. Beautiful 24" color monitors. Holy expensive...  What would take a pc using Autocad 2 min to draw, it would put on the screen of any of those terminals as fast as the refresh rate.  POW!  mind blowing speed.  Yes, they could have run all the video they wanted.

I was also a dealer for Autodesk then, and there was a company making a video card that had a dongle associated with it, and a "driver" "Optimized" for Autocad.  Was all bs.  You could put that dongle on any pc and get the full 40x performance increase in regen's and re renders.  Just load the "drivers" that fixed the shit code from Autodesk.  You didn't need the crappy cirrus logic crap video card they sold for perverse money.  This was an entire industry of selling snake oils.  Much like now.  They Want the stuff to run slow.  It's more profitable.

How do translucent windows and thumbnail images in folder views slow down the FFT?

TW's and thumbs (implementation and overhead) slow your system to a crawl, all the time. Mostly its the generic, do-everything-every-time mentality of disk access that kills pc os performance.  Win/Linux alike. 

But, a better question might be, wth does FFT have to do with the performance topics of either software or hardware at the PC OS level, or the uC level?

Facts? Where?

Facts about software performance.  Facts about how the filesystem implementations have far reaching affects to total system performance.  About how programming efficiency, even on a uC, has benefit beyond the shortsighted aims of many designers.  And, while it may or may not be a fact, it is my opinion that the argument where peoples time isn't worth the performance gains to be had, is patently false.  There is a balance somewhere between man hours development time vs system performance / user experience.  Ok, I'll agree that.  But, you seem very distant in your opinion that the current lack of performance in our OS lets say, is either my imagination, or justified due to todays hardware.  I'm on the other end of the world with my opinion, I think with minimal effort, huge gains are there to be had if anyone cared. 

To put it better, our tools we have to work with are built with such bloated libraries (which we are forced to use in many cases), that no matter how we try to make our stuff efficient, we're restricted in what we can achieve.  It appears to me that you think this justifies our lack of effort, I do not. 

The google example fits.  Data is data.  It doesn't become something other than 1's and 0's just cause it's a blu-ray movie.

They run the same OS that takes half a minute to display the contents of /usr/bin.

Couldn't have said it better myself.  I think you just made my point.  They took the same bloated OS that won't list a hard disk directory in 5 sec, re-worked the thing stem to stern, and made it search all data on earth in .01

[BBQdChips]

Here's an interesting irony too.

The Op, along with others in this thread, advocates the use of more processor than may be needed for the job, in the interest of reducing part count, ease of development (need to know less parts) and feels cost is a wash.  Not debating any of that.  Then almost opposite that mindset, you brought up the slow adoption of using GPU for processing, and I agree.  Here's Microsoft and all PC OS developers who have had this capability since back in the early 90's, yet never used it at the desktop level.    I bet by the late 90's, every pc on the market had a 3D graphics card capable of doing incredible amounts of processing, but sitting idle unless we played a game.  Why is that? 

One group want's more cpu even if there isn't work to do.  The other group has more computing power unused than used, but won't use more. 

[Zero999]

Yes it does.  Like, checking a jpg to see if there is something in it to execute so a virus has a way to become a reality.  Ever hear of "Data Execution Prevention"?  Wtf is there in "DATA" that needs executed?  Want a good example of wasted cpu cycles, don't read a data record from an SQL DB table and then check the contents to see if there's an exe header in there, then worse yet, act on it.  IT IS DATA.  What are we looking at that for?  Anyone want to answer that?  Ahhhh, yes, we do that so some dumbass doesn't have to remember that EXEs are executables.  They can type whatever errant syntax they want and 'something' will run.  Now we even check arbitrary data files for content that doesn't belong just in case... whatever...

You don't even know what data execution prevention is, let alone why it's a very good idea. On modern computers data execution prevention is primarily by the hardware and doesn't require any extra clock cycles. It is a good security feature because it helps to prevent buffer overrun vulnerabilities in the software from executing malware. This is when a harmless file such as a JPG is loaded and there is a vulnerability in the software that can cause the program counter to be set to where the data is loaded. Normally such a vulnerability will just cause the program to crash but if the JPG contains valid machine instructions it won't and if it's a virus you're buggered.

Call up a "Folder" in Windoze.  Why does it read every single file in that folder to get an icon from it.  If there are 20k files in the folder, then it takes an hour to get the folder contents on the screen.  I have done programming in C and done my own "directory" accesses.  It does not require pretty pictures.  Nobody cares about an icon that's 12px sq and was resized from an image 150px square, just to show what type of file it is in a folder listing.  Alphabetize and forget it.

Is this on your new machine with a flash drive? If so you definitely have malware in there. I have 1GB RAM, a single core 2GHz processor running XP and a fast 10,000 mechanical hard drive and it takes a couple of seconds at most to load a folder containing hundreds of pictures totalling nearly 700MB.

I type this now on an Ubuntu system here at work. I have 5 pcs, all with different OS's.  XP, 7, FC14, U11.04 and FC7.  FC and U have many the same problems with disk as does windows.  Just open a window with /usr/bin and you'll get the picture.  Wth is all that reading about, display the damn folder already. More reading of shit I don't care to see.  Nor does anyone else.  But I would like to see the folder contents before retirement...

Linux had data execution prevention long before Windows did and is one of the reasons why many preferred Linux at the time. I've dabbled with Linux too but I haven't really noticed it being any faster or slower than Windows.

[Mechatrommer]

you can still setup DOS in your system if you want faster performance, or XP like me talking about virus, avast is good in term of performance/overhead. i never felt the presence of it or overloading the cpu performance. last time i used norton antivirus which in each new version on faster machine, it runs slower, now for me norton no anymore, but it was good, esp on file defragmentation program. OTOH, one thing i hate about win7 is its start menu system is less productive imho compared to win XP, and it doesnt help in better aesthethic as well. ie win7 overlay the higher level submenu on top of lower one making it difficult to go back few menu level, not like XP with older style start menu, its popped up to the right with lower level menu still visible i can move my mouse to anywhere in the menu level. i tried to find the setting to go back to old menu style in win7 but cant find it.

[BBQdChips]

You don't even know what data execution prevention is, let alone why it's a very good idea. On modern computers data execution prevention is primarily by the hardware and doesn't require any extra clock cycles.

My point there was, why is it necessary?  Not any performance impact, but the idea that 'data' has something executable in it, a virus lets say.  It is loaded up into memory in it's entirety, meaning all file headers get brought in as well, even tho this is a data file and you should have already stripped all that since it really isn't "data".  So it's been put in ram quite consciously, then, an event occurs that would most likely cause a BSOD, but oh no, somehow it ends up making a call to a location in ram where this virus just "happens" to be, and without accidentally landing off an instruction boundary, this code begins to execute.   Hmm, sounds like a bit of a stretch to me.  Methinks somebody wants this malware to execute and already had all the control over the system they needed.  And, if the malware is what's making this call, then I guess our goose was cooked before any jpg got loaded anyway wasn't it.  Still no need for DEP.  Or well, it does nothing.  Oh, and how's it doing at stopping all the malware anyway? 

But you believe this is an every day occurrence that all these conditions just happen to line up?  Seriously, someone can stick executable code inside a jpg and it'll somehow run, cause it just magically takes over the program counter?

It doesn't matter if it's direct or indirect, its effects are still there. 

OTOH, one thing i hate about win7 is its start menu system is less productive imho compared to win XP, and it doesnt help in better aesthethic as well. ie win7 overlay the higher level submenu on top of lower one making it difficult to go back few menu level, not like XP with older style start menu, its popped up to the right with lower level menu still visible i can move my mouse to anywhere in the menu level. i tried to find the setting to go back to old menu style in win7 but cant find it.

That is because MS doesn't want you to be able to use the menu you've known for the past decade or so.  It MUST be redesigned and you must be forced to use the cell phone interface they've now got.  What a piece of s....

Without loosing the menu w7 came with (in case some functionality is still needed), you can still load up Classic Shell and have both. It fixes some of the other dumbass stuff Ms did to explorer, but of course it doesn't fix everything.

[BBQdChips]

you can still setup DOS in your system if you want faster performance,...

Actually, that's not true on a new system.  The lower memory layout has changed and so DOS won't actually work on a new motherboard.  Been that way for a while now, though I won't guess on an exact time.

[IanB]

But you believe this is an every day occurrence that all these conditions just happen to line up?  Seriously, someone can stick executable code inside a jpg and it'll somehow run, cause it just magically takes over the program counter?

It doesn't "just happen" and its not "magic", it is quite intentionally and deliberately achieved. You still don't quite understand, apparently, how easily unpatched vulnerabilities in almost any code running on your system can be exploited to let people compromise your machine. If you have not applied all the latest updates to Windows, Flash, Adobe Reader, Firefox etc. your machine is like a house with all the doors and windows unlocked just waiting for someone to take it over. DEP is one layer of protection to help stop this from happening.

Now of course it's true that some of those vulnerabilities should never have been there in the first place and Adobe is one of the worst offenders in this regard, but since many people run with Adobe crapware on their machines then at least keeping the crap up to date is essential.

[sub]

So it's been put in ram quite consciously, then, an event occurs that would most likely cause a BSOD, but oh no, somehow it ends up making a call to a location in ram where this virus just "happens" to be, and without accidentally landing off an instruction boundary, this code begins to execute.   Hmm, sounds like a bit of a stretch to me.  Methinks somebody wants this malware to execute and already had all the control over the system they needed.

The idea is that an error in the code causes the data to be written past the end of the buffer and over the top of the function's return address.  Then at the end of the function the program faithfully loads up this return address and jumps to the hostile code that was inserted into the data.    These indeed normally cause segfaults (not BSODs) as you said, but sometimes the fault in question does not occur in normal operation and so is not found during testing.

Various types of protection will stop the return address from being overwritten or the jump from succeeding.

But you believe this is an every day occurrence that all these conditions just happen to line up?  Seriously, someone can stick executable code inside a jpg and it'll somehow run, cause it just magically takes over the program counter?

In some (most? all?) calling conventions the address to which one must return is placed in the stack before memory for data is allocated.  If the program writes past the end of one of its buffers, it may well be able to keep going until it hits this address, in which case one can construct data that will change it to point to hostile code contained in the data.

Here are some articles describing how these exploits work: http://www.linuxjournal.com/article/6701, http://en.wikipedia.org/wiki/Buffer_overflow

[BBQdChips]

Ian, I've never had a virus on a system in my life.  I've worked on plenty for other folks, but not on mine.  I never run FF and use IE only for streaming drm video, and that's rarely.  Opera doesn't seem to have all the same holes.  I run WinUpdate once in a systems life.  At the begining.  If it works, I don't fix it...

sub,
Thanks for the link to the article. Pretty much what I was expecting.  Ian's last ppg and some of the other posters comments on that article seem to agree with me that all of that can be prevented by decent coding.  In my wildest dreams, I could never figure out how code would be written and allow such things to happen, and be so common.  A mistake by one person, sure, ok.  But for this to happen in virtually all software?  I guess I'm too old for todays 'New programming', (a joke in the US amongst many is the "new math", a way math is done today that arrives at different answers than it used to years ago.  Folks would jokingly refer to 'the new math" when some dumbass arrives at the wrong answer for a simple problem).   

Some of those examples are just silly.  Honestly, in my first weeks of C programming (going way back), I figured out that you don't use a get() for something variable length and put it in a buffer of finite size...  Are we seriously 25 years beyond and programmers of today haven't figured that out yet?  Looking at the comments, it appears I'm not the only one who doesn't feel compassion for these 'programmers'.  I'm not willing to make excuses for them on how this is easily overlooked.  This is first grade stuff.

Well, our discussion of efficiency has long since digressed past the 8 vs 16/32 subject.  Sorry for the thread hijack...  But then, looking at the traffic to this section, it could use a little discussion, even if it is bickering!

[IanB]

Ian, I've never had a virus on a system in my life.  I've worked on plenty for other folks, but not on mine.  I never run FF and use IE only for streaming drm video, and that's rarely.  Opera doesn't seem to have all the same holes.  I run WinUpdate once in a systems life.  At the begining.  If it works, I don't fix it...

Yeah, I used to be where you are. I ran like that for years. Viruses were something that happened to other people. Yet one day, I was just sitting there minding my own business when my computer took on a life of its own. The disk drive started whirring and suddenly my machine was misbehaving.  Every time I would try to visit a page in a web browser (any browser) it would jump to somewhere else. This would especially happen if I tried to visit pages to download antivirus software or security updates.

It took me about 8 hours to clean up this mess and remove the infection. It turned out my machine had been root kitted and the malware had got deep into the system. It took a lot of effort to find the infected files and remove them.

As far as I can tell it was a flash player vulnerability exploited by a malicious flash advert on an ad-supported web site open in the background. Needless to say I am now a bit wiser. Viruses are no longer things that happen to foolish people who download random crap off the Internet. I am much more thorough today about keeping all my software up to date with security patches.

Recently I watched a demo of what could happen to a Windows XP machine that was not up to date with the patches. From another machine on the network, the presenter was able to run a simple command "probe that Windows machine and fine a way in". Within about 5 seconds the program came back with "OK, we are in, you are now running as administrator on that machine". Next step was "get password hashes". Not much use in encrypted passwords, you might think? Well, "get plain text passwords from hashes" with a bit of help from Google soon revealed the administrator password for that machine.

This is so easy to do that if you plug an unpatched Windows XP machine into the open Internet without a firewall to protect it you can watch it get taken over in front of your very eyes. Usually the machine will be compromised faster than you can download and install the necessary Windows updates.

[alm]

In my wildest dreams, I could never figure out how code would be written and allow such things to happen, and be so common.

Part of it is due to some great design decisions in the C language. For example, if you use strncpy to avoid a buffer overflow, n bytes will be copied, but the string will not be null-terminated if the source string is longer than n. If you do the same with strncat, n bytes you specify will be copied, plus an additional null, so n+1 bytes in total. If you use snprintf, n-1 bytes will be written, plus a null, for a total of n bytes. There are also more subtle issues, like an unsigned integer being cast to signed (or visa versa). If the unsigned integer has the most significant bit set, a cast to signed will transform it to a negative integer. A negative integer is smaller than your limit, but the next function may take an unsigned integer and treat it as a really big number.

Writing secure software is just plain hard. Try to find an OS with significant popularity and features that's never had any security issues. Even the OpenBSD people, for whom security is the number one priority, have let through two remote root holes, and a lot more minor security issues.

I guess I'm too old for todays 'New programming', (a joke in the US amongst many is the "new math", a way math is done today that arrives at different answers than it used to years ago.

Old software is by far the worst offender. Only after the Morris worm somewhere in the eighties did anyone start paying some attention to security, and it took much longer for some companies (the small one in Redmond for example) to notice. Before networking became common, it just didn't matter if your word processor might screw up if you fed it incorrect data, since it would be hard to get the manipulated document on someone's computer.

[Zero999]

I've never had a virus either and I don't bother with memory resident anti-virus software because I find it too much of a recourse hog. I do keep my system fairly up to date though, run as a limited account for general usage and scan with Malwarebytes every now and then. I accept that there's a risk of my system getting owned but I feel I take far greater risks every day so it's not a priority for me.

So what my system gets owned, what's the worst that could happen? They get hold of my bank account details and buy loads of random crap off ebay. I soon find out, my card gets stopped, the bank cancel all of the transactions and I'm very likely to get my money back. I don't have anything I'm really bothered about loosing on my hard drive and will back up anything I really care about.

I don't understand why people bother spending hours cleaning up viruses. It's much easier to boot with a live Linux CD, back up all the important files to a USB stick or hard drive, format the hard drive, reinstall Windows and remove any virus from the backed up data before transferring it back.

[IanB]

I don't understand why people bother spending hours cleaning up viruses. It's much easier to boot with a live Linux CD, back up all the important files to a USB stick or hard drive, format the hard drive, reinstall Windows and remove any virus from the backed up data before transferring it back.

You miss one important point. It is not so much the data files, but reinstalling all the programs and utilities that you had installed previously. Do you have the installers for every one of those? Do you remember all the configuration settings you made? Following a clean OS restore, how long would it take you to reinstall every program you had installed before and restore all the system customizations back to the way they were?

[Mechatrommer]

You miss one important point...how long would it take you to reinstall every program you had installed before and restore all the system customizations back to the way they were?

so i KISS. programs that i've been using are pretty much established for years now, and only a couple, even if its old, i hate changes, i dont like to go find a latest software to try out like i was, more risk of downloading viruses that way, and less productive to keep trying instead of using the "real" softwares for me. so i've made backup from a fresh installation my common programs, so next time a virus hit, i just de-ghost that image, and restart to build up the setting again while using it. i've made many times of those reformat and reinstall and yes i got sick of it, i got sick of viruses. took me days to track the virus, but took me only a day to reformat the whole thing. i hate virus makers, they are losers and pathetic morons, the bad "offsprings" from good "hackers". i know my XP got outdated and highly probably got many holes, i only rely on my automatic updating avast antivirus, but if its still cannot the job then what the heck? even the new OS got holes, it will be always like that from stone age. once there is a new OS, there will be morons that got nothing else to do to find the holes, and they will succeded. they succeded in the past and they always succeded in the future. you can keep updating all you like, but the holes will be always there. i dont want to waste my time on this, i want to do the real job. to all virus/exploit makers, FUCK to all of you! and you know what? devcon is where all its started imho. i dont say everybody presented in there is bad people, but as i said, the "offsprings" are from there mostly, + other geeks (morons) who got nothing else to do in their cave other than stealing, criminal and antisocial! F**K! EOR! i'm just wasting my time here!

[BBQdChips]

Hero,
My system sounds a lot like yours.  No extra crap running.  My firewall is a router, not some MS bs in software.  Works for me.

You miss one important point. It is not so much the data files, but reinstalling all the programs and utilities that you had installed previously. Do you have the installers for every one of those? Do you remember all the configuration settings you made? Following a clean OS restore, how long would it take you to reinstall every program you had installed before and restore all the system customizations back to the way they were?

Ian, I reinstall due to new systems, hardware changes, or moving HD's around.  On my home theater PC, now that I do run Open source players on, MPC-HC, and all associated utilities, and software for MKV so I don't have to get out DVDs.  That stuff is a convoluted mess, but I need it.  Reconfig of a system with all that stuff on it to playback blu-ray mkv is a colossal pain in the ass.  Since the DOS days, I've kept a folder call Zips on any system I own (or built and sold when I did that) with 100% of all latest drivers on the system, all shareware / downloaded software I used, or whatever.  All my utilities for everything.  All stored in one nice neat location ready, should I need to move to a new system or reinstall.  My own software, I have ripped to ISO and mount with things like Alcohol or VirtualCloneDrive. I've done that for years and years.  If I load something on a system, it gets put either on that very system, or on an external drive just for this purpose.  So yes, I do keep all that stuff and I'm very methodical about it.  But as you say, it is still a huge pain to set the systems back up to where they were.

Using Opera for Internet and Mail is a huge help in that respect.  It stores data the old fashioned way, in files.  So you can just copy the folder to a backup location, and after you reinstall it, copy that folder back and 100% of your browser is back.  Even cross platform.  Copy the Linux files to the Win pc, still works.  Some are in different locations, and some do have slightly different formats, but for the stuff we actually use like Bookmarks, mail folders and accounts, passwords, all that stuff works regardless of the platform.  I also use their "cloud" like thing which really makes it simple.  Log in and pow, everything is back.  (configurable as to what you let them save).

Still, as you say, it's an all day affair to do a fresh load on a new system drive, so I prefer to do it as seldom as I can.

To get back on the subject of 8bit microcontrollers, I was today on the Atmel site looking at Tiny's and Microchip site looking at Pic16's for a new project.  I see prices have come down again on the 8 bit parts.  I can get everything I need for this project in a 28pin QFN for less than $1.50/unit qty 1.  Incredible, this on a chip that internally has more power than the first IBM PC I worked on which cost almost $20,000 back in 1984.  Back then a 10MB hard drive came in its own cabinet just like the PC cabinet, but with no front openings.  You stacked em up!  Of course, that system had a 8087 chip in it too, and that was no small-potatoes update!

Just for giggles, I looked for a comparable 32bit chip to see about this minimal difference in cost that's been advocated.  Sorry, but I do not see any 32bit parts for <$1.50/unit.  Even at volume pricing.

[Zero999]

It doesn't take me that long to reinstall everything. Windows probably takes the longest to set up and the other programs I use are easilly downloaded. If I was that bothered, I'd just backup the entire hard drive after I've installed everything I want for the first time. Another solution is copying where the configuration settings are stored such as .ini files and parts of the registry, although that's a bit hit and miss.

Come to think of it, wasting a half a day every five to ten years is probably less of a waste of time than the minutes I'd spend daily waiting for AV software to scan every file on my hard drive, USB stick or CD/DVD I use on my PC.

[sub]

A mistake by one person, sure, ok.  But for this to happen in virtually all software?  I guess I'm too old for todays 'New programming', (a joke in the US amongst many is the "new math", a way math is done today that arrives at different answers than it used to years ago.  Folks would jokingly refer to 'the new math" when some dumbass arrives at the wrong answer for a simple problem).   

Some of those examples are just silly.  Honestly, in my first weeks of C programming (going way back), I figured out that you don't use a get() for something variable length and put it in a buffer of finite size...  Are we seriously 25 years beyond and programmers of today haven't figured that out yet?  Looking at the comments, it appears I'm not the only one who doesn't feel compassion for these 'programmers'.  I'm not willing to make excuses for them on how this is easily overlooked.  This is first grade stuff.

Not all such errors are so obvious.  It only takes a single off-by-one to open a vulnerability---for example if you use strcpy on a fixed-length string that is not null-terminated because someone used the wrong length parameter for strncpy, you risk opening a hole.  Let the wrong integer overflow, you risk opening a hole.  Update by mistake the size of the array that you declared one line after the destination buffer, you risk opening a hole.

While everyone knows about these attacks and tries to avoid them, it takes only one person making one of a thousand small mistakes on one occasion in thousands or millions of lines of code to make the software vulnerable.

[ToBeFrank]

Just for giggles, I looked for a comparable 32bit chip to see about this minimal difference in cost that's been advocated.  Sorry, but I do not see any 32bit parts for <$1.50/unit.  Even at volume pricing.

32 bit, 50MHz for $1.40 quantity one, $0.91 in volume:

http://www.mouser.com/ProductDetail/NXP-Semiconductors/LPC1111FHN33-2025/?qs=sGAEpiMZZMutXGli8Ay4kPVk7KsQge6Uep3GMeQa6Xs%3d

[Zero999]

Part of it is due to some great design decisions in the C language. For example, if you use strncpy to avoid a buffer overflow, n bytes will be copied, but the string will not be null-terminated if the source string is longer than n. If you do the same with strncat, n bytes you specify will be copied, plus an additional null, so n+1 bytes in total.

I've never understood why the C developers decided to use zero terminated strings. When I played with x86 assembly I always used a byte at the start of the string to denote its length which made errors less common and certain functions faster because the the whole string doesn't have to be scanned for the zero to determine its length.

Of course the disadvantage of using a byte header to define the length limited the string to 255 characters but if I wanted more I'd just use two bytes or more for the header.

Just for giggles, I looked for a comparable 32bit chip to see about this minimal difference in cost that's been advocated.  Sorry, but I do not see any 32bit parts for <$1.50/unit.  Even at volume pricing.

32 bit, 50MHz for $1.40 quantity one, $0.91 in volume:

http://www.mouser.com/ProductDetail/NXP-Semiconductors/LPC1111FHN33-2025/?qs=sGAEpiMZZMutXGli8Ay4kPVk7KsQge6Uep3GMeQa6Xs%3d

There are additionals hidden costs to using that MCU.

Look at how many pins there are which make the PCB more expensive.

It requires a low voltage 3.3V supply which means having a regulator and will need output transistors for driving blue, white or violet LEDs which contribute to the cost.

The PIC16F505 is still half the price, comes in a smaller 16 pin package, will work from 2V to 5.5V so it can drive blue, white or violet LEDs directly and can run off four alkaline batteries via a cheap diode to drop 0.6V.

[BBQdChips]

Just for giggles, I looked for a comparable 32bit chip to see about this minimal difference in cost that's been advocated.  Sorry, but I do not see any 32bit parts for <$1.50/unit.  Even at volume pricing.

32 bit, 50MHz for $1.40 quantity one, $0.91 in volume:

http://www.mouser.com/ProductDetail/NXP-Semiconductors/LPC1111FHN33-2025/?qs=sGAEpiMZZMutXGli8Ay4kPVk7KsQge6Uep3GMeQa6Xs%3d

ToBeFrank,
I stand corrected.  And, that part in a 33pin quad would work for my application.  I am looking for a 5v part so this isn't the best choice for my app, but the 3.3v notwithstanding, if I wanted, it could be made to work.  I hadn't seen any 32bit parts for less than about $2.40 in volume, so clearly I missed these.

[ToBeFrank]

Look at how many pins there are which make the PCB more expensive.

He was looking for "a comparable 32bit chip", and the comparison was to a 28 pin pic16.

It requires a low voltage 3.3V supply which means having a regulator and will need output transistors for driving blue, white or violet LEDs which contribute to the cost.

That's project specific. I'm sure you can come up with scenarios where having 3.3V would be better than having 5V. For example, interfacing with other devices that require 3.3V.

The PIC16F505 is still half the price, comes in a smaller 16 pin package

You're comparing apples to oranges, not "a comparable 32bit chip".

[Zero999]

That's project specific. I'm sure you can come up with scenarios where having 3.3V would be better than having 5V. For example, interfacing with other devices that require 3.3V.

No because 8-bit MCUs are less fussy about the supply voltage, the IC I selected will work from 2V to 5.5V which includes 3.3V.

The PIC16F505 is still half the price, comes in a smaller 16 pin package

You're comparing apples to oranges, not "a comparable 32bit chip".

I know, I'm questioning the myth that 32-bit is always a better choice than 8-bit.

For an even cheaper 28 pin 8-bit IC go for the PIC16F57.

[ToBeFrank]

I know, I'm questioning the myth that 32-bit is always a better choice than 8-bit.

I agree that 8 bit chips still have there place, but there is definitely overlap these days, cost included.

[baljemmett]

I've never understood why the C developers decided to use zero terminated strings. When I played with x86 assembly I always used a byte at the start of the string to denote its length which made errors less common and certain functions faster because the the whole string doesn't have to be scanned for the zero to determine its length.

One possibility is that it made the original library code simpler/more compact/whatever -- remember that the C standard library has its roots in 'functions we found useful in the original Unix code' (which is, for instance, why strncpy is so bonkers).  Keeping a count and using an index variable to iterate is a little overhead for each string and function, and perhaps K&R felt the speed tradeoff for 'find end of string' operations was worth it.  Most string operations have to traverse the string to do what they need to do anyway, after all (strcpy, strcmp, strchr, strstr etc.; strcat and strlen are oddballs in that they waste a traversal.)

Of course many languages have richer string types -- your byte-counted example is often known as a 'Pascal string', for instance, and a modern OO language will have all sorts of fun data associated with a string.  The security implications of C having ruled the roost for so long are unfortunate, though...

[IanB]

If you look at the design of C from the perspective of its origins and the design philosophy expounded in K&R, it was inevitable that C strings would be null terminated. This was not an arbitrary choice that could have gone either way, it simply had to go the way it went.

Strings are arrays of characters; arrays and pointers are inextricably intertwined in the language; a pointer to an array must be a pointer to the first element of that array; an array of characters should behave the same way as an array of other types; etc. etc...

It's true that there could have been a special string data type different from an array of characters, but C was a low level systems language close to assembler, and a programmer needing high level strings could implement a library for that purpose making use of the raw facilities of the language.

If there is a complaint about C, it is why didn't an ecosystem of libraries get developed beyond the basic standard libraries? The C++ community is certainly doing that now, it is odd that the C community didn't do it then.

[ThePranksta]

I'm still using a 8 bit MCU because the project demands it.  MCU choice is based thousands of factors and going into a new project which a preconceived idea that one MCU is ALWAYS better than another is dangerous. Here is few examples I encountered so far in my short career.

Budget LEO satellite design, a specific 8051 has been radiation/temperature/vibration etc etc tested and approved at great cost 10 years earlier and subsequently used  dozens of times on five previous projects without failure.  The cost of this almost EOL MCU was actually quite high at $10+ a piece but still a lot cheaper than redoing all the tests or choosing a MCU that will fail 500km above my head.

Small simple cheap mass produced CR3032 powered product for a customer; they have numerous supply agreements in place with certain for a group of MCU's from specific chip manufactures.  That means you choose the cheapest/most power efficient MCU from the group, this case a 16-bit.

A product for our own company, generic with a great need for availability in the future coupled with an unknown number of future feature enhancements. A mid range CortexM3 was choosing.

Then take into account the worth of already produced/tested bulletproof code even if it is for a 8-bit processor and the capabilities and strong points of your developers.

[ThePranksta]

If there is a complaint about C, it is why didn't an ecosystem of libraries get developed beyond the basic standard libraries?

You answered your own question, ecosystems did develop and morphed into C++, Objective C, etc etc.

C strong point is because it old, simple, basic and small; if need a single library for something specific you find it, steal it or create it. If you need more you do not use C.

[Tony R]

Why would anyone, today in 2011., choose an 8 bit microcontroller for his project?

Well it is 2011, and 8 bit MCUs have been around for a very long time, so most of the bugs have been found and solved, thus they are reliable.

There are lots of small, very cheap, low power 32 bit devices on the market (like for example Cortex M0 series).

There are also a lot of small very cheep low powered 8 bit devices on the market (like the C8051)

What's wrong with you people? 

ooo so many things, but that will have to wait for another day. For me an 8 bit MCU is more intuitive. memory is arranged in bytes, for me I have a (and some what odd) fascination with programming in assembly language. memory alignment is easy then, I'm only pulling one byte at a time.

and why charter a plane to get you across the street when you have a crosswalk, why make things more complicated then you have to? Why give it more processing power than you need? If I'm making a microwave and programming the firmware, i don't need a ARM.

plus, i might be able to get 1 ARM for 11 bucks and one C8051 for around 8 at Digikey or some other vender, but if i want 100,000 i can assure you the C8051 becomes a lot cheaper than i can an Arm.

One thing I find a lot of people think "if you have the processing power available, build it in?"

[Bored@Work]

Why would anyone, today in 2011., choose an 8 bit microcontroller for his project?

Well it is 2011,

Did you notice that "john" wasn't active in the forum since March?

[ToBeFrank]

Looks like NXP is going after more of the 8 bit market:

NXP Semiconductors N.V. (NASDAQ: NXPI) today announced the availability of new low-pin-count package options – SO20, TSSOP20, TSSOP28 and DIP28.
...
Starting at $0.49, NXP’s low-pin-count devices deliver 50 MIPS of performance compared to the 1 to 5 MIPS performance typical of 8/16-bit MCUs, at a highly competitive price point enabled by NXP’s exceptional capacity in manufacturing high-volume commodity packages.

From http://www.nxp.com/news/press-releases/2011/10/nxp-cortex-m0-microcontrollers-in-high-volume-tssop-and-so-packages-target-8-16-bit-applications.html

[Mechatrommer]

well the other thread saying arm is going "dip sot" too.

[lightdiodedesignNEAL]

I've done some mega 8bit fun-code... To work through from the 90's, recently I've played with a lot of PIC!!!
  There's 2 x 8bit processors at work in this video...! 1 x 16F723@16Mhz and a 16F88 (the best 8bit & small!). The 723 has 192bytes of RAM, the 88 has 384.. The 64byte page also made things a bit tricky!!!

Working my way (through a few PIC16, PIC24s) towards the "new-to-me" PIC32 touchCap-demoboard (£16!!! Lots of pins!) I've still ordered a load of 16f887's recently, instead of using 7series logic gates or if I need async data transfer proxy... 8bit insn't really "easier" (64byte pages!) but being 5v friendlier helps and the PIC16's seem virtually indestructible!!!... The project I'm on also has some 24FJ64's for the "fancy graphics", so "Horses for courses"...!

My latest 16bit (PIC24FJ64GA102) demos are particle-sprites-digital-clocks.... The "horse for course" of having built in RTC was more a consideration than 8vs16vs32 bits...!

Not only are 8bit MCU still *very* useful, using FPGA 8bit "Virtual processors" vs 16 will obviously save gates... 4bit MCU are possible using 7series gates, but that's a bridge too far for me!!!

Hello!!! I still love 8bits!
NEAL

[Stephen Hill]

Why would anyone, today in 2011., choose an 8 bit microcontroller for his project?
There are lots of small, very cheap, low power 32 bit devices on the market (like for example Cortex M0 series). I don't mean just 32 bit ARM CPUs, but also all others like AVR32, TMS320C2000 series, PIC32, and many others...

What's wrong with you people? 

I think everyone should be buying and driving super cars. You can get them for 3-4 times the prices of a normal car. They are way faster and state of the art. It doesn't matter that they're not very practical, everyone should have one.

What's wrong with you people!!!

[Psi]

I think everyone should be buying and driving super cars. You can get them for 3-4 times the prices of a normal car. They are way faster and state of the art. It doesn't matter that they're not very practical, everyone should have one.

What's wrong with you people!!!

that's not really true, a 32bit ARM micro costs the same as a medium spec 8bit atmega

[JuKu]

But for a 8 bitters, the megas are mega-expensive.

[T4P]

Megas are expensive 8 bitters , the PIC32MX series is a small flop since it's according to some review not very good at all .
The best one is ARM , i've seen a arm chip at 5$ .

[amyk]

ARMs and more powerful MCUs still can't compete with things like the 8051-based chips which are <$0.25 packaged and ~$0.10 in bare die (for COB mounting). There is still a cost advantage in not using more MCU than you need for a particular application.

For the same reason you still see 4-bit MCUs in really ultra-low-cost stuff - those are <$0.01 in large quantities (mask ROM w/ 64 nybbles, 16 nybbles of RAM, bare die for COB) the last time I looked.

[T4P]

ARMs and more powerful MCUs still can't compete with things like the 8051-based chips which are <$0.25 packaged and ~$0.10 in bare die (for COB mounting). There is still a cost advantage in not using more MCU than you need for a particular application.

$0.25 ? No . Only in massive quantities .
This . Is the real future of ARM .
http://sg.element14.com/freescale-semiconductor/mcf51qe32lh/mcu-32bit-32k-flash-8k-ram-v1-64lqf/dp/1561464

[westfw]

>> "Only in massive quantities ."
That's what drives the market...

Meanwhile, I expect to be using 8bit cpus for quite a while, because they're easier to use.  Even if that only means two 5V power connections and 20mA output drive instead of four 3.3V power connections plus a filter cap for "Core voltage" and 8mA output drive.

[olsenn]

Another point worth making is that 8-bit microcontroller have less to them (from an ASIC point of view) which makes them (usually) less buggy and easier to understand. The more primitive something is, the easier we can master it

[westfw]

>> The more primitive something is, the easier we can master it

"The more advanced something is, the less we NEED to master it."

That's the bottom line: "why are you struggling to fit your modern algorithm into an 8bit, 16 mip, 32kbyte flash, cpu, when you could get a 32bit, 50 mip, 256kb flash CPU for about the same price?"
And the answer is "I'm not struggling; my algorithm is trivial even on the 8bit CPU, 32k is a lot of flash, and why are YOU sending a 4-layer PCB to fab for your 100pin LQFP and struggling with noise, EMI, and other issues, when you could have built a prototype on a protoboard last week?"

[jerry507]

Peripherals matter, the CPU is essentially just required to make the thing work. I don't care if it's 8 bit, 16 or 32.

[bfritz]

I heard that excuse couple of times, and I think it's a quite a lame excuse...
How do you define "overkill"? What do you get when you use 8 bit instead of 32 bit? Many 8 bit CPUs are actually more expensive than 32bit, so cost is not the issue (and even if it costs 2-3$ more,  it's hardly an issue for hobby projects)... So, what is?

When you write software, there is no such thing as "too fast" CPU 

Do you know why that portable device you were swearing at died the other day?  Because some guy who only writes software and doesn't understand that twiddling 32 bits to do simple integer math required for many solutions is consuming 4x the power, and getting no extra work or speed.  I've acually designed systems that use a uP with a 32KHz clock, because they didn't really have speed sensitive tasks, and it was easier to get things done slowly and never stop, than to use a more sophisticated micro, and generate interrupts and have a timer to wake at regular intervals, etc.

So, one reason would be power consumption.

Another reason is cost.  I design stuff that often gets built in the millions per year.  If I can get the job done with a $0.35 uP, I'm sure not going to choose a 16 or 32 bit device if the computing cycles aren't needed.

That is what engineering is about.  In the real world where I get paid for what I do, meeting the requirments is what designing a solution is about.  If I use more components, a faster processor, more costly BOM, and get it done faster than needed my company doesn't applaud me.  Engineering is about meeting the requirement, and lots of time that requirement includes goals like power consumption, and cost.

[slateraptor]

@bfritz: You're raging against a user who hasn't been active since March 3, 2011 on a thread that's over a year old...just a friendly FYI heads up.

[markus_b]

Peripherals matter, the CPU is essentially just required to make the thing work. I don't care if it's 8 bit, 16 or 32.

I very much agree, in my latest project I'm starting out with an xmega, 8bit, because I need the USB, ADC, DAC and eeprom, a combination I have not found elsewhere on the same chip.

A second argument is flexibility in supply voltage. Most >8bit micros take any supply voltage as long as it is 3.3V. I many cases I like to power a gadget directly from two AA cells with no (energy wasting) power regulator.

[ToBeFrank]

Another reason is cost.  I design stuff that often gets built in the millions per year.  If I can get the job done with a $0.35 uP, I'm sure not going to choose a 16 or 32 bit device if the computing cycles aren't needed.

Ohhhh, so you're the reason we have a thread ranting about bad caps.  (if it's not obvious, I'm totally joking)

[T4P]

I know 32bit micros have more power and yet use more computing cycles .
So therefore in a power starved situation it's either 8bit or 16bit .
But 32bit chips have been getting ridiculously cheap , like the one i posted that one is a 68-type 

[westfw]

>> like the one i posted that one is a 68-type ($0.79 mcf51qe32)

Pricing anomalies are always cheaper.  I can't find those for less than about $3 (and mostly $4+) at us distributors...

I'd so like a 50MHz coldfire Arduino-like system.  The 68k is a nice architecture; not as weird as ARM.
But the world needs "yet another CPU type on an Arduino formfactor" like it needs another bad TV sitcom...

[T4P]

>> like the one i posted that one is a 68-type ($0.79 mcf51qe32)

Pricing anomalies are always cheaper.  I can't find those for less than about $3 (and mostly $4+) at us distributors...

I'd so like a 50MHz coldfire Arduino-like system.  The 68k is a nice architecture; not as weird as ARM.
But the world needs "yet another CPU type on an Arduino formfactor" like it needs another bad TV sitcom...

Indeed . there's been some serious anomalies .

[jpelczar]

I guess for the same reason people still use 74XX or even 555 ICs. They could easily be replaced with cheap CPLDs, but they're proven to work for decades and they will probably be there 20 years later.

[westfw]

You know, I've looked at making a 555-replacement "super-timer" out of one of the tiny microcontrollers, and it's not nearly as easy as you might think, once you notice the 4.5-16V supply and 200mA output drive.  Heck, a lot of the voltage regulators used in modern circuits don't have that wide of an input range...  The same sort of thing is true of 8-bit microcontrollers; no matter how you look at it, a chip with a 1.8-5.5V supply range is more flexible (by some measure) than a chip with a 3.0-3.6V supply range...

[Kjelt]

I still use them cause I have over 300 pieces laying in a drawer, i use what I have unless its insufficient.

[dannyf]

Why are you still using 8 bit MCUs?

One reason could be software: too expensive to port existing software to a new platform.

[garak]

This is ludicrous. Why are 8-bit chips still used? Ever heard of KISS? Making things more complicated than they need to be generally means that they're more susceptible to failure, take longer to develop and cost more to produce. Simple! There's also issues of power consumption etc to look at, nevermind the costs of porting an existing design to a new architecture.

My most recent commercial outing with an 8-bit device was in some product-specific test gear in order to generate a couple of simple waveforms. Sure I could have gotten a 32 bit device and done it with that, or I could have selected a dedicated waveform generator or any number of other solutions. However, the results from the PIC I used were more than acceptable so why the bloody hell would I use anything else? Especially since the chip only cost about $0.50!

[Psi]

This thread title taunts me every-time someone posts and brings it to the top.

I use 8bit mcus because i want to, stop asking me the question

[mrflibble]

I use 8-bitters because of the peripherals they happen to have at a certain price point. If for the rest everything was the same, I'd pick 32-bit because it's more convenient. But if you can get real cheap 8-bit chippies with just the right peripherals for the right price, and can't find the 16/32-bit equivalent ... 8-bit it is.

[WarSim]

I use whatever is cheapest for the task.  Even when it is DIY and cost is mostly my choice rather that production cost.  Doesn't make sense to spend a dollar more when production cost are about pennies.  Right tool for the job is what it is all about. 

BTW My cost mantra has pushed me up the bit ladder on a few occasions.  Just happened to find a 16bit chips with the features I needed that sold for less that the same features in an 8bit chip.  Doesn't happen often. 

One argument I have yet to understand is the statements that using a smaller chip makes the task harder.  Makes no sense to me. A chip that is big enough is big enough.  No idea how a bunch of extra room or extra features make the task easier.  Different experiences I guess. 

[dannyf]

One argument I have yet to understand is the statements that using a smaller chip makes the task harder.

Maybe it was referring to the difficulties to shrink your code to fit into a smaller chip; or to use limited peripherals to perform a difficult task (like doing adc without an adc module), etc.

It makes perfect sense to me.

[dannyf]

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? ...

[dannyf]

I’ve yet to see a stunning endorsement for any 32b C compiler that doesn’t cost several thousand dollars.

As a Keil/IAR user, I could recommend CoIDE/gcc-arm as a competent alternative, if the mcu you use happens to be the one supported by CoIDE.

I also know what PITA open source software can be.

While they can be PITA, they don't have to be PITA and some of them aren't PITA.

[elcomtel]

This must be one of the most silly forum subjects that I have come across recently. 

It's all a matter of 'horses for courses'.

I don't want to get drawn into a discussion, but those who really know their stuff know exactly what they are doing. Those who pretend they know what they are doing will send off a lot of 'smoke screens' to hide their incompetence.

Any solution is a good solution as long as the designer can backup their methodology with sound reasoning. It's all about innovation and the level of your creativeness. There is nothing impressive about solving challenges when you are highly resourced. It takes a lot more ingenuity to set up a communications network in Sub-Saharan Africa than to the same in the developed world.

So I don't give a damn if you use an 8 bit micro or a 64 bit micro...who cares?

[mrflibble]

I did recently get a STM32DISCOVERY I want the speed basically. I’m hoping I can get away with using one of the limited professional compilers.

GCC + eclipse + openocd/stlink works fairly well IMO. But setting up the toolchain did take some mucking about.

[mrflibble]

This must be one of the most silly forum subjects that I have come across recently. 

I take it you managed to steer clear of the politically tinted threads?

[AlfBaz]

I could recommend CoIDE/gcc-arm as a competent alternative

I was having a quick look at that not long ago. One of the main bullet points said it was "internet based". Should I have read on or is this some off pc compiler?

[WarSim]

One argument I have yet to understand is the statements that using a smaller chip makes the task harder.

Maybe it was referring to the difficulties to shrink your code to fit into a smaller chip; or to use limited peripherals to perform a difficult task (like doing adc without an adc module), etc.

It makes perfect sense to me.

Yes obviously using an unsuitable chip makes the task harder, I have always agreed with that.  I do agree that crushing code size by more than 20% could be challenging in some cases.  To keep from quoting the statement completely I used the term smaller not intending to include too small.  Other items that where excluded was.  Not using bloated code in development, and applying program/system analysis techniques.   

My final response to the argument has always been.  Big enough is big enough who cares if it is bigger than enough.  Apparently others disagree. 

Tangent :

I also understand there are challenges in using limited resources.  Several hobby projects have been to accomplish "impossible" tasks.  About once a year I find a paper stating that say something is not possible and I disagree, so I do it.  Yes these projects are more difficult but I take these on for the challenge.  For example using a PIC as a controller of a LCD with just shift registers.  Even Ben Heck suggested it was not possible then qualified his statement saying it was difficult and not time efficient.  I agree my hobby tasks are rarely time efficient.

Some people still don't get when you say; always, never, all, none, everyone, nobody, must or impossible.  You will inevitably be proven wrong. 
I like the statement.  The impossible is not impossible it's just harder. 

[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.

[free_electron]

So you'd need to sell 2000 units before making a profit.

come back when you are doing millions of units. the beancounters will nibble you to death.

[ddavidebor]

Why 8 bit?

I'm asking myself why i can't find 4 bit mcu ;-)

[free_electron]

Why 8 bit?

I'm asking myself why i can't find 4 bit mcu ;-)

4bit is for wimps.

1 bit is the clear winner ! MC14500

http://en.wikipedia.org/wiki/Motorola_MC14500B

[c4757p]

4bit is for wimps.

1 bit is the clear winner ! MC14500

http://en.wikipedia.org/wiki/Motorola_MC14500B

Aren't there easier ways to commit suicide?

[westfw]

easier ways to commit suicide?

Hardwired ECL logic.

[c4757p]

No, easier, not just more reliable.

[Harvs]

Why 8 bit?

I'm asking myself why i can't find 4 bit mcu ;-)

4bit is for wimps.

1 bit is the clear winner ! MC14500

http://en.wikipedia.org/wiki/Motorola_MC14500B

Wow, I just had a look at that.  The guy who wrote that has got a VHDL model for it.  It's one clocked process that spans roughly one page!

[Kjelt]

Hehehe seven years ago i contacted a chinese 4 bit microcontroller salesperson who offered micros for less then 6 cents. My projectleader was interested so i investigated. The reason they were so cheap was that they were designed for toys and this was the fifth baddest selection of the product , there were in the final test more then 30 of the 128 bytes  of RAM corrupt, but on each device different ofcourse. On my question how you can work with that the manufacturer said to write test code in beginning of progam to test which cells were bad I told my projectleader then to go and @&€&@€& and do it himself but he already got the point.

[AndyC_772]

The point about cost is a very valid one, though. If a 6 cent processor can be made to work, and all it needs to do is make a toy go 'pow' or 'zap' depending on which button is pressed, then it's really not a bad solution. If the nearest PIC that could do the job is, say, 60 cents, then it's immediately priced itself out of the market.

On several occasions I've found myself needing to design a processor into an extremely low cost product, and I've struggled to find parts much below, say, $0.50 even in decent volume. I know there are plenty of Far Eastern manufacturers of cheap microcontrollers, but they have no presence in Western markets - no distributors, no technical support, and in some cases, no English data sheets.

Has anyone ever been called upon to design a toy, or a TV remote, or some other similar device that will sell in vast numbers but has a parts budget <$1? How did you go about it? Whose parts did you use?

[Abstr7ct]

Maybe irrelevant, but in my area where there is no distributor of 8-bit MCUs, I find a PIC18FXXX MCU costs as high as 30$.

[WarSim]

PIC24F, PIC24E, dsPICF

They are essentially the same.

Yup, they are just different speeds and RAM really,  I still picked three chips one from each to have on hand. 

[WarSim]

The point about cost is a very valid one, though. If a 6 cent processor can be made to work, and all it needs to do is make a toy go 'pow' or 'zap' depending on which button is pressed, then it's really not a bad solution. If the nearest PIC that could do the job is, say, 60 cents, then it's immediately priced itself out of the market.

On several occasions I've found myself needing to design a processor into an extremely low cost product, and I've struggled to find parts much below, say, $0.50 even in decent volume. I know there are plenty of Far Eastern manufacturers of cheap microcontrollers, but they have no presence in Western markets - no distributors, no technical support, and in some cases, no English data sheets.

Has anyone ever been called upon to design a toy, or a TV remote, or some other similar device that will sell in vast numbers but has a parts budget <$1? How did you go about it? Whose parts did you use?

The PIC10F220 can be had for 0.14 in moderate lots.  who knows how cheep they get in huge lots. 

[dannyf]

some other similar device that will sell in vast numbers but has a parts budget <$1?

In some parts of the world, there numerous mcus (some brand names) that sell for less than $0.16 each.

[nctnico]

Has anyone ever been called upon to design a toy, or a TV remote, or some other similar device that will sell in vast numbers but has a parts budget <$1? How did you go about it? Whose parts did you use?

A couple of months ago I co-designed a device which falls in that category. We used an MSP430. It needed the least external components and had the lowest power consumption so the battery could be much smaller (and cheaper).

[amyk]

Hehehe seven years ago i contacted a chinese 4 bit microcontroller salesperson who offered micros for less then 6 cents. My projectleader was interested so i investigated. The reason they were so cheap was that they were designed for toys and this was the fifth baddest selection of the product , there were in the final test more then 30 of the 128 bytes  of RAM corrupt, but on each device different ofcourse. On my question how you can work with that the manufacturer said to write test code in beginning of progam to test which cells were bad I told my projectleader then to go and @&€&@€& and do it himself but he already got the point.

This is actually quite common at the ultra-low-end: devices that are not 100% functional, but where the intent is that you don't actually use 100% of the functionality in your product. I've seen a design where a particular output could be jumpered using solder pads to one of several I/O pins - the firmware is written to set all of them to the same value, but the MCU is imperfect and so on assembly/test they choose a pin which works. It makes sense to the MCU company as they can make saleable product out of die which would otherwise be scrapped.

Microchip does this "sell as-is" with their PICs in China; look up CF745 and CF775 if you want more info.

[AndyC_772]

some other similar device that will sell in vast numbers but has a parts budget <$1?

In some parts of the world, there numerous mcus (some brand names) that sell for less than $0.16 each.

This is exactly what I'm getting at - but can you name any specific examples who will provide developer support and tools in the UK?

It's OK to forgo some of the nice features that might be expected in 'mainstream', western market products. It's OK to for the part to be OTP rather than Flash based, for example. I can probably do without debug features, provided there's a reprogrammable version of the device I can prototype with. Heck, if they're cheap enough, I can buy a hundred of them and a ZIF socket.

I've seen plenty of parts that aren't marked with any kind of manufacturer's logo - that's fine - and I know they're often available untested. Even that may even be OK; provided most of them work, the odd unit off the line which doesn't go 'zap' or 'pow' when prodded can be reworked.

[Rufus]

for less then 6 cents. My projectleader was interested so i investigated. The reason they were so cheap was that they were designed for toys and this was the fifth baddest selection of the product , there were in the final test more then 30 of the 128 bytes  of RAM corrupt, but on each device different ofcourse. On my question how you can work with that the manufacturer said to write test code in beginning of progam to test which cells were bad I told my projectleader then to go and @&€&@€& and do it himself but he already got the point.

And if parts with all the RAM good cost $0.16 and you are going to buy a million you have a $100,000 budget to write that test code. Doesn't sound like whatever point was given and got was the right one.

[nctnico]

I've seen plenty of parts that aren't marked with any kind of manufacturer's logo - that's fine - and I know they're often available untested. Even that may even be OK; provided most of them work, the odd unit off the line which doesn't go 'zap' or 'pow' when prodded can be reworked.

The interesting question here is whether you can test chips cheaper than the manufacturer can. And even then chances are you end up with devices which failed testing so many of them may be useless. So if you go down that road you probably need to make sure the supplier can guarantee a certain percentage of working devices.

[dannyf]

who will provide developer support and tools in the UK?

No idea about the UK. Taiwanese companies are very aggressive at the low-end of the market (toys, washers / dryers, etc.). Some of their high-end vendors (relatively speaking), like Holtek, do provide tools. Haier (a Chinese company) provides tools if you contact them. Some start-ups, like LogicGreen, provide samples / tools upon request.

ST also markets their STM8 chips very aggressively so that's another possibility.

[AndyC_772]

The interesting question here is whether you can test chips cheaper than the manufacturer can. And even then chances are you end up with devices which failed testing so many of them may be useless. So if you go down that road you probably need to make sure the supplier can guarantee a certain percentage of working devices.

Agreed, although there's also the important question over what constitutes a test pass vs fail.

The manufacturer must fail a chip if any feature doesn't work as per the data sheet spec, but in a given application that may be unnecessarily harsh. Perhaps I don't care if a couple of the ADC channels don't work, because I'm not using them anyway. Maybe the pin I'm using as a switch input doesn't actually work as an output, but again, not a problem in my circuit. The manufacturer's yield might be, say, 70% of parts meeting the spec in its entirety, but as far as my product is concerned, 98% of them might be usable.

Don't get me wrong, I don't like the idea of making any product with defective components, but I can see the economic argument for it right at the bottom end. If the end product has to be tested anyway, and especially if a handful of customer returns can be tolerated, then maybe there's no need to test the chip itself at all as a separate step - just replace it if the product coming off the line doesn't work.

No idea about the UK. Taiwanese companies are very aggressive at the low-end of the market (toys, washers / dryers, etc.). Some of their high-end vendors (relatively speaking), like Holtek, do provide tools. Haier (a Chinese company) provides tools if you contact them. Some start-ups, like LogicGreen, provide samples / tools upon request.

ST also markets their STM8 chips very aggressively so that's another possibility.

Thanks for the suggestions - I might start with ST and go from there.

[SeanB]

Intel does that with Pentiums and Celerons, the ones with cache bit errors are masked out to remove the half of the cache that is bad and sold cheaply. Same with clock speed, they are binned into speed grades and sold as such.

[AndyC_772]

Well, yes, but that's not quite the same thing from the end customer's perspective. What they're selling is a fully tested, guaranteed part which happens to have lesser (but known) specification, not an example of the 'full' device which may or may not work.

[Kjelt]

And if parts with all the RAM good cost $0.16 and you are going to buy a million you have a $100,000 budget to write that test code. Doesn't sound like whatever point was given and got was the right one.

The biggest issue was probably the unknown factor with these chips, is the defective areas a onetime issue at production or an ongoing one with a bad process and parts of the uC failing in the near future. I work for a company that literally guarantees some products for 60000 + hours at temperatures of 90 C. We buy elco.s that cost a multiple of this to guarantee that lifetime. But then the specs of these components are guaranteed by he supplier. Needless to say that the chinese manufacturer had little guarantees to give 

[WarSim]

And if parts with all the RAM good cost $0.16 and you are going to buy a million you have a $100,000 budget to write that test code. Doesn't sound like whatever point was given and got was the right one.

The biggest issue was probably the unknown factor with these chips, is the defective areas a onetime issue at production or an ongoing one with a bad process and parts of the uC failing in the near future. I work for a company that literally guarantees some products for 60000 + hours at temperatures of 90 C. We buy elco.s that cost a multiple of this to guarantee that lifetime. But then the specs of these components are guaranteed by he supplier. Needless to say that the chinese manufacturer had little guarantees to give 

Same with all industries.  I have used a $600.00 5/16 2.5" steal bolt before because lives depended on it.  If you need assurances then it costs.  If you don't need assurances you can save money. 

Take the toy idea.  A kid left a top at work.  It had 4 lights that flashed for a persistence of vision effect.  It had 6 LEDs, passives, a switch, a bare uC and a battery.  The uC would PWM the LEDs for different patterns.  Apparently new only 4 LEDs ever lit up and before the battery died another died.  This toy was still sold and played with by a child and adults after being abandoned at work.  This is the type of product that receives these cheep uCs.  Build it, if more than half of the lights work full price.  if less discount for dollar stores.  If all light up then mark it up as a rare collectors item.  It would be silly to put a 50 cent verified chip in a 99 cent toy.  It would take away the profit. 

[cloudscapes]

Lets say I only need to read a pot and control some LEDs and/or a relay.

Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576

That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.

I can't believe this thread even made it past 2 pages.

[AlfBaz]

Lets say I only need to read a pot and control some LEDs and/or a relay.

Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576

That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.

I can't believe this thread even made it past 2 pages.

32bits for that?!?
You could do that task with a handful of discretes for the cost of your decoupling caps alone

[WarSim]

Lets say I only need to read a pot and control some LEDs and/or a relay.

Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576

That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.

I can't believe this thread even made it past 2 pages.

32bits for that?!?
You could do that task with a handful of discretes for the cost of your decoupling caps alone

Yea but a 64bit uC would be stilly. 

[mariush]

Lets say I only need to read a pot and control some LEDs and/or a relay.

Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576

That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.

I can't believe this thread even made it past 2 pages.

Why the hell would you use a pic32 for that ?!  A PIC10 or a PIC16 should be available for under $0.5 and do the job.

[valdas]

I think because of quantity of tutorials most of 8bit users are beginners. I also started with atmega, then moved to arm. But still i have loads of atmega8 and they are cheap as hell

Because a lot of those are overkill for smaller projects. There's no point to using something that powerful unless you actually need it. Just because it's 8 bit doesn't mean it's useless.

[AndyC_772]

Lets say I only need to read a pot and control some LEDs and/or a relay.

Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576

That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.

I can't believe this thread even made it past 2 pages.

Cheapest Kinetis (ARM Cortex M0+) part on Mouser, qty 100, $0.87

Not quite such a big gap in price now! Also the ARM device is in a 24 pin package, so you're getting a lot more I/O which you'd have to pay for even with an 8 bit core.

Try comparing like-for-like in terms of I/O count and peripherals, and I reckon you'll be surprised just how little difference there is between 8-bit and 32-bit these days. Unless you're buying untested, near-junk grade chips, of course!

[Vasi]

The best use of a PIC32 microcontroller:
 - Maximite BASIC Interpreter (with Maximite Color board);
 - PIC32Lua Lua Interpreter (with ChipKit MAX32 board);
 - RetroBSD UNIX;
Writing tons of BASIC and LUA programs stored on SD-Card without wearing the microcontroller and still having a faster microcontroller for home automation, logging and whatever...

 - StickOS (but with this, the uC  is wearable);

For anything else, an 8bit AVR is more than enough (It can act as a 5V, hardware interface between sensors/actuators and the PIC32 board with one of the above systems installed).

[GeorgeHahn]

The best use of a PIC32 microcontroller:
 - Maximite BASIC Interpreter (with Maximite Color board);
 - PIC32Lua Lua Interpreter (with ChipKit MAX32 board);
 - RetroBSD UNIX;
Writing tons of BASIC and LUA programs stored on SD-Card without wearing the microcontroller and still having a faster microcontroller for home automation, logging and whatever...

 - StickOS (but with this, the uC  is wearable);

For anything else, an 8bit AVR is more than enough (It can act as a 5V, hardware interface between sensors/actuators and the PIC32 board with one of the above systems installed).

I agree with you on running interpreters - they can be a ton of fun! Problem is, running an interpreter is going to handicap your fancy 32 bit micro and increase your power consumption.

What I'd like to see is a benchmark of embedded interpreters by speed & power.

[dirtyfly]

I use them mainly because of the packaging. Simpler achitecture and because I grew with them.

[ZeroStatic]

I still use 8 bit mpu for price, power consumption and package size.
Most thing I use 8 bit for are very simple applications that only need a tiny amount of computing power.
Often times I use an 8 bit MPU as a remote I/O handler for a 16 or 32 bit MPU.
It's a case of using the right part for the right application, that's why they still make and sell millions of 8 bit MCU every year.

It hardly needs a 32bit processor to raise and lower a garage door with 2 relays controlling the motor.
It would be wasteful to put a 32 bit processor into a clock/radio.

I will keep on using 8 bit when it suits and 32 bit when it fits best.

Brenden

[Rellum]

Recently I took a freescale FRDM-KL25z devel.board launch event and for God Sake , what was that ? The IDE sucks, unstable , not free at all (just for small projects), heavy as a mamute,  tons of register options to be set. A simple blink program was amazingly complex. So , want something simple , free and efficient ? use 8 bits. Want to teach uc ? use 8 bits. And people still ask why the vast majority of mere mortal use 8 bits. Because nobody has to take a Phd in CS to develop a simple motor control ! Arduino surpassed that a long time ago. We need to go further.Not to go backwards. KISS is the best philosophy to be taken. By the way,  for those who love ARM , I didn't see any mention anywhere regarding the ARM Accredited Engineer program (AAE). Has anybody already took a look at that ? Gosh , how many years you are supposed to study all that ? 

[dannyf]

what was that ? The IDE sucks, unstable , not free at all (just for small projects), heavy as a mamute,  tons of register options to be set. A simple blink program was amazingly complex.

Their tools are expensive, their chips expensive (and hard to source), their support is practically non-existent, and their software sucks.

Yet, Freescale + Renesas absolutely dominate the global mcu markets.

Why? Because they don't want people who are interested in blinking leds.

[Valueduser]

I heard that excuse couple of times, and I think it's a quite a lame excuse...
How do you define "overkill"? What do you get when you use 8 bit instead of 32 bit? Many 8 bit CPUs are actually more expensive than 32bit, so cost is not the issue (and even if it costs 2-3$ more,  it's hardly an issue for hobby projects)... So, what is?

When you write software, there is no such thing as "too fast" CPU 

I define overkill as having more processing power than is required for the specified task.  Another factor is future availability as well as platform maturity.  If I design a system based on a z80 I can reasonably assume that it will be easy for others to service and develop for.  As far as I'm concerned, cost is always an issue.  If I can get an 8 bit chip for a project that is cheaper than a 16 bit chip and provides the same functionality, I would rather put the extra money towards a different project.

[cloudscapes]

Lets say I only need to read a pot and control some LEDs and/or a relay.

Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576

That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.

I can't believe this thread even made it past 2 pages.

Why the hell would you use a pic32 for that ?!  A PIC10 or a PIC16 should be available for under $0.5 and do the job.

That was exactly my point! You save $120 if you go the smart route at choose the $0.5 8bit micro!

[cloudscapes]

Lets say I only need to read a pot and control some LEDs and/or a relay.

Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576

That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.

I can't believe this thread even made it past 2 pages.

Cheapest Kinetis (ARM Cortex M0+) part on Mouser, qty 100, $0.87

Not quite such a big gap in price now! Also the ARM device is in a 24 pin package, so you're getting a lot more I/O which you'd have to pay for even with an 8 bit core.

Try comparing like-for-like in terms of I/O count and peripherals, and I reckon you'll be surprised just how little difference there is between 8-bit and 32-bit these days. Unless you're buying untested, near-junk grade chips, of course!

Fair-enough, price wise, I hadn't looked into ARM.

But still, I don't even know how to use ARM. And a year ago didn't know how to use 32bit micros at all. There's still a learning curve for architecture you're not familiar with. Why bother spend weeks and money learning new architecture when your 8bit micro can read a pot just fine!

Different hardware for different needs.

Even today, knowing how to use a PIC32, I still wouldn't use it for everything. The smallest PIC32 is 28-pins, so I spend a lot more board realestate. Your point about getting a lot more IO is true, of course, but what if I don't need more IO? For some of my projects, all I really need is literally 2 or 3 IO. I'm not going to use a 28pin PIC32 nor am I going to learn ARM just for a simple task.  Eventually, I will, but not now if I can use an 8pin AVR and get it doing what I want in an hour.

[AndyC_772]

Fair comment - I use 8 bit PICs a lot, but increasingly the only reason to do so is familiarity. I know I can chuck a PIC on a schematic and have it programmed to do something simple in a matter of hours, whereas programming the more complex peripherals in a 32 bit processor is likely to take longer.

However, I'm also very conscious that if I need a few more pins, an ARM based micro is not only a great deal faster, but it actually costs less than an 8-bit PIC with the same number of pins and similar peripherals. Commercially speaking - which I often am, as I do this stuff for a living - there is no reason to use the PIC at all unless development time is the critical factor.

[ben_r_]

Still using 8-bit PICs here too. Cheap and easy/quick for me to implement. I dont think they are going anywhere anytime soon.

[senso]

It could be the need for 5v tolerating devices, one attiny85 can work at 5v, can those arm's output 5v at 30-40mA in each pin?

[westfw]

Recently I took a freescale FRDM-KL25z devel.board launch event and for God Sake , what was that ? The IDE sucks, unstable , not free at all (just for small projects), heavy as a mamute,  tons of register options to be set. A simple blink program was amazingly complex.

YMMV.  Recently I bought some "Teensy3" boards that use a freescale ARM CM4.  The Arduino "Blink" sketch ran fine with essentially no modification.  The Teensy3 has 4 times the flash, 8 times the RAM, is about 3x faster, and has more IO than it's 8-bit brother the Teensy2.  It costs about 20% more.

(That said, I'm a firm believer that "the death of 8-bit processors" is not coming anytime soon.)

(you WOULD think that the vendors who are offering small (4k flash) CM0 "8bit replacements" would be spending more time producing small libraries and init code not based on bloated "frameworks", wouldn't you?  Sigh.  Arduino is potentially a reasonable example, except that their ARM code runs on top of Atmel Bloatware...)

[AndyC_772]

It could be the need for 5v tolerating devices, one attiny85 can work at 5v, can those arm's output 5v at 30-40mA in each pin?

Freescale has you covered:

http://media.freescale.com/phoenix.zhtml?c=196520&p=irol-newsArticle&ID=1843350&highlight=

Not sure about the high current outputs, but they promise 5V operation and breadboard-friendly chunky packages.

[WarSim]

Fair comment - I use 8 bit PICs a lot, but increasingly the only reason to do so is familiarity. I know I can chuck a PIC on a schematic and have it programmed to do something simple in a matter of hours, whereas programming the more complex peripherals in a 32 bit processor is likely to take longer.

However, I'm also very conscious that if I need a few more pins, an ARM based micro is not only a great deal faster, but it actually costs less than an 8-bit PIC with the same number of pins and similar peripherals. Commercially speaking - which I often am, as I do this stuff for a living - there is no reason to use the PIC at all unless development time is the critical factor.

Speed cost power, extra power equals extra power used.  Yes I know most EEs don't care.  And I don't mind because it supplied me with a revenue streams for many years. 

[AndyC_772]

That's a discussion I had with a Freescale rep the other day. The actual power used per instruction executed on an M0+ core is, apparently, comparable to or even better than many 8 bit devices.

If you make use of sleep modes or slow down the clock during idle periods, the power consumption of the 32 bit processor to do an equal amount of work can actually be less than an 8 bit - and, of course, you have the extra performance available to you if you need it.

I was surprised too.

[WarSim]

That's a discussion I had with a Freescale rep the other day. The actual power used per instruction executed on an M0+ core is, apparently, comparable to or even better than many 8 bit devices.

If you make use of sleep modes or slow down the clock during idle periods, the power consumption of the 32 bit processor to do an equal amount of work can actually be less than an 8 bit - and, of course, you have the extra performance available to you if you need it.

I was surprised too.

Not what I read in the white papers a data sheets. 
Or maybe they are comparing deep sleep on a Freescale to a non XLP 8 bit processors.  Ignoring that 8bit and 16bit uC designed for micro power also have clock switching, doze, idle, sleep and deep sleep. Of course the function names change between makers.  In no way am I saying that Freescale doesn't have great power saving methods.  I am saying that the power saving methods that are made more important on a power hungry processor has also been applied to the lower power chips.  Besides last Ike I looked Freescale had some very small chips also.  I remember reading one data-sheet of a real slow chip with a low pin count a few year ago.  So Freescale to me is a varied  chip description. 
If it cost over $30,000.00 to get to a devices location the user wants it to last as long as possible.  Yes there is tidal, wind, solar, motion, etc energy to be had in some circumstances but they can only be relied upon to a certain point.  These are the type of conditions I was referring to with my low power response.  In my opinion anything that uses a battery should have a very low power budget.  A lot lower than what is common.  But that is my opinion, and few share it. 

[AndyC_772]

Yeah, what they don't tell you is how many instructions you need to perform a specific task. In actual applications they still can't touch 8 bit MCUs.

Eh? Unless *all* you're doing is accessing I/O peripherals, in which case I'd agree the 32 bit parts take a few more cycles because their peripherals tend to be more complex, a 32 bit core inherently takes fewer instructions than an 8 bit. That's why the extra bits are there at all! Just consider for a moment what the CPU has to do to in order to implement, say, a 16 bit add, or an 8x8 multiply, or to copy 128 bytes of data from one area of memory to another.

8 bit will remain popular because it's easy. The tools are mature, it's well understood and easy to fully understand every aspect of the chip. It's cheap, low power

All agreed - though the price difference (for comparable peripherals and I/O count) is much smaller than you might expect, and actually favours the ARM device in many cases. Compare some PIC18 vs STM32 parts in 100+ and see.

, and actually faster than ARM in many applications (see how fast you can toggle a pin with a 1mA power budget on say XMEGA vs. any ARM micro you care to mention).

If that's what your application requires, an XMEGA might be a better choice. Nobody's arguing about that.

ARM also needs licencing fees, which is why some manufacturers have gone in a different direction. For example Microchip's 32 bit PICs are MIPS based.

Have you actually compared prices like-for-like for similar devices? This is a completely bogus argument, ARM based devices are generally cheaper than PIC32.

PIC32 doesn't use MIPS because it's cheaper, it uses MIPS because it's older.

Finally, 32 bit is almost always going to cost more simply because you need more memory to store larger instruction words and data types, and more transistors to handle manipulating them. That's another reason I'm extremely sceptical about Freescale's claims - all things being equal if you need to do an add instruction on 32 bits instead of 8 it's going to require more energy.

All other things aren't equal, though. Which devices are you going to make on your latest fab process?

[dannyf]

In actual applications they still can't touch 8 bit MCUs.

I am curious as to what those applications are.

I think it is fair to say that for many applications, 32-bit mcus don't offer significant advantages, on an apple-to-apple basis. On the flip side, 8-bit mcus don't offer significant advantages over 32-bit mcus too. For example, 32-bit mcus typically consume 30ma run current, vs. 10ma or so for (most) 8-bit mcus. But that's due to the 32-bit mcus running at much faster clock speed. If you control clock speed, most ARM mcus consume less than 8-bit mcus on a current/Mhz basis - due to the use of newer processes.

To me, 32-bit mcus' advantage is mostly in its peripherals and software - which is to say that if you were to put those peripherals on an 8-bit mcu, I wouldn't hesitate using them as well.

[dannyf]

you WOULD think that the vendors who are offering small (4k flash) CM0 "8bit replacements" would be spending more time producing small libraries and init code

Agreed. This is where the chip oems are missing the boat. The 32-bit chips are considerably more complex than the 8-bit chips hardware-wise (they don't need to be), and they oems aren't making the software guys' jobs any easier to help facilitate the transition.

If 32-bit chips are to be successful in displacing the 8-bit chips, someone has to dumb-down the 32-bit chips to the level of an 8-bit chip programmer, via hardware and software.

[dannyf]

XMEGA vs. any ARM micro

I am actually surprised that anyone is using Xmega. In my view, any investment in it is wasted - I don't see much future for it.

[olsenn]

Sometimes 8-bit is all (or more than) you need. 32-bit is more difficult to program, less power efficient (often), often more buggy, and probably often more expensive

[dannyf]

Sometimes 8-bit is all (or more than) you need.

Agreed.

[mrflibble]

In actual applications they still can't touch 8 bit MCUs.

I am curious as to what those applications are.

Maybe for example led lighting on the cheap. The STM8S003F3 is EUR 0.46 at 100 units. For that you get 5 PWM channels + a 10-bit ADC multiplexed over 5 channels, and then some spare pins for UART etc. I wouldn't mind at all using a 32-bit arm for that (mainly for convenience of toolchain), but I can't seem to find a part that meets the requirements. So 8-bit mcu it is, purely because the 32-bitters are too expensive. Price target is 0.10 EUR per PWM/adc channel pair.

[David_AVD]

I am actually surprised that anyone is using Xmega. In my view, any investment in it is wasted - I don't see much future for it.

I found the XMEGA to be perfectly fine for my first foray into Atmel micros.  I've just done another board design with one.

[Rufus]

PIC32 doesn't use MIPS because it's cheaper, it uses MIPS because it's older.

The PIC32 uses MIPS because Microchip didn't see any money competing in the cut-throat ARM cored processor market.

They claim the MIPS core uses a bit less silicon for the same performance and I am sure their licensing fees will be attractive.

All the ARM zealots rave about how they cost peanuts - means all the manufacturers are working for peanuts.

[brabus]

A quick answer to the original question.

John, if you want to play alone at home, I agree: have fun with your 32 bit MCU, make the LED blink at 100 MHz, while you pilot a color TFT touch screen display.

Serious production, however, is a different world, and there is a good reason if all those 8-bit families are still alive and rocking. 

We are going to see 8-bit MCUs in the market for a looong, looooong time...

[JTR]

A quick answer to the original question.

John, if you want to play alone at home, I agree: have fun with your 32 bit MCU, make the LED blink at 100 MHz, while you pilot a color TFT touch screen display.

John left the building over 2 1/2 years ago. Just a few days after his hit and run trolling. Probably on a tropical beach somewhere with a cold beer in one hand and a hot babe in the other laughing his head off...

[Vasi]

This is how you interface 5V sensors and actuators to a Sitara AM3359AZCZ100 (ARM Cortex-A8) via an 8bit AVR:
Arduino TRE

So I think this is the right answer to the OP.
In fact, it means much more if they will take the right decision and add 1024Mb instead of 512Mb of RAM. It will be a great Linux computer with AVR hardware inside and amazing interfacing capabilities.
Who want one ? ? ? I need one ASAP!

[ju1ce]

Do you use debuggers with 8-bit micros? I find Cortex-M0's much nicer than for example ATMegas because I can easily see what's happening. I think 32 bit micros are about as easy to program as 8-bitters - while 8-bit controllers are simpler, the 32-bit ones have nicer peripherals which make my life a lot easier.

On the other hand, if I were building something really simple, like some PWM controller, I would use a 8-bit micro. I wouldn't need debugging for that, and 8-bit micros come in DIP packages so I wouldn't have to have a board made.

[dannyf]

We are going to see 8-bit MCUs in the market for a looong, looooong time...

By that yardstick, 1-bit mcus are still alive and rocking too.

[Kjelt]

Both have their own turf, I can not imagine an 8 bitter doing a complete IP stack handling and controlling the rest of a device almost real time with an RTOS.

[gocemk]

IMHO and experience, 8-bit micros are much easier for programming (addressing registers, selecting I/Os, etc...) than their 32-bit counterparts from ARM. This is very important for someone who is just beginning to work with microcontrollers. Also the new, revised architectures, for PIC for example, are optimized for C programming, have low energy consumption features, and lots of other peripherals...I just finished my graduation work, which was 4DOF Robotic Arm, controlled via joystick.
All i needed was to read from 2 potentiometers, (2 channels from the AD converter), few push buttons to select the motors, and to read from 4 limit switches. The microcontroller i used (PIC18F45K22) was really an overkill for this kind of stuff, and many of it's features left unused. Should i have used STM32 or similar, just because it's 32-bit?!

[cloudscapes]

IMHO and experience, 8-bit micros are much easier for programming (addressing registers, selecting I/Os, etc...) than their 32-bit counterparts from ARM. This is very important for someone who is just beginning to work with microcontrollers.

Hugely important.

I started on 8bit micros in 2009. Wasn't a piece of cake but I kept at it. Had I started with 32bit micros right off the bat instead, I would have surely given up.

[WarSim]

I think I figured out one part of the disagreement. 
Comparing a new 32 bit chip power consumption to an old 8 bit chip could be better, just like power consumption on a new 8 bit is better than the old 8 bits.  This comparison would seem valid to someone that thinks 8 bit means old, and larger numbers in the part number means newer. 
Old 8 bit didn't have power saving methods like XLP, mXLP, dose, suspect etc.  Also microchip was smart with their new 8 bit product numbering just like the logic community.  The low power version part numbers where associated with their original market numbers.  Just like the J SL versions of logic.  So with just these two lapses of reality, yes a valid argument can be made for 32bit power consumption. 

I also noticed the disagreement changed from power consumption to power efficiency to cloud the point The one point that has validity for 32bit over 8bit is core voltage.  This topic was not mentioned once.  If Freescale is using 0.2v cores then yes they could be more efficient, until there is a 0.7v 8 bit chip.  As to port efficiency if I am using a PCI32 interface yes a 32bit chip would be a great choice.  But because of the drive to reduce design copper, intercommunication has been driven to serial, 4bit, 7bit, 8bit. 

 Cost debate.  The 32bit market is very competitive with very low margins.  One way to reduce costs is have a small active product span and evolving products.  In the consumer disposable mentality this could make sense to some.  In all other industries and many consumer goods sectors these methods are problematic. Microchip for example has taken a different approach.  They support each chip until it is deemed not required by its partners.  New chips are brought into the selection to satisfy new goals.  This system costs more but works better because it supplies the right chip for the task and maintains designer confidence.  They understand manufacturing and product life projections.  Other companies I am less sure, (aka I don't know).  Many be they all do understand but they have so few partners they can drop products faster. 

If anyone thinks that part substitution is only based on pin out and function.  I am not responding to you because you have already lost on this point.  Evolving a current part without significant partner participation is a big problem, and may be disastrous to the lesser partners, and opportunity consumers.  This is most likely you can still buy active products that are very close to the original design specs if not the same.  Hint, if the product site says not recommended for new design.  This means it is still active only because it is still needed to support previous designs.  If you use the part in a new design with a mid to long life then you are asking for trouble.  Other companies use this term for inactive products, Microchip uses the EOL term.  This is why there are so many chip available from Microchip and other like minded companies. 

Because of these factor yes you certainly find PICs that will use much more power than a low power 32bit variant.  TI still makes original and J logic this doesn't mean that SL series don't exist.  If you want to compare core efficiency select chips with equal core voltages.  If you want to compare power efficiency compare equivalent classes.  BTW due to the competitive market, marketing spins their figures.  The truth is only revealed until the entire data-sheet of both are fully digested.   

[tsmith35]

Personally, I like using 8-bit mcus because they're cheap, plentiful, and there are a ton of good programming examples out there for them.

[westfw]

The 32bit market is very competitive with very low margins.

Is this a good time to put on my accountant hat and point out that many of the vendors offering the low-end ARM chips are ... losing money?  EPS Atmel: -0.06, FreescaleL -0.69, ST Microsystems: -1.39, NXP: 0.38 (! that's new.  P/E 96+, though.)

Not that all 8-bit players are doing any better.  (many of those companies have feet in the 8bit market as well.)

[andyturk]

The main reason to go 32-bit (instead of 8- or 16-bit) is that you'll spend less time fiddling with algorithmic C code to make it work. 8-bit architectures often add restrictions to what you can do in C--compromises between what the language definition supplies and what the hardware can support. With a 32-bit ARM chip, the silicon is basically an engine that runs C.

If your code is simple, then you could spend less time with an 8-bit chip. But many projects nowadays have networking requirements (e.g., usb, bluetooth, ethernet, etc.) and network stacks are basically big piles of C code. Using up  your RAM or code space on networking stuff means you've got to spend more time optimizing everything else to shoehorn your software into a smaller mcu.

In the end, it comes down to which is more cost effective. Is it cheaper to spend engineering time to cram your software onto the cheapest piece of silicon that will run it, or is it better to use an architecture with some "headroom" and allocate your resources to other areas?

I'm working on a project now where we spec'd the biggest, baddest ARM Cortex M4 we could find for the first couple of prototypes. Later on, when get closer to production, we'll fit the hardware design to just what the software needs in order to run. We've got three code monkeys for each EE on the project, so software issues dominate the planning process.

[AndyC_772]

Is this a good time to put on my accountant hat and point out that many of the vendors offering the low-end ARM chips are ... losing money?  EPS Atmel: -0.06, FreescaleL -0.69, ST Microsystems: -1.39, NXP: 0.38 (! that's new.  P/E 96+, though.)

That sounds like the sort of confidential information I'd have expected manufacturers to want to keep very quiet indeed... mind if I ask where those figures came from?

[WarSim]

The main reason to go 32-bit (instead of 8- or 16-bit) is that you'll spend less time fiddling with algorithmic C code to make it work. 8-bit architectures often add restrictions to what you can do in C--compromises between what the language definition supplies and what the hardware can support. With a 32-bit ARM chip, the silicon is basically an engine that runs C.

If your code is simple, then you could spend less time with an 8-bit chip. But many projects nowadays have networking requirements (e.g., usb, bluetooth, ethernet, etc.) and network stacks are basically big piles of C code. Using up  your RAM or code space on networking stuff means you've got to spend more time optimizing everything else to shoehorn your software into a smaller mcu.

In the end, it comes down to which is more cost effective. Is it cheaper to spend engineering time to cram your software onto the cheapest piece of silicon that will run it, or is it better to use an architecture with some "headroom" and allocate your resources to other areas?

I'm working on a project now where we spec'd the biggest, baddest ARM Cortex M4 we could find for the first couple of prototypes. Later on, when get closer to production, we'll fit the hardware design to just what the software needs in order to run. We've got three code monkeys for each EE on the project, so software issues dominate the planning process.

Fiddling comment makes no sense.  Only difference is in skill set.  BTW programming has been part of my job since 1986.  During that time I have coded for many different architectures, spanning 4 bit micro processors to multi CPU clusters.  In all cases you code for the device and environment.  Calling one fiddly and another easier seems very silly to me. 

Second statement makes more sense.  Yes almost everyone here has stated or agreed that it is important to choose the right chip for the task.  As far as libraries are concerned, yes if your company has not made slimmer Bluetooth/Ethernet/USB libraries you will need to use the OEM supplied libraries.  Yes you will need more memory, again this is about selecting the right chip for the job.  Also makes me wonder what you call "big piles of C code".  Thus far my recent project have required 8bit and 16bit PICs, but this would not keep me from using one of the 32bit chip I have on my shelf.  The difference I see is I do not have an ad version to using a 8 or 16 bit microprocessor. 

Yes it is all about money almost all the time.  Again II agree that the right size for the job is required.  One factor is if you personally have to "cram" you code into the chip you selected the wrong size.  Just accept that others may not have these limitations.  Yes proper chip selection should supply headroom. 

Hmm.  By your derogatory comment of "code monkey" I now wonder why I would even bother to try explain my position to you as an peer.  I think giving you that credit was a mistake on my part.  As a person with decades of experience in electronics and programming I find your attitude deplorable. 

[westfw]

That sounds like the sort of confidential information I'd have expected manufacturers to want to keep very quiet indeed... mind if I ask where those figures came from?

If they're publicly traded companies, it's gotta be public information.
I got it from yahoo finance pages; you can probably find more details in published quarterly reports and such.
For example: http://finance.yahoo.com/q?s=STM
(a lot of stuff on yahoo finance boards is just public facts and figures, but ... avoid placing any faith in stuff that people say on the "message boards.")

(why do engineers tend to be so clueless when it comes to finance/business?  I certainly was before I was dragged along through the "successful start-up experience.")

[mtechmatt]

I have found most PIC24s are now cheaper than an 8 bit PIC18, but I love 5v (Working mainly with automotive stuff so 5v sensors etc)

Matt

[AndyC_772]

(why do engineers tend to be so clueless when it comes to finance/business?

Insufficient coffee. I probably shouldn't post anything before about 9.30am.

[Kjelt]

why do engineers tend to be so clueless when it comes to finance/business?

Perhaps because it is of no interest for an engineer to know if:
A certain 32bit uC is sold for 1.- with a loss for the company of 0,60 or a certain 8 bit uC is sold for 0,75 with a loss of 0,25. The only thing of direct intrest is the price that has to be paid in the end
Maybe that a financial manager starts to drool if he sees the extra discount and is willing to pay more so he feels good 

[dannyf]

you'll spend less time fiddling with algorithmic C code to make it work.

Is that really true?

"x = y+z;" is always the same (in C) on an 8-bit mcu or a 32-bit mcu.

I have plengty of math-intensive routines that run flawlessly, and unmodified, on 8-bit/16-bit and 32-bit mcus.

[JTR]

I have found most PIC24s are now cheaper than an 8 bit PIC18, but I love 5v (Working mainly with automotive stuff so 5v sensors etc)

Matt

Well there are some 5V PIC24s, not a huge selection but "some." Of course there is the older dsPIC30s and all of these are 5V.

The PIC24 is an "agreeable" ISA to work with whether you code in C or assembler.  When used with C30 or XC16 in free mode it suffers a lot less from the lost of optimisations than all the other PIC families in my experience. I sometimes wonder if this family is under utilized simply based on a perception that 32-bits is the way to go. Anyway, that's just me musing and wondering...

[dannyf]

I sometimes wonder if this family is under utilized simply based on a perception that 32-bits is the way to go.

Definitely the case. PIC24, in my view, is the best mcu Microchip has to offer. Yet, it is grossly under-marketed and under-appreciated.

[nctnico]

you'll spend less time fiddling with algorithmic C code to make it work.

Is that really true?

"x = y+z;" is always the same (in C) on an 8-bit mcu or a 32-bit mcu.

I have plengty of math-intensive routines that run flawlessly, and unmodified, on 8-bit/16-bit and 32-bit mcus.

Wait until you start using pointers on an 8 bit PIC or 8051. Ofcourse it works but its soooo slow because the compiler needs to adds a lots of extra code in order to emulate a single memory map. Its actually so bad that Keil's compiler for the 8051 doesn't even attempt to support non-constant function pointers.

[dannyf]

I have to say that I have used pointers (to constants / variables / functions) on both chips. No ill feeling so far.

What specific issues are you referring to?

[mikeselectricstuff]

I sometimes wonder if this family is under utilized simply based on a perception that 32-bits is the way to go.

Definitely the case. PIC24, in my view, is the best mcu Microchip has to offer. Yet, it is grossly under-marketed and under-appreciated.

yes - it is nice, especially the pin remapping which makes PCB layouts really easy  - QFNs on 2 layers - no problem!

[mrflibble]

yes - it is nice, especially the pin remapping which makes PCB layouts really easy  - QFNs on 2 layers - no problem!

Okay, now I'm curious. I had more or less kicked out microchip due to one bad experience too many. But good chips are good chips, sooooo. Any particular ones in the PIC24 family with an awesome price/performance ratio? Or if you happen to know this, any ones with center aligned PWM?

In the meantime, time for a parametric search...

[senso]

I used one PIC24, for 2 weeks, could blink and led, add code to init the uart the pic just hanged lol, tried 5 of them, consistent behavior, no one in the microchips forum could understand the error, tried tons of code, bye bye   

[nctnico]

I have to say that I have used pointers (to constants / variables / functions) on both chips. No ill feeling so far.

What specific issues are you referring to?

Speed and code size. Another problem is that 8 bit PICs and 8051 basically have no stack so the compiler needs to emulate this as well. This means that function parameters and variables are in RAM. The compiler usually tries to seperate IRQ processes from the primary process and reuse as much space as possible. Now try a function which is used both from the main process and an interrupt... Try to think about how this will work with pointers to functions. In a device with banked memory like the 8 bit PICs the mapping of variables to memory usually needs some 'pragma' steering as well. If you want fast & small code then you have to resort to some sort of C slang where C starts to look like programming with assembler macros.

[mikeselectricstuff]

yes - it is nice, especially the pin remapping which makes PCB layouts really easy  - QFNs on 2 layers - no problem!

Okay, now I'm curious. I had more or less kicked out microchip due to one bad experience too many. But good chips are good chips, sooooo. Any particular ones in the PIC24 family with an awesome price/performance ratio? Or if you happen to know this, any ones with center aligned PWM?

In the meantime, time for a parametric search...

My default is a PIC24FJ64GA002, as you can get it in a 28QFN which is one of the better package size to capability ratios available (RAM in particular), and a few bigger ones when I've needed more UARTS, but haven't looked very hard at the rest of the rage. I've also use the GB ones for USB host. 

[mikeselectricstuff]

The main reason to go 32-bit (instead of 8- or 16-bit) is that you'll spend less time fiddling with algorithmic C code to make it work. 8-bit architectures often add restrictions to what you can do in C--compromises between what the language definition supplies and what the hardware can support. With a 32-bit ARM chip, the silicon is basically an engine that runs C.

The only people who say that are desktop programmers who don't really understand C or what the compiler does, or how CPUs work. In that respect 8 bit is usually easier than 32.

It really isn't about the core - 32Bit MCUs tend to come with much more complex peripherals, clocking schemes & PLLs, power management,  memory mapping, DMA etc. which take more figuring out than the simpler peripherals of typical 8-bit devices.

[dannyf]

especially the pin remapping

Absolutely agree with that. A life saver.

Or if you happen to know this, any ones with center aligned PWM?

The good thing about those chips is that their pwm / ic channels utilize dedicated timers. Kinda like the TI approach: identical feature-rich peripherals. Datasheet is your best friend at this point.

tried tons of code,

Not enough information to blame it on the chip alone.

[dannyf]

Speed and code size.

How  much slower do you think it is?

[nctnico]

The main reason to go 32-bit (instead of 8- or 16-bit) is that you'll spend less time fiddling with algorithmic C code to make it work. 8-bit architectures often add restrictions to what you can do in C--compromises between what the language definition supplies and what the hardware can support. With a 32-bit ARM chip, the silicon is basically an engine that runs C.

The only people who say that are desktop programmers who don't really understand C or what the compiler does, or how CPUs work. In that respect 8 bit is usually easier than 32.

Its the other way around. I dumped the 8051 in favor of the MSP430 because the MSP430 has one single memory space, a real stack etc. I was tired of having to jump through hoops because of the limits the 8051 imposed. I wanted to get my projects going and that was much quicker with the 16 bit MSP430 than the 8051. I really don't understand how having 2 or 3 different memory spaces each with different instructions to access them can be regarded as being simple.

@dannyf: for the project I worked on it was way too slow and way too big because of the compiler inferred pointer emulation. The code size was twice the size of the available memory. I rewrote the software (which ran perfectly on ARM; ARM loves pointers) to be a better fit for the PIC (which was in the existing hardware so I couldn't get rid of it).

[senso]

I used one PIC24, for 2 weeks, could blink and led, add code to init the uart the pic just hanged lol, tried 5 of them, consistent behavior, no one in the microchips forum could understand the error, tried tons of code, bye bye   

Kinda suggests the problem was you, if such a simple application failed.

Kinda suggests the samples they sent me had a hardware bug
Never had a problem with STM32F4's, Atmegas, Attinys, PIC32 and MSP430..

There are also some pic's that have hardware stack's, and no one is crying about that, each chip as its limitations, choose whatever fits the best.

[dannyf]

Kinda suggests the samples they sent me had a hardware bug

Tough to argue against thousands / millions (?) of such chips used successfully.

The code size was twice the size of the available memory.

I hope that doesn't mean the use of pointers doubled the memory.

I have used pointers on those chips and I can code faster with pointers than with normal assignments for some applications.

[andyturk]

In all cases you code for the device and environment.

I disagree. You code for the product requirements. Device selection comes later (assuming you have a choice).

The difference I see is I do not have an ad version to using a 8 or 16 bit microprocessor. 

You're more flexible than I am, to your credit. My recent projects have involved enough code that 8-bit mcus simply wouldn't work. One project used an MSP430 and required dancing around address space limitations.

By your derogatory comment of "code monkey" I now wonder why I would even bother to try explain my position to you as an peer.  I think giving you that credit was a mistake on my part.  As a person with decades of experience in electronics and programming I find your attitude deplorable.

Chill out, dude. I *am* a "code monkey". 

[WarSim]

In all cases you code for the device and environment.

I disagree. You code for the product requirements. Device selection comes later (assuming you have a choice).

Pre-device selection programming is usually limited to templates, resource map and POC code.  Err wait ... Your statement indicates a different methodology.

I think I now understand which of the three programming methodology you use.  It is a valid, but i believe that process is best suited to programming in a single architecture class.  It is faster process but restricted by class, because any class deviations will cause any increased speed to be lost.  So yes given your chosen programming methodology using only 32bit uC would be your best choice.  Because not all tasks are amenable to a 8/16 bit chip but all should work in a 32bit chip with varying levels of efficiency.  Until 64bit uC are made

Sorry can't remember the names right now.  My best guesses are deconstruction (me), code collection (you) and story board (scripters and web programers). 

I used code collection method when programming for mini-computers and PCs.  When I started with AI programming in 90's I changed methodologies.  It was all IP locked down, everything I did was essentially original.  Later in 00 when programming uC I found I preferred the deconstruction methodology for these tasks as well. 

This debate helped me remember more about the methodologies thanks. 

[Kjelt]

Until 64bit uC are made  

Thanks for the smiley because I really, really would not know what to use a 64 bit address space for in an embedded device.      That said the term embedded is misused everywhere even in 6' large 19" rack sun systems driving some industrial application, which is far from embedded in my vocabulary.

[WarSim]

Until 64bit uC are made  

Thanks for the smiley because I really, really would not know what to use a 64 bit address space for in an embedded device.      That said the term embedded is misused everywhere even in 6' large 19" rack sun systems driving some industrial application, which is far from embedded in my vocabulary.

Yes, but it is part of a "System".  The quintessential over used word.   

Don't laugh (too much) we still used Solaris 9 on some of our special purpose computers. 

[westfw]

Wait until you start using pointers

Well, pointers to functions or data in Harvard "code space" can be interesting on an architecture where pointers are normally only 16 bits, but there is more than 64k of flash.  Compilers will do most of the work, most of the time, but they start to violate expectations of straightforward operation.  (avr-gcc has "trampolines."  Whee!)

Smaller PICs have trouble with data structures bigger than "some" of a bank size, because actual data memory isn't contiguous; each bank has some IO registers and some general purpose ram.

Many languages get a bit grumpy when you violate their core assumptions by having more than one address space (harvard architecture) or having pointers to different types of objects be different sizes.  (C on a PDP10 was interesting, because it was word-addressable.  Pointers to strings were an entirely different "thing.")

This is more of an argument about matching compilers to architectures and problems, rather than an 8bit vs 32bit argument, technically speaking.  But non-technically, "use a 32bit cpu because its architecture is more directly suited to running code written in a modern language" *is* part of the overall argument.

It can be "educational" to go back and look at some of the shared C software from the early days of the IBM/PC, when C libraries were less standardized, and there was CP/M plus several versions of unix floating around as well.  The amount of conditional compilation was ... horrifying!

[andyturk]

I used code collection method when programming for mini-computers and PCs.  When I started with AI programming in 90's I changed methodologies.  It was all IP locked down, everything I did was essentially original.  Later in 00 when programming uC I found I preferred the deconstruction methodology for these tasks as well. 

I'm not totally clear on the distinction between "code collection" and "deconstruction", but it sounds reasonable. There's quite a lot of open "source" out there now, and it often makes sense to use someone else's code (if it works) rather than writing it yourself. It used to be build vs. buy, but now it's more like build vs. fork. Is that what you mean by "code collection"?

BTW, it sounds like we're contemporaries. My first job was writing Z80 assembly code and FORTRAN in the early 80s.

[AndyC_772]

I've had an interesting couple of days trying to see how I might port a PIC18 design from a couple of years ago onto a faster processor.

The PIC in question was a particularly good fit for the design at the time, not because of the core (which was too slow, and the fragmented memory map was a PITA) but with the other peripherals integrated onto the die. Aside from the voltage regulator to power it, the PIC was about the only active component on the board.

The peripheral set in question? Two analogue comparators, three PWM outputs, an RTC, and some true, byte addressable EEPROM. Plus the usual Flash, RAM, timers and so on which just about every microcontroller has.

I'd hoped that with there being so many ARM Cortex M0 and M0+ micros out there, finding one to replace my PIC would have been easy, but no. EEPROM in particular seems quite rare, which is a great shame because the design really does need to store and update a few bytes at a time at fairly regular intervals. I'm fairly sure it's down to process limitations at the wafer fab... whatever process can make the core for pennies isn't so well suited to fabricating EEPROM cells.

Maybe this particular project is just a bit of an oddball in terms of its requirements?

The other thing which came out of my research is the difference in code space required. The original project fits (just!) into a 32k PIC18. Rewrite it for an STM32 part using the ST peripheral libraries - which, with hindsight, was probably more trouble than it's worth - and it won't fit into a 64k device without optimisation. Flash capacity would appear not to be directly comparable between the families, despite the fact that the Cortex M0 uses 16 bit (Thumb) instructions to improve code density. It's not a particularly I/O intensive project, most of the code is application level and stored bitmap graphics, so the impact of the more complex peripherals is minimal.

If anyone has any suggestions for a device with the necessary peripherals but about, say, twice the performance of a PIC18 @ 64 MHz, I'd be genuinely appreciative. If it's a similar price, so much the better!

[WarSim]

I used code collection method when programming for mini-computers and PCs.  When I started with AI programming in 90's I changed methodologies.  It was all IP locked down, everything I did was essentially original.  Later in 00 when programming uC I found I preferred the deconstruction methodology for these tasks as well. 

I'm not totally clear on the distinction between "code collection" and "deconstruction", but it sounds reasonable. There's quite a lot of open "source" out there now, and it often makes sense to use someone else's code (if it works) rather than writing it yourself. It used to be build vs. buy, but now it's more like build vs. fork. Is that what you mean by "code collection"?

BTW, it sounds like we're contemporaries. My first job was writing Z80 assembly code and FORTRAN in the early 80s.

No it doesn't imply borrowed code.  All the code can be original.  The distinction is by when in the programming process that functional blocks are implemented.
As I said I may have the names wrong. 

All programming problems are broken down in phases.  Starting at concept ending at working code, and extended by revision. 
The least used method method is story board is when the concept deconstruction diverts to code generation after info and data flow charting is done.  Fourth was the first attempt the bridge the gap.  Delphi was a half step between this and the next methodology. 

Code collection continues the process through process control and end point identification.  This methodology can have archive shorter development time through the use of existing libraries.  The negative effect is every architecture change can involve huge increases in conditional compile blocks.  In a perfect scenario the only code specifically created is the glue code to connect the parts together.  Another restriction is this method only gain it's full benefit if the process components have been generated before by the last methodology. 

Deconstruction continues the process through scope charts, convention controls and instance plans.  At this stage all that is left is code each task block.  Heave use of code snippets enables increased programming speed or just type at over 180wpm.  I can only do 120wpm so I use code snippets, allot of my peers are really fast typers.  Advantages are no IP costs and not preexisting code dependant.  Disadvantage longer pre-code planing. 

I hope this explains what I was referring to.  Even if I got the methodology names wrong. 

I was taught that keying in should only be 20% of the effort and if you have to recompile a third time you failed.  Yes this is old school it no longer takes a week to compile a complete project.  Obviously code for a uC could take more than 30min to compile.  My last major computer based project took a very fast PC 8 hrs to compile.  So this point was more significant then than now. 

Almost all my coding these days follows the deconstruction methodology not because it is better but because it is necessary.  At work I get assigned the tasks others don't want to tackle.  I get the project just before it goes back out the door as unable to implement.  The bean counters get the excuse to bid high and the job comes back and I get the work. 

Seems I find glueing libraries together boring, I don't do it as a hobby.  My last 5 DIY of my last 7 projects I did was to prove the that something can be done.  I really annoys me when people say something can't be done when it can.  I do it to prove to myself they are wrong no prove to them they are wrong.  The other projects because I could not find what I wanted for sale anywhere. 

[dannyf]

twice the performance of a PIC18 @ 64 MHz,

I don't know if you can run this particular pic at 64Mhz but what "performance" are you talking about? In certain cases, an ARM-based chip can be multitude faster than the PIC, and in others not so or just comparable. So without defining what "performance" you are looking for, it is hard to tell you specifically if an ARM chip will do.

I do say that in IO-intensive applications, an ARM chip can be considerably faster (and in some cases 3x faster) giving that many of them allow masked read / writes, or bitbanding. For math-intensive applications, the ones with FPUs are considerably faster but not so much on 8-bit types (other than division).

I do think your observation on code space is spot on and consistent with mine. The exception can be those chips with onboard ROM.

As to eeprom, Freescale, NXP and TI offer many such chips. Unfortunately, those happen to the high-end vendors too.

[Rufus]

If anyone has any suggestions for a device with the necessary peripherals but about, say, twice the performance of a PIC18 @ 64 MHz, I'd be genuinely appreciative. If it's a similar price, so much the better!

PIC24FV32KA304 maybe.

[nctnico]

I'd hoped that with there being so many ARM Cortex M0 and M0+ micros out there, finding one to replace my PIC would have been easy, but no. EEPROM in particular seems quite rare, which is a great shame because the design really does need to store and update a few bytes at a time at fairly regular intervals. I'm fairly sure it's down to process limitations at the wafer fab... whatever process can make the core for pennies isn't so well suited to fabricating EEPROM cells.

Maybe this particular project is just a bit of an oddball in terms of its requirements?

The other thing which came out of my research is the difference in code space required. The original project fits (just!) into a 32k PIC18. Rewrite it for an STM32 part using the ST peripheral libraries - which, with hindsight, was probably more trouble than it's worth - and it won't fit into a 64k device without optimisation. Flash capacity would appear not to be directly comparable between the families, despite the fact that the Cortex M0 uses 16 bit (Thumb) instructions to improve code density. It's not a particularly I/O intensive project, most of the code is application level and stored bitmap graphics, so the impact of the more complex peripherals is minimal.

What kind of optimisation? You probably use GCC and if you don't specify the optimisation level it doesn't optimise at all (which is nice if you want to check the assembler output or run the program in a debugger). For microcontrollers I always use -Os to optimise for size. This gives you the most compact code. For one of my larger ARM projects no optimisation gives me a binary of 60072 bytes. With optimisation for size that number gets reduced to 26610 bytes. I'd also check the mapfile generated by the linker to see what happened with the graphics. Maybe they got aligned to 4 byte boundaries so they take way more space than they should.

edit: another thing to look for in the mapfile is whether large chunks of standard C libraries are being pulled in. It helps a lot to use a miniaturised C library to reduce size.

Regarding the EEPROM: on a flash based device you simply use one (or more) flash sectors to store data. The only difference is that you'll need to do a read-modify-write.

[Kjelt]

Watch out with substituting an eeprom with flash. You wrote several bytes at fairly regular intervals you should calculate how many cycles that will total upto in the desired lifetime of the product. Eeprom can be written millions of times, flash 100000 to 300000 (check datasheet) so you have to do a wear leveling algorithm or if there is no secrets use an external i2c or spi eeprom.

[ElectroIrradiator]

If anyone has any suggestions for a device with the necessary peripherals but about, say, twice the performance of a PIC18 @ 64 MHz, I'd be genuinely appreciative. If it's a similar price, so much the better!

I haven't used them myself, but check the ARM Kinetis family from Freescale. They seem to have combinations of every sensible peripheral under the Sun, including comparators and on-chip EEPROM by way of their FlexMemory functionality.

[Rufus]

PIC24FV32KA304 maybe.

Microchip give their products such catchy names. I'm sure there's some logic to it.

There is logic to some of it.

PIC24F is the main family
V indicates 5v supply with internal regulator
32 is K of program memory
K is some kind of sub-family
A3 is some kind of generation indicator - there may be B3 or A4 parts in the future
04 indicates 44 pins

[dannyf]

Eeprom can be written millions of times,

Typical endurance is 300 - 500K cycles. I have tried PICs for over 2 million cycles, without any errors - I stopped at that time.

[AndyC_772]

twice the performance of a PIC18 @ 64 MHz,

I don't know if you can run this particular pic at 64Mhz but what "performance" are you talking about? In certain cases, an ARM-based chip can be multitude faster than the PIC, and in others not so or just comparable. So without defining what "performance" you are looking for, it is hard to tell you specifically if an ARM chip will do.

The time-critical bit happens on an edge of an external signal, the frequency of which can vary. On each edge, the PIC reads a timer and then performs a series of arithmetic operations based on that value, and these operations have to be complete before the next edge. Much less frequently (a few times per second), the result of all these calculations are shown on an LCD display.

I'd expect a considerable speed improvement from an ARM Cortex M0 processor over and above a PIC18. The raw instruction rate is, say, 3x faster (comparing a 48 MHz STM32 vs a PIC18 running at Fosc/4 = 16 MHz). On top of that, the algorithm is performing arithmetic on 16-bit integers, so I'd expect the ARM to require fewer instructions per computation than the PIC. The additional overhead of talking to more a more complex timer should be minimal.

As to eeprom, Freescale, NXP and TI offer many such chips. Unfortunately, those happen to the high-end vendors too.

Usual suspects, then. Atmel and NXP look closest, though nothing quite hits the same well-matched feature set as the PIC18F66K22 I'm currently using. Looks like I'm going to end up with either an external EEPROM, or some complex wear-levelling EEPROM emulation code that I could well do without. Shame.

PIC24FV32KA304 maybe.

Thanks, it looks like a close match, though still only 16 MIPs... I'd have to get good value from the fact that it's a 16 bit device in order to be a worthwhile update.

What kind of optimisation? You probably use GCC and if you don't specify the optimisation level it doesn't optimise at all (which is nice if you want to check the assembler output or run the program in a debugger).

Any of the GCC optimisation levels will get it into 64k, so it's not like it strictly "won't fit" - just that I'd like to be able to debug it easily.

As far as detailed usage goes, I don't know yet because I've been struggling to find an IDE that works reliably and that I can install and use... I've invested more of my life than I care to admit in both Eclipse / Yagarto and then CoIDE, and decided that there's a reason why there's a market for commercial development tools even with four figure price tags. I have CrossWorks for ARM on eval right now, which is probably the route I'll be taking; it seems easy enough to drive, and gives quite a nice graphical display of memory usage. The cost is, I think, less than the value of my time which I may end up wasting otherwise.

I haven't used them myself, but check the ARM Kinetis family from Freescale. They seem to have combinations of every sensible peripheral under the Sun, including comparators and on-chip EEPROM by way of their FlexMemory functionality.

Agreed - I did find a part which would do the job (a KL30 IIRC), but it was a bit over-powered for the job and slightly more expensive than I'd ideally have liked. But since this is really just a learning and development exercise for me right now, I might well go down that route. Thanks for the suggestion.

[dannyf]

On each edge, the PIC reads a timer and then performs a series of arithmetic operations based on that value, and these operations have to be complete before the next edge.

It is usually a bad design to put extensive arithmetic operations into the isr for those chips.

The ARM will give you an edge in terms of integer math capabilities, re-entrancy, isr latency (if chained), higher master clock, and IO-latency (on AHB), and floating point math on certain ARM chips; The PIC will give you an edge in terms of IO-latency (vs. APB), and clock speed (if you indeed could run the PIC at 64Mhz).

[Rufus]

PIC24FV32KA304 maybe.

Thanks, it looks like a close match, though still only 16 MIPs... I'd have to get good value from the fact that it's a 16 bit device in order to be a worthwhile update.

Well you know the tools, the compiler does a good enough job in free mode. Compile something representative and count cycles or time it in the simulator.

You might browse here
http://www.eembc.org/coremark/index.php
there are a couple of PIC18 scores giving about 0.16 coremarks/MIP. The 16 bit PICs about 1.8, 32 bit PICs 3 to 3.5. I expect the benchmarks are more generous towards processor 'bits' than most real world applications. Be careful some of the results confuse processor clock frequency and actual instruction rate.

[dannyf]

there's a reason why there's a market for commercial development tools even with four figure price tags.

Mostly for the support that a commercial vendor brings.

Otherwise, those free tools do a decent job, for those chips that they support. CoIDE is an excellent platform, but with limited support for chips that I use.

[Kjelt]

On each edge, the PIC reads a timer and then performs a series of arithmetic operations based on that value, and these operations have to be complete before the next edge.

It is usually a bad design to put extensive arithmetic operations into the isr for those chips. 

+1 and I would say on any chip. Esp. if you have no guarantee when the next pulse comes in respect to the processing. Better design in my opinion would be to do the most necessary tasks only in the isr, in this case store the timer value in a queue. And process that queue data in the main loop, or better in a seperate task if running an RTOS.
Then do an extensive test for the processor load (or the idle time in RTOS) to be sure it can handle the dataflow over a long period.
That way the pulses are allowed to also come almost after eachother and you will never miss one.

[andersm]

You might browse here
http://www.eembc.org/coremark/index.php
there are a couple of PIC18 scores giving about 0.16 coremarks/MIP. The 16 bit PICs about 1.8, 32 bit PICs 3 to 3.5. I expect the benchmarks are more generous towards processor 'bits' than most real world applications. Be careful some of the results confuse processor clock frequency and actual instruction rate.

The MIPS-based PIC32s generally benchmark well, due to the large number of registers and compiler-friendly instruction set. However those same registers add to the interrupt latency and especially things like RTOS context switch times.

[Rufus]

On each edge, the PIC reads a timer and then performs a series of arithmetic operations based on that value, and these operations have to be complete before the next edge.

It is usually a bad design to put extensive arithmetic operations into the isr for those chips. 

+1 and I would say on any chip.

He said "have to be complete before the next edge" how does trying to offload the calculations to foreground execution help meet that requirement in any way?

PWM generating applications for things like motor and switch mode power supply control often require calculation of the duty of every PWM cycle, often based on the result of ADC conversions synchronised with PWM generation. You can't ask a 3 phase motor to wait a bit for the PWM sine waves you are generating because your foreground code was servicing a query on a serial port.

[nctnico]

On each edge, the PIC reads a timer and then performs a series of arithmetic operations based on that value, and these operations have to be complete before the next edge.

It is usually a bad design to put extensive arithmetic operations into the isr for those chips. 

+1 and I would say on any chip. Esp. if you have no guarantee when the next pulse comes in respect to the processing. Better design in my opinion would be to do the most necessary tasks only in the isr, in this case store the timer value in a queue. And process that queue data in the main loop, or better in a seperate task if running an RTOS.

The worst advice I've ever seen. The only reason to make an ISR short is when there is a chance another ISR can kick in which needs to be serviced. But then again most microcontrollers support nested interrupts. Sometimes I make DSP-ish applications. In those all the signal processing is done inside the ISR (sometimes 90% of the CPU time is spend in one interrupt). This saves a lot of hassle and overhead with transferring buffers to the main process (think semaphores!). The main process usually isn't designed to handle timing cricital stuff anyway.

A controller has X time to handle Y instructions. Moving calculations outside an ISR doesn't mean that X or Y changes so it doesn't matter where you do the math. You need to do it anyway.

[AndyC_772]

Oh, dear, I was afraid that mentioning how the software works would spark a debate!

I know perfectly well the "rule" about not spending "too much" time in an ISR, but as with all such "rules", they're there to be broken if you know what you're doing. In this case I know what the nature of the input signal is like and where the time critical paths are, and I'm satisfied that it's OK for the CPU to spend most of its time in the ISR.

The timer captures the exact instant at which the pulse arrives; if it's not actually processed until later then that's OK - the application is for monitoring and display, not real-time control.

there's a reason why there's a market for commercial development tools even with four figure price tags.

Mostly for the support that a commercial vendor brings.

Otherwise, those free tools do a decent job, for those chips that they support. CoIDE is an excellent platform, but with limited support for chips that I use.

Support is great to have, but first and foremost, the tool has to 'just work' in a majority of cases. Sadly my experience of CoIDE is that it doesn't.

I, along with a number of other users, have had problems downloading code to my target board using CoIDE, and although the most recent version worked OK with a small project, it broke again when I ported a larger one. The developers haven't been able to reproduce or fix the problem - certainly not in a timely manner - and that leaves me at an unacceptable dead end.

For a hobby project it might then be OK to post a support request on the forum and hope for the best, but that's no good if I have a customer waiting. I need the tools I use to have been put through the sort of thorough beta testing that open source and other free software rarely gets, and I'm a firm believer that the best technical support is the support you don't need in the first place.

[nctnico]

I standarised all my software development to use Eclipse. As far as my experience goes Eclipse beats any IDE I have used so far. But then again Eclipse is intended to be the best IDE there is. The amount of features and workflow do take some getting used to. For programming I use standalone programming software/tools like 'Flashmagic' (for the NXP controllers). I gave up on in-circuit debugging decades ago. It takes more time to set it up than it takes to just run the software through a PC based debugger.

[dannyf]

it doesn't matter where you do the math.

Having actual experience programming those mcus would be quite helpful here. Talking about programming those mcus can only take you so far.

problems downloading code to my target board using CoIDE

I don't know your specific issues but downloading / debugging in any ide is done with the help of 3rd party tools, which often require proprietary IP from the 3rd party tool vendors. For example, CoIDE has no support for lpc-link since they haven't worked out a deal with nxp.

You cannot blame the ide entirely for that.

[AndyC_772]

I don't care about assigning blame, I care about having a tool chain available to me which works reliably. With commercial software, it's someone's responsibility to ensure this is the case, and to help me resolve any problems I do encounter.

This isn't the case with the free / open source stuff. An indignant "it works for me", or "it's your environment that's wrong", or "blame the developer of xxxx", or no response at all, doesn't help.

"I know what I'm doing" are the most famous last words in the history of the world.

You're thinking of "Hold my beer and watch this!"

[dannyf]

doesn't help.

They don't need to help you. As a matter of fact, no one needs to help you in that case. You made the decision to use free tools and you should expect "free" support. It is lucky that a free tool worked for you - that's the right expectation.

[AndyC_772]

I completely agree.

[Kjelt]

Indeed its getting offtopic but great that everybody has an opinion  , the problem here are the requirements and if the input signals are known and predictable.
And luckily in this case they are:

In this case I know what the nature of the input signal is like and where the time critical paths are

In my own experience however I have seen a lot of accidents happen with ADC sampling and directly in the ISR calculating all the (sometimes very complex) math for results that are NOT directly necessary. For instance energyconsumption. The requirements state for instance that this should be accurate every few seconds, so in those cases you can store the results and postpone the final calculation or do this over time with averaging. Also this code grows over time, new requirements and SW engineers, putting the extra code on top of the existing (inside the ISR), failure waiting to happen.

He said "have to be complete before the next edge" how does trying to offload the calculations to foreground execution help meet that requirement in any way?

In this case it probably doesn't, it does help however porting to another microcontroller , platform and overall readability, all which become more important these days then making it work on a single platform.

You can't ask a 3 phase motor to wait a bit for the PWM sine waves you are generating because your foreground code was servicing a query on a serial port.

True that's a matter of prioritizing the tasks. In the given case the calculations should have higher priority over a slow serial port query.
However the query should still be processed at some time also otherwise your system seems to be dead from an outside point of view.

The worst advice I've ever seen. The only reason to make an ISR short is when there is a chance another ISR can kick in which needs to be serviced.

That was exactly my point that the exact same interrupt is not going to be handled because the ISR is still in the middle of its calculations. You loose events and valuable information that is not going to be processed because the timer value that needs to be stored is increasing with every instruction you waste in the mean time and the results will be false.

A controller has X time to handle Y instructions. Moving calculations outside an ISR doesn't mean that X or Y changes so it doesn't matter where you do the math. You need to do it anyway.

Depends on the requirements if you need to do it right away or it can be handled in between events or even delayed for some times.
I firmly believe ISRs need to be as small and simple as possible do what they need to do and return. Do the prioritizing of the tasks in your taskshandler, if you have an RTOS and else write it yourself.

But then again most microcontrollers support nested interrupts.

Hooray, good luck handling the exact same interrupt you are already handling.

But I think we mean the same thing, you will probably say you have to make sure that the computations are finished before the next event comes which is correct. That said you sometimes don't know when the next event comes. If the whole point of the interrupt and thus the ISR is to simply store the exact timervalue at the exact moment of the interrupt, you better make sure that that interrupt is getting handled immediately which means keep the ISR to it's minimum.

Anyone interested in ISR's should take a Rate Monotonic Analysis course, very worth while 

[WarSim]

Indeed its getting offtopic but great that everybody has an opinion  , the problem here are the requirements and if the input signals are known and predictable.
And luckily in this case they are:

In this case I know what the nature of the input signal is like and where the time critical paths are

In my own experience however I have seen a lot of accidents happen with ADC sampling and directly in the ISR calculating all the (sometimes very complex) math for results that are NOT directly necessary. For instance energyconsumption. The requirements state for instance that this should be accurate every few seconds, so in those cases you can store the results and postpone the final calculation or do this over time with averaging. Also this code grows over time, new requirements and SW engineers, putting the extra code on top of the existing (inside the ISR), failure waiting to happen.

He said "have to be complete before the next edge" how does trying to offload the calculations to foreground execution help meet that requirement in any way?

In this case it probably doesn't, it does help however porting to another microcontroller , platform and overall readability, all which become more important these days then making it work on a single platform.

You can't ask a 3 phase motor to wait a bit for the PWM sine waves you are generating because your foreground code was servicing a query on a serial port.

True that's a matter of prioritizing the tasks. In the given case the calculations should have higher priority over a slow serial port query.
However the query should still be processed at some time also otherwise your system seems to be dead from an outside point of view.

The worst advice I've ever seen. The only reason to make an ISR short is when there is a chance another ISR can kick in which needs to be serviced.

That was exactly my point that the exact same interrupt is not going to be handled because the ISR is still in the middle of its calculations. You loose events and valuable information that is not going to be processed because the timer value that needs to be stored is increasing with every instruction you waste in the mean time and the results will be false.

A controller has X time to handle Y instructions. Moving calculations outside an ISR doesn't mean that X or Y changes so it doesn't matter where you do the math. You need to do it anyway.

Depends on the requirements if you need to do it right away or it can be handled in between events or even delayed for some times.
I firmly believe ISRs need to be as small and simple as possible do what they need to do and return. Do the prioritizing of the tasks in your taskshandler, if you have an RTOS and else write it yourself.

But then again most microcontrollers support nested interrupts.

Hooray, good luck handling the exact same interrupt you are already handling.

But I think we mean the same thing, you will probably say you have to make sure that the computations are finished before the next event comes which is correct. That said you sometimes don't know when the next event comes. If the whole point of the interrupt and thus the ISR is to simply store the exact timervalue at the exact moment of the interrupt, you better make sure that that interrupt is getting handled immediately which means keep the ISR to it's minimum.

Anyone interested in ISR's should take a Rate Monotonic Analysis course, very worth while 

Isn't this covered with synchronous / asynchronous event charts and the time budget table?  Which is used to develop the timing sequence tree?  Aren't these used anymore to figure out these issues?  After all this is where these rules of thumb came from.     

Hmmm.  "Rate Monotonic Analysis course" if I take this course name literally, this suggest the this subject is covered in part in a separate courses.  Strange to have such and integral part itemized out into a separate subject or subjects.  Then again schools love breaking everything up into tinny pieces to make more money. 

[Rufus]

If you think this doesn't apply to you just remember that "I know what I'm doing" are the most famous last words in the history of the world.

When you don't know what you are doing claiming no one else does either will make you feel better about it.

[nctnico]

A controller has X time to handle Y instructions. Moving calculations outside an ISR doesn't mean that X or Y changes so it doesn't matter where you do the math. You need to do it anyway.

Depends on the requirements if you need to do it right away or it can be handled in between events or even delayed for some times.
I firmly believe ISRs need to be as small and simple as possible do what they need to do and return. Do the prioritizing of the tasks in your taskshandler, if you have an RTOS and else write it yourself.

But then again most microcontrollers support nested interrupts.

Hooray, good luck handling the exact same interrupt you are already handling.

But I think we mean the same thing, you will probably say you have to make sure that the computations are finished before the next event comes which is correct. That said you sometimes don't know when the next event comes. If the whole point of the interrupt and thus the ISR is to simply store the exact timervalue at the exact moment of the interrupt, you better make sure that that interrupt is getting handled immediately which means keep the ISR to it's minimum.

Sources of interrupts should always have a predictable behaviour: a minimum and maximum interval so you can determine the CPU load and the maximum time that can be spend inside the interrupt. Just accepting interrupts without any predictability (like from an unfiltered GPIO input) is asking for major problems. Over the years I have started to see interrupts as seperate processes where the interrupt controller is the task scheduler. Modern microcontrollers have lots of features in their interrupt controllers which allow for pretty specific task handling (prioritizing). Either way you'll need to make sure whether the CPU isn't loaded too much.

[AndyC_772]

In the specific example I mentioned earlier, the device generating the interrupts is a sensor on a rotating machine. The spacing from one pulse to the next depends on the rotational speed, so there's a definite mechanical limit on how close together they can occur. Noise filtering is done in hardware, independently of the microcontroller.

[WarSim]

In the specific example I mentioned earlier, the device generating the interrupts is a sensor on a rotating machine. The spacing from one pulse to the next depends on the rotational speed, so there's a definite mechanical limit on how close together they can occur. Noise filtering is done in hardware, independently of the microcontroller.

By what I understand from your explications this is a project needs a plan of separating the tasks into asynchronous event response and opportunistic code. 
Because you have concerns about the frequency deviation the of the edge events the ISR needs to be as small as possible or through higher speed at the task. 
If there is a time gain from buffering for opportunistic completion do it.  Micro controllers are made with ISR nesting but there is no support for re-entrant ISRs which will happen if the ISR takes longer than the shortest inter edge gap.  The buffering to the opportunistic code could be programmed re-enterent dispute no core support . 

You mentioned that some calculations are inter cycle constrained.  Yes these should fit in your smallest inter edge gap.  If you have extensive math that exceeds the time this is where you will need to use math replacement routines.  If you are not familiar with this I will explain what I mean.  A compiler has no way of knowing the limits, scope , or exception of external data or triggers.  Therefor a compiler of any caliber has to make code for every combination.  Because you know scope, limits and exceptions you can derive much faster math processes through derivation and proofs. Depending on core support will determine your options.  Many uC have an ALU of some sort.  For example on the chip I am working with now only integer math I need to avoid is divide and rotate n, all the others are single cycle within the ALU limits.  Through this process on a dynamic DSS project we gained a 1,500% speed boost from the fastest compiler selected math.  Of course you milage will vary depending on the math required, and the methods you know. 

Or liquid cool your processor and over clock it enough to get the job done.  .  Most people do the easy thing and just throw speed at the problem, then say it can't be done when there isn't a faster chip.  If more speed is your decision I for one won't challenge it, it's you project, I am only offering my solution. 

[nctnico]

If you get way more interrupts than anticipated your application won't work anyway. Even with short ISRs and offloading the work to the main task. The events need to be handled somewhere. Like I typed before: there is X time to execute a Y amount of instructions.

Anyway, I can't recall ever using GPIO interrupts. Stuff on GPIO is usually slow so I simply poll it and while I'm at it I do the filtering in software.

[dannyf]

Stuff on GPIO is usually slow

Yes, GPIO instructions can be as slow as 1 instruction / clock cycle.

Many other peripherals run much faster than that, I am sure.

[geraldjhg]

hi
because a 8 bit mcu powered from a 3.7 lipo thats gets charged from a 5v usb socket
and uses low power is FUN

[cloudscapes]

Was PCB design mentioned? Probably.

8bit MCU. Drop DIP or SOIC package onto PCB. Single-sided is fine, even home-etched. It'll work without decoupling caps, even. It'll just work.

32bit MCU. Extremely difficult on home-etched boards. Probably need copper fills, vias and caps all over unless you clock it really low. 32bit PCB design considerations are at least an order of magnitude more complicated than 8bit, unless you stick with one of the low-speed low-pin ARM DIPs.

I'd say 8bit is an invaluable learning tool in part because it is much more forgiving.

[nctnico]

Ebay is swamped with ready-to-go ARM boards you can drop onto a breadboard.

[westfw]

ready-to-go ARM boards you can drop onto a breadboard.

But then you're no longer price-competitive with the 8bit chip-only solution.
At least; not obviously.

[WarSim]

32bit MCU. Extremely difficult on home-etched boards. Probably need copper fills, vias and caps all over unless you clock it really low. 32bit PCB design considerations are at least an order of magnitude more complicated than 8bit, unless you stick with one of the low-speed low-pin ARM DIPs.

LOL. You amuse me. 

[mariush]

32bit MCU. Extremely difficult on home-etched boards. Probably need copper fills, vias and caps all over unless you clock it really low. 32bit PCB design considerations are at least an order of magnitude more complicated than 8bit, unless you stick with one of the low-speed low-pin ARM DIPs.

I'd like to know what you're smoking. You can get 32 bit cpus in DIP packages, but there are chips in surface mount packages that are easy to solder, like SOIC20 or TQFP that are easy to solder..

For example
http://www.digikey.com/product-detail/en/PIC32MX110F016B-I%2FSP/PIC32MX110F016B-I%2FSP-ND/2802113
http://www.digikey.com/product-detail/en/LPC812M101JD20FP/568-10435-5-ND/4368883

[c4757p]

32bit MCU. Extremely difficult on home-etched boards. Probably need copper fills, vias and caps all over unless you clock it really low. 32bit PCB design considerations are at least an order of magnitude more complicated than 8bit, unless you stick with one of the low-speed low-pin ARM DIPs.

The last PIC32 I used might as well have been a PIC18F or an ATmega for how stupidly simple it was.

[cloudscapes]

I must have been lucky/unlucky, then, because I started with 8bit mcus and they were incredibly easy to design PCBs for, while I had so many problems getting 32bit mcus to function properly on my own layouts. even started a thread about it here, last year:

https://www.eevblog.com/forum/projects/got-my-new-batch-of-faulty-pcbs-!/

Where I was kindly taught by members here that PCB design for higher speed parts is a bit more involved. if you guys think I'm crazy, maybe you should take it up with those who helped me in that thread?  here's an example reply:

https://www.eevblog.com/forum/projects/got-my-new-batch-of-faulty-pcbs-!/msg148192/#msg148192

was he wrong? because that advice (and others) certainly fixed my problems.

EDIT: actually, okay. I admit the problem I was having in that other thread was in regards to higher speed, not necessarily them being 32bit. when I said "32bit is harder to design pcbs for" I kind of meants high-speed 32bit. I should have elaborated.

[WarSim]

I must have been lucky/unlucky, then, because I started with 8bit mcus and they were incredibly easy to design PCBs for, while I had so many problems getting 32bit mcus to function properly on my own layouts. even started a thread about it here, last year:

https://www.eevblog.com/forum/projects/got-my-new-batch-of-faulty-pcbs-!/

Where I was kindly taught by members here that PCB design for higher speed parts is a bit more involved. if you guys think I'm crazy, maybe you should take it up with those who helped me in that thread?  here's an example reply:

https://www.eevblog.com/forum/projects/got-my-new-batch-of-faulty-pcbs-!/msg148192/#msg148192

was he wrong? because that advice (and others) certainly fixed my problems.

EDIT: actually, okay. I admit the problem I was having in that other thread was in regards to higher speed, not necessarily them being 32bit. when I said "32bit is harder to design pcbs for" I kind of meants high-speed 32bit. I should have elaborated.

Re-edit:  What you actually want to say, so you are saying something actually correct is. 

Any IC with with higher exposed frequencies that require special attention to PCB design are more difficult to design for. 

With your statement that you happened upon this consideration for the first time with 32bit MCUs, would indirectly support you experiences. 

If anyone has difficulty maintaining signal integrity under 80MHz, they should read more and learn more.  Above 80MHz you should use signal safe practices as required.  400MHz ball park range is when the designs should specifically be focusing on signal integrity.  Multi GHz is about when everything is about good RF design.  Of course all of this is ballpark, there are many other factors that will effect these generalities. 

[AlfBaz]

EDIT: actually, okay. I admit the problem I was having in that other thread was in regards to higher speed, not necessarily them being 32bit. when I said "32bit is harder to design pcbs for" I kind of meants high-speed 32bit. I should have elaborated.

meh

Most of the high speed stuff happens inside the chip. conceivably the highest speed stuff would be the osc at around the 10-20MHz mark internally the pll ramps it up to whatever. Last time I looked max rise/fall times for any pin on a PIC32 was 10ns, hardly an issue unless your board is 1x1 meter

[AndyC_772]

Bear in mind that, when considering signal integrity, it's always the edge rate that matters, not the clock frequency. It's not something that's taught particularly well, or emphasized frequently and clearly enough.

It may well be the case that an output driving 10 MHz has slower edges than one which drives 100 MHz, but not necessarily so. If an I/O pin has a rise / fall time of, say, 2ns, it could easily require the same SI treatment whether it's carrying a 100 MHz clock or a reset signal that's only active once.

On the other hand, if a device runs at 10 MHz, chances are its I/O pin drivers will be designed to have slower rise / fall times, so it'll be easier to breadboard with and will be generally more forgiving of a bad PCB layout for that reason.

Check the edge rate, not the switching frequency.

[Rufus]

Bear in mind that, when considering signal integrity, it's always the edge rate that matters, not the clock frequency. It's not something that's taught particularly well, or emphasized frequently and clearly enough.

Edge rate - would be the rate at which edges occur under any sensible interpretation of the english language. Not really helping clarity is it?

[mrflibble]

Edge rate - would be the rate at which edges occur under any sensible interpretation of the english language. Not really helping clarity is it?

With edge rate he no doubt means slew rate. And lets not get into "sensible interpretation of the english language" because, yes just for the fun of it I checked the dictionary definition of "slew". Natural languages and their usage are not exactly a bastion of logic.

[alm]

Edge rate is a perfectly standard term for slew rate. See this Altera appnote for example.

[Rufus]

Edge rate is a perfectly standard term for slew rate. See this Altera appnote for example.

A lot of people being wrong doesn't make something right.

Slew isn't right either since the required frequency components then also depend on the size of the signal.

Rise and fall times are what we should be talking about.

[AlfBaz]

Given my feeble technical background I have yet to come to terms with this.

Having seen and mucked around with BW=0.35/Tr it would seem that rise times have some obvious importance but here's where it's' difficult. If we have a rise time of 10ns on two waveforms where one goes from 0V to 1V and another from 0V to 10V, the gradient of the second will be much steeper and would have major impact on impedance since I=C(dV/dt) and since a lot if integrity issues are born from impedance mismatches then surely the rate of rise is important

[Rufus]

If we have a rise time of 10ns on two waveforms where one goes from 0V to 1V and another from 0V to 10V, the gradient of the second will be much steeper and would have major impact on impedance since I=C(dV/dt) and since a lot if integrity issues are born from impedance mismatches then surely the rate of rise is important

A 10ns rise time square wave of 1v and 1000v amplitude have exactly the same frequency spectrum, they travel down a transmission line at the same speed, and the same proportion of voltage will be reflected by transmission line impedance mismatches. The impedance of ideal passive components does not change with applied voltage.

[nctnico]

Any math to back that up?

[c4757p]

Having seen and mucked around with BW=0.35/Tr it would seem that rise times have some obvious importance but here's where it's' difficult. If we have a rise time of 10ns on two waveforms where one goes from 0V to 1V and another from 0V to 10V, the gradient of the second will be much steeper and would have major impact on impedance since I=C(dV/dt) and since a lot if integrity issues are born from impedance mismatches then surely the rate of rise is important

Impedance isn't the amount of current conducted, it's the amount of current conducted per volt.

[AlfBaz]

Thanks for the feedback guys

A 10ns rise time square wave of 1v and 1000v amplitude have exactly the same frequency spectrum

Ok I struggled to see that at first but then it dawned on me that to recreate the square waves by superpositioning the relevant odd harmonic frequencies, the amplitudes of those harmonics would be proportional to the square wave voltages, thereby producing the steeper edges but still using the same set of frequencies... am I close?

they travel down a transmission line at the same speed, and the same proportion of voltage will be reflected by transmission line impedance mismatches.

This makes sense. I forgot that one of the reason we have signal integrity issues is because the voltage creates an initial current determined by how much of the path is "seen" due to the relatively slow speed of electricity.

The impedance of ideal passive components does not change with applied voltage.

Impedance isn't the amount of current conducted, it's the amount of current conducted per volt.

So the impedance remains the same because I is soley dependant on dV as dt remains the same?

[c4757p]

Yes.

Z = v/i

Capacitor: i = C dv/dt

Z = v / (C dv/dt)

Z': Replace v by 2v; dv/dt becomes 2dv/dt:

Z' = (2v) / (2C dv/dt) = 2/2 v/(C dv/dt) = v/(C dv/dt) = Z

So doubling the input voltage does not change the impedance.

Edit: Sorry, mistake.

[jahonen]

Any math to back that up?

Perhaps this: The Fourier transform is a linear operator, so F{A*x(t)} === A*F{x(t)}.

Regards,
Janne

[mrflibble]

Perhaps this: The Fourier transform is a linear operator, so F{A*x(t)} === A*F{x(t)}.

If the system is linear time invariant, then problem solved.

[AlfBaz]

Yes.

Z = v/i

Capacitor: i = C dv/dt

Z = v / (C dv/dt)

Z': Replace v by 2v; dv/dt becomes 2dv/dt:

Z' = (2v) / (2C dv/dt) = 2/2 v/(C dv/dt) = v/(C dv/dt) = Z

So doubling the input voltage does not change the impedance.

Edit: Sorry, mistake.

Thanks Mr P 
This may help me understand something I was looking at the other week

[dannyf]

am I close?

Probably not. a 10ns rise to (say 0-100%) on 1000v means that the signal gets to 1v much faster than 10ns -> the slew rate on a 10ns 1000v signal is much higher than that of a 10ns 1v signal.

The original assertion is simply wrong.

[AlfBaz]

am I close?

Probably not. a 10ns rise to (say 0-100%) on 1000v means that the signal gets to 1v much faster than 10ns -> the slew rate on a 10ns 1000v signal is much higher than that of a 10ns 1v signal.

The original assertion is simply wrong.

I'm all ears...
Please explain this then

4 sim runs

Here are 2 FFT's of a 1 volt 1kHz square wave. Top FFT has 1ns rise/fall time bottom is  10ns rise/fall time where we can see a substantial difference in the high frequency content



Here we have FFT's of a 1kHz square both with 10ns rise/fall times but the top one is 1000V and the bottom is 1V pk... remarkably similar in frequency content

[c4757p]

am I close?

Probably not. a 10ns rise to (say 0-100%) on 1000v means that the signal gets to 1v much faster than 10ns -> the slew rate on a 10ns 1000v signal is much higher than that of a 10ns 1v signal.

The original assertion is simply wrong.

Slew rate alone does not determine frequency... assuming a reference level 0dB being the amplitude of the fundamental, the frequency spectrum of the two signals will be exactly identical.

[nctnico]

IMHO this is one of the situations where something works counter intuitive.
The maximum amplitude for an amplifier (lets say a signal source) with a given bandwidth is: slewrate/(2*pi*bandwidth) (*)
If we take a look at the risetime we would need a 100kV/s slewrate for the 1V/10ns square wave and a 100MV/ns slewrate for the 1000V/10ns square wave.

If we use the formula to calculate the bandwidth for a given slewrate and amplitude then it becomes: bandwidth=slewrate/(2*pi*amplitude)
Fill in:
bw1=100k/(2*pi*1)=15.9kHz
bw2=100M/(2*pi*1000)=15.9kHz

So the amplitude of a signal has no influence on the bandwidth. I also did some simulations with a 10MHz signal (which is closer to the frequencies of interest) to check the math but there is no difference in the frequency spectrum.

Ofcourse the amplitude of the 1000V square is much higher so relative to the 1V square the amplitude of all the frequencies present in the signal will be 1000 times stronger.

(*) More math here:
http://www.ece.uprm.edu/~mtoledo/5207/2011/bw.pdf