MAXQ Competitive Performance

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://www.maxim-ic.com/products...

Maxim is touting their new MAXQ2000/3000 line, and had a benchmark graph on the cover of their mailing. Mega8 was one of the competitors. MAXQ whomped the Mega8 on the thumbnail.

Going through the full info at the link above, the Mega8 didn't do bad at all. Especially consider the iterations/$ -- the Mega8 is a $2 part; the MSP430s used are $8-10; the MAXQ $4.

I thought the 8-bit AVR fared quite well against the competition listed.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uhm... just how did they arrive at the numbers in that top thumbnail?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The page and linked document are quite specific about test conditions, etc.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The main advantage I can see for the MAXQ is the inclusion of a MAC. It would certainly speed up many of the DSP-like operations.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh... the top graph attempts to merge results from two conflicting test conditions:

It is the results for running one specific benchmark source code, but the operating conditions are different for the first (highlighted) bar than they were for the other (red) bars.

The first (highlighted) bar shows Iterations/sec for the MAXQ using their choice of compiler, with optimizations turned on.

The rest of the bars (red) show TI's original data for Iterations/sec for other MCUs specifically using the IAR compiler, with all optimizations turned off.

Fortunately, that's the only graph that uses conflicting test conditions. The remaining test results below that point all show data with optimizations turned on for all devices, and the same brand of compiler is used for all MCUs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I read it, the 'MAXQ2 stumps everyone else' graph is MAXQ2 with compiler optimizations enabled vs. the data from the TI benchmarks which had NO optimizations enabled.
Looking at the test code, the advantage likely comes from being a 16-bitter. In other words, for I/O intensive things like bit banging one won't see the gains.
Downs: The UART won't run faster than 500kbps (M16@16MHz does 2Mbps), separate hardware stack (fast but limited, and a pain for task switching), expensive enough that one can buy an ARM7 based microcontroller instead. The price gap it's targeting isn't big these days.
Conclusion: I'd rather go for ARM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Benchmarks are benchmarks; you can make them come out to whatever you want. So of course Maxim marketing will put the best thumbnail at the attention-getting spot.

I followed up since the AVR was listed, and looked fairly good against the MSP430 on the thumbnail. Also, we are considering the AT90SAM7S for a new app (Incorporates the ARM7TDMI® ARM® Thumb® Processor) and was wondering what "multiple" of an AVR I would end up with. I was trying to think of a piece of code that I could run on one of my AVRs and on the AT91 to try to come up with some kind of "index". I didn't look at the code yet for the TI==>Maxim benchmarks yet, but it is at least something.

The bottom line: The AVR at 16MHz seemed to do nicely against other 8-bit listed processors, and certainly didn't get blown away by the listed 16-bitters. (Contrary to Maxim's statement, I'd consider an ARM in Thumb mode a 16-bitter, but that is kind of gray--is an 8088 an 8-bit or 16-bit processor to dig up the old debate.)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, the MAXQ2000 is faster. BUT where is the rest of the peripherals? Where is the EEPROM? The ADC? I may have been unfair to the MAXQ; I have not read its full data sheet, but from the preview they seem to be missing.

I think that in the embedded world, the priority is not the total CPU power as the compactness and -maybe- the power consumption, as long as everything is done in time.
In other words the smaller the PCB (ie. the lesser the parts), the better it is. My target have always been the one-chip solutions. If I need real horsepower I still have the ARM option.

Fot instance, though this should not have been an 8bit but a 16bit one, my current project is a smart, user-configurable, performance motorcycle ECU that handles the ignition as well as the injection too. And the obsolete-to-be m32's resources have not yet been exhausted. And if they do, I still have the m324/644/1281/2561 option.

Though it could finally turn to be a restrictive way, I really like the compact solutions.

