On 7/22/2011 8:53 AM, KK6GM wrote:> On Jul 21, 3:28 pm, DJ Delorie<d...@delorie.com> wrote: >> Also compare power consumption. Renesas just came out with a >> brandy-spanking-new 8-bit chip family (they call it 16-bit but it's >> mostly 8-bit operations) specifically to address extreme low power >> designs. > > Just thinking out loud here. An 8-bit core is obviously (?) going to > be better on power consumption than a corresponding 32-bit core. > OTOH, an 8-bit core isn't a good fit for most real-world data, nor for*What* "real world data"? Do you need a 32b core in a mouse? Keyboard? Microwave oven? Controlling the power windows in your car? Running (i.e., *in*) your furnace or ACbrrr? As your "intelligent thermostat"? Scanning credit cards for sales authorizations? We see all these "big" applications (iPhones, etc.) with *huge* volumes... and forget that their actual volumes are *tiny* when you think of all the other "non-glorious" things that are out there "just doing their jobs"...> addressing, which is why 8-bit code spends a lot of time doing 16-bit > work. So is it possible that 16-bits will become the preferred ultra- > low-power sweet spot? More energy-per-instruction than an 8-bit, but > fewer instructions? I know this flies in the face of "16 is dying, > squeezed out by 8 and 32." Like I said, just thinking out loud...
Do you see any future to the 8-bit MCU's?
Started by ●July 21, 2011
Reply by ●July 22, 20112011-07-22
Reply by ●July 22, 20112011-07-22
On Fri, 22 Jul 2011 06:46:58 -0700, linnix wrote:> On Jul 21, 2:24 pm, Tim Wescott <t...@seemywebsite.com> wrote: >> On Thu, 21 Jul 2011 12:15:19 -0700, linnix wrote: >> > On Jul 21, 11:14 am, Tim Wescott <t...@seemywebsite.com> wrote: >> >> On Thu, 21 Jul 2011 11:06:23 -0700, linnix wrote: >> >> > On Jul 21, 9:46 am, Tauno Voipio <tauno.voi...@notused.fi.invalid> >> >> > wrote: >> >> >> On 21.7.11 6:30 , Antoni Lacasta i Sullà wrote: >> >> >> >> > Hi, >> >> >> >> > During the latest months I have been receiving offers for >> >> >> > 32-bit MCU's, mostly based on ARM-Cortex CPU's, at prices I'm >> >> >> > currently paying for 8-bit devices, or even cheaper! This has >> >> >> > brought me to benchmark them with the MCU independent part of >> >> >> > my C++ code and surprisingly the results are quite similar. >> >> >> >> > Same price, same flash consumption ... what do yo think? Is >> >> >> > this the end of the 8-bit's? I guess it is. >> >> >> >> > Regards, >> >> >> > Toni. >> >> >> >> I just redesigned an old card using a 8051, an A/D converter, a >> >> >> static RAM (2 kilobytes) and some glue logic. The new card was >> >> >> done with a Stellaris Cortex, LM3S818. All the IC:s on the new >> >> >> card costed together less than the A/D converter chip on the old >> >> >> design. >> >> >> >> When our current AVR -based designs need to be replaced, the >> >> >> Stellaris chips are the potential replacements. >> >> >> >> The Stellaris chips run fast with minimal electricity, but there >> >> >> is the price of a quite complicated set-up of the master and >> >> >> peripheral clocks and port pins. >> >> >> > Except for the price of the tools. AVR and PIC tools are still >> >> > much cheaper. We expect to spend around $1k for the new tools; >> >> > unfortunately, the cheap/low cost version won't cut it. >> >> >> I'm using the gnu-arm tool chain, built from source*. It works >> >> fine. >> >> > Does it work for Freescale's Cortex M4 w/ DSP? >> >> I don't know -- but it took to the Cortex M3 like wildfire. I suspect >> that the best you could hope for would be that the 'ordinary' C and C++ >> stuff would compile just fine, but anything DSP would have to be done >> in assembly, by hand. >> >> But then, that's the best I've ever gotten out of a 'paid for' tool >> chain. >> >> >> How much does CodeSourcery want for the 'real' tools? >> >> > Around 1K for most of them. >> >> Then unless you're facing a period of forced unemployment, just plain >> want to learn how to build the tools, or head up a big group and can >> set one person to being "the tools guy" it's probably worth it to buy, >> or to try out their free tool chain. >> >> > Yes, we are going to need DSP. I have fixed gcc and gas before. I can > probably hack in the necessary DSP instructions. I still need some kind > of JTAG/SWD programmer. Do TI/LMI and NXP programmers work on other > chips? If not, i will get the Freescale one. > > I am still waiting for the customer decision for this. If we buy, we > would need at least two licenses. If we build on a virtual server, > there is no limit.I don't know about specific company's programmers -- so far I've only used TI's. But I do know that the ARM JTAG programming interface is pretty generic. Your best bet for a programmer may be to get a 3rd-party one that's optimized for speed, or just get one of the cheapie Olimex ones that's optimized for price. -- www.wescottdesign.com
Reply by ●July 22, 20112011-07-22
On Jul 22, 9:23=A0am, Don Y <nowh...@here.com> wrote:> On 7/22/2011 8:53 AM, KK6GM wrote: > > > On Jul 21, 3:28 pm, DJ Delorie<d...@delorie.com> =A0wrote: > >> Also compare power consumption. =A0Renesas just came out with a > >> brandy-spanking-new 8-bit chip family (they call it 16-bit but it's > >> mostly 8-bit operations) specifically to address extreme low power > >> designs. > > > Just thinking out loud here. =A0An 8-bit core is obviously (?) going to > > be better on power consumption than a corresponding 32-bit core. > > OTOH, an 8-bit core isn't a good fit for most real-world data, nor for > > *What* "real world data"? > > Do you need a 32b core in a mouse? =A0Keyboard? =A0Microwave oven? > Controlling the power windows in your car? =A0Running (i.e., *in*) > your furnace or ACbrrr? =A0As your "intelligent thermostat"? > Scanning credit cards for sales authorizations? > > We see all these "big" applications (iPhones, etc.) with *huge* > volumes... and forget that their actual volumes are *tiny* when > you think of all the other "non-glorious" things that are out there > "just doing their jobs"... > > > > > addressing, which is why 8-bit code spends a lot of time doing 16-bit > > work. =A0So is it possible that 16-bits will become the preferred ultra=-> > low-power sweet spot? =A0More energy-per-instruction than an 8-bit, but > > fewer instructions? =A0I know this flies in the face of "16 is dying, > > squeezed out by 8 and 32." =A0Like I said, just thinking out loud...- H=ide quoted text -> > - Show quoted text -Huh? Where did I suggest 32-bit cores for anything? As to the question "what real-world data" the answer is any unsigned count or quantity over 255, or any signed count or quantity outside -128..+127. Including addresses. I doubt you'll find much 8-bit code that doesn't have any such data. It's an open question as to the distribution of the amounts of such data manipulation over all 8-bit applications. All I know for sure is that I've seen plenty of operations on such data ever since the 8080 days.
Reply by ●July 22, 20112011-07-22
On 7/22/2011 10:23 AM, Don Y wrote:> On 7/22/2011 8:53 AM, KK6GM wrote: >> On Jul 21, 3:28 pm, DJ Delorie<d...@delorie.com> wrote: >>> Also compare power consumption. Renesas just came out with a >>> brandy-spanking-new 8-bit chip family (they call it 16-bit but it's >>> mostly 8-bit operations) specifically to address extreme low power >>> designs. >> >> Just thinking out loud here. An 8-bit core is obviously (?) going to >> be better on power consumption than a corresponding 32-bit core. >> OTOH, an 8-bit core isn't a good fit for most real-world data, nor for > > *What* "real world data"? > > Do you need a 32b core in a mouse? Keyboard? Microwave oven? > Controlling the power windows in your car? Running (i.e., *in*) > your furnace or ACbrrr? As your "intelligent thermostat"? > Scanning credit cards for sales authorizations? > > We see all these "big" applications (iPhones, etc.) with *huge* > volumes... and forget that their actual volumes are *tiny* when > you think of all the other "non-glorious" things that are out there > "just doing their jobs"...LOL, remember that there is an two 8049s shipped with every computer ever sold !!! One is in the keyboard. The other is in the keyboard controller on the motherboard. So for every one million computers shipped, there are two million 8049s shipped. hamilton> >> addressing, which is why 8-bit code spends a lot of time doing 16-bit >> work. So is it possible that 16-bits will become the preferred ultra- >> low-power sweet spot? More energy-per-instruction than an 8-bit, but >> fewer instructions? I know this flies in the face of "16 is dying, >> squeezed out by 8 and 32." Like I said, just thinking out loud...
Reply by ●July 22, 20112011-07-22
On 7/22/2011 9:40 AM, KK6GM wrote:> On Jul 22, 9:23 am, Don Y<nowh...@here.com> wrote: >> On 7/22/2011 8:53 AM, KK6GM wrote: >> >>> On Jul 21, 3:28 pm, DJ Delorie<d...@delorie.com> wrote: >>>> Also compare power consumption. Renesas just came out with a >>>> brandy-spanking-new 8-bit chip family (they call it 16-bit but it's >>>> mostly 8-bit operations) specifically to address extreme low power >>>> designs. >> >>> Just thinking out loud here. An 8-bit core is obviously (?) going to >>> be better on power consumption than a corresponding 32-bit core. >>> OTOH, an 8-bit core isn't a good fit for most real-world data, nor for >> >> *What* "real world data"? >> >> Do you need a 32b core in a mouse? Keyboard? Microwave oven? >> Controlling the power windows in your car? Running (i.e., *in*) >> your furnace or ACbrrr? As your "intelligent thermostat"? >> Scanning credit cards for sales authorizations? >> >> We see all these "big" applications (iPhones, etc.) with *huge* >> volumes... and forget that their actual volumes are *tiny* when >> you think of all the other "non-glorious" things that are out there >> "just doing their jobs"... >> >>> addressing, which is why 8-bit code spends a lot of time doing 16-bit >>> work. So is it possible that 16-bits will become the preferred ultra- >>> low-power sweet spot? More energy-per-instruction than an 8-bit, but >>> fewer instructions? I know this flies in the face of "16 is dying, >>> squeezed out by 8 and 32." Like I said, just thinking out loud...- Hide quoted text - >> >> - Show quoted text - > > Huh? Where did I suggest 32-bit cores for anything?The OP's post concerned 32b being "cheap enough" to make 8b cores obsolescent.> As to the question "what real-world data" the answer is any unsigned > count or quantity over 255, or any signed count or quantity outside > -128..+127. Including addresses. I doubt you'll find much 8-bit code > that doesn't have any such data. It's an open question as to the > distribution of the amounts of such data manipulation over all 8-bit > applications. All I know for sure is that I've seen plenty of > operations on such data ever since the 8080 days.What sort of number crunching do you think goes on inside a microwave oven? Or, when you push the "open" button for your car window? Or when your furnace decides "Yes, the igniter *has* lit the gas so I can keep it flowing and don't have to retry the ignition sequence"? Or, when your *toaster* decides the toast is ready?? Do you think all n-bit processors have n-bit ALU's? Extending the precision of a computation is such a rudimentary operation that folks don't even *think* of it in deciding how complex an application is ("OK, I need to keep track of time... that will be 6 *digits* for HH:MM:SS, 2 more for day, 2 more for month and some number for year -- plus whatever I need for a prescaler"). With HLL's, you don't even *see* this. I.e., there are very few applications that deal with SINGLE *CHARACTERS* yet we have no problem running those "*string* applications" on 8, 16 or 32b processors. We just inherently know that the cost of operating on a string exceeds the cost of operating on a character (just like the cost of operating on a long exceeds the cost of operating on a short) (I know of products that do everything in BCD. So, [0..9] is effectively their concept of "real world data") It's surprising how few (percentage-wise) applications really *need* 32b power. Especially when you consider how fast instruction cycles have become (want to buy some 600ns 2KB EPROMs?). Work with something truly RISC-y (e.g., 8x300, SPARC, etc.) to get a feel for how easily you can trade cycles for complexity.
Reply by ●July 22, 20112011-07-22
On Jul 22, 9:32=A0am, Tim Wescott <t...@seemywebsite.com> wrote:> On Fri, 22 Jul 2011 06:46:58 -0700, linnix wrote: > > On Jul 21, 2:24=A0pm, Tim Wescott <t...@seemywebsite.com> wrote: > >> On Thu, 21 Jul 2011 12:15:19 -0700, linnix wrote: > >> > On Jul 21, 11:14=A0am, Tim Wescott <t...@seemywebsite.com> wrote: > >> >> On Thu, 21 Jul 2011 11:06:23 -0700, linnix wrote: > >> >> > On Jul 21, 9:46=A0am, Tauno Voipio <tauno.voi...@notused.fi.inval=id>> >> >> > wrote: > >> >> >> On 21.7.11 6:30 , Antoni Lacasta i Sull=E0 wrote: > > >> >> >> > Hi, > > >> >> >> > During the latest months I have been receiving offers for > >> >> >> > 32-bit MCU's, mostly based on ARM-Cortex CPU's, at prices I'm > >> >> >> > currently paying for 8-bit devices, or even cheaper! This has > >> >> >> > brought me to benchmark them with the MCU independent part of > >> >> >> > my C++ code and surprisingly the results are quite similar. > > >> >> >> > Same price, same flash consumption ... what do yo think? Is > >> >> >> > this the end of the 8-bit's? I guess it is. > > >> >> >> > Regards, > >> >> >> > Toni. > > >> >> >> I just redesigned an old card using a 8051, an A/D converter, a > >> >> >> static RAM (2 kilobytes) and some glue logic. The new card was > >> >> >> done with a Stellaris Cortex, LM3S818. All the IC:s on the new > >> >> >> card costed together less than the A/D converter chip on the old > >> >> >> design. > > >> >> >> When our current AVR -based designs need to be replaced, the > >> >> >> Stellaris chips are the potential replacements. > > >> >> >> The Stellaris chips run fast with minimal electricity, but there > >> >> >> is the price of a quite complicated set-up of the master and > >> >> >> peripheral clocks and port pins. > > >> >> > Except for the price of the tools. =A0AVR and PIC tools are still > >> >> > much cheaper. =A0We expect to spend around $1k for the new tools; > >> >> > unfortunately, the cheap/low cost version won't cut it. > > >> >> I'm using the gnu-arm tool chain, built from source*. =A0It works > >> >> fine. > > >> > Does it work for Freescale's Cortex M4 w/ DSP? > > >> I don't know -- but it took to the Cortex M3 like wildfire. =A0I suspe=ct> >> that the best you could hope for would be that the 'ordinary' C and C+=+> >> stuff would compile just fine, but anything DSP would have to be done > >> in assembly, by hand. > > >> But then, that's the best I've ever gotten out of a 'paid for' tool > >> chain. > > >> >> How much does CodeSourcery want for the 'real' tools? > > >> > Around 1K for most of them. > > >> Then unless you're facing a period of forced unemployment, just plain > >> want to learn how to build the tools, or head up a big group and can > >> set one person to being "the tools guy" it's probably worth it to buy, > >> or to try out their free tool chain. > > > Yes, we are going to need DSP. =A0I have fixed gcc and gas before. =A0I=can> > probably hack in the necessary DSP instructions. =A0I still need some k=ind> > of JTAG/SWD programmer. =A0Do TI/LMI and NXP programmers work on other > > chips? =A0If not, i will get the Freescale one. > > > I am still waiting for the customer decision for this. =A0If we buy, we > > would need at least two licenses. =A0If we build on a virtual server, > > there is no limit. > > I don't know about specific company's programmers -- so far I've only > used TI's. =A0But I do know that the ARM JTAG programming interface is > pretty generic. =A0Your best bet for a programmer may be to get a 3rd-par=ty> one that's optimized for speed, or just get one of the cheapie Olimex > ones that's optimized for price.Yes, i have the TI/LMI (based on FTDI). It would have been a cheaper solution for me. But eventually, Freescale won with the 16 bits A2D we needed.
Reply by ●July 22, 20112011-07-22
On 7/22/2011 9:58 AM, hamilton wrote:> On 7/22/2011 10:23 AM, Don Y wrote: >> On 7/22/2011 8:53 AM, KK6GM wrote: >>> On Jul 21, 3:28 pm, DJ Delorie<d...@delorie.com> wrote: >>>> Also compare power consumption. Renesas just came out with a >>>> brandy-spanking-new 8-bit chip family (they call it 16-bit but it's >>>> mostly 8-bit operations) specifically to address extreme low power >>>> designs. >>> >>> Just thinking out loud here. An 8-bit core is obviously (?) going to >>> be better on power consumption than a corresponding 32-bit core. >>> OTOH, an 8-bit core isn't a good fit for most real-world data, nor for >> >> *What* "real world data"? >> >> Do you need a 32b core in a mouse? Keyboard? Microwave oven? >> Controlling the power windows in your car? Running (i.e., *in*) >> your furnace or ACbrrr? As your "intelligent thermostat"? >> Scanning credit cards for sales authorizations? >> >> We see all these "big" applications (iPhones, etc.) with *huge* >> volumes... and forget that their actual volumes are *tiny* when >> you think of all the other "non-glorious" things that are out there >> "just doing their jobs"... > > LOL, remember that there is an two 8049s shipped with every computer > ever sold !!! > > One is in the keyboard. > The other is in the keyboard controller on the motherboard. > > So for every one million computers shipped, there are two million 8049s > shipped.It's worse than that. There's typically an 8b MCU in your CD/DVD drive. Another in your mouse. Some systems have one that acts as the "system monitor". What's in your WiFi adapter? etc. It's like *ants*. They seem so small and inconsequential that we ignore them. Oh, sure, we know that there are "a lot" of them. But, do we really know just how many?? IIRC, the cumulative **mass** of the "ants" exceeds that of "humans" on the planet by a HUGE margin!
Reply by ●July 22, 20112011-07-22
Don Y wrote:> Do you need a 32b core in a mouse? Keyboard?Optical and/or wireless mouse/keyboard.> Microwave oven?Unicode support for multi language user interface.> Controlling the power windows in your car?J1839 protocol stack. Running (i.e., *in*)> your furnace or ACbrrr? As your "intelligent thermostat"?Multi language user interface, connectivity and compatibility with the different hardwares.> Scanning credit cards for sales authorizations?Certified WAN-class TCP/IP stack and https.> We see all these "big" applications (iPhones, etc.) with *huge* > volumes...What you mentioned are all big applications for 32-bitters.> and forget that their actual volumes are *tiny* when > you think of all the other "non-glorious" things that are out there > "just doing their jobs"...Toys, smartcards, timers, RKE, sensors, battery maintainers, miscellaneous small controllers and other large volume standalone stuff is the area of 8- and 4-bit MCUs. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●July 22, 20112011-07-22
On Jul 22, 10:01=A0am, Don Y <nowh...@here.com> wrote:> On 7/22/2011 9:40 AM, KK6GM wrote: > > > > > > > On Jul 22, 9:23 am, Don Y<nowh...@here.com> =A0wrote: > >> On 7/22/2011 8:53 AM, KK6GM wrote: > > >>> On Jul 21, 3:28 pm, DJ Delorie<d...@delorie.com> =A0 =A0wrote: > >>>> Also compare power consumption. =A0Renesas just came out with a > >>>> brandy-spanking-new 8-bit chip family (they call it 16-bit but it's > >>>> mostly 8-bit operations) specifically to address extreme low power > >>>> designs. > > >>> Just thinking out loud here. =A0An 8-bit core is obviously (?) going =to> >>> be better on power consumption than a corresponding 32-bit core. > >>> OTOH, an 8-bit core isn't a good fit for most real-world data, nor fo=r> > >> *What* "real world data"? > > >> Do you need a 32b core in a mouse? =A0Keyboard? =A0Microwave oven? > >> Controlling the power windows in your car? =A0Running (i.e., *in*) > >> your furnace or ACbrrr? =A0As your "intelligent thermostat"? > >> Scanning credit cards for sales authorizations? > > >> We see all these "big" applications (iPhones, etc.) with *huge* > >> volumes... and forget that their actual volumes are *tiny* when > >> you think of all the other "non-glorious" things that are out there > >> "just doing their jobs"... > > >>> addressing, which is why 8-bit code spends a lot of time doing 16-bit > >>> work. =A0So is it possible that 16-bits will become the preferred ult=ra-> >>> low-power sweet spot? =A0More energy-per-instruction than an 8-bit, b=ut> >>> fewer instructions? =A0I know this flies in the face of "16 is dying, > >>> squeezed out by 8 and 32." =A0Like I said, just thinking out loud...-=Hide quoted text -> > >> - Show quoted text - > > > Huh? =A0Where did I suggest 32-bit cores for anything? > > The OP's post concerned 32b being "cheap enough" to make 8b cores > obsolescent. > > > As to the question "what real-world data" the answer is any unsigned > > count or quantity over 255, or any signed count or quantity outside > > -128..+127. =A0Including addresses. =A0I doubt you'll find much 8-bit c=ode> > that doesn't have any such data. =A0It's an open question as to the > > distribution of the amounts of such data manipulation over all 8-bit > > applications. =A0All I know for sure is that I've seen plenty of > > operations on such data ever since the 8080 days. > > What sort of number crunching do you think goes on inside a microwave > oven? =A0Or, when you push the "open" button for your car window? =A0Or > when your furnace decides "Yes, the igniter *has* lit the gas so I > can keep it flowing and don't have to retry the ignition sequence"? > Or, when your *toaster* decides the toast is ready?? > > Do you think all n-bit processors have n-bit ALU's? =A0Extending the > precision of a computation is such a rudimentary operation that > folks don't even *think* of it in deciding how complex an > application is ("OK, I need to keep track of time... that will be > 6 *digits* for HH:MM:SS, 2 more for day, 2 more for month and > some number for year -- plus whatever I need for a prescaler"). > With HLL's, you don't even *see* this. > > I.e., there are very few applications that deal with SINGLE *CHARACTERS* > yet we have no problem running those "*string* applications" on 8, 16 > or 32b processors. =A0We just inherently know that the cost of operating > on a string exceeds the cost of operating on a character (just like > the cost of operating on a long exceeds the cost of operating on a > short) > > (I know of products that do everything in BCD. =A0So, [0..9] is > effectively their concept of "real world data") > > It's surprising how few (percentage-wise) applications really *need* > 32b power. =A0Especially when you consider how fast instruction > cycles have become (want to buy some 600ns 2KB EPROMs?). =A0Work with > something truly RISC-y (e.g., 8x300, SPARC, etc.) to get a feel for > how easily you can trade cycles for complexity.- Hide quoted text - > > - Show quoted text -I don't think you're following my question. Let me try again. Remember, I was responding to a post about "extreme low power designs." 1) 8-bit cores presumably are lower-power than corresponding 16-bit cores. 2) 8-bit code will require more instructions than 16-bit code when dealing with >8-bit values, including addresses. 3) Might it be the case that the disadvantage of (2) offsets the advantage of (1) in many cases, thus making 16-bits a sweet spot in extreme low power designs? It may be true or it may be false, but it is not _obviously_ false to me.
Reply by ●July 22, 20112011-07-22
On 07/22/2011 07:01 PM, Don Y wrote:> It's surprising how few (percentage-wise) applications really *need* > 32b power. Especially when you consider how fast instruction > cycles have become (want to buy some 600ns 2KB EPROMs?). Work with > something truly RISC-y (e.g., 8x300, SPARC, etc.) to get a feel for > how easily you can trade cycles for complexity.In a lot of cases, the *need* for 32 bit is not the determining factor. In some cases, a capable 32 bit chip is cheaper than a similarly capable 8 bit device, and even when the 32 bit device is slightly more expensive, it may have other advantage, like a better high-level language support allowing shorter development times.
