Actions
Forum Thread Details
  • State Not Answered
  • Replies 8 replies
  • Subscribers 360 subscribers
  • Views 792 views
  • Users 0 members are here
Related

Who does I2C address decode better - Agilent or Tektronix?

Instructorman

This question is for anyone who has used I2C decode features on Agilent or Tektronix oscilloscopes, or anyone interested in how I2C address decode should be done.  The two manufacturers handle I2C addresses differently and I wonder how users feel about the two approaches.

 

On Tektronix 'scopes, I2C addresses are entered as full 8-bit hex values, so the R/W' bit is included in the hex value.  On Agilent scopes, I2C addresses are entered as 7-bit hex values, and the R/W' bit is tacked on as the letter R or W.

 

Obviously, both approaches work, but the Agilent approach strikes me as a little odd.  Here is why:  Most data sheets I've seen provide I2C addresses as 8-bit values with the R/W' bit included as the LSB.  For example, Maxim refers to the DS1307 address as 1101000 followed by a R/W' bit of either 0 (for write) or 1 (for read).  Put that all together and you get 11010000b = D0h for write and 11010001b = D1h for read.  These are the values a user would enter into a Tektronix 'scope to detect and decode I2C communication with a DS1307.  On the other hand, on an Agilent 'scope the I2C addresses for the DS1307 are entered as 68W and 68R.  These values correspond to the 7-bit I2C address followed by an R or W to denote an 8th bit.  Now, a hex digit should, to me, represent 4-bits of binary.  Agilent seems to be using an octal digit followed by a hex digit, followed by a letter.  I find that confusing and awkward.  I asked an Agilent rep about why I2C was handled this way, but never got a response.

 

So, which approach do you prefer, and why?

  • 0

    I definitely prefer it the way Tek does it. give me the actual value so i don't screw up my code.

  • 0 in reply to sqkybeaver

    I checked in the I2C standard (NXP document UM10204), and interestingly enough NXP don't express addresses in hex at all: from page 13:

    Data transfers follow the format shown in Figure 9. After the START condition (S), a slave

    address is sent. This address is seven bits long followed by an eighth bit which is a data

    direction bit (R/W) — a ‘zero’ indicates a transmission (WRITE), a ‘one’ indicates a

    request for data (READ)

    The table on page 17 gives a clue about NXP's prefered route, the address is binary with the R/W bit shown separately. This would suggest that Agilent and Tek are both wrong and that the address in Mark's example should be shown as 0x34 (which is confusing but is a method I have seen used in several data sheets).

     

    I think I have a marginal preference for the Agilent approach - it draws your attention to the fact that it is definitely NOT an 8 bit address.

     

    If I remember I'll post exactly how the LeCroy decoder and ZeroPlus logic analyser do it when I next have an I2C something running.

     

    BTW do ANY of these decoders cope with 10 bit I2C addressing (which I didn't even know about until I was reading the standard this morning !!)

     

    MK

  • 0

    I'll copy my reply to your original question in here:

    Indeed, some manufacturers do that, but it doesn't mean it's correct. The address is still a 7-bit value, with the exception of 10-bit addresses.

     

    Being able to only display an 8-bit address is obviously an error, while having the option to switch between the two is an attempt at making it easier for the engineer to deal with crappy datasheets (really makes you wonder who's in charge of deciding what to put in the datasheet).

     

    Edit: To answer Mark's question, it doesn't matter if you're only left with 3 bits, any value can be represented in any base and the number of bits is absolutely meaningless from that point of view. This means that the address is fully represented in hex, it just happens that it can't go above 127 (dec).

     

    As for which is correct, binary or hex - any base is fine. An address is nothing more than a number and it will be the same number no matter how it's represented.

     

    Razvan

  • 0 in reply to jadew

    i double checked the dpo4embd module. it actually is capable of displaying with and without the w/r bit included in the address byte.

     

    does this change the conversation any?

  • 0 in reply to sqkybeaver

    Sheldon,

     

    Hmm, I hadn't noticed that the dpo4embd allows the r/w bit to be included or excluded. Thanks for pointing that out.  I wonder if Agilent decoders can do the same?

    I prefer to have the I2C address expressed with the R/W' bit tacked on, thus creating an 8-bit value.  To me this makes code writing more straigtforward, even though, as Michael and Razvan point out, strictly speaking I2C addresses are either 7-bits or 10-bits long.

     

    Has anyone determined if any of the scopes can decode 10-bit I2C addresses?

  • 0 in reply to Instructorman

    Mark Archibald wrote:

     

    Has anyone determined if any of the scopes can decode 10-bit I2C addresses?

    the dpo4embd will also decode 10 bit addresses.

     

    I do believe it also displays a W or R regardless of wither you include the r/w bit in the address.

  • 0

    Thanks for the discussion everyone.  It seems to me that the format used to set up I2C address decode on an oscilloscope is best left as a matter of personal preference. As Razvan pointed out, an address is a number and any base will work to represent that number.  Having the option to include or exclude the R/W' bit in that number is a nice option to have - at least on the DPO4EMBD Tektronix decoder.  I don't know if Agilent provides that option.

  • 0

    I have used both, and in terms of Usability, tek wins every time.  The way you can use the wave inspector to browse through the event table or view the data in a linear (waveform) format where the decoded data along with frame start/end, direction (R/W) and actual data can be presented in any format (ie binary, hex, etc).  The only neat Agilent feature is the segmented memory if you have huge quiet periods between data bursts (tek captures everything including quiet periods), but the Tek has plenty of deep memory/record length to do more than I need it to.  My scope of choice is usually the DPO3000 using DPO3EMBD decode for serial (I2C/SPI/CAN/RS232) debugging.   If dealing with large parallel buses I prefer to use an MSO4000 due to the logic analyzer probe and larger screen side to see 20 channels at the same time.