Why are you still using 8 bit MCUs?

[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