Arduino Due (released Oct 22, 2012) Compatibility

In terms of programming environments, I would prefer an intermediate step between bare metal programming (Ardunio) and running a full OS with full protection (Rasberry-pi, Beaglebone). Many of the things I contemplate doing would be better expressed as a series of cooperating threads, rather than building state machines that keeps track of everything.

For example consider a setup with an IR receiver that is waiting for the user to push a button on a hand held IR transmitter like a TV remote, but at the same time, you want the chip to do what it is normally doing. With cooperative threads, you would have one thread waiting on IR pulses, and when it gets a full sequence of pulses that it recognizes as say the 'up' button, then it sends a message that the button was pressed. Sure on a bare metal system, you build a state machine for the IR pulses, etc. and separate state machines for each of the other tasks.

One problem with threads, is each thread needs its own stack space, and machines like the Arduino have rather limited memory setups. I'm not sure Due will solve this.

There is the QP state machine (Arduino Playground - QP-nano framework) that I've thought about, but I haven't yet used it.

Jantje:

MichaelMeissner:

retrolefty:
Ok, but lets focus a bit. What would be your recommendation to a newbie to the hobby (with little or no electronics or software experiance) as to which would be their best choice to enter the arduino world once the Due is in fact avalible. I vote Uno, you vote ?
Lefty

Right now (October 2012), the Uno. However, I imagine by the January time frame, it would be probably be the Due. There is a saying in parts of the US, that pioneers are the ones with arrows in their back, and anybody that buys a Due on day one is a pioneer. But after the initial problems are sorted out, I see the current 8-bit chips going being more of a niche market. Will it happen overnight? Certainly not, but it will happen.

I fully agree with this. Certainly for newbies the stabilized due will be the platform of choice. It just makes everything easier. For instance it takes away the problem of memory management for small projects. You can do some really bad coding and still have enough cpu left not to notice.
It just makes the start easier and the old farts like me will do the hard work on the small slow 8 bit chips.
At least that means I will have a job until I die :wink:
Best regards
Jantje

I still say a begineer to electronics is better off starting with a Uno. One other reason would be the very wimpy output pins that ARM chips have, even driving a 20ma led will require a switching transistor making a learning lesson all that much more complex to build and understand. Most all tutorials showing interfacing to simple circuits will have to be revaluated to see if they are compatible with ARM output/input pin specs. I think the rather rugged I/O pins of the AVR 8 bitters work much to the favor of raw begineers. Keep pushing those Uno boards. I think many are focusing too much on what a ARM chip is better at, rather then also considering what a 328P chip is better at in context to someone first starting out building simple stuff to learn how electronics works.

Lefty

retrolefty:
... One other reason would be the very wimpy output pins that ARM chips have, even driving a 20ma led will require a switching transistor making a learning lesson all that much more complex to build and understand. ...

I wasn't aware of that. This is indeed a really strong point for the UNO.
Best regards
Jantje

I agree that a Uno is a better choice for a beginner who

a) won't be writing 10000 lines of code,
b) just needs to see a LED flashing and
c) will be following examples that will 99% be for a 5v Uno-style board with IO grunt.


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 ...

One problem with threads, is each thread needs its own stack space, and machines like the Arduino have rather limited memory setups. I'm not sure Due will solve this.

I think the relevant number is the ratio of RAM size to thread state size (roughly, number of bytes of registers). AVR is particularly weak here: 2048/32 = 64. Due is about 96k/(4*16) = 1536, so that SHOULD be a lot better.

even driving a 20ma led will require a switching transistor

Or a driver chip. OTOH, these days for a lot of apps you can just use a 1mA LED instead...

westfw:

One problem with threads, is each thread needs its own stack space, and machines like the Arduino have rather limited memory setups. I'm not sure Due will solve this.

I think the relevant number is the ratio of RAM size to thread state size (roughly, number of bytes of registers). AVR is particularly weak here: 2048/32 = 64. Due is about 96k/(4*16) = 1536, so that SHOULD be a lot better.

