ATTINY48/88 I2C hardware implementation

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

I'm working on a project that started with a smaller device but ran out of I/O so was considering the ATTINY48/88 series.  One thing I need to do is communicate with a sensor using I2C.  It wasn't going to be a problem with the previous ATTINY device, but with this device it shows the top speed in master mode is 25 kHz when the internal 8 MHz oscillator used as the clock.  The formula reduces down to fscl = fclk / 320 when using it as a master with the lowest prescaler of 1.  Am I missing something?  25 kHz is only 1/4 the lowest "standard" I2C speed of 100 kHz.  I was planning to use a different lower-frequency clock (for power savings and other reasons), and with it I can't even hit the minimum sensor I2C clock frequency.

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

The formula reduces down to fscl = fclk / 320 when using it as a master with the lowest prescaler of 1.  Am I missing something?

Looks to me like it is-

 

TWBR = ftwi/fscl/2 - 8  (ftwi is twi peripheral speed chosen)

TWBR = 8MHz/100kHz/2 -8 = 32 (which is >= 10, so is good)

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

I have a Tiny88 chip. The TWI works just like any other traditional Mega TWI.  i.e. same formula.

 

Note that Tiny88 is limited to 12MHz but you are probably using the 8MHz RC in most designs.

 

If you are simply reading a Sensor in I2C Master mode it is easy enough to bit-bash I2C Master.  i.e. any AVR can be used.

Obviously I2C Slave mode needs hardware support.   But USI I2C Slave works pretty well.

 

David.

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

You missed the point that I'm going to be running much slower than 8 MHz since this is a low-power design.  When I use my target clock speed of around 1 MHz, I don't hit the minimum 10 kHz Fscl the sensor specifies.  This device has 3 speed grades topping out at 4, 8 and 12 MHz.  Which means in master mode even the top speed grade doesn't come anywhere close to the typical 100 kHz "standard" I2C frequency, not to mention the 200 and 400 kHz faster frequencies.  The killer seems to be that little note in the 48/88 datasheet about TWBR needing to be 10 or higher in master mode.  I've not seen this in other Atmel data sheets, including the ATMEGA I'm probably going to use (see below).  So assuming the rise time is negligible, this formula reduces down to Fscl = Fclk / (10 + 2 * BAUD).  If we use that same 8 MHz oscillator (this ATMEGA has an internal 20 MHz oscillator but using 8 for the sake of comparison), and if we set the BAUD register to 0 we get Fscl = Fclk / 10 or 800 kHz for an 8 MHz clock.  Contrast that to the 25 kHz for the same clock frequency in the ATTINY48/88.  At my 1 MHz intended clock frequency, I'm right at the 100 kHz target I was going for instead of 400 Hz with the ATTINY48/88.

 

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

TWBR = 1MHz/100kHz/2 - 8 = -3 i.e. no good

TWBR = 1MHz/50kHz/2 - 8 = 2  i.e. not in spec but just try it

TWBR = 1MHz/10kHz/2 - 8 = 42

 

Any low power app is better off with run fast,  sleep long.

 

The TWBR >= 10 caveat appears in mega32 datasheets but not in mega328 or mega324.

 

But as I said earlier you can use most AVRs.  Just pick one that is actually available from Distributors.

 

David.

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

but with this device it shows the top speed in master mode is 25 kHz when the internal 8 MHz oscillator used as the clock.  The formula reduces down to fscl = fclk / 320 when using it as a master with the lowest prescaler of 1. 

The point was your formula is wrong. When using the internal 8Mhz osc, the max fscl is ~222kHz, not 25kHz.

 

When I use my target clock speed of around 1 MHz, I don't hit the minimum 10 kHz Fscl the sensor specifies

max Fscl = Ftwi/36 -> 1MHz/36 = ~27kHz

seems bigger than 10kHz to me.

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

david.prentice wrote:

Any low power app is better off with run fast,  sleep long.

 

+1

 

When we put this Tiny48/88 into an app, I didn't like the wimpy pin drive (compared to a "real" 48/88).  Just kind of annoying needing to adjust our usual stuff for e.g. the "I'm alive" LED.  For our modest-volume apps, it wasn't worth it but for Cliff's kazillion-volume apps it can be different.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Oh the joys of AVR! Each model being slightly different from the one you used before.

There's nothing like having to read the entire datasheet for a chip family you thought you knew.

 

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

