Ryan M Sutton

Put together a full release of Sanguino that supports version 1.0.1.  Actually ended up not being as difficult as I expected since most of the directory layout has stayed the same.  I was hoping to use the new ‘variants’ to avoid making changes to the core files but ended up needing to do that to get some stuff working.Like I have said before the new method the Arduino team is using to guide the precompiler for different chips by using whether registers exist or not is much better and makes porting it to different hardware much easier.  Unfortunately the few libraries I have has issues with did not follow this lead.

The SDcard lib which is included with the install now has pin assignments hard coded for different processors rather then referencing the core/variant.  It is a quick workaround if you want to use Sanguino (with a atmega1284) with this libary.  Simply change line 120 of ‘arduino-1.0.1/libraries/SD/utility/Sd2PinMap.h’ from

#elif defined(__AVR_ATmega644P__) ||  defined(__AVR_ATmega644__)

to this

#elif defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega1284P__)

I was able to get my DataLogger project up and running with a fresh bootloader burn and recompiled in 1.0.1.  The project uses SPI, I2C, ADC, and both UARTS so I generally use it as a test case since it covers the most common features used.  I did have to modify my GPX, and Producer/Consumer libraries to work with 1.0 which was fairly easy. Mostly just changing WProgram.h to Arduino.h in a few places as well as some string functions which changed.  I’m going to clean those up and post them soon hopefully.

You can grab the new version over on Google Code: http://code.google.com/p/sanguino/downloads/detail?name=Sanguino-0101r1.zip

After putting it off long enough I started working on updating Sanguino to work with Arduino 1.0 and higher.   It looks like this could actually be easier then any version since. It looks like the Arduino guys are now doing all core features based on register values.   I first saw this tactic from msproul at http://www.avr-developers.com/ and used the same method whenever possible when I was modifying the core for Sanguino.

I haven’t really done any extensive testing but I was able to get blink, SPI, and UART functions working by just adding a ‘variant’ to the original core.  This brings up an interesting delema, which is how to install Sanguino.  If I stick with it as just a ‘variant’ (which I would really like to do) I need to be able to install into the variant directory which isn’t a big deal, but also append to the board.txt. This is no longer as simple as unzipping an archive into a directory, the boards.txt step would have to be manual or some sort of setup routine run. Not to mention making all of that cross platform.  I need to dig deeper but I’m guessing that using things like extra interrupts or UARTs might require actually modifying the core which will make my decision for me.  The traditional approach of adding a completely new directory under hardware is an option but I want to make that a last resort.

(more…)

The last few months has been busy for me, but I’m finally getting time to put back into electronics.  I had found that INT2 was not accessible with the previous Sanquino core I had built so after fixing that as well as a couple other bugs others had pointed out I put together a quick release.  As I say on the Google Code site, this will probably be the last release for Arduino 0023.  I am going to start putting my time into getting the bootloaders/cores working with Arduino 1.0 ( If possible)  I do not want to go the route of a fully forked arduino environment.  There is not necessarily anything wrong with that but I like the idea of a plugin much better and hopefully we can keep that alive.

Download the new version HERE

Should have posted about this earlier. I have been updating the Sanguino project over on Google Code with the changes I have made to support the atmega1284P and support up to arduino 0023.  If you have issues with the HEX files I posted here earlier check out the new versions.  If you still have problems open an issue on google code, I try to go through the issues reported ever week or two.

Just a quick update to the Sanguino enviroment I’m working with.  Fixed an issue in boards.txt where only one of the 1284 boards would show up. Also changed some pin definitions so that hardware SPI works. Full details here.

Sanguino-0023r2.zip

In order to get some of the features like serial ports and I2C working on my atmega1284p chips, I needed to update the Sanguino core I have been using. The latest one published is based off arduino 0018 which works ok, but 0018 is before they had added strings and other useful features built into the core. I initially started updating the Sanguino core to 0021 which is what I was using as my dev environment but was having some issues with some conflicts in stdio and stdlib. From looking at the release notes the arduino team moved to register based pre-compiler directives rather then the CPU based ones used before. This method seems to be much better suited to alternative processors and is illustrated well here.

So I moved forward updating the Sanguino core files to 0023 which is the current version on arduino.cc. The modifications are pretty simple, update the pin outs in pins_arduino.c and everything else just falls into place.

I am currently working through testing functions on the atmega1284p I have gotten both UARTs  working with out issue.  I did need to make some modifications to the Wire library to get I2C working.  Just needed to have it add pullups to the correct pins, this could have been done in hardware but I like using the software pullups.  I believe SPI will work, but am still testing that.

Here are the modified Sanguino files which support 644p,1284p,and 1284p @8mhz and also the updated Wire library:

Sanguino-0023r1.zip UPDATED (details): Sanguino-0023r2.zip UPDATED (details): Sanguino-0023r3.zip UPDATED (details):Sanguino-0023r4.zip  UPDATED(details): Sanguino-0101r1.zip
Wire-Sanguino-0023.zip

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!