I'm about to embark on a new project that will require a 32-bit microcontroller. I've spent the last month evaluating the merits of the various choices architecturely, and have a pretty good idea of what's out there. It's come down to development environments, and I'd like to get some first-hand reports from people on this group.
The three choices on my short-list are:
Pic32 and MPLAB
AVR32 and AVR32 Studio
ARM7 and Rowley CrossStudio for ARM
If anyone has any opinions on the relative merits of these three development environments (and the JTAG hardware that goes with them), I'd appreciate it.
I find this really hard to believe, but okay, fine:
Optimization not available in the freeware compiler (nobody really understands how they get away with this one on GPL grounds). MPLAB is a fairly primitive IDE originally designed for working on 8-bit assembly language files of a few hundred lines, but it works.
AVR32 Studio is Eclipse, which is full-featured but for my money very slow. The JTAG hardware is JTAG-ICE mk.II which is a rather finicky beast, at least when it's talking to other AVR parts; I haven't used it talking to an AVR32. When it works, it works fine, but it can get into a mood where disconnects, power-cycling target and emulator, and maybe even a reboot become necessary. In my benchmarking, the AVR32 compiler scored poorly on code density even with maximum optimization options turned on.
There is no specific JTAG hardware that goes with this combination so it's not possible to make a truly generic comment, but I use the CrossConnect Lite and it is trouble-free for me. CrossStudio+ARM would be my choice out of the three. Of course it gives you by far the widest choice of actual chips to work with, since the other two are proprietary, vendor-specific DKs (yes, I know PIC32 is MIPS, but MPLAB and Microchip C32 are decidedly NOT generic MIPS development tools, and AVR32 is of course totally proprietary).
You should also consider the SH2A and SH4A from Renesas. The SH has been around as long as the MIPS and ARM cores, and features super-scalar execution for fast operations with slower clock rates. You didn't say what the application was, but these chips excel at motor control, multimedia, and networking.
The best part is the tools. The SH MCU/MPU chips use the HEW environment which runs under windows and comes with either GNU or Renesas Compiler (256k binary code size limit for the free version.)
Look at the family roadmap diagram on the main web-page and pick a chip (like the 7263 series). There's also a link to on-line training tools.
formatting link
You can download the full development suite here and try it out.
Why is that so hard to believe? All of these microcontrollers are more similar than different. They all come with 256-512K of Flash, 32-64K of RAM, all have I2C, SPI, ADC, GPIO, timers, and other peripherals in very similar configurations. The base architectures are different, sure, but since I'll be writing all of my code in C, that really doesn't matter. Working with reasonable tools is far more important to me than whether the core is MIPS or ARM.
Does CrossStudio have the capability to display processor peripheral registers, such as the timer control registers, like the other IDEs do?
larwe writes about the MPLAB C compiler for PIC32:
I guess I'm "nobody", since I understand it without difficulty. Nothing in the GPL precludes defeaturing GPL'd software, provided that you meet the GPL terms.
They get away with it because they are fully in compliance with the GPL, which merely requires that if they distribute a binary built from modified sources, they have to provide the source code. They do provide the source code; it's on their web site and there's even a link from the compiler product page.
Anyone can download that source code, "fix" the problem, and have a compiler with full optimization. They could even distribute binaries or sources of that "fixed" compiler, provided that they meet the GPL requirements.
The "fix" is very simple. Build it with a -DSKIP_LICENSE_MANAGER option on the command line.
That's almost as good as "Linux Genuine Advantage" - a GPL-licensed package (source code link prominent on website) that you can install that after a while won't let you log in anymore unless you buy a license.
Freedom after all also means freedom to configure your computer to be _less_ functional.
"Texas Instruments Incorporated (TI) (NYSE: TXN) today announced a new series of 32-bit TMS320F2802x/F2803x microcontrollers (MCU) starting at less than $2 in volume. The new Piccolo(TM) F2802x/F2803x microcontrollers feature architectural advancements and enhanced peripherals in package sizes starting at 38-pins to bring the benefits of 32-bit real-time control to applications typically unable to justify the associated cost."
12 bit ADC and 150ps PWM, as well as a programmable, floating-point control law accelerator (CLA), make for an impressive embedded controller.
Of course, that only applies to the compiler - as far as I know, (at least some of) their libraries can only be used with their pre-built binaries - either the free non-optimised version, or the paid-for full version. Again, this is all perfectly legal and conforms to the GPL.
However, while they conform to the letter of the GPL, they are arguably going against the spirit of the GPL, and they are certainly going to annoy potential developers. I don't mind paying a company for software that it writes, but I *do* object to companies going out of their way to make it hard to use free software written by other people.
I've worked with Rowley for the MSP430 and the ARM, and have only good things to say about them. Not only are the tools excellent, they give you several extras which don't exist in all environments, the most important of which is their excellent support. Beyond that, they have a few nice things which don't come everywhere:
1) A very nice built-in tasking library, which I have used in several projects (even on the MSP with its very limited resources).
2) Where the above wasn't appropriate (military apps with hard RT requirements), there was a ready port to FreeRTOS.
3) A set of debug_xxx functions, parallel to the functions in which allow sending debug messages (and write debug files, and even get debug keyboard input) via the JTAG; this really helped out a lot of times, especially where there was no debug UART available.
and again, fantastic support.
As for ARMs - they come in several shapes and sizes. I much prefer the AT91 with ample RAM to the LPC2000 where they were stingy with it. Make sure you know your needs first.
Most importantly: Linux support for when you want to switch to a host system bred for software development instead of one designed for showing power-point presentations. ;)
--
Grant Edwards grante Yow! Everywhere I look I
at see NEGATIVITY and ASPHALT
visi.com ...
Saw some studies on this. Eclipse uses a lot of RAM. Minimum 1 GB, possibly 2 GB is needed. If you have too little RAM you would obviously be swapping = SLOW.
Quite often this is a problem with the flatcable connecting the JTAGICE Mk II to the target. If the internal wires are flaky anything can happen.
There is now a new emulator available, AVRONE, which uses high speed USB to connect to the target. This also supports tracing.
--
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
When I tried AVR Studio, I didn't notice any performance problems. I do have an 8-processor machine with 16G of RAM, though, so I wouldn't expect performance to be an issue.
I did have some issues, though, that I found annoying. Perhaps these are related to my inexperience with the product, however:
The project builder seemingly compiles the source files making up a project in a random order. It never seems to compile them in the same order twice. This is extremely annoying when fixing syntax errors followed by a rebuild to check the fixes.
The simulator seems flaky. There are times when it goes into the weeds and requires a reset to fix. Why this happens with a simulator, which the IDE has complete control over, I can't honestly fathom.
Several of the applications I tried running under the simulator didn't stop at the main() function. Rather, the debugger just started free running. Not even a breakpoint at the first executable line of main() would tame it. I tried building the exact same code under MPLAB and CrossStudio and did not experience this simulator runaway. I'm very concerned that if the debugger is this flaky running a simulator, how will it perform with real hardware?
Eclipse is written in java and usually runs under a java VM. But I believe there has been some work done on compiling it to native code. Would be interesting if that can be compatible with the AVR studio additions.
Eh? Its you creating the fuss over Linux!! In any case embedded Linux sells 3 million+ embedded Linux gadgets PER DAY. About 270 billion dollars in annual sales. So it is VERY pertinent question - and I'd rather listen to the Linux answer than hear you whine.
Thats nice - 12 bit ADC! The only things that worry me at times having gone to one of their meetings recently is their very public stance against Linux and releasing everything as open source tools. Personally I don't understand it. They can acclerate their whole demand profile by focusing in on open source tools instead of flaffing about on open source tool sets.
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.