How is the formula wrong?  The requirement that TWBR >= 10 comes right out of the ATTINY48/88 datasheet that I pasted above.  So in master mode (since the sensor is in slave mode), it works out to Fscl = Fclk / (16 * (2 * 10 * 1)) since TWBR >= 10 and the smallest that TWPS can be is 1.  So Fscl = Fclk / 320 and for 8 MHz it is 8 MHz / 320 = 25 kHz.  No idea where you got the 222 figure from.

 

I also have no interest in trying to match the bottom limit for the sensor so 10 kHz isn't even acceptable; that's just bad engineering.  I just used that as a reference point.  The range is 10 to 200 kHz and I chose 100 kHz which is close to the middle of the range.  I also need to talk to other devices that want to see a higher throughput and I have some debugging tools that I believe are happier with the more "standard" I2C frequencies, although I haven't used them in a while to be sure.

 

The app can't sleep at all.  It's constantly acquiring data and number crunching all day long.  So in interest of battery life, I'm dropping my clock speed down just enough to be able to sustain operations but minimize power consumption in an active state.  It's only when the user stops it and connects it to a PC to download the data that it goes into sleep mode after that to "power off".

 

I can't use most AVRs.  The 48/88 has 28 I/O and I'm using the majority of them.  Cost is also a factor so I'm sticking with the lower end devices.  I've settled for a similar ATMEGA with similar specs and slightly higher cost.  Distribution is another story.  To actually get them for the timeframe you need in sufficient quantities, advance purchase orders are the only way to have a chance at them.

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

david.prentice wrote:
Note that Tiny88 is limited to 12MHz

 

We discussed it in my ATTiny88 overclocking, or is it?

 

It should be 16M, then.

 

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

The requirement that TWBR >= 10 comes right out of the ATTINY48/88 datasheet that I pasted above.

16 + 2*10*1 is 36 

 

8e6/36 is 222 kHZ

1e6/36 is  28 kHz

 

Yes, if you run the process at 1 MHz vs 20 Mhz range of AVR, it will be 20x slower! 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

If the mentioned 28 kHz above is too slow, ask

 It's constantly acquiring data and number crunching all day long.

 What kind of number crunching?? Also if being connected to the PC, maybe let the PC do the crunching.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

How is the formula wrong?  ... it works out to Fscl = Fclk / (16 * (2 * 10 * 1)) 

It is wrong because you are using a * instead of a +.

 

Fscl = Fclk / (16 + (2*10*1)) 

 

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

nmcs2012 wrote:
The app can't sleep at all.  It's constantly acquiring data and number crunching all day long. 

Try this pencil-and-paper exercise, using datasheet power draw graphs:

 

1.  Tell more about getting this data and number crunching....

 

1a.  Let's say that your processor utilization is a modest/safe/comfortable level at say 50%.

1b.  So at your 1MHz out of 1000ms you are doing your important stuff for 500ms.  But no sleeping; not even a cat nap.  Thus always active and busy like a bee for the full second.

1c.  But if your AVR's clock is say 10MHz then the important stuff is done in 50ms.

 

2a.  Use the datasheet and get the current draw numbers for running active for one second at 1MHz.

2b.  Use the datasheet and get the current draw numbers for running active at [say] 10MHz for 1/20th of the time (50ms every 1000 ms) and a suitable sleep mode for the other 95% of the time.

 

3.  After that exercise, can you take a siesta or not?

 

===============

5V Vcc, 1MHz active, 800uA draw. x100% gives a usage of 800 power units.

 

5V Vcc, 10MHz active, 5250uA draw.  x5% gives a usage of 262 power units.

Plus sleeping the other 95% of the time.  IDLE mode won't help my analysis, as draw is a bit over a mA.  LOL -- again the choice of a crippled model hurts, the sleep modes are limited.  Power-down can be trickier, but let's see the numbers:  I'll spot you the watchdog and the other 5% of the time and we'll call it 6uA draw.  x100% gives 6 more power units to add to the 262 above, for a total of 268.

 

So with this noodling, which approach saves your battery?
 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Tue. Jul 19, 2022 - 01:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's what I get for copying the formula on paper using my small monitor.  I guess it's time for new glasses or start viewing datasheets on the big monitor, which I use for CAD and code dev.  I should have noticed this because I had the ATMEGA formula written down correctly and the difference is it has 10 in the divisor and no requirement for BAUD to be 10 or above.   Thanks for the spot!

 

Although I am still likely to go with the ATMGEGA device anyway, as there's a chance I can implement software USB on it without having to use a 12 MHz crystal and I can easily hit my target 100 kHz Fscl using the internal oscillator running at 1 MHz except during USB transfers.