What I mean by "crash" is it crashes on sketch upload, not when the command is executed.

Well uploading usually leaves error messages in the IDE output window if unsuccessful, as uploading is a simple serial communications of the hex file data that avrdude uses to send to the bootloader code in the arduino board and stored in program flash memory area. If you get no errors on uploading (get the uploading complete message), then the code is indeed crashing as it tries to execute the code, more likely stuck in some infinite loop.

Usually one can embed diagnostic serial messages into the sketch code to determine how far the program is getting before 'crashing'.

The upload shows successful, but the code will not start on upload or reset.I have experimented with this for two days, and finally came up with this code to determine where the crash was happening. The LED does not light. Remark out the "Serial.begin(9600);", and all is as you would expect.

Yes. I did download it from the repository for my version of Linux. These are the versions they show:avr-gcc 4.4.2avr-binutils 2.20avr-libc 1.67

The repository has been very reliable in the past. Do you see anything here that should be upgraded? Did I miss a utility?If so, I can recommend the repository team compile new versions. It might take a while tho.

EDIT: I missed the link on your first post. I see it now, and thanks!

I do not really see a "problem solved" anywhere tho. The Windows version compiler works great. It is set a a tcp client with an ethernet shield, and after "flying" all night, it just "phoned home", and established 2-way comm immediately. Very impressive hardware.

Yes. I did download it from the repository for my version of Linux. These are the versions they show:avr-gcc 4.4.2avr-binutils 2.20avr-libc 1.67

The repository has been very reliable in the past. Do you see anything here that should be upgraded? Did I miss a utility?If so, I can recommend the repository team compile new versions. It might take a while tho.

Based on my own experience, chances are very high they are handing out known buggy compilers. You can compile your own binutils, compiler, and libc; which I strongly recommend. Again, from my own experience, the distros are very much aware they have a crappy AVR compiler but just don't care. I guess from their perspective, the number of users who not only cross compile for AVR AND are using one of the MCUs which are buggy with their compiler is so small, its not worth their time.

As a stop gap, so as to allow you to use the Serial interface with your compiler, try this. Modify HardwareSerial.cpp. Make the following changes at the end of the file.

The Mega2560 has four hardware UARTS. This change means only one is available (Serial); without manually instantiating them inside your loop. Furthermore, instantiating other global objects will likely also trigger the compiler bug which screws up save/restore of a couple of registers. This in turn means you'll need to move some globals into the loop() scope. This in turn means lots of examples will not work without change. Furthermore, this means a lot of code will simply not work without yet more changes.

If compiling for the 2560 is important for your project, I strongly encourage you to compile your own compiler. The combination which works is documented in the thread. The important part is applying the patches. As noted in that thread, one hunk from one patch failed to apply for me. Regardless, once done you should have a compiler which at the very least is far more reliable than the one provided by your distribution.

Now if only the arduino devs would release a 0023 based on the current libc + gcc 4.6.x. In doing so, it would likely prevent the Linux problems altogether. But once again, I guess the cross section of users means they don't really care either.

Thanks very much. I missed the link to the other post my first time through. I will try the patch, but my current app requires ethernet client to work also, so overall it will help, but not enough for this project.

Winavr works good. Gotta get back to my Windoze computer and do some coding. It is compiling everything correctly. Serial, ethernet client, and all....so but =(

A followup. I downloaded the newest 8-bit compiler from Atmel. http://www.atmel.com/dyn/products/tools_card.asp?tool_id=17311&category_id=163&family_id=607&subfamily_id=760Unzipped it and copied the files to the /usr/ folder.Tried to compile a test program and crash! Got an error about delay.h when it compiled. An error about fabs and ceil.No problem here. That is because they forgot the#include <math.h>So if you are following along, open /usr/avr/include/util/delay.hand add the #include <math.h>.Try a compile, and crash!Now something about "( or : expected before double".So open /usr/avr/include/math.hand remark out this line:

EDIT2: IT IS WORKING!! Serial works, ethernet doesn't crash. I forgot to set the board type after the new install. Now it uploads and all...Thisis what I show now:

avr-gcc (AVR_8_bit_GNU_Toolchain_3.2.3_314) 4.5.1Copyright (C) 2010 Free Software Foundation, Inc.This is free software; see the source for copying conditions. There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But you must do the changes to the header files or it will still crash.

I should had said in the other thread that I also tried their compiler. It didn't work for me. I didn't spend much time on it but that also ignores they install the compiler into a system location they shouldn't be, which makes it all the more unattractive.

I disagree. If this were a compiler for Linux, I would agree. But it isn't. This codes for Atmel. Has nothing to do with the host machine. Kinda like Java in a way.

I really wish you would try it, just on a test machine if you have one. Wouldn't it be nice to be able to download this and have work right "out of the box"?

Standard convention is they should not be installing anything into /usr. They should be installing into /opt or /usr/local. To install third party software into /usr is a horrible violation of standard and best practices; especially since it can directly conflict with system provided packages. There is nothing about it which is a good idea.

And as I said, I did previously try it and it failed right off. I don't recall the nature of the issue I experienced but it may be what observed. Its also worth noting, I'm running 64-bit which can sometimes further complicate things. Again, as I said, I may give it another whirl.

Many thanks for your input. I had not considered the location of the code. I had gone only by what the repository had done. That may be a good thing to consider. My repository put the files in /usr/avr//usr/bin//usr/include/etc.

The types of files that it put in those locations fit. That is the same file location/type that came from Atmel also. ??

Any time you download executable files, or even source code to build them, you are taking a bit of a chance. It is best if you stick to reputable suppliers. That link above is to the Atmel website, where I downloaded this from.

WARNING!! It did NOT work in all cases. ethernet client has problems with client.available() and client.read().