element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Test & Tools
  • Technologies
  • More
Test & Tools
Forum Who does I2C address decode better - Agilent or Tektronix?
  • Blog
  • Forum
  • Documents
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Test & Tools to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Not Answered
  • Replies 8 replies
  • Subscribers 360 subscribers
  • Views 796 views
  • Users 0 members are here
  • address
  • i2c
  • tektronix
  • decode
  • agilent
Related

Who does I2C address decode better - Agilent or Tektronix?

Instructorman
Instructorman over 11 years ago

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?

  • Sign in to reply
  • Cancel
Parents
  • sqkybeaver
    0 sqkybeaver over 11 years ago

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

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • michaelkellett
    0 michaelkellett over 11 years ago 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

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
Reply
  • michaelkellett
    0 michaelkellett over 11 years ago 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

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube