Disadvantages of Arduino Mega 2560?

Can anyone cite any disadvantages for Arduino Mega 2560? We just need to have these information for the comparison of Microcontrollers for our project study. Thanks in advance! :slight_smile:

Only 8 bit, not 32
Top clock speed is limited to 20 MHz
Not many internal resources for SRAM, Flash, EEPROM
Relatively expensive, $16-17 each.

What are you comparing it to?

We are comparing Arduino Mega 2560 to Arduino Mega. :slight_smile: Btw, thanks for the info. :smiley:

What is an Arduino Mega?

Isn't Mega and Arduino Mega2560 the same thing?

Click on Mega in the 2nd block, it opens up to Mega2560.

Perhaps you meant something else?

Sir, here is the link for Arduino Mega:
https://www.arduino.cc/en/Main/arduinoBoardMega

While for Arduino Mega 2560:

Ok, so comparing the 1280 chip to the 2560 chip.
2560 basically just has twice the memory.
Only "disadvantage" to usinsg 2560 vs 1280 is higher cost of the chip.
"advantage" is more memory if the program is big enough to need it.

Oh, the differences are:

The Mega uses the 128k chip, and the Mega2560 uses the 256k version of the same chip. Only difference is the amount of flash memory on the chip.

The Mega uses an FTDI FT232 usb serial interface chip, while the Mega2560 uses the 16u2. This doesn't matter for most users, though there are some advanced things you can do by reprogramming the 16u2.

The old 128kb Mega is scarce now, being mostly replaced with Mega2560, and clones thereof (which often use a CH340G serial adapter instead of 16u2 or FT232 for USB-serial)

OK, so if you look on the Arduino products page, you will find a section marked "Retired products".

The Arduino Mega is not included there. It's not on that page at all.

There is a reference at the bottom to "Older boards". If you follow that link, you will find the Mega.

So the Mega as a project is older than "retired"! What do you call something older than "retired"? :astonished:

Indeed - in current common usage (ie, on this forum), when someone refers to the "Mega", they're almost invariably referring to the Mega2560, not the old mega.

xtremefist23:
Can anyone cite any disadvantages for Arduino Mega 2560? We just need to have these information for the comparison of Microcontrollers for our project study. Thanks in advance! :slight_smile:

Disadvantages? How much time do you have?

Mounting holes placed so that they are unusable.

No keep-out for the mounting holes, resulting in the need for insulating washers if you do try to use the mounting holes.

CPU is clocked with a temperature-unstable ceramic resonator instead of a crystal. (I REALLY would not mind paying an extra dollar for a dang crystal!).

No footprint on the board in which TO install a crystal if one wanted to (for example, USE a crystal or change the clock frequency, etc..)

Three of the five input capture pins are not connected to any IO connectors, making them useless.

Horrible 16u2 USB to Serial adapter (pukes anything above 115K baud). What was wrong with the FTDI?

Many 8 bit ports mish-mash connected to various places, making it difficult to find and use a contiguous 8 bit port for parallel writes and reads.

Pathetic little 5 volt regulator on board that overheats if it even THINKS about incoming voltage over 9.0
Not enough VCC and GND pins, invariably forcing the user to make special adapters to power added-on peripherals.

Terrible stock bootloader. The actual bootloader fits in 2K with room to spare, but it's clogged with over 6K of code providing a "monitor" that nobody uses and actually causes lockups if code or user input happens to contain the magic "!!!" string used to access it.

Everyone whines that "floating point libraries cannot be used because they consume an extra 1.5K of flash", but the wasted 6K of flash containing the unused monitor is OK? Go figure.

