Why are you still using 8 bit MCUs?

[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