>> 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?"
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 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.
@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.
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.
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)
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
>> 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...
>> 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 .
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.
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...
I still use them cause I have over 300 pieces laying in a drawer, i use what I have unless its insufficient.
Why are you still using 8 bit MCUs?
One reason could be software: too expensive to port existing software to a new platform.
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!
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
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.
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.
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.
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? ...
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.
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?
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.
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?
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?
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.