PIC vs AVR vs ARM

Started by Miem October 2, 2006
Hi All,

As an amateur embedded circuit player, I have used couple of AVR and
PIC microcontrollers in the past.

In these days it is not to hard to find small, ARM based ready to use
embedded  boards under $100. They seems to have faster clock speed then
most of the AVR and PIC boards.

Can anybody shortly compare ARM with PIC ad AVR interms of (a)
performance (b) software support (c) price?

Regards,

Miem

Miem wrote:

> Hi All, > > As an amateur embedded circuit player, I have used couple of AVR and > PIC microcontrollers in the past. > > In these days it is not to hard to find small, ARM based ready to use > embedded boards under $100. They seems to have faster clock speed then > most of the AVR and PIC boards. > > Can anybody shortly compare ARM with PIC ad AVR interms of (a) > performance (b) software support (c) price? > > Regards, > > Miem >
(a) Significantly better. You can't beat it with an 8-bit processor. (b) At least as good, particularly if you don't mind gnu tools. (c) It'll be harder to really shave the pennies off in a high- volume application, and a bare-minimum ARM board will be bigger, more power hungry and have a higher BOM cost than a bare- minimum AVR or PIC board. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.html
> ...
> (c) It'll be harder to really shave the pennies off in a high- > volume application, and a bare-minimum ARM board will be bigger, > more power hungry and have a higher BOM cost than a bare- > minimum AVR or PIC board.
AVR has wider operating voltage range than ARM, which is useful for dealing with different logic devices.
linnix wrote:
> > ... > > (c) It'll be harder to really shave the pennies off in a high- > > volume application, and a bare-minimum ARM board will be bigger, > > more power hungry and have a higher BOM cost than a bare- > > minimum AVR or PIC board. > > AVR has wider operating voltage range than ARM, which is useful for > dealing with different logic devices.
The only technical downsides to ARM are the minimum system complexity and power, as Tim already mentioned. As always in engineering, it comes down to 'it depends' and the dependency is, in this case, what you need (or want) to achieve with the system. If you need an ultra low current system monitor, it's hard to beat the AVR or PIC (I prefer the AVR for a number of reasons). So which is 'better' is a much harder question. Cheers PeteS
PeteS wrote:
> linnix wrote: >>> ... >>> (c) It'll be harder to really shave the pennies off in a high- >>> volume application, and a bare-minimum ARM board will be >>> bigger, more power hungry and have a higher BOM cost than a >>> bare- minimum AVR or PIC board. >> >> AVR has wider operating voltage range than ARM, which is useful for >> dealing with different logic devices. > > The only technical downsides to ARM are the minimum system complexity > and power, as Tim already mentioned. As always in engineering, it > comes down to 'it depends' and the dependency is, in this case, what > you need (or want) to achieve with the system. > > If you need an ultra low current system monitor, it's hard to beat the > AVR or PIC (I prefer the AVR for a number of reasons). So which is > 'better' is a much harder question. >
Some more things that come to mind... Size of package could be an issue as well. Not a lot of ARM options below 48 pins. Almost all ARM have JTAG so if you need OCD you lose multiple pins. Determinism when toggling I/O ports could be an issue. The ARM has to pass through a number of interfaces before the I/O pin is reached, and this can take some clock cycles and add jitter. This of course allows an AVR to run at lower clock frequqncy at the same toggle rate. Putting the I/O on the 32 bit ASB/AHB bus will help but the drawback is higher capacitance on the ASB/AHB bus which should increase power consumption. ARM parts typically lack byte addressable EEPROM. It is easy to prototype using DIL packages. Normally not available for ARM. The AVR has more (but narrower) registers allowing global variables to be stored there. Bit instructions. Generally AVR code is smaller than ARM code.
> Cheers > > PeteS
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
> Almost all ARM have JTAG so if you need OCD you lose multiple pins.
That is the positive side of ARM. Jtag is always there, and reliable. AVR Jtag, on the other hand, could be disabled, and thus un-reliable by definition.
On 2 Oct 2006 15:16:16 -0700, "linnix" <me@linnix.info-for.us> wrote:

