Difficulty with Fleury i2C - moving from ATTINY to ATMEGA

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

I have a project that's migrating from ATTINY to ATMEGA. They Fleury library worked great on my attiny, but there seems to be a timing problem when using the code on atmega.

Waveforms attached as image.

See how the first upward transition of SDA happens about at the same time as SCL goes down? This should be delayed so that the transition of the clock occurs when SDA is clearly down. I suspect this is why I'm not getting an ACK.

The library is vanilla, except for slowing i2c_delay_T2. Any ideas? I was under the impression this basically would work out of the box.

Attachment(s): 

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

Well, the Megas all have TWI don't they? "TWI_master.c" requires no edits. But from memory,
you need to #define XTAL F_CPU

You appear to have a bit-time of about 18us. i.e. 55kHz.

Yes, if you are using the bit-bang "i2c_master.S" then the Stop and Start times look legal but not in concert with 55kHz bus.

Oh, if you are complaining about " first upward transition of SDA happens about at the same time as SCL goes down?", this is down to your Saleae sampling speed.

It looks as if you are talking to a RTC chip. The DS1307 will only run < 100kHz. Later RTC chips might manage 400kHz.

David.

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

Thanks. I could use TWI_master if I can't get this to work, but I was trying to avoid getting familiar with another library and changing old code (too much).

Anyway, adding #define XTAL F_CPU didn't change anything. I don't think there's any other timing/delay mechanism in i2cmaster.S besides i2c_delay_T2 .

I was concerned with the timing because when I compare the waveforms with something known to be working, there's a nice half-clock offset (attached). But you're right that the transitions are legal, as the positive edge of SCL is what counts.

(The Salae is sampling at 24MHz. Clock pulses are 6us wide, for a period of 12us approx., so ~83kHz)

However, now that I look more closely at the difference, the i2c_master waveform holds down SDA for one fewer SCL cycles than my "reference" waveform. Doesn't that indicate a "read"? I wonder why Salae interprets it as a write.

Attachment(s): 

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

No, "i2c_master.S" is a bit naughty over the delay timing. It would be perfectly possible to construct the correct delay dependent on F_CPU.

But the main point of the two Fleury files is that you have the same API regardless of the implementation.

David.

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

Oh, certainly. I just happened to use the author's model of adding appropriate rjmp's and nop's. But I don't think this is the problem.

It's just odd how it worked perfectly in attiny, but breaks in atmega.

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

Rubbish. The bit-bash version works exactly the same on a Tiny, Mega or Xmega. The ports work the same, the delays work the same, the API is the same.

Yes, you can add the appropriate number of wasted cycles. e.g. RJMP 1f. Or you use a loop (which is easier to tailor)

If you find a functional difference between your Mega and Tiny, I suggest you compare F_CPUs and your particular ad-hoc delay. I would also check the values of the external pull-up resistors.

David.

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

Remember that TWI/I2C is not about setting and clearing logic levels between two ICs: it is asserting and releasing the signals that are all tied together as a "wired AND" gate. The SDA and SCL line will only go to logic high when all the I2C chips tied to these lines release their logic zero states.

It doesn't matter that the first upward transition of SDA (master releases SDA) happens about at the same time as the master asserts the SCL (SCL goes down) because the receiving IC only checks for valid data when the master releases the SCL line.

I'm putting together a selection of cut-and-paste well-commented AVR assembler routines for TWI, PS2 keyboard, USART, Nokia 5110, and MIDI interfacing. When they all work seamlessly, I'll post them here.

By the way, almost nothing in the microcontroller field 'works right out of the box'. The only exceptions are low-level Arduino libraries and demo programs, such as those written by Limor Fried. And even those require careful study and review to know why they work well.

If the external I2C resistors are too big in value, the rising edge of the released signal on SDA and SCL will be rounded. I use 3K ohms.

I concur that the I2C clock speed has to be less than 100KHz for interfacing the DS1307 RTC that has the SLA of 0x68 (as shown in the diagram).

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

Quote:
By the way, almost nothing in the microcontroller field 'works right out of the box'.

Rubbish. The AVR has been in existence for about 15 years. The peripherals on the current Mega models have been in existence for about 10 years.

So everything is proven by now. The Stang and Fleury libraries were published almost 10 years ago.

However it does not stop the square wheel enthusiasts. Every day we get LCDs without proper timing, UART_RX without proper buffering, atomic access etc, I2C without pull-up resistors, ...

Yes, you can make the odd improvement/correction to Stang, Fleury, Atmel app notes, ...
I have no idea who Stang or Fleury are, or whether they are still alive. There is a good case for someone to maintain their code.
Likewise, there is a good case for Atmel to maintain their app notes.

The Arduino libraries are well used and pretty reliable. Definitely the first place to look for examples for new and exotic hardware chips.

David.

p.s. it will be interesting to hear the reason for the OP's difficulty in Tiny -> Mega bit-bash.

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

FWIW, I'm using 2.2k pullups, as I did with attiny. 3.3V rail. There is only one delay routine used, and the pulses are scaled correctly.

I'd love to find out the cause here!

The only other discrepancy I see between the working and nonworking waveforms is what I mentioned earlier:

"However, now that I look more closely at the difference, the i2c_master waveform holds down SDA for one fewer SCL cycles than my "reference" waveform. Doesn't that indicate a "read"? I wonder why Salae interprets it as a write."

I'm not sure what to make of it, if that's the cause of the error.

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

2k2 sounds fine for the pull-ups @ 3.3V.

I have several Tinys and several Megas and a Saleae LA.

So I can build most arrangements. You just need to post the code and specify F_CPU, AVR etc.

As I said earlier, the Tiny and the Mega use exactly the same AVR opcodes. Apart from the MUL instruction which is never used in i2c_master.S anyway.

I assume that you are only using SBI/CBI ports. You would have to rewrite i2c_master.S for LDS/STS/ORI/ANDI

David.