AVR32 availablilty ?

Cortex-M3 doesn't

Reply to
steve
Loading thread data ...

You've missed the point - Lewin was the one advocating "..and reducing the number of target cores " - not me.

My point is that in the Design Selection process, the CORE features less and less. The CAPABILITY of the core of course matters, but if you have C cource, and good debug support, the designer never thinks at the Opcode level anyway!

I'd say the peripherals now dominate the selection choice, more than the core, and that will increase over time.

There are expanding selections choices of 32 bit uC cores (even MIPS are soon to join the fray), and I think the Low Cost Debug is now more important than the core. Vendors NEED to get designers' attention.

-jg

Reply to
Jim Granville

I can understand the 32 bits, it was the 768K and 100 pins that was more puzzling.

Of course, the bike you mention is not your 'average' journeyman bike either, and not many of the China/India growth infineon is chasing, will be in SV1000's :)

-jg

Reply to
Jim Granville

meddelandetnews: snipped-for-privacy@o3g2000hsb.googlegroups.com...

In fact for Smartcard, most people will happily use a 8 bit core..

Sure they could. It is a pity that Atmel didn't produce pin compatible ARM7 and AVR32 parts with the same peripheral mix That way, there would be minimal risk in migrating between AVR32 and ARM7, depending on the app. At least you could backtrack.

The problem with ARM is that despite the core licensing, there is no second source if you are looking for a pin compatible part with a particular peripheral mix. I think that if this problem was addressed, then there would be less argument about cores.

Of course the license cost is an issue. If you look at ARM's annual report, large amount of revenue are due to the per unit royalties. If you are trying to make a sub $10 part, then this could be a major issue.

one company

It will be interesting to see if Atmel license the AVR32 core eventually. It is the availability of ARM cores at places like TSMC, which help considerably.

I see no real issue migrating between ARM and AVR32 if the majority of the code is compiled. How much code (apart from I/O) tends to be hand- crafted in low/mid performance embedded apps these days? This is what happens in the smartcard market, multiple different cores are used running the same OS and App code.

We ended up choosing an AVR32 processor for our latest product, not because of the core, but because we couldn't find a single chip solution with USB 2.0 High Speed elsewhere (available in low volumes). I guess in the end you choose the solution that provides the features that you need at the price point you want to pay.

It would be interesting to go back a few years and apply the discussion to why develop the AVR, since there is the PIC ;)

Reply to
Andrew Burnside

Cortex-M3 does have MAC. Its multiplier is single cycle, and although accumulate needs another cycle due to register port limitations, it has significantly better DSP performance than ARM7. It also has all of the

64-bit multiplies of course.

Wilco

Reply to
Wilco Dijkstra

Sure, royalties are a recurring cost, but I don't believe your numbers are realistic. The average royalty per core is about $0.15 and that number goes down as volume increases and ASP decreases. The total royalty revenue that ARM receives for MCUs per year is about $20-$25M. This is of course split between many different manufacturers. I don't know Atmel's market share, but it surely isn't 100M units. Even replacing all your current ARM units with AVR32 is going to be a challenge...

A few million a year would be enough to pay for the cost of developing tools, but not for the team you need to develop your own architecture and cores ($5M a year allows you to employ just 35 people, not counting costs for EDA licenses and the cost of a server room for them to use).

You also hear about people making their own primitive cars or even helicopters. I'm sure when you ask about interrupts, debug, design for test etc the answer would be "eh, haven't thought about that". Quite superior indeed...

Wilco

Reply to
Wilco Dijkstra

The engine controller problem on a motorcycle is essentially the same as a car just with less cylinders to manage, primarily the problem of a separate core.

12000 rpm (200 rp second 100 or 200 engine cycles per cylinder per second) by itself is not a particular problem. Most race cars and dragsters are using standard engine controllers with software to support their unique requirements.

Motorcycles for quite a while were using PIC's and 8051's primarily for ignition and fuel metering. This is now changing.