>> Almost all ARM have JTAG so if you need OCD you lose multiple pins. > >That is the positive side of ARM. Jtag is always there, and reliable. >AVR Jtag, on the other hand, could be disabled, and thus un-reliable by >definition.
Last I looked, some years ago, ARM JTAG is also documented -- including the debug interface. Jon
Miem wrote:
> Hi All, > > As an amateur embedded circuit player, I have used couple of AVR and > PIC microcontrollers in the past. > > In these days it is not to hard to find small, ARM based ready to use > embedded boards under $100. They seems to have faster clock speed then > most of the AVR and PIC boards. > > Can anybody shortly compare ARM with PIC ad AVR interms of (a) > performance (b) software support (c) price? > > Regards, > > Miem
AVR and PIC aren't really comparable with ARM, the first two are very low cost/power 8 bit machines, the ARM is a higher power, higher cost 32 bit machine. If you need to make a device that needs to run on a coin cell for 2 years, you can't pick an ARM processor, if you need a CPU that can do real time FFT, a PIC won't do it.
steve <bungalow_steve@yahoo.com> wrote:

> AVR and PIC aren't really comparable with ARM, the first two are very > low cost/power 8 bit machines, the ARM is a higher power, higher cost > 32 bit machine. If you need to make a device that needs to run on a > coin cell for 2 years, you can't pick an ARM processor, if you need a > CPU that can do real time FFT, a PIC won't do it.
I thought so too, but the products from luminary micro (luminarymicro.com), discussed in this newsgroup recently and in Circuit Cellar, have changed my mind. They make ARM CPUs with very little RAM and flash, on the cheap.... they say less than one dollar in 10k quantities (from an advertising spiel) ttyl, --buddy
Buddy Smith wrote:

