At this point I'm really regretting my purchase of a mega2560 based board. The compiler (4.4.3) my distribution provides is buggy. Seemingly, the bugs are well known and yet many distributions still provide it. I can confirm my compiler is buggy as everything immediately crashes after flash unless some modifications for core arduino code is first made. Sure enough, after making some modest changes to some core arduino files, I can and have managed to compile a cross section of code but even that is iffy as anything which requires globals object instantiation and even ISRs is begging to trigger the compiler bug; which has to do with register save/restore. I've repeatedly read for the 2560 you should use <= 4.3.x >= 4.6x. Worse, I also found that avr-libc < 1.7.1 also contains some mega bugs. Further reading indicates even 1.7.1 still contains some bugs but I'll happily ignore those for now and hope for any solution which actually works, even if its with known caveats.
So I bit the bullet and decided to compile my own compiler and avr-libs. I've done this type of things before. I'm hoping this doesn't turn into a minotaur maze as is frequently the case. So, I decided to start with gcc 4.6.1, believing this will provide the latest bug fixes and MCU support. Appears I'm right. So I get 4.6.1 compiled and then move on to avr-libc 1.7.1. Turns out its not really compatible with 4.6.1 and a manual patch it required. Fine. Spent some time reading and finally got binutils 2.21.1 + gcc 4.6.1 + avr-libc-1.7.1+manual patch compiled and installed. I'm starting to get excited. All my problems might now be behind me.
I then undo the manual arduino tweaks which I had previously done to allow for code compilation with gcc 4.4.3; allowing for some code to run properly. I then go to one of my examples which I had previously compiled via gcc 4.4.3 + tweaked core; keeping in mind object code from the 4.4.3 compiler still existed. To my amazement it compiles and flashes; recompiling only the un-tweaked core arduino code and associated dependencies. Wow! First time anything compiled and ran without a tweaked arduino core. And with the latest stable gcc + avr-libc no less! Really getting excited now! Next, I did a, "make clean && make". After all, I still had objects from the old compiler being used. Everything falls apart here. Turns out arduino 0022 isn't compatible with gcc 4.6.1. Crap!!! More reading hints that arduino 1.0 may be more friendly with this compiler library combination.
So I decide to take a step back in time and try my luck with gcc 4.3.6; though 4.3.4 is generally what I find is recommended; whereby those recommendations tend to be rather dated. So I compile c and c++ support for 4.3.6. No real surprises. I then attempt to compile avr-libc 1.7.1, at which time it happily informs me my compiler (4.3.6) does not support the mega2560. Even after ignoring and moving on, attempts to compile my code proves this by the compiler confirming the MCU is not supported by the compiler. So 4.3.6 and presumably 4.3.4 are not even an option for my MCU, despite the old recommendations, which likely centered on the mega12xx anyways.
So at this point, I'm seriously regretting my purchase of a mega2560 based development board. The state of things for these MCUs is extremely bad and most definitely not an out of the box solution for your typical arduino newb.
So here I am, begging the question, which combination of gcc+lib-avr+arduino actually works properly with the mega2560? What is winavr doing to support this MCU? On which gcc and avr-libc is it based? And assuming it actually has a working solution, are its patches generally available? Should I be looking at gcc 4.5.x + arduino 0022?
Actually, I'm beginning to regret my 2560 board as well. I have not had any trouble compiling. Everything I try seems to work just fine using arduino IDE 21. However, getting it on the board is an exercise in anger management. Add to that the fact that simple changes to the watchdog timer code that were discovered and created years ago are not in the 2560 bootloader.
I realize that bugs happen and that sometimes it's a painful process to get fixes in place, but it's approaching a year ago that these shortcoming were discovered and there is nothing being talked about (other than my one little thread) fixing it. I have indications that the code fixes for both of the items I have problems with have existed for months, MONTHS, and there is nothing out there for me to load on the board.
What the heck?
Currently, my recommendation to folks is to avoid the entire UNO line and stick with the older or clone stuff. I'm sure I could have used the previous mega board just fine. And frankly, I'll wait at least a year before I even try version 1.0
At this point I've now tried arduino 0021+4.5.3, 0022+4.5.3, 1.0-beta1+4.5.3, all of which are broken for mega2560. Meaning, compiles and flashes fine but doesn't run assumingly because of the register save/load bugs. I then tried 0021, 0022 (again), and 1.0-beta1 + 4.6.1, all of which are broken for mega2560, typically unable to even compile.
This is especially frustrating as I can find projects which reportedly are using mega2560s + avr-gcc. The ArduoPilot seems to be one such project; though perhaps with a 1280 (IIRC) bias. And it seems winavr claims to support mega2560. So I guess the real question is, what combination is working? Which, if any patches are being applied? And in which combination is it being used with the arduino core libraries? Even stranger yet, why are linux distributions providing a known buggy compiler which has been known to be broken for over a year now? Fedora seems to be stepping in the right direction but I have no idea if they have actually found success.
Thus far, I can't stress enough no one should be using mega2560 until this this silliness becomes a priority and gets resolved. As you've pointed out, this nonsense has been going on for over a year now. Why it is this painful to simply get something to cleanly compile and reliability run with the mega2560?
It seems you're using arduino 0021. Which compiler/platform are you using? Are you using winavr? Based on various readings, I get the impression winavr is 4.5.x + a bunch of patches. So perhaps this is why the majority (assuming they are using winavr) are finding success with the mega2560 series?
Actually, I don't know what the versions are internal to the IDE. What I did was download iDE 21 and just use it on a windows machine. It has worked pretty reliably in creating code that actually runs. There were a couple of things that wouldn't compile early in my experimenting with it, but I've forgotten the details and I found work arounds pretty easily. I've been afraid to experiment too much because of the problems other folk have reported with various changes. Basically, I've got something that seems to work most of the time and I'm afraid to change it.
However, if you move this thread to the Installation and Troubleshooting area, it might (maybe) get more attention. However, I can't prove that since my thread on the bootloader has been essentially ignored by the developers. Also, if you need numbers from what I'm running, let me know what to look for and I'll get them for you. However, I'm using windows so it may not be any help for you.
Did you try the install scripts from Bingo (avrfreaks.net) ?
One is for avr-gcc 4.3.4, the other one will give you 4.4.3 + libs etc. I've attached both, so you don't have to register at their forum just to get the files. Going there is recommended anyway!
I'm trying out the build scripts and whatnot. I'll report back success or failure. The good news is I quickly reviewed the patches which was part of the build and it very clearly adds support for 2560s. Looks like it has a number of other tweaks too but I didn't investigate much beyond that.
Quick update. The provided scripts does the job - sorta - indirectly. The scripts are extremely fragile and make wildly poor security assumptions. I suspect for most linux users, the scripts only have value so far as their content. Which is to say they have links to patches. Furthermore, some of the download links simply don't work. The hosts were likely at capacity or some such thing. At any rate, I had to do everything manually. Thankfully the patches provided by those scripts were readily available for download. I quickly snatched up those patches. One item of concern is that a hunk from one patch did not apply. I blissfully pretended I didn't notice. I guess we'll see if this bites me later.
After various trails and tweaks, ignoring some flags provided by the scripts and using yet others, I finally got a compiler and libc which seems to compile fine against my tweaked core. It even runs. I then removed my core file tweaks (HardwareSerial.cpp). It too compiles and runs! Woohoo! Did a make clean. It too compiles and runs! Double woohoo! I then modified my example to instantiate a global object instance. Previously I had to do it inside of loop(). It too compiles and runs! Seemingly perfect!!!!!
I finally have what I'm strongly inclined to declare is a working compiler for the mega2560 MCU! Painful but thus far working.
I guess the underlying question remains. After over a year, why is a mostly broken toolchain for the mega2560 still prevalently pushed and provided on linux? And why isn't a moderm toolchain being embraced whereby additional optimizations are otherwise unavailable. For example, link time optimizations (lto) would be a really nice feather for the platform, especially for C++.
Of course, the libc, AFAIK, still has some mega2560 bugs. Last I read, 1.7.1 is required to fix a number of known bugs and even that version still has some outstanding mega2560 issues. So while thus far things have vastly improved, until libc > 1.7.1 is found to compile and work, chances are the mega2560 is still going to be a buggy architecture. But I have no idea if that's a reasonable, pragmatic concern.
Thanks so much guys!!!
If anyone cares, here is what I'm currently running:
binutils 2.20 + provided patches
gcc 4.3.4 + gmp-4.3.1 + mpfr-2.4.1 + provided patches, which includes mega256[01] support
avr-libc-1.6.8
arduino 22
I completely agree. I have no idea why so many Linux distributions go out of their way to provide cross compilers when the majority of these compilers are completely broken for a number of CPUs.
Of course, I still don't get why the compiler/libc/arduino combination seems to be so incredibly fragile. I guess I'm nieve in my thinking that people would actually want the latest on compiler bug fixes, optimizations, language features (cough c++), latest MCU support, library accessibility, so on and so on. Perhaps its just a lack of manpower. If so, hopefully the influx of interest from the arduino community will help address the issue down the road.
But even still, the mega2560 in general seems to be poorly supported. I mean look at some of the threads which talk about broken bootloaders (wdt & flash protocol), broken libcs (still broken in the latest 1.7.1), so on and so on. Many of these seem to largely plague the 2560 platform and in many cases, the problems seems to have been ignored for very large spans of time. Its disappointing to say the least.
Edited: Added the following...
Based on what I read in the GCC bug reports, even they seem to officially recommend 4.3.x and 4.6.x. Which makes me wonder why isn't the AVR/arduino community pushing to modernize on 4.6.x such that the AVR line is well supported with vanilla GCC/binutils? That alone would have prevented a fair bit of pain I experienced. As is, 4.6.x and arduino seem to be completely incompatible.
But even still, the mega2560 in general seems to be poorly supported. I mean look at some of the threads which talk about broken bootloaders (wdt & flash protocol), broken libcs (still broken in the latest 1.7.1), so on and so on. Many of these seem to largely plague the 2560 platform and in many cases, the problems seems to have been ignored for very large spans of time. Its disappointing to say the least.
Both the Uno and mega2560 boards have had more then their fair share of problems and bugs. The new 8u2 serial converter chips and the new bootloaders were probably not quite ready for prime time when released to the wild. Not sure the current IDE release even has the latest corrected fixes yet, and of course a lot of user contributed libraries are not 2560 aware, but that's not a fault of the arduino team. I know SparkFun had to replace a lot of the early Uno (or mega2560?) boards for one of the early bugs.
But even still, the mega2560 in general seems to be poorly supported. I mean look at some of the threads which talk about broken bootloaders (wdt & flash protocol), broken libcs (still broken in the latest 1.7.1), so on and so on. Many of these seem to largely plague the 2560 platform and in many cases, the problems seems to have been ignored for very large spans of time. Its disappointing to say the least.
Both the Uno and mega2560 boards have had more then their fair share of problems and bugs. The new 8u2 serial converter chips and the new bootloaders were probably not quite ready for prime time when released to the wild. Not sure the current IDE release even has the latest corrected fixes yet, and of course a lot of user contributed libraries are not 2560 aware, but that's not a fault of the arduino team. I know SparkFun had to replace a lot of the early Uno (or mega2560?) boards for one of the early bugs.
Lefty
Eeek. Well, that doesn't sound good. From reading other threads, it seems my board wasn't alone in having an entirely incorrect 8u2 firmware. Seems others have reported theirs have been loaded with uno firmware; or at least that's what it identified itself as.
Lefty, do you have the impression things are improving for the 2560 or is it to become the red headed step child of arduinos? Thus far it certainly doesn't seem likes its getting much love.
Lefty, do you have the impression things are improving for the 2560 or is it to become the red headed step child of arduinos? Thus far it certainly doesn't seem likes its getting much love.
Nothing fundementally wrong with the underlining hardware on either the Uno or mega2560, just firmware/software issues that are either solved or will be solved in time.