Giorgos.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee, the 'bitness' of a cpu is normally based on its ALU and datapath. Therefore the 8088 is a 16 bit cpu (look at the times for an 8bit and 16 bit add). The ARM with its THUMB mode is another kettle of fish. The native instruction for the ARM is 32bits (as per the RISC requirement - keep all instructions the same length) and its ALU and datapath is 32 bits. What the thumb mode does is slim down the instruction length to 16 bits. Depending on the exact configuration of the cpu/cache/memory this can have speed advantages as well as code density advantages. The ALU is still 32 bits in the thumb mode.

We don't call the AVR a 16bit cpu because it fetches 16 bit instructions as we know it has a 8bit ALU and datapath.

Giorgos - I wouldn't have thought that the AVR would have not been a good choice for fuel injection since the you would normally require plenty of capture/compare. These days any sort of performance injection system has to do per cylinder adjustments for fuel and ignition - especially on V twins.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

Quote:
Benchmarks are benchmarks; you can make them come out to whatever you want

Absolutely!!

Some factors that contribute to my selecting a chip (or family), chip cost, cost of tools, the range of chips the tools will work with, pin to pin compatibility allowing for more Rom space within the same family , availability, reprogramable, different package types, support, and perhaps a dozen other things .

Being able to say, hey, were do one thing well, see here's our test data. Therefore were the best, is like adding 2 and 2 and getting 24.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Choosing CPU's is a vastly complex task! Especially in an environment like today where we have so many competing parts. I use a lot fo mega8's so I was intrigued to read the comparison. I won't be changing! The only nice thing is the MAXQ3120FFN has a couple of 16 bit ADC's. But mostly the 10 bit ones are fine. It only comes in a QFP package, whereas we prefer the MLF to get the size down. AND they dont appear to have a port of GCC yet!

If I need more horsepower than my $1.50 ATmega8, then I can get an LPC21xx fmaily ARM7 for about $6 versus the $5 MAXQ3120. Even an Atmel AT91S is only in the $12-15 class. So I, like a lot of the rest of you it seems, cant see a reason to change away form a product that gives me plenty of package/peripheral choices with easy code migration from part to part.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Even an Atmel AT91S is only in the $12-15 class.

Not really true, oh processor-breath.

The AT91SAM7S series was announce by Atmel as having break-through pricing for ARMs. Now that several flavours are in stock at distributors that claim seems to have been borne out.

A [very rough] comparison between the AT91SAM7S64 and the ATMega64:

--Both have roughly the same microcontroller subsystems: ADC, PWM, timers, TWI, SPI, UARTs, brown out, clock dividers, sleep modes, .
--S64 has less general I/O (32 to 52? for Mega64); S64 has ~8 "special" I/O (4 A/D; USB; and I forget the rest)
--Both 64k flash; S64 has 16k SRAM vs. 4k for Mega64. S64 would have to emulate Mega64 EEPROM with flash pages.
--Mega64 has external bus interface; none on S64
--S64 has extra peripheral subsystems: SSC that can do I2S and others; DMA; extra UART for "debug port"; full-speed USB; full modem control on one UART, partial on another.
--Both 10-bit 8-channel A/D; S64 is 300+ksps with dedicated external trigger pin
--Same package size & pins QFP64
--S64 is a bit cheaper than Mega64 in qty. 1 & 100

I believe that the AT91SAM7X series which adds Ethernet 10/100 MAC is also supposed to be attractively priced.

A very similar comparison can be made between the AT91SAM7S32 and ATMega32, including the pricing.

I didn't start the thread to have another Processor War installment, but I kind of suspected it might happen. :) I just thought the Maxim article was interesting & pertinent.

We are considering the SAM7S for a new app to get the streaming I2S/DMA. Good MIPS/watt and not expensive.

I haven't fully explored the Philips ARM offerings, but I think they are supposed to come out (or already have) with similarly priced models.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since gap between ARM and 'big 8 bit uC' (like Mega64) is very small, then I will ask where is enough room for 16 bit uC?

We are considering too the step between M64 and ARM instead of M128 for our next product family (dataloggers with ZigBee).

Guillem.

Guillem.
"Common sense is the least common of the senses" Anonymous.