> I thought so too, but the products from luminary micro > (luminarymicro.com), discussed in this newsgroup recently and in Circuit > Cellar, have changed my mind. > > They make ARM CPUs with very little RAM and flash, on the cheap.... they > say less than one dollar in 10k quantities (from an advertising spiel) > > ttyl, > > --buddy
yes but they are very high power, I think 10x the power of the AVR at 1Mhz, if I remember correctly
Anton Erasmus wrote:
> On Mon, 15 Jan 2007 06:41:36 +0100, "Guy Fawkes" > <spare_the_rod@spoilthechild.com> wrote: >
<snip>
>> The only drawback with ARM is the development tools. Basically only the GNU >> toolset is available for ARM which is quite 'raw' compared to AVRStudio and >> MPLAB on both AVR and PIC. I wish someone would develop a nice IDE for ARM >> (open source and free, off course) with support for debugging and JTAG/ISP >> built-in. > > There are Eclipse and K-Develop based IDEs for ARM available. It might > be a bit tricky to put together for someone starting out, but quite a > few development boards provide already setup versions for download or > as a CD with the development board. > Rowley has a new personal licensing option which is quite inexpensive. >
Another option would be CodeSourcery, who make an Eclipse plugin and provide ready-to-run binaries. They have the advantage of being serious gcc developers (they are the official maintainers for some ports, although I don't know about the ARM). Of course, there are other options - the ColdFire microcontrollers cover a similar range of speed and features (some better, some worse) to the ARMs, but are much nicer to work with at a low level. <snip>
On Mon, 15 Jan 2007 06:41:36 +0100, "Guy Fawkes"
<spare_the_rod@spoilthechild.com> wrote:

> >"Miem" <MiemChan@gmail.com> schreef in bericht >news:1159777724.426016.42900@b28g2000cwb.googlegroups.com... >> Hi All, >> >> As an amateur embedded circuit player, I have used couple of AVR and >> PIC microcontrollers in the past. >> >> In these days it is not to hard to find small, ARM based ready to use >> embedded boards under $100. They seems to have faster clock speed then >> most of the AVR and PIC boards. >> >> Can anybody shortly compare ARM with PIC ad AVR interms of (a) >> performance (b) software support (c) price? >> > >The only drawback with ARM is the development tools. Basically only the GNU >toolset is available for ARM which is quite 'raw' compared to AVRStudio and >MPLAB on both AVR and PIC. I wish someone would develop a nice IDE for ARM >(open source and free, off course) with support for debugging and JTAG/ISP >built-in.
There are Eclipse and K-Develop based IDEs for ARM available. It might be a bit tricky to put together for someone starting out, but quite a few development boards provide already setup versions for download or as a CD with the development board. Rowley has a new personal licensing option which is quite inexpensive.
>Aside from that (huge) drawback I believe ARM is by far the best platform, >it's far more powerfull than AVR and PIC and costs about as much (sometimes >even less). There's also a growth path from ARM to StrongARM on to XScale >(which as PC processor horsepower) whereas AVR and PIC top out at about >20MIPS and have limited memory addressing capabillity. ARM also gives one >the abillity to run very large software stacks (such as Linux or eCos) and >high-quality GUI's (such as Microwindows). None of this is possible with >AVR/PIC.
I agree that it is a huge drawback to have to get to grips with command line GNU tools as well as with a new architecture at the same time. I would suggest to the OP that he should use an existing AVR board he has got and get something going using WinAVR (gcc for AVR). Once he has played a bit with the GNU tools, it is much easier to get going with GNU and ARM. Regards Anton Erasmus
"Miem" <MiemChan@gmail.com> schreef in bericht
news:1159777724.426016.42900@b28g2000cwb.googlegroups.com...
> Hi All, > > As an amateur embedded circuit player, I have used couple of AVR and > PIC microcontrollers in the past. > > In these days it is not to hard to find small, ARM based ready to use > embedded boards under $100. They seems to have faster clock speed then > most of the AVR and PIC boards. > > Can anybody shortly compare ARM with PIC ad AVR interms of (a) > performance (b) software support (c) price? >
The only drawback with ARM is the development tools. Basically only the GNU toolset is available for ARM which is quite 'raw' compared to AVRStudio and MPLAB on both AVR and PIC. I wish someone would develop a nice IDE for ARM (open source and free, off course) with support for debugging and JTAG/ISP built-in. Aside from that (huge) drawback I believe ARM is by far the best platform, it's far more powerfull than AVR and PIC and costs about as much (sometimes even less). There's also a growth path from ARM to StrongARM on to XScale (which as PC processor horsepower) whereas AVR and PIC top out at about 20MIPS and have limited memory addressing capabillity. ARM also gives one the abillity to run very large software stacks (such as Linux or eCos) and high-quality GUI's (such as Microwindows). None of this is possible with AVR/PIC. -- Posted via a free Usenet account from http://www.teranews.com
> rickman wrote:
> > > Which ARM and AVR did you compare? At what speed? > > > ATmega128 and SAM7S64 at 4 MHz. > > > Hmm, the PLL on the SAM7 probably takes more current then the entire > ATmega128, but I guess you can disable that and run at 4Mhz directly > from the crystal, do you remember what is your total current was at > 4Mhz on the SAM7 device? > > steve
I can't reply directly to Steve because Google won't let me reply to a post older than 30 days. So I am replying to my post. I don't recall the exact numbers or method that we used last spring to figure this out, but I expect we measured it. I currently have a spread sheet from Atmel for the power consumption and it linearly derates the power by frequency with no offset. 18.236 mA is the figure it uses for 50 MHz. The only power drains I can't turn off in the spread sheet are 10 uA for the POR, 1 uA for the BOD (when off), 2 uA for the RC oscillator and 2 uA for the ADC (when off). This is executing from RAM with Flash disabled and everything off including the internal LDO (external core power). In a real app where I would use every peripheral except for one of the two UARTs and the USB, the current is still below 30 mA at 50 MHz or 2 mA at 3.125 MHz. I think that will give any of the 8 bit parts a run for the money, especially considering that the SAM7 can be clocked slower given the higher performance of the CPU and the DMA that can keep the CPU in sleep mode until I/O data has been transferred to memory. In very low speed mode the SAM7S parts can run under 35 uA with the CPU chugging along at 500 Hz from RAM or 46 uA at 32 kHz. This is almost as good as sleep mode!
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
news:45294ac8$1@clear.net.nz...
> Wilco Dijkstra wrote: >> "rickman" <gnuarm@gmail.com> wrote in message >> news:1160312205.310331.133880@m7g2000cwm.googlegroups.com...
>> Where did you get that from? Volume production was scheduled >> for Q3, and it will take a few months before first shipments. And >> all documentation still refers to the initial preproduction run. > > Ouch - so design these in slowly, then ?
Do you have any idea how long it takes from start of production to actual shipment? If anything, LM is very aggressive in their timescales. http://www.automotivedesignline.com/products/193006369;jsessionid=HVMIQR1HTAYY0QSNDLQSKHSCJUNN2JVN
> > These are now 72Mhz devices, but comparing MHz alone is not such a big > deal anymore. These are Microcontrollers, and MANY things dictate design > selection, appart from some MHz spec.
Maximum frequency has never been a big deal in the ARM world - most MCUs run at a fraction of their maximum frequency. I've never heard anybody complaining that ARM chips are too slow!
>These new Philips devices have DMA ( as do Atmel's ) and Philips keep >expanding the peripheral support. > I see DMA, CAN, USB and Ethernet on the Philips devices, at a price point > that will depress Luminary investors.....
It's good competition is heating up a bit - low-cost highly integrated devices like that mean more 8/16-bit users will switch.
>> You won't ever see public benchmarking info from ARM or any of >> its licensees about actual chips, this is all under NDA. The best you >> get is amateuristic rubbish like the Keil benchmarking pages... >> >> I agree there is a general lack of impartial benchmarking, EEMBC is >> a mess (more marketing than benchmarking) and there is nothing else. > > Amazing, so ARM restricts what their users can say ?
It's not just ARM, it is common across the industry. Many commercial compiler vendors (ARM included) have anti-benchmarking clauses which stop users from publishing benchmark scores. EEMBC forbid any publication of scores until chips are finished, runs are certified and published on their website. This takes a lot of time and money, so everybody just shows scores to customers under NDA and never certifies or publishes them.
> Do ARM not realize that's a rather dumb thing to do, and will > harm their users efforts to compete agaist a growing number of > competition devices ?
I agree it is a bad strategy indeed. How much harm it does I'm not sure. At the low end people are more interested in codesize and peripherals rather than performance, and the new competitors (eg. AVR32, ZNEO) are not aiming at performance at all. Wilco
Wilco Dijkstra wrote:
> "rickman" <gnuarm@gmail.com> wrote in message > news:1160312205.310331.133880@m7g2000cwm.googlegroups.com... > >>Wilco Dijkstra wrote: >> >>>Sure, the current devices use a lot of power. We'll have to wait till >>>production, they might fix the issues and hopefully move to a >>>better process. However they are ahead on other aspects, I like the >>>50MHz zero-waitstate flash - nobody has flash that fast. >> >>Aren't you aware that the current devices *are* production? > > > Where did you get that from? Volume production was scheduled > for Q3, and it will take a few months before first shipments. And > all documentation still refers to the initial preproduction run.
Ouch - so design these in slowly, then ?
> >>Most of >>our apps are very power sensitive and I asked when they would be moving >>to a newer, lower power process. The answer was that they have no >>plans. > > > That's a shame.
It is for Luminary :) - but low power is not a rare requirement. Others are not standing still: http://www.automotivedesignline.com/products/193006369;jsessionid=HVMIQR1HTAYY0QSNDLQSKHSCJUNN2JVN These are now 72Mhz devices, but comparing MHz alone is not such a big deal anymore. These are Microcontrollers, and MANY things dictate design selection, appart from some MHz spec. These new Philips devices have DMA ( as do Atmel's ) and Philips keep expanding the peripheral support. I see DMA, CAN, USB and Ethernet on the Philips devices, at a price point that will depress Luminary investors..... <snip>
> > You won't ever see public benchmarking info from ARM or any of > its licensees about actual chips, this is all under NDA. The best you > get is amateuristic rubbish like the Keil benchmarking pages... > > I agree there is a general lack of impartial benchmarking, EEMBC is > a mess (more marketing than benchmarking) and there is nothing else.
Amazing, so ARM restricts what their users can say ? Do ARM not realize that's a rather dumb thing to do, and will harm their users efforts to compete agaist a growing number of competition devices ? -jg
"rickman" <gnuarm@gmail.com> wrote in message 
news:1160312205.310331.133880@m7g2000cwm.googlegroups.com...
> Wilco Dijkstra wrote: >> Sure, the current devices use a lot of power. We'll have to wait till >> production, they might fix the issues and hopefully move to a >> better process. However they are ahead on other aspects, I like the >> 50MHz zero-waitstate flash - nobody has flash that fast. > > Aren't you aware that the current devices *are* production?
Where did you get that from? Volume production was scheduled for Q3, and it will take a few months before first shipments. And all documentation still refers to the initial preproduction run.
>Most of > our apps are very power sensitive and I asked when they would be moving > to a newer, lower power process. The answer was that they have no > plans.
That's a shame.
>> Dhrystone numbers are available everywhere, including from Luminary: >> >> ARM7: ARM 0.9, Thumb 0.7 DMIPS/MHz >> ARM9: ARM 1.1, Thumb 0.9 DMIPS/MHz >> Cortex-M3 1.25 DMIPS/MHz >> >> These are comparisons of ARM7/ARM9/M3 hardware using the >> ARM compiler running from 32-bit zero-waitstate memory. As you >> know speeds will differ depending on the flash implementation. So >> if you want to know the speed of a particular MCU, you have to >> benchmark it yourself (manufacturers typically quote max speed >> of ARM code running from SRAM). > > Yes, so these are not measured benchmarks at all, they are simulations.
Hardware simulation (whether in software or on a FPGA) is as accurate as real hardware. They are based on the same RTL and so give identical results, the only difference is elapsed time... So yes, these are real measurements.
> We can assume they were realistic about the Cortex processor, but do > we know anything about how realistic the assumptions are about the ARM7 > and ARM9 simulations?
The ARM7 and ARM9 numbers are realistic when running from single cycle memory, so you get identical results on chips that have a cache, SRAM or TCM (eg. ARM920, ARM946). On MCUs with flash speeds can vary greatly due to width and waitstates. The Philips and Atmel chips are slowed down by waitstates, the Luminary devices aren't.
>> I always recommend you benchmark your own application on your >> MCU using your toolset rather than rely on micro benchmarks done >> by others. As I've explained before, Dhrystone is not the best possible >> benchmark, it underestimates the difference between ARM and Thumb >> and overestimates micro architecture features like fast branches. > > That is what people often say when claims are made about power levels > on the LM parts. In reality there currently is no data that actually > compares real ARM7 to real Cortex processors.
You won't ever see public benchmarking info from ARM or any of its licensees about actual chips, this is all under NDA. The best you get is amateuristic rubbish like the Keil benchmarking pages... I agree there is a general lack of impartial benchmarking, EEMBC is a mess (more marketing than benchmarking) and there is nothing else.
>> It is a well-known fact that 32-bit RISC CPUs are many times faster than >> 8/16-bit (mostly CISC) chips - around 20 times in the case of 8051... >> Yes, 1 ARM instruction can do the work of around 20 8-bit instructions! >> There aren't many comparisons available because they are hard to do >> and mostly pointless as you know who is going to win. One glance at >> the cycle timings does it for me :-) > > But as you say, there are many factors involved when comparing speeds, > not just cycle counts or clock speeds.
Like using the right compiler (and options) for example... Wilco
Wilco Dijkstra wrote:
> Sure, the current devices use a lot of power. We'll have to wait till > production, they might fix the issues and hopefully move to a > better process. However they are ahead on other aspects, I like the > 50MHz zero-waitstate flash - nobody has flash that fast.
Aren't you aware that the current devices *are* production? Most of our apps are very power sensitive and I asked when they would be moving to a newer, lower power process. The answer was that they have no plans.
> Dhrystone numbers are available everywhere, including from Luminary: > > ARM7: ARM 0.9, Thumb 0.7 DMIPS/MHz > ARM9: ARM 1.1, Thumb 0.9 DMIPS/MHz > Cortex-M3 1.25 DMIPS/MHz > > These are comparisons of ARM7/ARM9/M3 hardware using the > ARM compiler running from 32-bit zero-waitstate memory. As you > know speeds will differ depending on the flash implementation. So > if you want to know the speed of a particular MCU, you have to > benchmark it yourself (manufacturers typically quote max speed > of ARM code running from SRAM).
Yes, so these are not measured benchmarks at all, they are simulations. We can assume they were realistic about the Cortex processor, but do we know anything about how realistic the assumptions are about the ARM7 and ARM9 simulations?
> I always recommend you benchmark your own application on your > MCU using your toolset rather than rely on micro benchmarks done > by others. As I've explained before, Dhrystone is not the best possible > benchmark, it underestimates the difference between ARM and Thumb > and overestimates micro architecture features like fast branches.
That is what people often say when claims are made about power levels on the LM parts. In reality there currently is no data that actually compares real ARM7 to real Cortex processors.
> It is a well-known fact that 32-bit RISC CPUs are many times faster than > 8/16-bit (mostly CISC) chips - around 20 times in the case of 8051... > Yes, 1 ARM instruction can do the work of around 20 8-bit instructions! > There aren't many comparisons available because they are hard to do > and mostly pointless as you know who is going to win. One glance at > the cycle timings does it for me :-)
But as you say, there are many factors involved when comparing speeds, not just cycle counts or clock speeds. Currently I am not believing that the CM3 processors are any better than the ARM7 parts until I see the evidence against real parts.
"rickman" <gnuarm@gmail.com> wrote in message 
news:1160256085.857608.36770@e3g2000cwe.googlegroups.com...
> Wilco Dijkstra wrote:
>> They can survive because they will make money once they get to volume >> production. Even with a tiny profit per chip selling millions of them >> means >> lots of money. > > But they have to get to the millions level pretty quickly to make that > work. Meanwhile they have completed two rounds of financing.
Absolutely, but they seem to be pushing hard for it. It will take a while before volumes are high enough they become profitable, but that is normal for a startup.
>> The initial devices are on an older process than the Atmel and Philips >> devices. Even so, since the M3 is a lot faster, it doesn't need to run at >> the same frequency as other MCUs so it may actually use less power. > > That is not at all clear. "May" is a word that has been used a lot > with these parts and I am still waiting for the evidence. At a 2:1 > power ratio for the max speed and with the other parts running at > higher clock rates, the LM parts need to do a lot of catching up.
Sure, the current devices use a lot of power. We'll have to wait till production, they might fix the issues and hopefully move to a better process. However they are ahead on other aspects, I like the 50MHz zero-waitstate flash - nobody has flash that fast.
>> You're falling into the MHz = performance trap. An M3 is about twice >> as fast as ARM7 MCUs running Thumb code (it runs Thumb-2 >> code at the same efficiency of an ARM9 running ARM code). That >> means you don't need to run at a high frequency to get the same >> performance, and you use less power due to the lower frequency. > > Again, where are the benchmarks to show this? I'm not talking about > stuff from simulations of an instruction set, I mean comparisons of an > ARM7 chip and a Cortex chip.
Dhrystone numbers are available everywhere, including from Luminary: ARM7: ARM 0.9, Thumb 0.7 DMIPS/MHz ARM9: ARM 1.1, Thumb 0.9 DMIPS/MHz Cortex-M3 1.25 DMIPS/MHz These are comparisons of ARM7/ARM9/M3 hardware using the ARM compiler running from 32-bit zero-waitstate memory. As you know speeds will differ depending on the flash implementation. So if you want to know the speed of a particular MCU, you have to benchmark it yourself (manufacturers typically quote max speed of ARM code running from SRAM). I always recommend you benchmark your own application on your MCU using your toolset rather than rely on micro benchmarks done by others. As I've explained before, Dhrystone is not the best possible benchmark, it underestimates the difference between ARM and Thumb and overestimates micro architecture features like fast branches.
>> A 20MHz Cortex-M3 is faster than just about all existing 8/16-bit CPUs, >> including for example a 100MHz single cycle 8051. And the 50MHz >> version outperforms current ARM7 MCUs by a huge margin. > > Are there benchmarks to show this? I would think LM would be posting > these all over their web site and I don't see any.
It is a well-known fact that 32-bit RISC CPUs are many times faster than 8/16-bit (mostly CISC) chips - around 20 times in the case of 8051... Yes, 1 ARM instruction can do the work of around 20 8-bit instructions! There aren't many comparisons available because they are hard to do and mostly pointless as you know who is going to win. One glance at the cycle timings does it for me :-) Wilco
Wilco Dijkstra wrote:
> "An Schwob in the USA" <schwobus@aol.com> wrote in message > news:1160196565.981433.178410@i42g2000cwa.googlegroups.com... > > > > On Oct 3, 1:56 am, Joseph <joseph....@somewhere-in-arm.com> wrote: > > >> LMI is not financed by ARM. We are two different companies, and LMI > >> is a ARM partner. > > Sure different companies but almost as sure ARM puts in a lot of money > > into Luminary. How could they otherwise survive? > > ARM did invest a small amount, but only a tiny amount of what a startup > needs. > > They can survive because they will make money once they get to volume > production. Even with a tiny profit per chip selling millions of them means > lots of money.
But they have to get to the millions level pretty quickly to make that work. Meanwhile they have completed two rounds of financing.
> > Having devices that > > use the lowest power ARM CPU yet they are much higher current than > > SAM7 or LPC2000. > > The initial devices are on an older process than the Atmel and Philips > devices. Even so, since the M3 is a lot faster, it doesn't need to run at > the same frequency as other MCUs so it may actually use less power.
That is not at all clear. "May" is a word that has been used a lot with these parts and I am still waiting for the evidence. At a 2:1 power ratio for the max speed and with the other parts running at higher clock rates, the LM parts need to do a lot of catching up.
> > THe marketing gimick of the 99 cent device which I yet have to see > > available anywhere is a 20 MHz max 28-pin device. You get an LPC2101 > > for a $1.47 @ 10k that runs 3.5 times faster, uses a lot less current > > You're falling into the MHz = performance trap. An M3 is about twice > as fast as ARM7 MCUs running Thumb code (it runs Thumb-2 > code at the same efficiency of an ARM9 running ARM code). That > means you don't need to run at a high frequency to get the same > performance, and you use less power due to the lower frequency.
Again, where are the benchmarks to show this? I'm not talking about stuff from simulations of an instruction set, I mean comparisons of an ARM7 chip and a Cortex chip.
> A 20MHz Cortex-M3 is faster than just about all existing 8/16-bit CPUs, > including for example a 100MHz single cycle 8051. And the 50MHz > version outperforms current ARM7 MCUs by a huge margin.
Are there benchmarks to show this? I would think LM would be posting these all over their web site and I don't see any.