Arduino Mega with ATmega2560

devobitch... I assume you are selecting the Mega board in the Arduino IDE?

One way to fix this is to add this to your boards.txt file... which is located in your arduino\hardware\arduino folder. Note that the fuse bits may be incorrect as I just copied the code from the Mega. Also the maximum_size could be increased. You should be able to find those settings with a google search. But as is, this should let you upload a sketch without getting the signature error. Just make sure you restart the Arduino IDE after updating this file and select the Arduino Mega2560 instead of Arduino Mega.

#######################
mega2.name=Arduino Mega2560

mega2.upload.protocol=stk500
mega2.upload.maximum_size=126976
mega2.upload.speed=57600

mega2.bootloader.low_fuses=0xFF
mega2.bootloader.high_fuses=0xDA
mega2.bootloader.extended_fuses=0xF5
mega2.bootloader.path=atmega
mega2.bootloader.file=ATmegaBOOT_168_atmega1280.hex
mega2.bootloader.unlock_bits=0x3F
mega2.bootloader.lock_bits=0x0F

mega2.build.mcu=atmega2560
mega2.build.f_cpu=16000000L
mega2.build.core=arduino

yes thanks it works now

aaah cool it's working?
i own a mega and NEVER got low on space...

Not that need that much of space but dam it would be cool :stuck_out_tongue: just to have it!

Greet work!

Can this version be officially brought out so i can buy one or 2?

I think it should be made official! :stuck_out_tongue:

the atmega2560's are on ebay
i bought 2
but most of the lcd's and other boards
i bought dont work i am still in the process of
trying to learn how to program and modify the i/o ports

mark

I have modified the standard bootloader to work on the 2560 mega.

http://www.cbxdragbike.com/arduino/bootloaderdocs/index.html

One important note, it only supports 128K bytes because the stk500 v1 protocol only supports 128k bytes.

Also, there is a bug in the gcc 4.3.2 compiler that really limits you to much beyond about 80K program space. This if fixed in gcc 4.4.0 and later.

I am working on an stk500 v2 bootloader for the 2560.

Mark

Funny you should bring this up I was just looking at one today. You might want to check out eMartee at www.emartee.com. They sell the board and have a post on how to get the bootloader, as a matter of fact they have everything on thier site. I was logging in to ask if anyone had dealt with this company before I placed my order for one.

I was logging in to ask if anyone had dealt with this company before I placed my order for one

Hi, i have more than once bought things from emartee, at ebay. I am very pleased about this seller on ebay. emartee2009 on eBay
Correct and fast shipping. I did not bought on their site yet.

Hi, Mark, have you got any result on stk500 v2 bootloader for the 2560?
Thanks a lot for your time.

Hi, Mark, have you got any result on stk500 v2 bootloader for the 2560?
Thanks a lot for your time

Yes it is all finished. I am working on documentation and waiting on Massimo before I can do some final testing. Then I will release it.

The new bootloader has a built in monitor that allows you to examine memory and and ports.

Mark

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1274821710

for now, you can't even use all the flash memory on the 1280 and none of the extra flash memory on the 2560.

That said, I too think it would be cool.

That is correct, there is a bug in the avr 4.3.x compiler. It is supposedly fixed in 4.4.0 and later. I hope to have the new version of the compiler tested by the end of the week.

I have documented the bug in other threads.

Mark

That is correct, there is a bug in the avr 4.3.x compiler. It is supposedly fixed in 4.4.0 and later. I hope to have the new version of the compiler tested by the end of the week.

There seems to be a major bug in 4.5.0 and 4.5.1 to do with the initialization of global class variables that is not present in 4.3.x. It manifests itself most obviously in the failed initialization of multiple instances of HardwareSerial on the mega in even the smallest projects:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617

I can confirm that the bug is present in 4.5.0/4.5.1 on Windows (mingw compiled gcc, avr-libc 1.7.0).

After refactoring the HardwareSerial instances to be dynamically initialized I found other cases in my project where this bug caused crashes. I would advise staying away from 4.5.0+ until this bug is fixed.

Hi;

is the bootloader downloadable from the cbxdragbike site (June 23rd post in this thread) the latest version for the Emartee Atmega2560 board?

Jan

I would assume the latest version of the bootloader should be the one in the latest version of the Arduino IDE. Arduino as supported the Atmega2560 since the release of the UNO and MEGA2560... release 20 I think? You can either load it directly from the latest version of the Arduino IDE or you can find the hex file in the same place as the other bootloaders within the Arduino IDE directory structure.

I looked in:

C:\Program Files\arduino-0021\hardware\arduino\bootloaders\atmega

and the most recent/modern bootloader in the IDE seems to be atmega1280.

The procedure outlined in:

http://www.cbxdragbike.com/arduino/bootloaderdocs/index.html

seems straightforward, I am assuming that after following the instructions, and wiring my target board according to the first example in the arduinoISP tutorial

my atmega2560 board can be programmed using USB.

Jan

Just downloaded it to check where it was...

look in

arduino-0021\hardware\arduino\bootloaders\stk500v2

then it should be stk500boot_v2_mega2560.hex

I'm not sure if this is different or not, but it is definitely the "official" one

Thank you, that is definitely a newer file than the one I was contemplating burning!

Cheers,

Jan

A couple of weeks ago Mark suggested to me that the compiler issues with the 2560 are not as great as we had thought. the tests referred to above filled the lowest 64K of static memory (where your program and PROGMEM data go) with a huge amount of PROGMEM data. I checked out the issue with a program (a very atypical program that I generated using another program) that uses no PROGMEM data. It compiled loaded and ran OK. I have seen programs based on this work up to about 110K so far.

Most address information generated by the compiler is 16 bits and so is limited to addressing 64K. The compiler, however creates a 'trampoline' table in the lower 64K that is a list of long JMP instructions to addresses higher in the static RAM. I think the test that used a huge amount of PROGMEM data and failed put so much data in the low 64K that the trampoline table would not fit there. I know Mark's been working on this and is probably considerably more knowledgeable than I am about it.

Googling 'GCC AVR trampoline' is useful.