Serial bootloader and serial monitor are on the same port (even though the Mega has 4 UARTS (forcing the user to manually close the serial monitor before uploading another sketch if they use a real serial emulator instead of the barely functional one built into the IDE). Worse yet, forgetting to close the monitor usually causes the OS to think the current port is in use and it switches to another one, leaving the user wondering why he sees no more serial data.

There is a lot more wrong with the whole system (the terrible "IDE" for example), but that doesn't relate specifically to the Mega, so I won't go into it.

On this note....... does anyone know of a board that contains a MEGA2560 CPU, a crystal and an FTDI interface? (Doesn't have to be Arduino footprint compatible - in fact it it were footprint compatible, that would be a negative feature).

I spend way too much time hacking Arduino boards to get them to work properly... I need to find one that is "right" out of the box so I can get on with PROGRAMMING.

Krupski:
Disadvantages? How much time do you have?

So, does this mean you are not enthusiastic about it?

Why would you want an FTDI interface? What's wrong with a CP2102? Or even a CH340?

(The 16U2 was supposed to be an advantage! Why would it not function correctly? A code foul-up perhaps? Could you not fix that?)

Krupski:
Pathetic little 5 volt regulator on board that overheats if it even THINKS about incoming voltage over 9.0

That is the issue with dog hunter AG using inferior components, possibly? Starting the end of 2013, I've seen the MEGA2560 coming with a small regulator with backward C then || marking. They have overheat issues with input voltage at 12V, after a few minutes of use. Affected a number of data loggers in a project, had to circumvent it with 12V-5V buck regulators. Same brand of regulators on wireless sd shield will not be able to power an xbee pro 900 HP (output voltage swings). Same shield manufactured a little earlier using 1117-3.3 type regulators never have this issue.

On the software side, the larger FLASH must require some long jumps and 4-byte PROGMEM pointers. I don't know to what extent this makes the code longer and slower though. Also I don't know if arduino IDE has solved the issue of using the upper 128KB FLASH (probably solved it already, but at one point you could only use the lower 128KB FLASH).

The 2560 needs (or "should have") a better and less common device programmer hardware for loading software.
(Arduino as ISP and USBTiny don't work, for instance.)

The 2560 may run into avr-gcc "oddities" when dealing with the bank switching necessary for accessing programs longer than 128kbytes (actually, SOME of those show up at >64kbytes, so they might be an issue for 1280-based Arduinos as well.) (liudr mentioned a couple.)

One issue I ran into was in larger projects that incorporate a lot of compiled libraries and source code libraries. The absence of long jumps in the code breaks function calls (my code) that originate from a memory location that is more than 64Kwords (or is it bytes) away from the function being called (library code). I had to do my own versions of strncpy so I don't have to call it when in actuality short jumps originating all over my code can't all reach it.

I still don't know how to solve this issue, just replacing stdlib calls with my own code to get by.

westfw:
The 2560 needs (or "should have") a better and less common device programmer hardware for loading software.
(Arduino as ISP and USBTiny don't work, for instance.)

The 2560 may run into avr-gcc "oddities" when dealing with the bank switching necessary for accessing programs longer than 128kbytes (actually, SOME of those show up at >64kbytes, so they might be an issue for 1280-based Arduinos as well.) (liudr mentioned a couple.)

I use an AVRISPMKII (a real Atmel one, not the Olimex clone that's labelled to look like an Atmel).

Never have any problems flashing any board or chip.

People try to save a buck and end up with $100 worth of grief in return.

Paul__B:
So, does this mean you are not enthusiastic about it?

Why would you want an FTDI interface? What's wrong with a CP2102? Or even a CH340?

(The 16U2 was supposed to be an advantage! Why would it not function correctly? A code foul-up perhaps? Could you not fix that?)

The firmware in my 16u2 chips is factory stock. I've never touched them, flashed them or modified them.

As far as the CP-2102, it's also just fine (I've got a few from Sparkfun as breakout boards). Don't have any experience with the CH340.

Unfortunately the Atmel AVR ISP MKii are no longer available for purchase. I use mine a lot, and bought a couple spares from Rochester Electronics at a slight premium in price.
I believe Nick Gammon's hex code uploader works just fine, and I have developed this standalone programmer to run that code & load files from SD card. I'll try it with a Mega to confirm.

http://www.crossroadsfencing.com/BobuinoRev17/

So the Mega as a project is older than "retired"! What do you call something older than "retired"?

Consultant 8)

westfw:
The 2560 needs (or "should have") a better and less common device programmer hardware for loading software.
(Arduino as ISP and USBTiny don't work, for instance.)

The 2560 may run into avr-gcc "oddities" when dealing with the bank switching necessary for accessing programs longer than 128kbytes (actually, SOME of those show up at >64kbytes, so they might be an issue for 1280-based Arduinos as well.) (liudr mentioned a couple.)

pgm_get_far_address () and pgm_read_byte_far () can access any address in the 2560.

In fact, I have a riot with a 2560 board loaded with about 235K of digitized audio (8 khz mono) of the "Mr Softee Ice Cream Truck" jingle and an 8 bit R-2R ladder DAC feeding an amplifier.

In summer I play it out the window and then ROFLMAO watching the kids come outside desperately searching for the ice cream truck!

This is the entire program!

int main (void)
{
    sei (); // interrupts on
    uint32_t x, y, z;
    while (1) {
        x = 0x0400; // wav data loaded at this offset
        y = 234893; // file size
        z = (1e9 / 8000); // constant for 8 khz sample rate
        while (y--) {
            DDRK = 0x00; // prevent popping due to timing skew in the AVR
            PORTK = pgm_read_byte_far (x++); // send sample to DAC
            DDRK = 0xFF; // play sample
            _delay_ns (z);
        }
        _delay_ms (3000); // 3 seconds between plays - just like the truck!
    }
}