ATMEGA328P I2C Speed Issue

Go To Last Post
39 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey,

 

     I have a custom designed CCA that uses an ATMEGA328P micro controller, a MCP4725 DAC (I2C interface) and another sensor (SPI interface).  In my initial design all of these devices ran off of 5VCC and the atmega utilized a 16MHz resonator to provide the clock.  Everything worked great, I had my I2C clock at 400khz and my SPI clock at 5Mhz.  In an effort to reduce the power consumption, I was playing with the clock scaler to get the ATMEGA to run at a lower speed and use less power with success.. To reduce power even further I made the following changes:

 

1.  I replaced the 16MHz resonator with a 2MHz resonator

2.  I put a 5V to 3.3V regulator on my board to run the ATMEGA at 3.3V

3.  I used a PCA9306 voltage level translator to work between the ATMEGA and MCP4725 (I2C lines)

4.  I updated the boards.txt file to change f.cpu to 2Mhz (this was already done when i was using the clock scalers)

 

    The design functions but for some reason my I2C clock is running at 1.9-3.8khz depending on how I play with my code.

 

1.  When I have the following enabled in my code i get the 1.9khz, when i disable it (i.e. "\\") i get 3.8khz

CLKPR = 0x80;
CLKPR = 0x01;

 

2.  I played around with the TWBR, which i had always run the following:

 

TWBR = ((2000000 /400000l) - 16) / 2; // Change the i2c clock to 400KHz

 

     but it didn't seem to make a difference.

 

When I have both #1 and #2 above enabled this is what I get:

 

The ATMEGA328P clock was probed at the external resonator

The SPI clock was probed at the ATMEGA328P pin

