I wonder to know I2C hardware sequence

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

Hello guys, First, I am Korean so my English is some awkward but I will try to my best.

 

I have been studied for a month after graduation and now I studied at I2C interface & Protocol

 

and I got a problem with hardware sequence. 

 

If I may ask, I wonder to know Hardware sequences in detail.

 

After starting I2C communication, slave and master both communicate 8-bit data and 1-bit ack, am I right?

 

If I am good to understand that let you know about my problem.

 

First, according to this website (http://www.ermicro.com/blog/?p=1239)

in Master's write mode, at last, sequence point, they got ACK from slave and master sends STOP signal to end hands shake.

 

But I can't understand at this point, how can the slave distinguish this signal is STOP? OR DATA?

 

According to this picture, master got Ack from a slave and they go to sequence sending a data. 

 

However, STOP is (SCL 1 / SDA 1) if trailing data would be data is 1, This signal could be (SCL 1 / SDA 1) !?..

 

Then, the slave can't know this signal is Data or STOP because it is same level 1/1.

 

How can slave distinguish this as STOP or DATA?

 

 

Seconds is Hardware level.

 

Master's cathing timing is SCL 1. If SCL would be 0, slave or master can change signal.

 

Then I think, If data signal 1 in SCL 1, I mean both is 1 level.

 

This condition is a Free state also the delay condition which devices can understand "FreeState" is just 1.3 us or 4.7us and I2c Speed is just 400 kHz ~ 100KHz.

 

So I guess If that timing, data 1 and SCL 1, another master can interfere with both's communication.

 

Are my thoughts right?

 

And I am sorry -_- my English isn't sure 

 

 

 

 

 

 

 

This topic has a solution.

Korean

Last Edited: Thu. Sep 6, 2018 - 01:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings and welcome to AVR Freaks!

 

Ack/nak occur at specific points in the transfer. 8 bits, ack, 8 bits, ack, ...

 

Start and stop are unique combinations of clock change and data level that do not happen at any other time in a tranfer. Start is recognized because it happens only when data is NOT being transferred. Stop is recognized because it happens only when data IS being transferred.

 

That diagram is useful but not complete because it does not include the clock, which is a crucial part of identifying start and stop conditions.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

I2C is a standard bus, implemented on (almost) all microcontrollers - it is not specific to AVR.

 

What you are asking is not specific to AVR.

 

The full I2C specification is here: https://www.nxp.com/docs/en/user-guide/UM10204.pdf

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

Thanks your efforts.

 

I can understand your mentioned "it happens only when data is not being transferred"

 

I got a good advice from you and you are upper hand in every way Thanks : ) 

 

WonCheol

Korean

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

First thanks your advice, sometimes i forget this isn't only used by AVR.

 

So i don't find full I2C specification and so I think that I got a light which is good for understanding I2C.

 

Thanks for your kindness. 

 

WonCheol

Korean

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

There is a nice diagram in Wikipedia, I'll just copy it here:

Timing diagram

Data transfer sequence

  1. Data transfer is initiated with a start bit (S) signaled by SDA being pulled low while SCL stays high.
  2. SCL is pulled low, and SDA sets the first data bit level while keeping SCL low (during blue bar time).
  3. The data are sampled (received) when SCL rises for the first bit (B1). For a bit to be valid, SDA must not change between a rising edge of SCL and the subsequent falling edge (the entire green bar time).
  4. This process repeats, SDA transitioning while SCL is low, and the data being read while SCL is high (B2, ...Bn).
  5. The final bit is followed by a clock pulse, during which SDA is pulled low in preparation for the stop bit.
  6. A stop bit (P) is signaled when SCL rises, followed by SDA rising.

 

Edit: also, I2C outputs are open drain, so the rising edges are caused by pull-up resistors, not by actual high outputs, so they are affected by capacitance.

Last Edited: Mon. Sep 3, 2018 - 10:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas said Wikipedia wrote:

5. The final bit is followed by a clock pulse, during which SDA is pulled low in preparation for the stop bit.

6. A stop bit (P) is signaled when SCL rises, followed by SDA rising.

That's not correct:

NXP, in the I2C Specification, wrote:

A HIGH to LOW transition on the SDA line while SCL is HIGH defines a START condition.

A LOW to HIGH transition on the SDA line while SCL is HIGH defines a STOP condition.

(which is what the Wikipedia diagram shows)

 

Note that NXP don't use the terms "Start bit" or "Stop bit"

 

EDIT

 

Actually, re-reading it, I think the Wikipedia wording does actually amount to the sane thing - but I find NXP's description clearer.

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: Mon. Sep 3, 2018 - 11:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The standard refers to "Start Condition" and "Stop Condition". That is well shown in #6.

 

