I think the symptoms fit this problem... http://arduino.cc/forum/index.php/topic,64256.0.html

I may have to read this a few times to catch the relevance.  There is a lot of info here and I am still a bit green around the ears.

Thank you for the response.

Some time back I had an Arduino Duemilanove that was working quite well.  Then I started getting a "stk500_getsync(): not in sync: resp=0x00.  I found lots of suggestions on the web but nothing worked.  Stuck the board in a drawer, ordered an Uno and went on my merry way.  Sometime later, I ordered several 328 chips with the bootloader, so I decided to replace the chip on the Duemilanove with one of these, but got the same error.    Then some time after that (15 minutes ago)  I wondered if using a programmer and the ICSP pins might allow me to program the chip.  Sure enought, avrdude saw the chip fine, so I went into Arduino IDE and loaded the blink program using the programmer and it was successfull....to a point.   I noticed that the blink rate seems to be running at ~15 seconds instead instead of the 1000 ms that the program calls for.   Does this added tidbit of info tell anyone more about what might have happened in the first place?   Unfortunately, I can't find the original 328 that I took out six months ago.

Obviously, not the end of the world since I have something that works...but would like to understand anyway.

Thanks

So...I do the avrdude as outlined above and the final message is an error.  I'm think "Oh crap!"  Then I realize that if it changed the fuse, it would expect the occilator and even though it communicated long enough to change the fuse, it couldn't communicate after tha to give the rest of the message.

Plugged it into the board that was running so slow and it does exactly what I wanted.

Thank you again.  I love it when a forum plan comes together.

Charlie

Ok according to avrdude using -v my fuses are currently....
lfuse = 0x62
hfuse = 0xD9
efuse = 0x7  (07 I guess)

according to the simulator in AVR Studio, I need lfuse to be FF, so it seems that I should be able to use avrdude to make the changes like this...

avrdude -c usbasp -p m328p -U lfuse:w:0xff:m

I am assuming that this will change the lfuse and leave efuse and hfuse as they are.  

