Arduino Due (released Oct 22, 2012) Compatibility

Grumpy_Mike:
Add to that the portability remembering the Raspberry Pi takes 700mA to drive.

RPi current draw actually can be a half of that or less depending on which peripherals/processes you are running, but still at least a dozen times larger than a barebones SAM3X8E-based board.

giantsfan3:

Grumpy_Mike:
Add to that the portability remembering the Raspberry Pi takes 700mA to drive.

RPi current draw actually can be a half of that or less depending on which peripherals/processes you are running, but still at least a dozen times larger than a barebones SAM3X8E-based board.

If you look at table 46-11 on page 1401 of the SAM3X datasheet, there's total current specs.

Running from flash at 84 MHz is 76.47 mA. Clocking slower saves power. At very slow speeds, it looks like the current approaches about 15 to 16 mA.

This makes me wonder: Are ARM7 processors in smartphones (like the one in the iPhone) somehow designed for extremely low current draw? Shouldn't they consume more current than a 84-Mhz SAM3X would... As in, how do smartphones still get such long lifetimes while the processor is handling presumably a LOT of instructions, and also additionally using display, graphics driver, Wi-fi, GPS, etc.

Si:

@Si: But doesn't that mean that ALL ARM Cortex M3 and various other companies' 32-bit microcontrollers, have no applications?

Not amongst Hobbyists I expect.

Still waiting for the flood of examples :wink:

Ah, but what if a 32 bit MCU came in a DIP package and was roughly the same
cost as the 8 bit AVR?
Wouldn't it make sense to take a serious look at it?
and perhaps leave the 8 bit world behind?

I think something like the new Microchip pic32 28pin dip parts would be a much better option than
all these ARMs for hobbiests. ARM is really a technology and not a processor.
ARM is great for embedding in custom silicon designs, something hobbyists will probably never need.

Consider this.
An Arduino board based on the pic32 28 pin dip parts would return Arduino back to its roots,
which is what got all the interest to begin with.
The pic32 parts are currently readily available and only cost slightly more than a mega328
in QTY 1.

http://www.mouser.com/Microchip/Semiconductors/Embedded-Controllers-Processors/Microcontrollers-MCU/32-bit-Microcontrollers-MCU/_/N-a85nm?P=1z0zl2wZ1z0z63x&Keyword=pic32&FS=True

It is 32 bit vs 8 bit with a linear address space so no more hassles with having to deal with things
like progmem and having to constantly declare things 8 bit in order to optimize code.
For beginners I think it would actually be an easier environment to work with
than the AVR architecture while offering much more processing power and RAM than the AVR based parts.

The pic32 DIP parts seems to hit a very nice sweet spot in that it solves many of the wants for more
performance and resources yet still can provide a nice easy to work with package for hobbyists,
students, and DIYers.

My fear is that the DUE product has strayed a bit far away from the hobby and educational markets
that originally made Arduino so popular.

--- bill

I think something like the new Microchip pic32 28pin dip parts would be a much better option than
all these ARMs for hobbiests.

The hobbyists market is a total irrelevance for all semiconductor manufacturers, it is just a flee byte in there sales. Even the Arduino has hardly made a blip for Atmel. Massimo said this in his talk to the Open Source conference in 2011.

What hobbyists are doing is riding the wave on the back of industry. Just at the moment we can do this however it will become increasingly more difficult.

For beginners I think it would actually be an easier environment to work with
than the AVR architecture

The whole point of the arduino is that it abstracts the AVR environment out of existence, as does the Due. It is still under the hood if you want it but most do not venture into those parts.

My fear is that the DUE product has strayed a bit far away from the hobby and educational markets
that originally made Arduino so popular.

Fear not and just see what happens.

Grumpy_Mike:

I think something like the new Microchip pic32 28pin dip parts would be a much better option than
all these ARMs for hobbiests.

The hobbyists market is a total irrelevance for all semiconductor manufacturers, it is just a flee byte in there sales. Even the Arduino has hardly made a blip for Atmel. Massimo said this in his talk to the Open Source conference in 2011.