Well it would be less than that since you have to account for the stack frame size of each thread. Having more ram also means you can think about using dynamic allocation (in moderation). There are certainly ways to do it in memory starved environments, but it takes more effort (essentially going back to a state machine for each thread).

However, if the DUE has 100k RAM or so that the SAM3X83 has on chip, it still in inadequate for doing much with video. A QVGA (320x240) image with 3 bytes/pixel, is something like 225K, and if you wanted to full hog to HD video, that is 5 megabytes per picture.

Reading the data sheet, there is a large section on the different types of memory which was over my head, but gave the impression that it would not be too difficult to attach banks of high speed external memory.

Duane B

Yes the SAM chip is designed to access external memory, 8x16Meg (or 4x16Meg, depends on what part of the data sheet you read) of SRAM and possibly more of other types like SDRAM although I've not looked into them.

I doubt the signals will be all broken out on the Due but you never know.


Rob

I doubt the signals will be all broken out on the Due but you never know.

I hadn't considered that while wading through the datasheet.

I hope that some form of native external memory support is available, it will open up all sorts of audio sampling projects.

Duane B

rcarduino.blogspot.com

Note: I'm not a hardware guy so this may be complete crap.
I have been thinking about the "wimpy output pins that ARM chips, even driving a 20ma led will require a switching transistor"
Now I ask myself:
Would it be possible to make a go between kind of like shield that would cater for this shortcoming?
I'm thinking about having a mosfet on all(?) pins in parallel to (in)direct access to the pin via the header. This way you could chose to have a resistive load on the mosfet or (in)direct access to the 3.3 pin.
I'm saying (in)direct because maybe some extra stuff (I wouldn't know what) could allow for switching between mosfet, 3.3V and 5V. With solder paths the headers could be connected to the pin with the desired functionality. (maybe you guys are smart enough to do it automatically)
Maybe not all options (mosfet, 3,3 and 5Volt) are needed for all pins. I think the UNO digital and analog pins are the first to look at. And probably pin 0 and 1 are never used by any shield as it would ruin the USB communication on the UNO. Which makes 16 pins for all options.

Any input from people who know what they are talking about when it deals with electronics?
Best regards
Jantje

PS
For the UNO there is a go between shield that disconnects the pins from the headers and uses solder paths to connect the pins to the headers. This is part of the solution I'm thinking of "http://tronixstuff.wordpress.com/2012/01/18/review-mayhew-labs-go-between-arduino-shield/"
I say mosfet because mosfet have a smaller voltage drop and internal resistance but maybe transistors or anything else is far better. (I really don't claim I know)

Jantje:
Note: I'm not a hardware guy so this may be complete crap.
I have been thinking about the "wimpy output pins that ARM chips, even driving a 20ma led will require a switching transistor"
Now I ask myself:
Would it be possible to make a go between kind of like shield that would cater for this shortcoming?
I'm thinking about having a mosfet on all(?) pins in parallel to (in)direct access to the pin via the header. This way you could chose to have a resistive load on the mosfet or (in)direct access to the 3.3 pin.
I'm saying (in)direct because maybe some extra stuff (I wouldn't know what) could allow for switching between mosfet, 3.3V and 5V. With solder paths the headers could be connected to the pin with the desired functionality. (maybe you guys are smart enough to do it automatically)
Maybe not all options (mosfet, 3,3 and 5Volt) are needed for all pins. I think the UNO digital and analog pins are the first to look at. And probably pin 0 and 1 are never used by any shield as it would ruin the USB communication on the UNO. Which makes 16 pins for all options.

Any input from people who know what they are talking about when it deals with electronics?
Best regards
Jantje

