Ryan M Sutton

When I was running into some issues of running out of sram on the atmega 328 I started to look at alternative chips, unfortunally the next chip up in the standard line is the atmega 2560 that is used in the Arduino Mega. Since I was focusing on sram i was mainly concentrating on that aspect for my next chip. The 2560 has 8k sram, which is nice ( compared to the 2k in the 328 ) but I saw the 1284P which has 16k. Before ordering some i looked around to see if anyone had put a arduino bootloader on it, and there were a number of people tinkering with them on the arduino.cc forms so I went for it.

The main issue I was running into was that everyone on the forms wanted to run their chips at 16mhz or 20mhz, way faster then the 8mhz I use. So, this ment no using or even trying the .hex files posted by others. It was pretty clear from this thread, that the direction to go would be a modified Sanguino bootloader. The Sanguino project is a modified arduino stack ( bootloader and wireing library ) for the atmega644 which is the same class of processors and is pin compatible with the 1284.

I had the timing issues with the clock change sorted out pretty early, but was still having issues getting the bootloader to write code into the flash. I could see code going from serial, to buffer, to page buffer, but the page just wasn’t being written by SPM into flash. I believe my main issue was the calculation of where the boot section actually started. When you look at the fuse descriptions they tell you where the boot section should start. For example I am using a 2048 word boot section. What they don’t make clear is that the address they give you ( 0xF800 ) is in words as well, then when you specify the load point to avrdude it is in bytes. This is probably something I should have found sooner, epically since this is the main problem referenced on the forms. So, when you load your application into the wrong section say 0x7C00 it will still run ( assuming your chip is otherwise blank ) since it is the first instruction in memory, but when it hit the SPM call, it will fail since SPM is only allowed in the bootloader section.

Here is the files that ended up working for me, see the form above for where they came from:

UPDATE: Broken Links fixed.

Ran into a bug in my GPX Library that produced some interesting results. The problem manifested itself as what initially looked like half my data from a test drive being currupted, I initially was thinking it was a memory problem, or data being currupted in the I2C transfer. After looking at the tracks for a while trying to figure out how they got currupted I noticed that the point where the data went from clean to corrupt appeared to be level. When I focused in on these points they were in fact exactly at 43deg latitude. I then noticed a small piece of what looked to be clean data a bit north of the 43deg point. Uppon inspection clean data was at 43.10000 deg latitude. It didn’t take long to realise that I had not padded the fraction part, so 43.00001 was going into the file as 43.1

I went back to the source file and quickly fixed them with ‘sed’ and the result is a much cleaner track.

And when over layered with OSM (http://www.openstreetmap.org/) data the track appears to be very accurate!