AVR32 availablilty ?

Sure ARM9 royalties are a bit higher, but ARM7 are a bit lower. The $0.15 average royalty consists of ~60% ARM7, ~40% ARM9, so it is the relevant number to use if you expect a similar mix.

replacing all your current ARM

emerging

If you could get a big segment of the smartcard market you would indeed get good volumes. It's a mixed blessing as smartcards don't attract high royalties. So while

100M units at $0.10 royalty sounds nice, it would be nontrivial to actually get there.

You can use fewer people but then it takes more time to develop something. The total investment is going to be similar but you risk a competitor getting in there before you.

Wilco

Reply to
Wilco Dijkstra
Loading thread data ...

You do get similar pinouts for cores with a different amount of memory or peripheral mix but only from one manufacturer. I wouldn't expect any standardisation between manufacturers - after all they are competitors...

Remember ARM sells something like 3 billion cores a year nowadays, so the actual royalty per core is only $0.15. I don't know the ASP of ARMs but it is likely around $5, ie. a few percent goes to royalties.

As I've been saying for years, recompiling code is not really an issue as few people use assembler these days. However if you move between different architectures you have the tools cost, the learning curve and obviously porting of peripheral or CPU specific code. Overall, it is still a significant cost, especially if it involves training many engineers or porting a large codebase. For this reason many companies prefer to standardise on a single architecture.

Not exactly the same situation... I'm sure you didn't mean to compare ARM with PIC :-)

Wilco

Reply to
Wilco Dijkstra

"Wilco Dijkstra" skrev i meddelandet news:yhYXi.20474$ snipped-for-privacy@newsfe3-gui.ntli.net...

I said that the DSP "operations" are faster on the AVR32, and that is what I meant. I have clarified that DSP "operations" is not the same as DSP "code", and you still wine and try to put things I have not said into my mouth.

You load 32 bits in a clock cycle with the AVR32 which is two samples/constants The ARM7 cannot easily do the same thing since it cannot multiply anything in the high word of a 32 bit word, and the load instruction is 3 clocks. This gives 6 x performance for loading data. If you on top of that add that the ARM cannot handle unaligned 32 bit loads, you could see much worse data for the ARM, since it could be forced to trap if the programmer was sloppy.

They can, but noone will care too much for most applications, since repeated divisions is not very common in DSP application while repeated MACs are. Any comparision with the Cortex is really irrelevant for a discussion which revolves around, "why design an AVR32 core when there is an industry standard ARM7"

You are, as always, deviating from the subject of the discussion By promoting the Cortex, you just prove that I am right that it makes sense to design a new core. Seeing, how you twist and slither in these discussions, I doubt that you will be able to focus on the issue though.

--
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
Reply to
Ulf Samuelsson

Here is the low frequencies core power consumption data for UC3A and UC3B devices:

UC3A @ 1,8V F = 115 kHz, IccDyn = 470 uA F = 500 kHz, IccDyn = 750 uA F = 1 MHz, IccDyn = 1.1 mA F = 2 MHz, IccDyn = 1.9 mA F = 8 MHz, IccDyn = 6.2 mA

UC3B @ 1,8V F = 115 kHz, IccDyn = 280 uA F = 500 kHz, IccDyn = 450 uA F = 1 MHz, IccDyn = 670 uA F = 2 MHz, IccDyn = 1.2 mA F = 8 MHz, IccDyn = 3.8 mA

As a comparision, the ATmega644P uses (typical) 400 uA at 1 MHz (2,2V),

so the UC3B uses 37% more energy than an AVR at the same clock frequency.

Due to a faster implementation of internals (MIPS/MHz), I suspect that you can build a system using less energy to do a task with an AVR32.

The current crop of parts is using high performance transistors which results in higher leakage.

It would be interesting to know what could have been achieved if power optimized transistors like those on the SAM7L series had been used instead.

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

Reply to
Ulf Samuelsson

Someone wanted to clean out the stock of capacitors I guess.

Here is the recommendation from the product line:

For VDDPLL, VDDCORE and VDDIO, you should place a

10nF and 100nF capacitors in parallel per a group of 4 pins.

In addition you need to place one common 'bulk' for VDDPLL, VDDCORE and VDDIO with a value equal to C = I*dT/dV dT = frequency of this application dV = maximum of noise acceptable (50mV is a good choice) I = current consumption of circuit

In that case the AVR32 needs 11 capacitors for a 64 pins.

================================================================ STM32F10 (from

formatting link
VDD pins: (five 100 nF ceramic capacitor + one Tantalum capacitor (min. 4.7 ?F typ.10 ?F). VBAT pin must be connected to the external battery (1.8 V < VBAT < 3.6 V). if no external battery is used, this pin must be connected to VDD with a 100 nF external ceramic stabilization capacitor. The VDDA pin must be connected to two external stabilization capacitors (10 nF ceramic + 1 ?F Tantalum). The VREF+ pin can be connected to the VDDA external power supply. If a separate, external reference voltage is applied on VREF+, two 10 nF and 1 ?F capacitors must be connected on this pin. In all cases, VREF+ must be kept between 2.0 V and VDDA.

VDD: 6 caps VBAT: 1 cap or 1 battery VDDA: 2 caps VREF: 0/2 caps

Looks like STM32F10x need 8-11 caps, depending on configuration.

--
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
Reply to
Ulf Samuelsson

Thanks, that is great info. You kinda read my mind, I basically have an application that requires AVR levels of power consumption and CPU processing power but only need more RAM. So the AVR32 running at very low speeds seems like an option (or the SAM7L series maybe, but I still see that's in development on your site, so no info is yet available)

Reply to
steve

The ATmega1284P will have 16 kB of SRAM. The SAM7L will only have 6 kB of SRAM (to get the leakage current down) You should be able to get samples of both before the end of the year.

--
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
Reply to
Ulf Samuelsson

So data for the SAM7L should be close then ?

-jg

Reply to
Jim Granville

meddelandetnews: snipped-for-privacy@50g2000hsm.googlegroups.com...

ok thanks, 6K of SRAM on a 32 bit processor, that is a very limited market (or should I say maybe a few products use them, but they may sell a gillion of them) I suppose there is still hope with the xmega too

Reply to
steve

In SAM7L the L stands for LCD as well as Low power. It includes a LCD driver and voltage block, and so targets 'highly portable' and battery applications. It has a number of low power modes, including a voltage regulator that can trim both Iq and Vo, and has sub uA deep off, and low uA 'ticking over' modes. Unlike the AVR, it seems to have a uA region Low Freq RC osc. [That's the most glaring ommission in the AVR-P series: fine with a RTC Xtal, but very high LF-RC osc drain ]

So SAM7L IS a targeted part - for those apps, 6K is probably OK.

One large market it seems to miss, is electronic metering, but Atmel do not have that type of ADC block in their stable. You can get separate ADC front ends for metering.

Google SAM7L :)

-jg

Reply to
Jim Granville

Ok, yes nice SAM7L info on google, big part, also found the xmega datasheets,not much RAM there either (same as mega) guess I need external SRAM. STM32 has sub uA LF-RC osc drain, nice chip, but no LCD, always something missing :)

Reply to
steve

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.