Contrary to what I wrote, these conditions are uniquely defined by clock transition directions and data logic levels and do not depend on whether data is  or has been transferred. 

 

This diagram (#6) is complete, as far as a single byte transfer is concerned. But, it does not really do a good job of describing a complete transaction, however. The diagram in #1 shows a full transaction but is missing the crucial detail about start and stop conditions because it is missing any sense of clock. 

 

For the OP, you really need to consider the two diagrams together.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Before I started teasing, I did indeed scan the thread.

 

Now, someone saw fit to move the thread to a different forum.  Perhaps at a suggestion?

 

But now I know why I'm retiring -- I cannot keep up any longer.  Agreed that the initial query had little if any direct connection to AVR.  But please -- where is the connection to "Compilers" or "General Programming"?

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

theusch wrote:
where is the connection to "Compilers" or "General Programming"?

No idea!

 

Should be "General Electronics".

 

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

The OP diagram makes the common mistake of confusing the Slave Address and the R/W bit: https://www.avrfreaks.net/commen...

 

The Slave Address is, strictly, just the 7 bits circled in blue;  so the address shown in the diagram is 0x27 - not 0x4E

 

The 8th bit - circled in red - is the Read/Write bit

 

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: Mon. Sep 3, 2018 - 07:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In re-implementing a colleague's defects in a bit-banged I2C driver on PIC32; I found the Microchip Family Reference Manual for I2C one of the most detailed and clear I have ever read. The timing diagrams are very good in that each element of the transaction is shown in detail separately and show the interaction between Master SDA & Slave SDA. I can recommend this manual for I2C implementers, even if not using PIC32.

 

Unfortunately, the same cannot be said for the buggy I2C peripheral(s) on PIC32 - hence the need for a bit-banged driver.

 

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

That's ironic - they give the best description of it, yet can't actually implement it?!

 

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

Isn’t it ironic,
It’s like bit banging i2c, on a pic32
...........

I want to know what i2c is,
I want you to show me.......

Apologies to Alanis Morrissette and Foreigner.

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

Sorry I was late because of my accounts problmes.

 

First of all, your comments is right I think and I didn't understand how to make HIgh state of I2C signal.

 

But I can understand now becase of your mentioned for me.

 

Thanks to your efforts and now I will search WiKI

Korean

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

Hello JIm I was late because of my accounts problem.

 

Before I saw your mentioned, I think this diagram appoximately are completed.

 

But I agree with your mentioned, It isn't completed.

 

Thanks your reply and Sorry my late : ) 

Korean

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

Yeah I refer to Link which was poste by others.

 

So I wonder to know START Condition means ' 1 bit ' or ' 0 bit trasmission?..'

 

But I get correct information from you perfectly.

 

It isn't "bit" Just condition.

 

