I am beginning the design of a specialized voice recorder device. It needs to do decent quality voice recording (and play back) and it has a graphic LCD display that shows certain information about the context of the recording and shows simple animations. It also needs USB and memory card I/O capabilities.
I've been researching which microcontrollers might be suited to this purpose. I'm impressed by the relatively new AVR32 line. These seem to be inexpensive, low power, and (depending on the model) integrate a good deal of functionality, like 16bit ADC, USB controller, LCD controller, SmartMedia, even audio amp, etc. Also, free development tools are distributed by AVR that run on non-Windows platforms.
This all seems like a win. Am I missing something? Does anyone have a criticism of the AVR32, or a recommendation for a good alternative?
Yes; it's a sole-source core with little developer interest compared to the more mainstream offerings. Anything you can get in an AVR32 you can also get with a mainstream core like ARM or MIPS, and probably cheaper.
Could you suggest a good resource that gives an overview of the ARM core market? I'm having trouble finding a comparable ARM based mcu with USB, 16 bit ADC/DAC, LCD, etc. I don't doubt it's out there somewhere, but there are so many vendors and products that it's hard to find your way.
However I am not aware of anything wih that exact feature mix. AFAIK
16 bit ADC and DAC is non-existant on ARM. Even the few 12 bit capable devices are smaller devices, at the other end of the scale from devices with integrated USB and LCD.
Unless the 16 bit ADC/DAC is audio, in which case perhaps there is something media orientated (like i.mx? not looked.)
Your best bet is probably to have external ADC/DAC.
Try analog devices. They usually do good ADC/DAC Also ST Micros have a reputation for lots of IO on ARM parts.
That said..... almost any part (including MIPS) is going to be less popular than "ARM" per say. However you want an ARM core with a 16bit ADC/DAC so you will have to pick a single source implementation. That implementation may go away if it does not sell well. For example the Sharp ARM7 cores with the graphics controller. Though in that case NXP took over the parts.
The AVR32 is not likely to go away any time soon as Atmel have pinned a lot on it. Their other AVR's are very popular despite being single source. So I would say there is as much risk going with an Atmel AVR32 and any other chip implementation.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Personally, I wouldn't worry about not using an ARM chip, there are zero multi sourced ARM chips anyway (if whatever ARM chip you pick goes obsolete your screwed just like if the AVR32 goes obsolete). Pick whatever processor has the right combination of peripherals.
This is my web page and I am glad that people find it useful. However, I have to apologize for not keeping it up to date. I have intended to update it for some time now, but there are so many new devices and my time seems to always be so limited. In particular, there are always new devices from Atmel and Philips as well as some significant new devices from Luminary Micro. I also am aware of new Cortex M3 parts (STM32) from ST Micro which I have not even had a chance to really read up on. So please don't consider the above page to be complete in any way.
A 16 bit ADC on an MCU is likely not going to be a very good 16 bit ADC. If you really need anything nearly that accurate, you should consider a separate device. You will find that for the most part, a
16 bit ADC will run as much as the MCU... 12 bit ADCs, on the other hand, are a dime a dozen (although not literally).
Steve below makes a valid point. Although there is some commonality within the ARM family that your code can take advantage of, the peripherals are largely different between manufacturers. So it will not be easy to port application code between manufacturers. However, there are other concerns about using a proprietary device such as the AVR32. The main one is tools. Although Atmel may have supported tool vendors to develop compilers and debuggers for this devices, the tool vendors will sell a lot more of the ARM tool sets and it is very unlikely that the AVR32 tools will work as well as the ARM tools.
So if you have the resources to spend some extra time with development, you might get a better match between your application and the AVR32 devices lowering your unit costs. But if you need to optimize your development time and cost, you might want to stay with a more mainstream family.
I'd suggest looking at the Renesas SH2A series, in particular the 7263 which is designed for embedded audio and LCD control.
formatting link
The Hitach (Renesas) SH core has been around for 12+ years, unlike th AVR32, and there are dozens of variations of the architechture. All ar supported by multiple tools vendors like IAR and GCC. Check ou
formatting link
I also think an external A/D chip is a requirement if you need more tha
10 bits (if you don't believe me, do a calculation on the noise "floor for a system running at 3.3 volts and compare it to the resolution of a 1 or 16 bit A/D.)
There is a *free* gcc compiler suite, which is supported by Atmel. This is integrated with the *free* Eclipse based AVR32 Studio. Linux is free and can be easily built using buildroot
formatting link
This will also build the U-boot monitor.
You can also get the IAR Embedded Workbench for AVR32.
The AVR32 Gateway is a real low cost board (< $100 single qty) capable of running Linux (16 MB Flash and 32 MB SDRAM) which can be used as is, in many applications.
If you happen to have used the JTAGICE Mk II for the AVR, then the same unit will work with the AVR32, otherwise this is about $300.
--
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
ALL MCU are proprietary except the 8051 where there are multiple cores (over 40) some of which are FREE, and multiple implementations over 600 from about 60+ chip vendors.. The ARM core is single source and definitely NOT free.
I think you will find that the IAR compiler will be at a similar standard for both ARM and AVR32.
The Gcc is a movable feast and depending who's implementation (and library) you get is not going to be constant on any architecture let alone across architectures. However I would think that it is going to be as good on AVR as ARM.
Maybe but the same could be said for the AVR family in general. Or for that matter the PIC parts which are VERY non-standard and proprietary. They seem to do very well.
The AVR32 is still worth a look as it does have support from main stream tools. I am sure you will get a lot of support from Atmel.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
I wouldn't call ARM cores single source as they are produced by many different fabs but there are also several architecture licensees who produce their own implementations. The only thing that is single source is the ARM architecture, and that's exactly how you want it (or you get the mess the x86 "architecture" is in today).
Of course it's rare to see MCUs that have the exact same peripherals, are pin compatible and run at exact the the same frequency, voltage and power - this simply doesn't make sense commercially. I'm sure few 8051 implementations fit these criteria.
both ARM and AVR32.
Ie. code quality similar to GCC...
you get is not going to be constant on
is going to be as good on AVR as ARM.
GCC is far behind the state of the art on many architectures.
So? What does the fact gcc on HC11 sucks have to do with gcc on AVR32 or ARM? The 8-bit avr-gcc is exceptionally good.
What gcc needs to excel on a platform is a motivated sponsor. Atmel hired the developer of WinAVR, presumably to ensure that he has time to keep WinAVR current. I don't know but would think its a safe bet the way Atmel is backing Eclipse and gcc for the AVR32 that many full time employees are working there too.
As I'm sure you know, compilers share a lot of code between targets. One of GCC's weakest points is the register allocator, and this affects all targets (though not equally of course).
The latest GCC for ARM is pretty bad by any standard - the Thumb code it generates is often larger than ARM code from good ARM compilers! I haven't looked at AVR32 but since the instruction set is very similar to Thumb-2, there is no reason to believe it is much better than the ARM port.
True, it takes a lot of time and effort to create a good compiler. But you can avoid the fact that most GCC development is geared towards x86 and Lunix rather than small embedded CPUs. Think of the libraries for example.
I think you will find that it was a licensed ARM core in them,
Somewhere there was a Black ARM which was a non-ARM ARM core clone. I heard something of it about 4 years ago (It was confirmed in conversation with someone from ARM) However I have not looked for it since.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
StrongARM and XScale are different cores. Intel still sells the networking XScales. Marvell and Qualcomm also design their own set of high-end ARM cores. There are others that take an existing ARM core and optimise it for high performance, for example Samsung makes the high speed ARM11 used in the iPhone.
No, definitely not. These were not licensed ARM cores. They were new designs based on an ARM architecture. There are many ARM architecture licensees who make their own cores (see my other post).
something of it about 4 years ago (It was
for it since.
Illegal cloning is something different altogether...
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.