Why I chose the 32-bit AVR

Recently I announced the possible move from 32-bit AVR to Atmel’s SAM3U ARM Cortex-M3 series. Soon after, I tweeted that I’m sticking with 32-bit AVR and mentioned that I would write a blog post explaining what happened. As promised, here is the post. Fair warning: long post is long.

Way back when I first started looking around for microcontrollers to do the isostick project I had a few requirements:

  • High-Speed USB
  • SD Card controller
  • Internal program memory
  • Enough internal SRAM to get the job done

The HS USB was needed for reasonable transfer speeds, as was the SD Card controller (bit-banging SD or using the SPI interface is insufficient). Internal program memory and SRAM reduces overall part count and board size, so I can fit it all on a conveniently tiny board.

It turns out finding a combination such as this was quite difficult at the time (though this is becoming easier with time). First I came across the now-obsolete LPC2888 from NXP, a spiffy little chip with 1MegaByte of internal flash — MASSIVE! Unfortunately the price tag was equally massive, so I set it aside and kept searching.

Next I came across the SAM3U series of Cortex-M3 microcontrollers from Atmel. They seemed great, meeting all my requirements and more! Alas, they were just recently announced at the time and weren’t available other than samples. Knowing that it may be a very long time before they’re in mass production, I set them aside as well.

While perusing Atmel’s website for other suitable microcontrollers, I recalled their 32-bit AVR AP7 series, which I thought may meet my requirements. Atmel had discontinued the AP7 series, although it lacked internal flash so it was off the list anyhow. Poking around the 32-bit AVR section, I noticed the UC3A3 series with HS USB and SD Card controllers. They had internal flash, an abundance of SRAM, and I knew if they were anything like the 8-bit AVR series they would be easy to develop for, too!

The next few days were spent digging around the interwebs for alternatives; not because I didn’t like the AVR, but simply because I wanted to make an informed decision. There were dozens of possible contenders, but most were missing the crucial combination of internal flash and HS USB.

There’s an interesting divide in the embedded micro world: microcontrollers versus microprocessors. A microprocessor historically is a CPU and a simple bus interface. Today, however, it is more common in the embedded arena to find a CPU surrounded by a plethora of amazingly useful peripherals and all sorts of fun interfaces, all in the same package. So, what differentiates a microcontroller from a microprocessor today? Internal flash and SRAM seem to be the delta, based on my own experience. Devices billed as microcontrollers tend to run at lower clock speeds and focus less on complex caching schemes and multimedia/SIMD instructions and instead put the flash and SRAM right on the die and run them at or near CPU clock rate. They compromise clock speed in exchange for a simpler device and lower external part count; a true System-on-Chip in many cases.

Getting back to the tale of part selection, I had settled on the 32-bit AVR. The feature set is impressive for such a small device. The cost is higher than competing ARM devices, but they generally lacked HS USB and so they weren’t an option for me. I set out learning the SD protocol, SCSI SPC SBC and MMC, FAT Filesystem, et al. Over the next few months much code was written!

The AVR32 Studio development environment was pretty amazing. I’m not a huge fan of Eclipse (which AVR32 Studio is built upon), but it certainly has features that made the job easier. Atmel’s integration of their libraries and programmers was impressive to say the least, and the debugger was fantastic.

Fast-forward to a few months ago: AVR Studio 5 goes into beta, and wow what an amazing application that is. It is built upon Visual Studio, so *nix folk will need to try wine or run a Virtual Machine. That said, it’s entirely worth the effort to get this running if you’re not a Windows user — AVR Studio 5 is simply awesome. It’s hard to believe it’s free given how great it is.

Fast-forward a little further: the SAM3U series goes into production. It was one of my first choices, and I wanted to go back and try it for a number of reasons. Primarily speed: I want to deliver a good experience to the end user, the faster the better. A week later a SAM3U-EK Eval Kit arrived at my doorstep. Porting of the code began. Admittedly I was disappointed with the complexity of the USB Mass Storage stack Atmel provided. The SD stack was equally spaghettified, with lots of asynchronous code and layer upon layer of oniony state machines. If you were doing time-critical/realtime system design, this might be nice — it tries as best it can to avoid monopolizing the CPU for any amount of time, and I’m sure it does that well.

The tools: I learned a very hard lesson when trying the SAM3U. I’m spoiled. AVR Studio 5 and even AVR32 Studio have seriously skewed my perception of other embedded IDEs. Atollic TrueSTUDIO seemed pretty good, almost on par with the old AVR32 Studio, but I couldn’t afford to purchase a license. ARM/Keil have their own offerings but again my research showed insane pricing. Eventually I settled on using YAGARTO / GNU toolchain with vanilla Eclipse. After much frustration and heads colliding with desks, it was working.

The port: In lieu of the Atmel-supplied SAM3U USB Mass Storage and SD libraries, I ported over the AVR Software Framework (ASF) libs. The SAM3U USB libs stayed in place and I spliced the ASF’s Mass Storage drivers on top of them. I did a complete port of the ASF’s SD/MMC libs including the low-level MCI portion, because the MCI silicon used in the SAM3U and UC3A3 is largely the same (the VERSION register shows the SAM3U is a variant of an older revision than that used in UC3A3, if I recall correctly).

By porting over the ASF’s Mass Storage drivers, my SCSI stack fell right into place. Likewise, by porting the ASF’s SD/MMC services I was able to drop my filesystem code in easily. After patching up a few spots where I made assumptions about endianness (32-bit AVR is Big Endian, whereas SAM3U is Little Endian), I had things up and running.