The I2C clock was probed at the ATMEGA328P pin (although I probed it on the MCP4725 side and got the same #'s)

 

ATMEGA328P Clock ...2Mhz as expected

 

 

 

SPI Clock (was expecting 500khz but plenty fast for what i need)

 

 

I2C Clock... 1.9Khz.... Much slower than what i expect which is 400khz

 

 

If i disable the clock scaler (#1 above), the ATMEGA328P clock stays the same.

 

SPI clock... 500khz as expected

 

 

I2C clock... 3.8khz, so it doubles but it is way low still.

 

 

No idea why my I2C clock is so slow now, any ideas?

 

Basic code below:

 

</p>
<p>#include <Wire.h><br />
#include <Adafruit_MCP4725.h><br />
#include <SPI.h><br />
#define kNOERROR 0<br />
#define kPRIMARYREADERROR 1<br />
#define kEXTENDEDREADTIMEOUTERROR 2<br />
#define kPRIMARYWRITEERROR 3<br />
#define kEXTENDEDWRITETIMEOUTERROR 4<br />
#define kCRCERROR 5<br />
#define kUNABLETOCHANGEPROCESSORSTATE 6<br />
#include <avr/sleep.h><br />
#include <avr/power.h></p>
<p>//190907const uint16_t LEDPin = 13;<br />
const uint32_t WRITE = 0x40;<br />
const uint32_t READ = 0x00;</p>
<p>const uint32_t COMMAND_MASK = 0xC0;<br />
const uint32_t ADDRESS_MASK = 0x3F;<br />
unsigned long nextTime;<br />
bool ledOn = false;<br />
bool includeCRC = true;</p>
<p>Adafruit_MCP4725 dac;</p>
<p>void setup(void) {</p>
<p>  //disable ADC<br />
ADCSRA = 0;</p>
<p>power_adc_disable(); // ADC converter<br />
power_timer0_disable();// Timer 0<br />
power_timer1_disable();// Timer 1<br />
power_timer2_disable();// Timer 2</p>
<p>CLKPR = 0x80;<br />
CLKPR = 0x01;</p>
<p>  uint16_t unused;<br />
  uint32_t flags;<br />
  uint32_t flagsAndZeroOffset;<br />
  // Initialize SPI<br />
  SPI.begin();<br />
  pinMode(SS, OUTPUT);<br />
  //Sets Unused Pins to Internal Pullup<br />
  pinMode(2,INPUT_PULLUP);<br />
  pinMode(3,INPUT_PULLUP);<br />
  pinMode(4,INPUT_PULLUP);<br />
  pinMode(5,INPUT_PULLUP);<br />
  pinMode(6,INPUT_PULLUP);<br />
  pinMode(7,INPUT_PULLUP);<br />
  pinMode(8,INPUT_PULLUP);<br />
  pinMode(9,INPUT_PULLUP);<br />
  pinMode(15,INPUT_PULLUP);<br />
  pinMode(16,INPUT_PULLUP);<br />
  pinMode(17,INPUT_PULLUP);</p>
<p> //190907 pinMode(LEDPin, OUTPUT);</p>
<p>  nextTime = millis();<br />
  //190907digitalWrite(LEDPin, LOW);<br />
  digitalWrite(SS, HIGH);<br />
  // Make sure all of the SPI pins are<br />
  // ready by doing a read<br />
  PrimaryRead(SS, 0x0, unused);<br />
  // Unlock the device<br />
  ExtendedWrite(SS, 0xFFFE, 0x27811F77);<br />
  // Make sure the device is unlocked<br />
  ExtendedRead(SS, 0x22, flags);<br />
  if (!((flags & 0x0022) == 0x0020))<br />
  {<br />
  Serial.println("Device is not Unlocked");<br />
  }</p>
<p>  </p>
<p>  // For Adafruit MCP4725A1 the address is 0x62 (default) or 0x63 (ADDR pin tied to VCC)<br />
 dac.begin(0x62);<br />
TWBR = ((2000000 /400000l) - 16) / 2; // Change the i2c clock to 400KHz</p>
<p>  <br />
}</p>
<p>void loop(void) {</p>
<p>  temp = PrimaryRead(SS, 0x20, angle);<br />
  SPIvariable = (float)(angle & 0x0FFF) * (360.0 / 4096.0);</p>
<p>//    Serial.println(SPIvariable);<br />
  </p>
<p>   dac.setVoltage(3*SPIvariable,false);</p>
<p>}</p>
<p>

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

YOU set the I2C clock scaler. It is always a fixed fraction of the mcu clock. I could not tell from your code how it was set.

 

TWBR = ((2000000 /400000l) - 16) / 2; // Change the i2c clock to 400KHz

 

TWBR must be an integer and there is a certain minimum allowed value. You have 1/2 - 16 and that certainly will not work.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Fri. Jan 10, 2020 - 06:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

for a start put this on a calculator and see what result you get:

TWBR = ((2000000 /400000l) - 16) / 2; // Change the i2c clock to 400KHz

 

note that TWBR technically is a UNsigned integer 8 bits long.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
You have 1/2 - 16 and that certainly will not work.

Actually 5 - 16.

 

But that will still certainly not work!

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jan 10, 2020 - 10:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I've calculated. The highest SCL Frequency you can achieve on a 2Mhz system is 125khz. Prescaler 0, TWBR 0.

I'm using 7,2738Mhz. TWBR = 1,216, TWPS = 0. SCL = 400khz. But you cannot enter 1,216 because TWBR ist uint8_t.

 

 

friendly reagrds

Ellen

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So if
TWBR = 0.5 * (F_CPU / 100kHz - 16)

Then I calculated I need to set TWBR = 2. Don't need to keep the formula in the code and can just state "TWBR = 2;"

I wonder if I have a prescaler set somewhere. Is there any harm in putting this in the code too?

TWSR = 0x00; // Select Prescaler of 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unless your app needs to generate high frequency (that's a relative value) waveforms, you probably don't need 400kHz I2C to your DAC's, I've run projects where even 25kHz to an DAC was more then enough.

Although you have stated your looking to lower the power requirements, so a slower I2C may draw more power across the pull ups at a slower speed, may have to test that theory to be sure. 

Jim

edit: ADC -> DAC

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

Last Edited: Fri. Jan 10, 2020 - 04:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim, agreed but it should be higher than 3.8khz.

I did some testing by changing the i2c clock with no real change in power draw. Now obviously if I changed the pull up resistors in conjunction with the clock it would have an affect.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EllenR wrote:
I've calculated. The highest SCL Frequency you can achieve on a 2Mhz system is 125khz. Prescaler 0, TWBR 0.

That's what I get as well.

vettett15 set your regs:

    TWBR = 0;
    //prescaler to 0 as well
    //I2C clock = 125kHz

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure what i'm doing wrong but I set TWBR = 0; and the prescaler CLKPR = 0x00; which should give me 1.... same results, i wonder if i mucked up something in my boards.txt file, i attached it just in case.

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If you have a custom board for your Arduino IDE,  you need to give it a separate entry in boards.txt.   And provide the variant files.

You appear to have hacked the Diecimillia to say it runs at 2MHz.   (which it doesn't)

 

You can run TWI at a slow speed if you want.   I2C spec has no maximum time requirements.

 

As a general rule,  you run at a high or moderate speed when awake.   And sleep as much as possible.   This will give good performance and low average current.

 

An idle I2C bus takes no current.    An  active I2C bus sinks current through its pullups.   And obviously requires Master and Slave to be awake.

So it is worth running for as short a time as possible.    Be realistic.   You probably know how many bytes are transferred in a typical day.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David,

 

        I did modify the board file, see picture below for differences, which i had to do just to get it to upload.  Not sure how making a variant in the boards file will fix my problem.  Agreed that I should figure out how fast i need to run the I2c but I would like to understand why it is maxing out at 3.8khz.  I agree I should eventually make my own varient but i would have no idea what to set all of these values to.

 

Last Edited: Fri. Jan 10, 2020 - 05:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well i'm sorta making progress... I went back to the boards.txt file and changed the frequency back to 16mhz and started playing around with the low byte fuse value using this website:  http://www.martyncurrey.com/arduino-atmega-328p-fuse-settings/

 

Using 0xCA I got the I2C up to ~50khz but now my SPI bus is down to ~60khz... WTH... Guess i'll keep looking at it.

 

This is with TWBR = 0 and the prescalers commented out

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For Mega and Tiny fuse settings the Freaks use this site:  http://www.engbedded.com/fusecalc/

Select your part number and either click the check boxes, or enter your hex fuse settings at the bottom of the page to see what they do.

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or just "Burn Bootloader" from the Arduino IDE.

This will restore your Arduino to its virgin state.

 

I would be happier with a 16MHz Arduino than a 16mhz "custom" board.

 

Seriously.   A 16MHz Arduino Uno Wire.h runs fine at 400kHz

 

You don't need to use Arduino code.    Bare metal C or C++ can still run on Arduino hardware board.

If you try and mix Arduino and bare metal,   you should make sure that you initialise peripheral registers.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I recommend using the 16mHz Arduino and reading the sensor at the minimum number of times per second as possible.   Do you update the DAC value with each sensor read?

Change the Arduino AMS1117 voltage regulator to +3.3V.  These ICs in Arduino-compatable packages sell for 5 cents each on eBay when buying a strip of 100 or so.  Run the Arduino with +5 -- +12 through the V-raw pin.   I do this with all my Arduino Nanos and have never had a problem running the Mega328p at 16 MHz/+3.3V.   Update the DAC at 400 KHz I2C speed and +3.3V Vcc.  Use standard Arduino SPI library. 

 

What is your "interface time resolution"?  That is to say, how fast to you have to do a sensor read/DAC update for your data to be valid for your application.   For example, for a video game, the "interface time resolution" should not be greater than 20 times a second.  That is as fast as the AVR must read the switch presses to interface with the gamer who is trying to respond to screen changes as fast as possible.   Are you changing the DAC value over 1000 times per second?  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Right but it can't run at 16Mhz any longer because I have a 2Mhz resonator on the board, so wouldn't that not do anything for me or am i missing something.

 

I update the DAC value in a continuous loop, definitely not as fast as each sensor reads since my SPI bus runs much faster than my I2C bus.

 

I'm not using the arduino regulator, i'm already on a custom CCA.  Regulator seems to be acting just fine.

 

The question regarding the interface time resolution is tough... I'm interfacing with a 1990's computer that I have no data on.  Thus I wanted to run the I2C and SPI lines as fast as I could reliably 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

I refer to datasheet Atmega328 page 180. The max SCL frequency on 2Mhz system, crystal is 125khz 

 

Ellen

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update, did some testing and think i got it where i need it.  Not sure why the SPI and I2C clocks seem to scale differently but nonetheless i made it work.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By chance did you activate the DIV8 fuse by mistake?

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the 2MHz "resonator" is replaced by the original 16MHz unit,   the Diecimillia is restored to its proper functionality.

And "Burn Bootloader" will set the correct Fuse and Lock values.

 

You can always run the 16MHz board at 2MHz via the CLKPR prescaler.   The 16MHz crystal/ceramic will take the same current as a 2MHz crystal/ceramic.

Yes,  the board will take a smaller current if the CPU is running at a slower speed.

 

But if you want to minimise current,  you would use the 8MHz RC and do a lot of sleeping.    And you get good performance @ 8MHz.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David,

I was doing it that way, problem you run into is you get a surge current at the beginning that is still equal to the current running it at 16mhz. That's a no go for me, I was running too close to a current limit. Also I don't believe sleeping will help me, I'm not trying to make a battery last a long time, when my device gets power from the system it has to be fully functional, when the system doesn't need it anymore it turns off the power.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You design your software to suit your specific application.

 

Waking up the RC or just waking up the CPU from a running clock should not be a problem.

 

If battery life is not critical you can run slowly (via CLKPR) instead of sleep.    Sleep is always the more efficient strategy.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are running from batteries, then slow clock rate is the wrong way to go.

 

Basically, every executing clock edge uses a specific amount of energy from the battery. To execute a given task, the MCU takes the same amount of energy whether fast or slow because the same number of clock edges are involved, fast or slow.

 

What saves energy are (usually) the peripherals. If you clock TWI at the fastest rate for a given byte transfer, it will use LESS energy because the clock and data lines spend less time in the low state and that is the state where the highest current flows through through the pull-up resistors. Typically same with other peripherals; the less time it is active on, the less energy. This might not be true for a DAC, though, because it will draw current through the analog-digital resistor network at all times (but varies with the output voltage). Sensors vary, hugely, but, generally, the less on-time, the lower the energy consumption. 

 

When the MCU sleeps, provided you have done the necessary things to enable lowest power consumption in the peripherals, you actually use less energy per unit time. And that translates into longer battery life. That is because each battery stores a specific quantity of energy. 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Fri. Jan 10, 2020 - 11:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unless I was missing some ability to control it differently, using a 16mhz clock and scaling it down was for sure a problem because it trips the current limit. Npp batteries here.

By far the biggest power savings was from reducing the clock speed

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

vettett15 wrote:
By far the biggest power savings was from reducing the clock speed

That's only while the processor is running.

 

The general idea is to have it sleeping as much as possible.

 

If often pays to run as fast as possible so that the processor can get back to sleep sooner:  you take a bit more current while running, but you run for less time (ie, sleep more) - hence you win overall

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agreed but again that is irrelevant for my application.  All i care about is max current draw, not an average.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

vettett15 wrote:
I was running too close to a current limit.

Can't you simply use a bigger power supply?

 

You also did not answer my question regarding the DIV8 fuse when you are running on 2Mhz

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Power supply is fixed, i was surprised how low its limit is but nonetheless it is what it is.

 

Yes, sorry, it does look like i had that divide by 8 activated.  Good catch.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

vettett15 wrote:
Yes, sorry, it does look like i had that divide by 8 activated.  Good catch.

 

THats probably the big reason your I2C speed is so slow.

 

The compiler has no idea what the hardware fuses are set for.  And the hardware fuses pay no mind to the compiler.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agreed. Which is why since I set the clock at 8mhz in the boards.txt file I have to scale up my spi rate by 4 (8/2mhz).

What doesn't make sense is why I was only getting 3.8khz on my i2c clock when I put the clock at 2mhz in the boards.txt file.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

vettett15 wrote:
Agreed. Which is why since I set the clock at 8mhz in the boards.txt file I have to scale up my spi rate by 4 (8/2mhz). What doesn't make sense is why I was only getting 3.8khz on my i2c clock when I put the clock at 2mhz in the boards.txt file.

 

Simple.  Teh DIV8 fuse is not controlled by the IDE or ANYTHING else.  It's a hardware 'prescaler' of sorts.  It's like having a 16Mhz clock physically, but telling your IDE through a .txt or in teh actual code that your clock is only 2Mhz guess what...your timing is off by 8x

 

So, if you take your 2 Megahertz crystal, and divide it by 8 you get 250K hertz.  then you take the value of the TWI clock generator/divisor and 250K by that number.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If my TWBR was set to 0 I'm not seeing how I get to 3.8khz

Since any b Prescaler is multiplied by t the TWBR shouldn't that negate any affect of a bad Prescaler.

Even if you did 2mhz/8/16 I get 15.6khz

SCLfreq = F_CPU / (16 + (2 * TWBR * Prescaler) )

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agreed. I did the math and came up with 15khz as well. Now the only other thing I came up with as a possible answer to your issue is the 2Mhz crystal is not oscillating at 2Mhz. Maybe the caps on the board need to be changed, or the Crystal is defective.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just thought of something else. Set the SUT to the slowest. I think that's 65ms. Also, change the crystal drive to full swing. If you have it set to low power you might not be driving the crystal hard enough.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I use a ceramic resonator which has the caps built in. I'm measuring with my oscilloscope that the resonator is giving me 2mhz, that's been very consistent.

I think you're right, I should play with the fuse settings to see, I assume SUT is start up time?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes but the SUT does not have anything to donwith the I2c speed. Since your power limits are such a concern a long SUT allows thngs to be stable before your code executes.

Heres an idea. I think the 328 has a clock out fuse. Program that and then put a scope on i think PortB pin 2. The frequency you see there is your internal clock. Check the datasheet for the clkout pin.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah I see it in the low fuse settings. It's not obvious to me whether it will output the frequency of my resonator or the internal clock. I'll give it a shot later

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's PortB pin 0. Not pin 2. My apologies
It's the divided system clock...meaning what the internals are running off of.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user