PS
For the UNO there is a go between shield that disconnects the pins from the headers and uses solder paths to connect the pins to the headers. This is part of the solution I'm thinking of "http://tronixstuff.wordpress.com/2012/01/18/review-mayhew-labs-go-between-arduino-shield/"
I say mosfet because mosfet have a smaller voltage drop and internal resistance but maybe transistors or anything else is far better. (I really don't claim I know)

I suspect a 'go between shield' board that converted all the ARM pins to active 5 volt signals capable of sinking and sourcing 30+ ma is possible, but how would you switch them from output pins to input pins via sketch mode commands? No, I think that actual hardware arduino projects will now (or soon post DUE release) have take two different paths, one for the 5 volt higher current capable boards and one for the new 3.3 volt lower current world. It will just be cheaper to buy both kinds of boards rather then to expect some kind of 'go between' board to solve the rather drastic electrical different I/O pin capablities between AVR and ARM chip boards.

Lefty

I think so to, plus how do you deal with analog pins? They can be digital IO as well. It gets very tricky.

I suspect that future shield makers will have to accommodate both voltages if they want to be compatible with both types of base board. That's pretty easy to do on a shield because you know what pins you are using for what. Isn't that what the IOREF signal is to be used for?


Rob

Graynomad:
I think so to, plus how do you deal with analog pins? They can be digital IO as well. It gets very tricky.

I suspect that future shield makers will have to accommodate both voltages if they want to be compatible with both types of base board. That's pretty easy to do on a shield because you know what pins you are using for what. Isn't that what the IOREF signal is to be used for?

Yes, The voltage applied to the IOREF pin from the controller board will tell the shield board what kind of host Arduino controller board is being mated with. However that is only avalible on the newer Rev3 arduino boards, not the zillions of pre UNO and MEGA rev3 boards. Chaos will be present for some time ahead. :smiley:
A shield maker might (or will?) have to state if their shield design is Due only, Due and Rev 3 Uno and Rev 3 Mega compatible, or only non-Due board compatible I guess for one to purchase a future shield and be sure it's compatible with what they are using?
Lefty


Rob

retrolefty:
Ok, but lets focus a bit. What would be your recommendation to a newbie to the hobby (with little or no electronics or software experiance) as to which would be their best choice to enter the arduino world once the Due is in fact avalible. I vote Uno, you vote ?

Lefty

For a beginner needing shield compatibility yes, an UNO makes sense, but
I might lean a bit more towards a Leonardo as it can do many interesting things with USB
that can't be done with UNO.

That said, I'd guess an absolute beginner probably doesn't need shield compatibility initially,
so a Teensy board might be an even better choice than an Uno.
It's much smaller, a bit cheaper, has more resources than an UNO.
(more i/o pins, more RAM, more flash), has native USB capabilities,
and is also breadboard friendly which makes it much easier to play round with than
an UNO.
For little bit more and about the same cost as an UNO, there is Teensy++ which
has 4X the code space, 4X the RAM and more than twice the i/o pins as UNO.

IMHO, Teensy++ solves the code, RAM, and I/O pin issues for most projects.

Teensy boards are also nice because of their size and form factor they can easily move
from a breadboard prototype to a 1 off project as it can easily be squeezed into many
environments that a Arduino factor simply doesn't fit very well.

With respect to the DUE being a solution for
more speed and resources than the UNO, there are other solutions out there already that
may be more cost effective than the DUE that the DUE will have to compete against.
For example, Chipkit boards. The Chipkit UNO32 is about same cost as the Arduino UNO
(nearly half the cost of the DUE)
but it has the CPU power of the DUE with 5V tolerant inputs in the form factor of the UNO.

---- bill

Si:
Maybe I am lacking imagination, but how about some examples?

The Due fits between the things an arduino can't do because of limited speed / memory and the stuff the Raspberry Pi can't do because it is not a real time system.

So some examples:-

  1. Driving a decent resolution graphics display. (LDC or OLED)
  2. Sound sampling and manipulation
  3. Direct video digitization / generation
  4. Controlling stepping motors for CNC with look ahead acceleration / deceleration
  5. RFID access control with a decent size database and response time.
  6. Oscilloscope / logic analyser with decent sample depth.

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

Now go and write your Due book. :stuck_out_tongue:

I Wonder where our Friends in Shenzhen are with this because on the 22nd of this month a LOT of crap from there is going to be devalued a bit due to the Due and just how many DFRobot shield issues there are going to be... the one with a bi-polar in place of a Mosfet?.

Bob

Now go and write your Due book. :stuck_out_tongue:

I was thinking the same thing!

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.