Arduino as a programming bridge to another Arduino

I had this crazy idea some days ago..

I have an Arduino Duemilanove and a couple of bare ATMEGA168s. I mainly use the ATMEGA168s for "short life" projects on a breadboard so I can try different sketches etc :wink:

I'm currently using the ATMEGA168s without the Arduino bootloader and I program them with the BitBanging method. That not easy for me, because I have to remove and insert the different chips, risking their.. pins ;D

Can the Arduino be used as a bridge to another Arduino chip?

( PC ) -- program --> Duemilaove -- program --> Arduino bootloaded chip

Of course a modified IDE will be needed in order to stop the autoreset feature or perhaps a (permanately) modified board.

Any ideas are welcome! ;D

If you pop the ATMega out of the arduino board, you can then simply carry the appropriate connections to the chip on your breadboard (TX, RX, RST, GND at least), no modifications necessary. Alternatively, you can get one of the various FTDI boards like this one to program breadboard arduinos.

Thank you! Those breakout boards are just what I needed! :slight_smile:

I also found this project* which is exactyly what I want! And no need to use the bootloader :wink:

*Google Code Archive - Long-term storage for Google Code Project Hosting.

hm, there are several ways of doing this. The simplest (from what i know) are:

  1. Build a programmer. There was a sketch ( i think it is called ISPMega or so) that you have to upload on your standard arduino. Now with simply connecting 4 lines you can program a fresh Atmel the way you want, even upload programmes

  2. This one is just an idea - havent tried it so far:
    You could connect the RX and TX lines of your USB Arduino to the RX and TX lines of the second Arduino and reroute the upload that way. Downside is defenetly that you already need a bootloader on the second arduino

  3. Try to rewire a ZIF socket to fit on your Arduino and just swap Chips as you need (the same as in the post above, yet i have ruined several atmels this way by breaking it's legs)

Hey! Thank for the reply :slight_smile:

  1. I found that sketch! I was about to build an AVR on a breadboard :wink: I will try and make some modifications to the Arduino IDE .txt config files. I saw somewhere that you can set an uploader, eg AVRISP, the one that Mega-ISP "emulates"! :wink:

  2. Also thought of that but I think it won't work because the on board AVR would interfere. It would work if I remove the on board AVR though!

I'm going to try and modify the IDE to upload a sketch to a bare AVR using an Arduino board with the Mega-ISP sketch :slight_smile:

I've got a a board I'm using for the same reason as of now.. just uploading / updating some chips that are being used for a base station...
and well, I'm really cheap! The way I see it..

I could buy the programmer (about $20 ish) and well.. use it a few times. (I'm sure it will be more useful as I get more experienced)

Or I could buy an Arduino, so I have two! And I got the upgrade chip with it as well, so got an extra for my "breadboard Arduino".

I have to say, I LOVE that you can just hook the board up to the RX and TX! Makes things a million times easier.

One thing you've got to keep in mind when doing this, is choosing the right board and chip! Every time I change boards, I forget to change it back to the 168 when on the breadboard.

Thanks CaptainObvious for the reply :wink:

Here's how I do it.

Uploading an Arduino sketch to a bare AVR or a Breadboard Arduino.

I remove the ATMEGA328 from my Duemilanove and insert the ATMEGA168 I want to program. I've modified the Duemilanove and connect the BitBanging cables.

On the IDE, I'm selecting the Lilipad Arduino (8mhz ftw) and a COM other than my Arduino's. Of course it displays a problem.. ;D I go to my sketche's folder and then on the "applet" folder inside it. TADA! There's a .hex! I grab it and burn it to my bare avr with the BitBanging method!

That mega-isp was brillitant! :slight_smile:

A big thanks to the folks behind mega-isp! Great work!

I have some extra atmega 328's that was empty with exactly this in mind.

Some problems though, avdude reports that the programmer is out of sync sometimes, quite often in fact. I don't know why that is, it generally means I can't verify. Eventually I chosed to ignore the error, and it seems to work - they can upload and run sketches from the arduino IDE :slight_smile: Which is what I wanted of course, I like that IDE. But I guess I can do (almost) without it now, but I'll wait with that until I need the space and get some more experience.

I'm really quite new to this, so the first tries didn't went too well. Until I read about the fuse settings. I followed the settings listed here: http://blog.modifiedelectronics.com/2009/08/arduino-atmega328-fuse-settings.html and (sort of) verified them against the fuse calculator here AVR® Fuse Calculator – The Engbedded Blog

I used the ADABOOT bootloader btw, since that's what was shipped on my BBB - Bare Bones Board (Arduino compatible). And more important - it seems to be a very good bootloader. http://www.wulfden.org/TheShoppe/freeduino/ADABOOT.shtml

I'm not sure why the hex file is 6k, but the bootloader 2k. I guess there are other stuff in it as well, probably including the (hex) adresses of the contents?

The fuse settings for an Atmega 328 with a 2kB (1k word) bootloader is, or at least can be (though no guaranties, of course):

High: 0xDA
Low: 0xFF
Extended: 0xFD

Oh yeah, I almost forgot the lock-bits.. in fact I tested the atmega's in the Arduino IDE before settings these, but it sems to work even though I programmed these afterwards (I just used a simple blinker app to test from the Arduino IDE anyway, no fancy stuff like interrupts or program memory access).

I set the lockbits (according to the same blog) to be 0xCF. Checking the settings in the Atmega 328 datasheet seems to indicate it is safe, but I'm no expert (table 25-1 and 25-2 page 294).

Reading back (verifying) the extended fuse setting seems to be inverted, so there is an error about it being changed. Same thing with the lock bits, but that one seems to just be the upper nibble inverted (or ignored?). Ignoring these errors seems to work (as long as the device ID checks out).