PIC vs AVR vs ARM

That will work if the other end is timed perfectly, but in reality you need to split the timing error budget between sender and receiver. So that gives you 2.5% in an otherwise perfect world. So in the real world 2% is a better figure.

Exactly. I was under the impression that on the newer parts internal oscillators were being trimmed and compensated to get under the 2% figure over temperature and voltage. But since I normally use crystals, I have not followed this closely.

Not when you can calibrate the R/C oscillator against a known source (like the incoming data on the serial port)

The LIN protocol for automotive application was designed to allow the use controllers running from an R/C oscillator.

The protocol start with a "wakeup" byte followed by a "calibration" byte and after that, the uC knows the bit time in clocks regardless of its current frequency.

So if you have a choice of protocol, and choose a protocol that requires a stable CPU clock, you just did not do your homework.

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

The theoretical limit (for 10-bit chars, including start and stop) is a

5% match. If each end is within 2.5%, you'll get a match - you don't need to chop off anything extra because of uneven splits. In fact, you can often *add* significant margins because of uneven splits - if one end is a PC, or other equipment with known tight margins, you might be confident of a 1% margin at the PC end, giving you 4% to play with at the embedded end.

However, there are other things that eat away at your margins. Assuming a balanced split, you need to aim for (0.5 / 10) / 2 = 2.5% for a half-bit error. If you want to take advantage of the majority vote noise immunity feature of many uarts, you want to be maximally 7/16 bits out over a total of 9 + 9/16 bits (only half the stop bit is used), giving you 4.6%/2 = 2.3% margins.

Then you need to look at your drivers, terminations, cable load, etc., and how they affect your timings. In particular, you are looking for the skew between the delays on a rising edge and the delays on a falling edge. These delays are absolute timings, independent of the baud rate and the length of each character.

Thermal and voltage effects will also affect your timing reference, and can be considered as part of the same margin calculations.

I'd say 2% for a simple RS-232 or RS-485 link that was not stretching speed or distance limits, and 1% when using optical isolation or cables with significant capacitance. YMMV, of course.

If you have good control of the environment (temperature and voltage), and simple links, then 2% is good enough. If one end of the communication link has a more precise reference, then 2% is more than sufficient.

The implementors largely worked for large companies selling computer hardware. They did their job.

Pete

Sure different companies but almost as sure ARM puts in a lot of money into Luminary. How could they otherwise survive? Having devices that use the lowest power ARM CPU yet they are much higher current than SAM7 or LPC2000. 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 at the same speed, offer more peripherals and a nice upgrade path that does not multiply the price just because the next device runs a whopping 25 MHz. This company (Luminary) can not really make any money with the devices that lack performance, are high power and can not keep up with the wide range of available ARM7 devices, so they must be sponsored and who but ARM would be interested to finance it?

Talking about ARM partner, the only thing that I see Luminary attacking are other ARM partners (canibalism!?)

They should compare themselves to the PIC24, dsPIC, AVRs (sorry Ulf), ST10, HC12, S12, MSP430..... you name them.

An Schwob

You are assuming facts not in evidence. If you read their web site you will see that they just completed a second round of financing...

"Luminary Micro closed its first private funding of $5M in February

2005 with lead investor EXA Ventures. Luminary Micro also closed a Series B of $14 million as announced on June 12, 2006. "

I am sure they are getting a ton of support from ARM and they may have gotten their initial funding in an indirect way from ARM. I have seen startups get free office space, free use of facilities and even the loan of personel from interested parties without showing it as "financing". But I have no doubt that at this point LM is self sufficient and will be turning a profit in the next year or so.

I don't agree that the $.99 LM3S101 is a "gimick". At that price point there are any number of sockets this device can steal from the 8 bit world. I seem to recall a PIC clone that ran at 50 MHz and emulated a lot of peripherals in software. Clearly there is a place for higher horsepower at the low price end of the market. These smallest parts are clearly aimed at the automotive market. If you don't think this market is significant, ask TI (whose ARM parts were only for automotive customers until a year or so ago) and Micronas who makes several ARM parts that they target to the automotive world. Neither TI nor Micronas make low power devices since this is not the factor in this segment that it is in other markets.

Of course they can make money. The claim of lacking performance is not in any way justified. Their core can run at 50 MHz from Flash with no wait states regardless of the code being executed which no other ARM part can do. The Philips parts use a lookahead buffer, but when a jump is executed you get a multi clock cycle delay while a new Flash access is started.

The high power claim is a bit exaggerated. LM parts use more power than the Atmel or Philips parts, but they are in the same ballpark as the ADI, ST and TI product lines. Are you suggesting that none of these four companies have a chance of competing in the ARM market place?

I'm not sure what that is supposed to mean. All ARM vendors compete against one another.

I guess you are referring to their marketing. My guess is that currently there is a lot of market focus on moving to the 32 bit world. There are any number of articles in the trade journals about how users are skipping 16 bits and moving directly from 8 bit parts to the 32 bit devices. In that context the smart marketing is to use that momentum as leverage and show your advantages over the other 32 bit devices.

I guess your requirements exclude the LM ARM devices. But that does not mean they are making inferior products. Different customers have different requirements.

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.

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.

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.

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.

Maybe it's a conspiracy?

On the contrary, Luminary is aiming their chips primarily to people who upgrade from 8-bit and 16-bit chips when they run out of steam. Other manufacturers can and do make cheap ARM MCUs, competition is good. What evidence do you have Luminary is "attacking" ARM partners?

Existing ARMs outperform most of those already by a large margin. In cases where they don't, the M3 does now - the M3 exists solely to beat the existing

8/16-bitters on every aspect. As it happens it does beat ARM7 as well, but then again ARM7 is over 10 years old...

Wilco

But they have to get to the millions level pretty quickly to make that work. Meanwhile they have completed two rounds of financing.

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.

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.

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.

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.

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.

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.

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

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.

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?

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.

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.

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.

That's a shame.

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.

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.

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.

Like using the right compiler (and options) for example...

Wilco

Ouch - so design these in slowly, then ?

It is for Luminary :) - but low power is not a rare requirement.

Others are not standing still:

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.....

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

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.

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!

It's good competition is heating up a bit - low-cost highly integrated devices like that mean more 8/16-bit users will switch.

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.

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

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!

"Miem" schreef in bericht news: snipped-for-privacy@b28g2000cwb.googlegroups.com...

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

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.

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

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.