PSAS/ NodeMicrocontrollerSearch
  1. Avionics Node Microcontroller Reqirements
  2. Why ARM? Why 32 bits? Why...?
  3. Comparision chart for microcontrollers
  4. Manufacturers of Relevant ARM7 Microcontrollers
  5. Final Cut Microcontrollers
    1. Justification for Final Choices
    2. Tim's Thoughts
  6. Misc
    1. Did someone say Atmel AT91SAM7A3 ?
      1. Data sheet
      2. Distributors
      3. Eval boards
      4. eCos

Avionics Node Microcontroller Reqirements

Here's the requirements for the microcontroller that will run all of our non-flight computer "nodes" - small boards usually centered around some application-specific task, like the IMU or magnetometer or whatnot. Note the differentiation between "must" (a hard requirements) and "should" (a not so hard requirement).

  1. Architecture
    • Must be >= 32 bits.
    • Should have many implementations, by more than one manufacturer if possible.
    • Should have decent integer math ALU (e.g., 32 x 32 -> 64, MAC, etc).
  2. Development Tools
    • Must have current and active OSS tools: gcc, gdb, binutils, etc.
    • Must have useful open debugger protocol (e.g., JTAG)
    • Should have existing open source real time operating system (e.g., eCos)
  3. Packaging
    • Must have "usable" packaging: packaging that can be used on two layer boards.
    • Must not be a DIP or PLCC or BGA with > 32 pins.
    • This leaves a "Quad Flat Pack" (or QFP, e.g. a TQFP or LQFP), or possibly a BGA with < 32 pins.
      • QFP should have <= 64 pins. >= 100 pins is possible but a pain. 144 pins absolute maximum.
  4. Peripherals
    • Must have onboard memory: >= 128 KB flash, >= 32 KB SRAM.
    • Must have necessary communication busses (CAN and/or USB).
    • Should have one or more serial busses: UART, SPI, etc.
    • Should have a >= 10 bit ADC.
    • Should have >= 3 PWMs.
    • Should have a watchdog timer.
    • Should have brown out reset.
  5. Computational Horsepower
    • Must have > 10 MIPS, but should have >= 60 MIPS.
  6. Power Consumption
    • Should have reasonable voltage requirements (e.g., 3.3V only (best) or 3.3V/5V).
    • Should have low power modes.
  7. Should be relatively low cost

Why ARM? Why 32 bits? Why...?

The requirements dictate our choice, but the reality is that so far we've only found ARM7 chips that come even close to matching this spec. The PowerPC, MIPS and x86 chips we've seen are too "microprocessory" in that they lack onboard flash, RAM, and peripherals, else they come in some giant BGA package which forces us to 10 layer boards which we just can't afford to do. And looking for a 16 bit processor doesn't make sense: we can get 32 bits for about the same price given that our quantities are just a few dozen chips.

Comparision chart for microcontrollers

See the ARMs.xls attachment.

Manufacturers of Relevant ARM7 Microcontrollers

Big list of companies that make ARM chips, and why those company's chips don't meet our requirements.

Final Cut Microcontrollers

See the final candidates discussion page.

Justification for Final Choices

The best choice (besides the 100 pin CAN and USB Atmel chip) seems to be STMicroelectronics' microcontrollers. They're either CAN or USB only, and the pins are similar enough that we could swap them out without much trouble. It was decided in the February 22nd Avionics meeting to go with the STM chips. We'll design both the CAN and USB revs, but only fab the USB design first. If the USB design meet our avionics system needs, we'll still have the CAN version we can fab.

Tim's Thoughts

Atmel AT91SAM7x256: ARM7TDMI-USB/CAN, package LQFP100

Philips LPC2129: ARM7TDMI-CAN (USB => 2148), package LQFP64

Philips LPC2148: ARM7TDMI-USB, package LQFP64

ST STR711FR2: ARM7TDMI-USB (CAN available STR712FR2), package TQFP64

Roughly ARM7 offers 0.9 MIPS/MHz assuming no wait states.

An ST part offers CAN+USB in the 144pin package. I don't think this is desirable.

The ST CAN and USB parts both use pins 42/43 as their differential outputs, so they are potentially drop-ins for each other.

All these parts have problems and advantages.

The Philips is fastest, then Atmel, then ST, but the differences are not very large. (Roughly 54, 49, 45 MIPS respectively) This is not totally clear however, since running from SRAM the ST is spec'd fastest (59 MIPS), but there would be extra complexity.

The Atmel come in a large package (LQFP100)

The Philips CAN part has only 16kB SRAM

The Philips USB part and the Atmel are sampling. Also the Philips USB part has only a very preliminary datasheet.

The ST part has a 4ch/12bit ADC

The Philips USB part has a single 10bit DAC

Some things yet to be determined:

The Philips line is the most mature, yet their USB part is the least far along. (It is odd they seem to be the fastest.)

The Atmel does have things to recommend it (5V tolerant I/O for example), but the 100 pin package is a pain compared to the 64pins.

Power supply notes:


Did someone say Atmel AT91SAM7A3 ?

Data sheet


Eval boards