Add support for Atmega2560#190
Conversation
It adds generic support for devices with more than 128KB flash. Also MEGA 2560 is included as valid target. It needs Avrdude 6.1 or at least patch from http://savannah.nongnu.org/bugs/?40897 for earlier versions.
|
We've been running with these changes in production for a year now (100+ boards) without any problems. If there is interest to merge this, I'm happy to rebase this PR to make it apply again. |
|
Yeah, OK. My objections were mainly philosophical (it's a hack to STK500v1, where the protocol-aware parts become unaware of the addresses in use), but testing plus the fact that it doesn't affect any chips without RAMPZ (wait - how much has this been tested on 128, 1284, and 1280 systems? They have RAMPZ but don't need this patch, right?) |
|
Hm, I see your point about the hack to stk500, though this is how tools expect it to work in practice, so we might just have to deal with that... As for testing - I have only tested this on a 2560, good point about testing on 64kiB systems. Turns out I have a 1284 board here, so I'll make sure to test on that board as well (might take a bit of time, though). |
|
MegaCore uses the majekw version of optiboot with the code from #159 for ATmega128 and ATmega1280 and others. It's a reasonably popular hardware package and there have been no related bug reports in its over two years of existence. MightyCore uses the same bootloader for ATmega1284, ATmega644 etc. for years, is even more popular, and also has had no related bug reports. I've used that bootloader on ATmega644, ATmega1284P, ATmega128, ATmega2560, ATmega2561 with no problems. I have not tried the bootloader from this PR. If there are any specific tests you want done I'm happy to do so with any of those chips. |
|
Looking again, I see that @majekw has picked up the fix from this PR into his #159. I compared the resulting patches with some help from git, and the code is now identical (the only difference is the ordering of boards in boards.txt). Given that #159 was first and has seen more testing (as pointed out by @per1234), I'm closing this PR in favor of #159. |
4 participants
This PR makes some improvements on #159, which I've amended into @majekw's commit. Compared to that PR, this rebases the commit on top of the current master, makes some cosmetic improvements, and makes sure that RAMSTART is correctly set. With the commit from that PR, the data buffer is placed halfway the I/O register space, which causes data to be written into various port, timer and uart registers. Not all bits in these registers are writable, so the data would not make it into flash unchanged.
@majekw, it seemed faster and easier (also for you) to just create a new PR instead of asking you to change yours, even though it might seem a bit unfriendly :-)