The problem: Testing, testing testing. I was seeing relatively slow read speeds. The SAM3U’s MCI can run at up to half the CPU clock. The CPU clock is 96MHz, so the MCI is 48MHz. The SD bus transfers 4bits/cycle, so 4bits/cycle * 48Mcycle/second * 1byte/8bits = 24MByte/s. There’s a bit of overhead to account for, but I should realistically have seen speeds in the ballpark of 20MB/s. Instead I was seeing closer to 15MB/s. For reference, the 32-bit AVR UC3A3’s MCI, running at the top speed of 33MHz, has a theoretical transfer rate of 33Mcycle/second * 4bits/cycle * 1byte/8bits = 16.5MB/s, and I see sustained throughput in the area of 12.5MB/s. The discrepancy here is likely due to the latency of issuing the command over USB (which is half-duplex), parsing that, issuing a command to the SD card, and so on.

It dawned on me that I had only been testing with a single card, so I pulled out some others I had, and behold! One card did in fact achieve around 18MB/s, the others hovered between 13MB/s and 15MB/s. Testing with other commercial readers, indeed it appeared to be the cards that were at fault. Some Googling revealed this seems to be commonplace. It’s also interesting to note that the microSD cards I have that are of Class 2 and 4 actually perform better for reading and writing than the Class 6 card I have, though the Class 6 does meet its specification. Go figure!

The decision: There were other subtle bugs in the SAM3U port (it was, after all, quickly hacked together over a week or two). So I decided to go with 32-bit AVR UC3A3, based on: the real speed gain of the SAM3U was much less than predicted, the subtle bugs in the port that had marginal benefit now, my deep familiarity with the 32-bit AVR UC3 series, and finally the amazing ease of use and integration of AVR Studio 5.

Phew, this has been a long post. I hope this has been an interesting or at least informative insight into the decision-making that went into designing the isostick.

8 thoughts on “Why I chose the 32-bit AVR

  1. I’m about to embark on a similar journey though I don’t have to present the USB interface as a mass storage device. I was wondering if you could give me any pointers — I’m going with the sam3u because i’ve always wanted an excuse to use an arm processor. or if you have any desire to share your work?


    • reza,
      The sam3u-ek evaluation kit is a great start, lots of nifty things to test out like a USB interface, touch screen LCD, accelerometer, etc. Their software library is a bit over-the-top in terms of asynchronous coding, lots of state machines that maybe aren’t necessary. That makes the library code a bit difficult to read, but it doesn’t make it much harder to use if you’re not interested in reading and learning how they did it. You could also, of course, write your own libraries!
      One of my biggest complaints about sam3u and ARM in general is lack of a good FREE development environment. If they’re out there, I haven’t found them. Atollic TrueSTUDIO is a pretty damn good IDE with a free version for non-commercial use. The commercial version, however, is fairly expensive. ARM also has their own tool suite called RVDS, but it’s something like USD$6000, ouch.
      If it’s a hobby project or you have money to burn on a commercial one, I suggest Atollic TrueSTUDIO, but I haven’t used very many of the ARM IDEs. You could also use the GCC toolchain for ARM with Eclipse, for that I suggest YAGARTO, found at http://www.yagarto.de/
      As far as sharing my work, for now my work is closed-source, sorry.
      Hope that helps!
      – Eric

  2. with my experience with commodity USB flash, if it got 9MB/s I’d consider that a win! You usually have to pay a hell of a lot more for flash faster than that. Also since a 52x CDROM maxes at less than 8MB/s (and you rarely see the max) 10MB/s+ is a total win no matter what.

  3. Excellent post that you wrote!
    For my work, I also got my hands on a sam3u-ek dev kit and I share your feelings… the asf library is just a nightmare. The doxygen doc on atmel website doesn’t even includes the description of the lib functions.
    The depth of the library function calls is impressive, which makes the understanding of the library much harder (if not impossible).
    I’m not even mentionning their callback functions defines (I never used so much the “goto implementation” button).
    I honestly think that it might take the same amount of time to read the datasheet + understand the different protocols + write your own lib rather than trying to understand the asf lib & modifying it to use it for your own needs (and you’ll still have to copy the license, making the readers believe it’s a good lib)
    good luck for what you are doing!

  4. I know this is an old post and I got here asking the question “Is there any reason to use the AVR32 anymore” It still hasn’t answered my question. I am currently building a system using the SAM3X and it is a very nice chip to work with. For everyone one else who reads this, Atmel Studios 6 as well as the ASF now supports all of the Atmel ARM offerings. Making prototyping and development a breeze. (still built on Visual Studios so us linux people have to suffer)

    • Sorry, for some reason I wasn’t notified of a new comment and just noticed it.

      Anyway, thank you for your comment! I have to agree — with Atmel Studio supporting ARM and AVR offerings, and a wider selection of ARM chips in general, I can’t see any solid reason to use AVR32 these days.

      Now if only Atmel could add AVR ONE Trace support to Atmel Studio…… Well, it makes a shiny paperweight at least 😐

  5. i am familiar with avr-8 bit but got an opportunity to work on avr-32 bit……..but i didnt understand how to initial port………..like in 8 bit i use DDR……….is there any site or any idea that from where i got to learn all these thing……because i saw the data sheets of AT32UC3A0128 and from there i didnt understand anything…there is register mention there………also what ide…because in avr studio4 its shows error by 8bit method……….if some one having basic program like toggling so plz mail me……..so that i will get some idea from there………..plz reply

  6. Hi! Even if it looks like AVR32 is a bit old fashion nowadays compared to Cortex M3-4 Seriels supporting 100+ Mhz i think there is an innovative advantage with AVR32 UC3-C. It has floating point like cortex m4f and CANBUS communication. Surprisingly it supports 5V VCC supply which is important in very noisy environments!!! Are any Cortex M MCUs in the market that support 5V VCC like UC3C ?

Leave a Reply

Your email address will not be published. Required fields are marked *