Go Down

Topic: Arduino Mega or DUE? (Read 55765 times) previous topic - next topic


Leaf Labs Maple is a nice board but, it also has some issues. Like the Due there is some give and take. The Due has a bigger support group and I think it will be an amazing tool with some time given to people working with it.
Good links: Eagle tutorial= http://www.youtube.com/playlist?list=PLDE1858BD83D19C70
General Arduion tutorials = http://tronixstuff.wordpress.com


The big down fall is all of these Some what zippier  devices are 3.3v at low current. This requires more attention to detail when designing a circuit. Careful not to smoke the cpu.

Unlike with DUE, at least with the chipkit and maple, the inputs are 5v tolerant so that can make
interfacing to 5v devices simpler in some cases.

--- bill


This post is quite old but i wanted some help understanding one difference in Due and Mega.

Is the code written for Mega compatible with Due or will i have to make some changes?


This post is quite old but i wanted some help understanding one difference in Due and Mega.

Is the code written for Mega compatible with Due or will i have to make some changes?

Short answer "it depends".
If the code limits itself to not directly touching the internal MCU  h/w directly and only uses the
Arduino core library functions or the APIs from the libraries that come with the IDE then the code will work for both.

But by you saying "code written for Mega", I'm assuming you have code that is not really
truly Arduino code in that it violates the Arduino APIs by directly touching hardware.
If that is the case, then no, it will not work on DUE.

That is from a s/w perspective.
Then there is the h/w issue of 5v vs 3v and pin drive capability.


Thanks Bperrybap.

I now understand what you mean. Well i am using a few libraries, some from Arduino and some from other contributors.

Is there anyway i can know if the h/w is being touched in those libraries? I will have to skim these lib files.


I will have to skim these lib files.

Rob Gray aka the GRAYnomad www.robgray.com


Is there anyway i can know if the h/w is being touched in those libraries?

If the module includes an AVR specific header file then it is probably touching hardware directly.
Things like
Code: [Select]
#include <wdt.h>
#include <pgmspace.h>
#include <eeprom.h>
#include <util/delay.h>
#include <util/atmoic.h>
#include <avr/{anything}.h>

are sure signs that there is likely to be AVR proprietary code involved.
The only reason there wouldn't be is if the header was included by accident and not used.

Then there are some other things like the AVR proprietary PROGMEM stuff:
PROGMEM, prog_char, progmem etc... to look for.

You can also look for AVR registers being used. Things like:
PORTA, PORTB, ...,  PORTG, etc
Timer registers:

Anything that uses interrupts or timers will definitely have issues.
The reason being that the Arduino environment does not provide
APIs for interrupts or timers so anything that needs this has to step
outside Arduino and talk to the h/w directly.

If you are using Paul's Teensy 3 boards instead of DUE, there are some compatibility
macros/templates/classes that provide some additional level of AVR compatibility
that the Arduino DUE support provided by team Arduino does not provide.


Thanks so much guys for taking the time out and helping :)

I will keep an eye out for the constants and avr header files you mentioned.

I have ordered a Due. Lets see when it arrives.

I have seen the Teensy 3 board. They are not available here locally. Also their I/O are lesser (right)?


You don't need to have a DUE to be able to compile the code for a DUE board.

The teensy 3.1 does have fewer i/o pins and is not shield compatible (because of its much smaller size),
half the flash and 2/3 the RAM but it has 21 analog input pins vs 12 on DUE and the biggest nice thing
on the Teensy is 5v tolerance which means you can hook up to 5v output signals.
If you do that on a DUE you blow up the processor.

--- bill


Yes you are right :)

Well i just gave it a test run.

By the way, i am assuming Arduino due is Arduino Duemilanove w/ Atmega328?

The code gave compiler error in one place.

modbus_configure(&Serial1, COM_baud, SERIAL_8N2, roomNetworkAddress, COM_TxEnablePin, HOLDING_REGS_SIZE, COM_holdingRegs);

&Serial1 which is the serial port reference


Ah. Seems i was wrong.

Had to install another IDE 1.5.8 for Due.

It gives error on first line:

#include <EEPROM.h>

How to you Flash memory for storage?


There is a libary that uses the EEPROM of the USB to serial processor for non volatile storage.
As well as one that uses flash, try google.


It is pretty crappy that the 1.5x IDE that supports DUE doesn't include a few of the libraries
that come with the AVR like EEPROM and SoftSerial.

Paul's Teensyduino does come with support for these for his Teensy 3 ARM based products.
Yet another reason why I really like the Teensy products.
Paul has done a great amount of work to ensure backward compatibility with the AVR
based interfaces & APIs so often things "just work" with teensy that don't with other
products - including the official Arduino boards.
This includes handling many of the pre 1.0 to 1.0 library APIs that the Arduino team changed
which broke 100% of all the 3rd party library code and sketches that used them.

--- bill


Maintaining backwards compatibility with legacy kit is always a problem, if you want to move forward with new technology.

A decision was made to use SAM3X, which does not have EEPROM. I think the best solution is an i2c/spi EEPROM on the Due, could have been easily done , but wasn't. Storing data in Flash is a problem because downloading a sketch erases the Flash, storing data in 16u2 requires a hardware mod and/or new firmware in the 16u2.

As for software serial, I have been tempted to do a Due version, but with 4 real serial ports on the Due, is it necessary? It would mean time spent that could be spent on doing something possibly more useful. This is the same dilemma for Arduino, do they spend limited resources developing new stuff or spend time just to stay still?

It's a tradeoff, Paul has made the decision base on his needs, Arduino have made a different decision.
Please ask questions in the forum so everyone can benefit. PM me for paid work.

Go Up