Obviously.
While irrelevant in terms of revenue, it can be very relevant in terms of mind share as
students that learn/know a particular technology in school might carry that knowledge/familiarity
forward into their real-world jobs, where they will be making product design decisions that will
affect manufacturers revenue.

All that said, I'm guessing that vast majority of Arduino sales go to the hobbyist/educational market
and that was the point I was trying to make. "The Arduino market IS the hobbyist market."
High density pin count surface mount or BGA packages are pretty much non-starters for most DIYers trying
trying to build their own projects. Those types of users are much more likely to
experiment with parts in DIP packages.

My guess is that many current Arduino users would be very happy with a
faster 32 bit processor with more flash and RAM than the mega238 in the same 28 pin DIP package.
Particularly when that part can offer additional features like DMA, USB, 5v tolerant inputs,
and real-time clock all at pretty much the same price point.

If I were a teacher, I'd much rather put more rugged devices into the hands of students
that won't blow up when they accidentally do things like hook up a MCU pin to a 5v sensor.
Having a pic32 based Arduino would offer the chance to use 3v devices or 5v devices
while playing with a 32 bit environment all at the same price point and same ability to move
designs to to a standalone board as the current UNO.
This is something that simply cannot be done with DUE.

For beginners I think it would actually be an easier environment to work with
than the AVR architecture

The whole point of the arduino is that it abstracts the AVR environment out of existence, as does the Due. It is still under the hood if you want it but most do not venture into those parts.

But Arduino doest extract away enough AVR, which is why it is difficult to bring up new processor like the ARM on DUE.
It is missing many things in the core library that are needed for higher level i/o libraries.
It wasn't even until recently that the pin numbers for certain functions like LED, analog pins, etc...
were abstracted on the AVR chips.
And then don't forget the progmem and 8 bit variable issues that have to be dealt with in
user code (sketch). Arduino code is littered with these types of needed optimizations
even in sketch/user-land code.
Things like progmem go completely away when using other non-harvard
architectures and you no longer have to educate users on the s/w complexities of having to
use multiple address spaces. Instead, things like "const" in C/C++ code just work
and you can start to use ints for loops and counters without fear of reduced performance
or increased code size.

My fear is that the DUE product has strayed a bit far away from the hobby and educational markets
that originally made Arduino so popular.

Fear not and just see what happens.

It will be interesting for sure.

--- bill

bperrybap:
But Arduino doest extract away enough AVR, which is why it is difficult to bring up new processor like the ARM on DUE.
It is missing many things in the core library that are needed for higher level i/o libraries.

One advantage of the relatively simple AVR architecture is that it provides a gentle transition for the beginner to intermediate stage when the programmer needs to (or simply wants to) go beyond what's offered by the Arduino/wiring core libs. Direct port IO for faster/multiple pin manipulation. Managing multiple interrupt handlers. Inline assembly code. On AVR, all pretty easy stuff to get a handle on for the novice ready to move to next step for the AVR chips.

OTOH, the ARM architecture is much more complex. Nested interrupt handlers, anyone? Even porting conceptually straightforward code from the AVR world to the ARM can raise some tricky questions. For example, I ported Dean Camera's ATOMIC BLOCK routines from AVR to ARM, so I could use them on the Maple... which yielded some interesting and curly questions on how to emulate something as conceptually simple as "cli" an a processor like the ARM, where there is potentially a lot of stuff happening in parallel in the silicon.

Anyway, I don't see the one step transition from Arduino to ARM in the same way you can go from Arduino to AVR. If you were teaching the principles of uC programming, you certainly wouldn't start with ARM in any case (or at least, I wouldn't); something like an AVR, 8051 or 6502 architecture and instruction set is far more tractable. I'd introduce ARM only at the sophomore or senior level once the students had passed the intro uC course.

So is the the Due a suitable dev board design for beginners? It might turn out to be OK, but it's certainly far from optimal. OTOH, it may yet turn out to be a white elephant stuck in the netherworld between niches. I agree with Bill that an electrically more robust chip, preferably still in a DIP package (like the Microchip pic32 part Bill mentions), would be much more consistent with what made the first gen Arduinos attractive to neophytes in the first place. (While even MIPS is not exactly ideal as a learning architecture, it's still a hell of a lot simpler than ARM.)

We shall see.

Nested interrupt handlers, anyone?

That is one fundamental difference, by default on the Due you are not safe from other interrupts when in an ISR.

how to emulate something as conceptually simple as "cli" an a processor like the ARM,

I've done this on an LPC

#define		ATOMIC_START			__disable_irq();__interruptLevel++;
#define		ATOMIC_END				if ((__interruptLevel) && !(--__interruptLevel))__enable_irq();

I haven't tested it yet and may have a -- in the wrong place or something but the idea is that I disable all interrupts at the start of an atomic block but only re-enable them if they were enabled when I entered the block.


Rob

Graynomad:

Nested interrupt handlers, anyone?

That is one fundamental difference, by default on the Due you are not safe from other interrupts when in an ISR.

how to emulate something as conceptually simple as "cli" an a processor like the ARM,

I've done this on an LPC

#define		ATOMIC_START			__disable_irq();__interruptLevel++;

#define ATOMIC_END if ((__interruptLevel) && !(--__interruptLevel))__enable_irq();




I haven't tested it yet and may have a -- in the wrong place or something but the idea is that I disable all interrupts at the start of an atomic block but only re-enable them if they were enabled when I entered the block.

You still need to consider the many and several membar/memory fence instructions if you really want a robust equivalent of cli. You would have to look at what __disable_irq()/__enable_irq() do exactly, but if they simply compile down to the the standard single special register instructions -- CPSID I and CPSIE I -- not enough to fully emulate cli...

As I say, there are some threads on the Leaflabs forum where this was discussed in some gory detail. :wink:

Thanks pico,

if they simply compile down to the the standard single special register instructions -- CPSID I and CPSIE I --

They do, so I've added the three barrier instructions along the lines of what x893 had in one of those threads. As nobody argued his code in the last two months I'm figure it's kosher until I look into this more deeply.

As I understand it though as I'm using an M0 it's not important, but makes the macro pore portable.


Rob

And of course don't forget the ::: "memory" compiler barrier (gcc specific, probably -- need to find the equivalent on your compiler/assembler).

Then I think you've got what was termed the "thermonuclear option". :slight_smile:

"thermonuclear option".

Correct, if one barrier is good then three is better eh?

I'm using GCC (Code red/LPC Xpresso IDE) so I'll add the ::: memory, I get the need to flush pipelines etc but don't really understand these instructions yet. No matter, meanwhile I'll do do what others have done, shoulders of giants and all that. :slight_smile:


Rob

Graynomad:
so I'll add the ::: memory

Don't forget the quotes around "memory".

If you are using gcc, you should be fine. The "memory" directive tells the compiler not to reorder the assembly instructions with respect to the C code statements in an optimisation step -- at least from from memory. :wink:

Then you've successfully ported CLI. phew!

Then you've successfully ported CLI. phew!

One down ? to go.

I'm porting the Arduino core stuff onto LPCs, slowly but surely :slight_smile: I think I can run any standard program now but haven't tested that much I admit.


Rob

Graynomad:
There are gotchas though, on the LPCs the GPIO ports don't work until you enable their clock, I spent some time wondering why my writes had no affect. Same goes with the other peripherals.

Presumably this sort of thing will not bother any Due users.


Rob

Arduino has Serial.begin() and TBH I don't know what-all that does. LPC.begin()?

Serial.begin() just enables the UART, sets the baud rate etc.

On the Due the equivalent of an LPC.begin() will be in init() I would think. That's why they get the big bucks, so we don't have to worry about such things :slight_smile:


Rob

"You think i can use a DUE on my project of a spaceship to go to the Moon ?!
PS- My Arduino UNO didnt had enough Sram ..."

http://downloadsquad.switched.com/2009/07/20/how-powerful-was-the-apollo-11-computer

When the first landing was on the way down, a side program that was loaded crashed the computer.

That one caused a panic, the error message was a number btw.