Does this seem to be the right direction?  
(it almost seems that I should be able to do it in AVR Studio, but don't know how to get it to recognize my usbasp)

Sorry...sometimes I just can't turn loose of things.

I was looking at the AVR Studio simulator and it appears that there are two changes I would need to make.  I would want to turn off (0) the CKDIV8 bit and turn on (1) the CKOUT bit.  Does that sound right?   

You are a jewel!!   

I have a USBASP so I will probably try the ISP method.    Unfortunately, my day job is pulling my strings pretty hard right now, but hopefully in a day or two.

Thank you.

I would really like to learn to change these fuses "safely" even if one or two hit the sacroficial flames.   Any clues as to where I might get the info to learn this?

I have never added the bootloader either, but I figure that won't be to difficult through the arduino software.  Just hate to add something unnecessarily.

Nick:   Am I right to assume that if want to use 328p with a 16mhz oscillator, I would need to change the fuses by loading the uno bootloader or by some other method?

Reason:  I have a sketch that runs quite will on the uno, but runs quite slow on the breadboarded 328p.  I tried hooking up an oscillator (don't have a crystal right now), but it seems to make no difference, so I assumed that something has to happen with the fuses.  Correct?

Also, I don't know if this is proper board etiquette since I may be introducing topic drift with this question.
Thanks for all your help.

Thank you very much for confirming that it should work.

I have separate power to both and both are lit up.   

The mega, unfortunately is a counterfeit (Says Arduino Mega 2560, cost the same, but turned out to be a knock off).  I don't completely trust that it is not the problem.

I will swap master and slave and see what happens.   If still no go, I will breadboard an atmega328 with the uno and try it that way.   

I have taken this apart and put it together many times, so I am very confident that what I described is what I am doing so I have to think something is not behaving right.

Thank you again.

Is there any reason that I should not be able to use the Mega2560 as the master and the Uno Rev3 as the slave using the Wire.h library and the example sketches (master_writer on the Mega2560 and slave_receiver on the Uno).   They are wired ....

Mega GND -> Uno GND
Mega SDA (pin 20) -> Uno SDA (pin A4)
Mega SCL (pin 21) -> Uno SCL (pin A5)

Seems to hang on endTransmission on the master with no activity ever on the slave

On the Mega (some serial output added for debugging) ....

Code:

// Wire Master Writer
// by Nicholas Zambetti <http://www.zambetti.com>

// Demonstrates use of the Wire library
// Writes data to an I2C/TWI slave device
// Refer to the "Wire Slave Receiver" example for use with this

// Created 29 March 2006

// This example code is in the public domain.


#include <Wire.h>

void setup()
{
  Wire.begin(); // join i2c bus (address optional for master)
  Serial.begin(9600);
}

byte x = 0;

void loop()
{
  Serial.println("starting transmission");
  Wire.beginTransmission(4); // transmit to device #4
  Serial.println("write value");
  Wire.write("x is ");        // sends five bytes
  Wire.write(x);              // sends one byte  
  Serial.println("end transmission");
  Wire.endTransmission();    // stop transmitting
  Serial.println("increment value");
  x++;
  Serial.println(x);
  delay(500);
}

On the Uno

Code:

// Wire Slave Receiver
// by Nicholas Zambetti <http://www.zambetti.com>

// Demonstrates use of the Wire library
// Receives data as an I2C/TWI slave device
// Refer to the "Wire Master Writer" example for use with this

// Created 29 March 2006

// This example code is in the public domain.


#include <Wire.h>

void setup()
{
  Wire.begin(4);                // join i2c bus with address #4
  Wire.onReceive(receiveEvent); // register event
  Serial.begin(9600);  // start serial for output
  Serial.println("waiting...");
}

void loop()
{
  delay(100);
}

// function that executes whenever data is received from master
// this function is registered as an event, see setup()
void receiveEvent(int howMany)
{
  while(1 < Wire.available()) // loop through all but the last
  {
    char c = Wire.read(); // receive byte as a character
    Serial.print(c);         // print the character
  }
  int x = Wire.read();    // receive byte as an integer
  Serial.println(x);         // print the integer
}

I tried it with and without a pullup on the Uno pins A4 and A5

Another user thought it might be usefull for me to post the code I used to solve this problem.  There is not very much relevant code, but I guess for a newbee like myself, it might be helpfull.   The more experienced users may find ways I could have done this better,but at least I know it works.  

The goal was to pass a value 0 thrugh 5 from the atmega328 to the attiny85 so that the attiny counld take some action.   The value, I guess could have been any value between 0 and 255, but I just needed the six above.  This code will show how I did it but not why.  This was just to test the ability to make these two talk to each other.

On the atmega328p (uno or mini)....

Code:

#include <Wire.h>

void setup()
{
  // initialize the attiny with a starting value  Wire.beginTransmission(38); // transmit to device 38 -- should  match only one slave.

  Wire.begin(); // join i2c bus (address optional for master)
   Wire.write(5);         // sends a byte
  Wire.endTransmission();     // stop transmitting

}

void loop()
{
  for (int i=0; i<6; i++) {
    Wire.beginTransmission(38);   // transmit to device #38
    Wire.write(i);                // sends mode as 0 - 5
    Wire.endTransmission();       // stop transmitting
    delay(1000);    
    }

  
}

on the Attiny....

Code:

#include "TinyWireS.h"
 #define I2C_SLAVE_ADDR  0x26            // i2c slave address (38) -- the number is a bit arbitrary, but needs to be unique on the network.

int recvd;  


void setup() {
  TinyWireS.begin(I2C_SLAVE_ADDR);      // init I2C Slave lightMode
  }
  
void loop() {

  // these lines will be used to retrieve a byte (0 - 5) once I can get this to work
  
    if (TinyWireS.available()) {
        recvd=TinyWireS.receive();
        
        // take some action with the value in recvd.
        
      }
  
  }

I used a 4k7 pullup on attiny 5 and 7 and attached them to arduino A4 and A5 respectively.  Of course both processors shared  ground and 5v

Thanks for the code, Erni.   This is one of the ways I had tried to make this work, but did not know how exactly.  This code will be extremely instructive.   I managed to solve my problem using Wire.h on the uno master and TinyWireS.h on the attiny85, thanks to a lot of help from Nick.   This will be another way that I want to understand so I will play with this.

Charlie

Yep, that did it!

Thank you very much, Nick.   I learned a good bit.   

Now on to coding the master.  Hopefully with more understanding.

Charlie

Therein lies my salvation......maybe.   I will swap  SDA and SCL for CLK0 and CLK1.   I will also use a 4k7 pull-up on SCL and SDA.   Does that sound right?

I will also post the results in case  I am not the only knucklehead that runs into this issue. 

Thanks.

Your description of "the plan" is correct and what you say about I2C using the pins makes sence.     I guess I need to figure out what pins the I2C needs to communicate.    Do you think I could use the PB5 (reset) or would I have to make changes to the fuses to do that?  How about the CLK1, or CLK0. 

Do you know what pins I2C requires.  Also, my limited understanding is that the attiny does not directly support I2C so the TinyWireS library creates a wrapper around USI in order to communicate.  Does that mean that I am more concerned with what pins USI uses than I2C?