Will Arduino Due support this NICE ARM microcontroller in a DIP package?

Hi Arduino Team!

I couldn't believe when I saw this:


An ARM uC in a DIP package!!!! :astonished:

Is the upcoming Arduino Due based on this family? I REALLY hope so! :)

Please let us know!



I'm afraid it won't be supporting that chip....

Read more about the due here http://arduino.cc/blog/2011/09/17/arduino-launches-new-products-in-maker-faire/

Yes, you're probably right...

Well, that's a bummer, as I think that there should be a DIP alternative for the new ARM based Arduino.

Actually, an ARM chip with only 32k of program memory isn't very "nice", IMO.

Microchip is putting more than that into some of their DIP PIC32 chips...


Why do you think it's not great compared to an atmega328P, for instance? Are ARM binaries way bigger than ones generated for 8-bit atmel processors?

Are ARM binaries way bigger than ones generated for 8-bit atmel processors?

Hmm. Interesting question. I was assuming so, but it will strongly depend on the app and how the development libraries are set up. In retrospect, the sort of applications that most "push" the limits of a 32k AVR are more likely to NOT be significantly larger on an ARM (for example, 32-bit integer math is "big" on an AVR, and not on an ARM.)

Mostly, if you're going to the trouble of designing and building a new board, you want it to be better in more than one way. "Faster" only isn't enough. I want faster, more data space, more code space, etc.

On the third hand, I keep forgetting to take cost into account. a 32k ARM chip that is about the same price as a 32k AVR chip...

That DIP28 is not one of the fanciest LPC ARMs but still I think better in most respects to the Mega328 (except no EEPROM :(). Still if it's not supported that's all a moot point.

As for code density, according to the LPC promos 32-bits has more code density than 8 bits. I'm not sure how that works but for a start they have thumb mode in which most (all?) instructions are actually 16 bits, still with 32-bit operands though.

Also I guess a 16 or 32 bit maths op is a single instruction rather than half a dozen and there must be many other examples. Some even have floating point maths in ROM, that would save pulling in an entire library.

Throw in DMA, 8-byte FIFOs on serial IO, no PROGMEM crap (constants are placed in flash and stay there) etc.

Now of course most people don't need this stuff or even know what it is, so with no Arduino native support it ain't gonna happen I would think. Maybe if Atmel bring out a small ARM there would be a chance.


if it’s not supported

Who knows. Once there is basic compiler and libc support for ARM-anything (for Due), adding other ARM chips should be comparatively easy (although CM3 vs CM0 might be an issue.) The DIP28 might enjoy all the “unsupported popularity” of ATtiny and ATmega644 in the current environment.

Various sites have benchmarks and whitepapers to show code density is better with 32bit ARMs than 8bit CPUs, but they tend to have a somewhat skewed view of what makes up “typical” microcontroller code. Lots of math (usually at least 16 bits) and not much IO port manipulation, for example.
Here’s one that’s not too bad: http://ics.nxp.com/literature/presentations/microcontrollers/pdf/cortex.m0.code.density.pdf It has actual examples of how costly a 16bit multiply is on a CPU that only has an 8bit multiply instruction, but their main benchmarks are based on “CoreMark”, which does “matrix manipulation, linked list, state machines, and CRCs.” Those may be common computer tasks, but … they’re not something I see a lot of questions about here in arduinoland.

but for a start they have thumb mode

The “Cortex M Series” of ARMs are ALL thumb; no more 32bit basic ARM instruction set at all (some THUMB and THUMB2 instructions are longer than 16 bits, though.) Yeah, AVR instructions are at least 16bits too.

The big danger seems to be in relying on vendor-provided libraries (CMSIS and peripheral libraries, though I haven’t researched them much yet.) The complexity of the overall chip seems to be such that writing “bare metal” code is difficult. Supposedly.