There is quite a niche opening now for processor based engine control for lawn mowers and weed wackers now that they have been identified and significant contributors to pollution.

Regards

-- Walter Banks Byte Craft Limited Tel. (519) 888-6911 Fax (519) 746 6751

formatting link
snipped-for-privacy@bytecraft.com

Reply to
Walter Banks

TI DaVinci MCUs all have USB 2.0 High Speed controllers. Yes, high speed, not just full speed.

--
******************************************************************
*  KSI@home    KOI8 Net  < >  The impossible we do immediately.  *
 Click to see the full signature
Reply to
Sergey Kubushin

"Wilco Dijkstra" skrev i meddelandet news:v6iXi.119550$ snipped-for-privacy@newsfe7-gui.ntli.net...

An AP7000 is more comparable with an ARM926 which is more expensive than the average.

You dont develop a core for yesterdays market, you develop the core for emerging markets. The 32 bit market is expected to grow and if/when smart cards adopt this in volume, these figures are not unrealistic.

The AVR32 core(s) were developed by much less than 35 people.

Yep , all interrupts handled, and the core could execute any instruction in debug mode (not updating any status or PC), so that you could read out/modify anything in between two other instructions etc.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

And half that of the AVR32 which does a MAC in a single cycle using the MAC accumulator cache to handle register port limitation.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

meddelandetnews: snipped-for-privacy@19g2000hsx.googlegroups.com...

Hey, how come the AVR32 requires so many decoupling caps, you guys use

26(!) for your 64 pin eval board, i think that's a record for a 64 pin device

formatting link

STM32 recommends 7 on their 100 pin parts.

Reply to
steve

meddelandetnews: snipped-for-privacy@19g2000hsx.googlegroups.com...

Oh, one more question, does the AVR32 have a ultra low power mode like your ARM7 processors, it has an internal 115Khz clock but don't see any mention of ultra low power current consumption in the data sheets, just active and static numbers (maybe next revision of the datasheets?)

Reply to
steve

Have to check that.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

He was, as usual advocating making much of it Open (as in open source) . It never fails to amaze me how many who work in this industry don't understand it.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Now that really is disingenuous! With your attitude I am not surprised you have so much trouble with silicon vendors (plural) and tool vendors.

Ulf does talk about Atmel who he works for but AFAIKS he usually only puts up the facts. Personally I am surprised the Atmel marketing department haven't gagged him before now.

Quite probably. This is how the semiconductor industry has been since day one. And your point is?

BTW why would they be locked into the Atmel parts forever? Much as Ulf and Atmel would like that things don't happen like that. If everyone was "locked in" new companies like ARM would never have sold a license.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Actually AVR32 needs 2 cycles as well by default. It has an optimization that allows subsequent MACs to run in 1 cycle if they happen to use the same accumulator register. You need to change your code to take advantage of this and you can get undeterministic timing unlike real single cycle multipliers.

Wilco

Reply to
Wilco Dijkstra

You're as usual spinning marketing lies. Show me an example that proves it is a factor of 10. I bet you can't even show a factor of 5.

Wilco

Reply to
Wilco Dijkstra

He advocated (in this thread, at least) "opening documentation on the debugging protocols in use". Making documentation (for hardware, software, protocols, or whatever) openly available benefits almost everyone. In particular (from your viewpoint), I'm sure that most proprietary, closed source, commercial toolkit vendors would prefer more information from the hardware vendors, and would prefer it earlier and more easily available. The only people that might want that kind of information kept secret are big commercial vendors who want to corner the market for a processor by being the only ones with the information. That sort of behaviour does not help the hardware vendor, and it does not help end users (and it certainly does not help other toolkit vendors).

The word "open" has a much wider meaning than just "open source", you know.

Reply to
David Brown

Just do a series of MACs where you check for saturation and the AVR32 will excel. Note: There is a difference between DSP "operations" and DSP "applications".

I resent your comments about lies.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

They get the information usually well before the part is released. I know of a couple of occasions where debugger companies have fed information back and influenced the hardware design.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.