Thanks your efforts and forgive me I am late becase of my accounts problme :( 

Korean

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

?__? Sorry my english is lack

 

So I can't understand in detail.

 

I must described cmoplier and what program of IDE ?..

Korean

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

Yeah, this diagram is so useful but some parts is lack.. such as your mentioned. 

Korean

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

Okay I will read PIC32's reference. I will get more information surely. 

 

Thanks your reply and sorry my late (because of my accounts problem)

Korean

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

I am so sorry : ( awneil.

 

I was late because of my accounts problems.

 

I am thankful to your mentiond and sorry for my late. 

 

I apologize to you.

Korean

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

Hello Kartman. I got many advice from here including NXP.

 

Before I enter here, I have been read Atmega128's TWI interface.

 

and now I read NXP's guidline. 

 

Now I think NXP guidline is some correct and described so detail. I was surprised. 

 

So I can understand your metion(big banging I2c, on a pic32)

Korean

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

START condition sends NO data bit. It has only one purpose. It tells all other devices on the bus that a new message starts. STOP condition, likewise, tells the device that is the slave for the current message that the message now ends. There is no other purpose for these two signals.

 

Jim

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Thanks for yours.

 

I can understand I2C's condition and bits differetns

 

I am so happy and feel so good. 

 

and someone who knows about I2C contact me, I will let you know, if it isn't beyond my knowledge.

 

WonCheol

Korean

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

:) I can understand surley "It's just condition not bits"

 

and you change my wrong concepts of I2C.

 

Thanks

 

- WonCheol.

 

 

Korean

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

With I2C it's important to understand that the SDA and SCL lines are not pulled to logic high and low in the same manner as input/output GPIO pins.   Instead they are "asserted" and "released".  Asserted means that either the SDA or SCL is indeed pulled to ground in a manner that is similar to an output pin, but Released means that the pin is switched to an input pin and the 4.7K ohm resistor pulls the pin to logic high (Vcc).    If the Master were to output logic high on SCL or SDA instead of Releasing it, then it would not be possible for the Slave to keep SCL or SDA asserted (at ground) after the Master has released it.   If -any- of the I2C devices asserts SDA or SCL, then that line is asserted for all the I2C devices.  But for release, -all- of the I2C devices have to switch to input mode in order for the logic level on the pin to rise to Vcc (its idle state).

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

Hello,  Thank your kind example and I get what mena "assert" "release"

 

But I have a question because I am new-bie in this side.

 

If i may ask, What GPIO's logic to high or Low? GPIO didn't use switch like I2C Signaling?

 

GPIO just flow High Current or Low Current without switing manner?

 

And If you are okay, could you recommend a good Reference for that?

Korean

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

Simonetta wrote:

With I2C it's important to understand that the SDA and SCL lines are not pulled to logic high and low in the same manner as input/output GPIO pins.   Instead they are "asserted" and "released".  Asserted means that either the SDA or SCL is indeed pulled to ground in a manner that is similar to an output pin, but Released means that the pin is switched to an input pin and the 4.7K ohm resistor pulls the pin to logic high (Vcc).    If the Master were to output logic high on SCL or SDA instead of Releasing it, then it would not be possible for the Slave to keep SCL or SDA asserted (at ground) after the Master has released it.   If -any- of the I2C devices asserts SDA or SCL, then that line is asserted for all the I2C devices.  But for release, -all- of the I2C devices have to switch to input mode in order for the logic level on the pin to rise to Vcc (its idle state).

 

Hello,  Thank your kind example and I get what mena "assert" "release"

 

But I have a question because I am new-bie in this side.

 

If i may ask, What GPIO's logic to high or Low? GPIO didn't use switch like I2C Signaling?

 

GPIO just flow High Current or Low Current without switing manner?

 

And If you are okay, could you recommend a good Reference for that?

Korean

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

GPIO means general-purpose input-output pin, which the CPU can set to either logic low (0 volts or ground) or logic high (Vcc).  These pins are referred to their port names in the AVR: PortB1, PortA7, but are called GPIO pins by other microprocessors.  High and low are called logic levels because it is the term selected by George Boole in the 1800's.  Mr. Boole developed a method of using algebra to determine whether people were telling the truth or lying.  In the 1920s it was discovered that Mr. Boole's work would be perfect for setting up a city-wide telephone switching system.  In the 1940's Boolean algebra was used to make the first programmable computers.

 

Computers try to use as little electrical current as possible, so high and low refer to voltage levels, not current flows.

 

With the AVR, there are four ways to implement I2C.   One is to "bit-bang" the SDA and SCL lines by treating them as ordinary GPIO pins and directly setting and clearing them as needed.  The old AVRs used this. 

 

The second way is to use the Universal Serial Interface found on AVR Tiny models.  Some people have been able to understand the datasheet and get 2-wire USI to actually work.  I'm not one of them.  Check in the projects section for an I2C sniffer by "danni" for an example of actually working USI I2C code.

 

The third way is to use the TWI section found on the AVR mega series.  This uses four or so control registers to do ordinary I2C tasks like generating START and STOP, and ACK signals.  Most AVR libraries use this control method, but the Fleury library includes a "bit-bang" code example as well.

 

The fourth way can be used with an Arduino board.  In Arduino C++ the user adds a reference to the Wire.h library.  The lets you use methods like  Wire.beginTransmission() to  handle all the I2C activities on a more abstract level.  Arduino code also allows you to use different processors with the same exact code.  This is possible because handling the actual CPU hardware is done on the library level, not the application code level, and you would use different versions of the Wire.h library for difference microprocessors, and the same Arduino .ino main sketch code regardless of the specific CPU.

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

Awesome, you are so professional based on my feeling.

 

I don't ever seen simple & clear explanation like this. It is fresh ideas for me and I will look for them from now on.

 

It is only natural thing to thank after reading a good explanation.

 

Thanks for your special knowledge.

Korean

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

Simonetta wrote:
With the AVR, there are four ways to implement I2C

You actually only describe three different ways to implement it:

  1. bit-banging
  2. the USI hardware found on some AVRs
  3. the TWI hardware found on other AVRs

 

The Arduino is not a 4th way to implement it - in the sense of those other 3 - it is simply some specific software which sits on top of the implementation.

Libraries such as Peter Fleury's provide similar abstraction for non-Arduino systems.

 

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...