Design World

  • Home
  • Technologies
    • 3D CAD
    • Electronics • electrical
    • Fastening & Joining
    • Factory automation
    • Linear Motion
    • Motion Control
    • Test & Measurement
    • Sensors
    • Fluid power
  • Learn
    • Ebooks / Tech Tips
    • Engineering Week
    • Future of Design Engineering
    • MC² Motion Control Classrooms
    • Podcasts
    • Videos
    • Webinars
  • LEAP AWARDS
  • Leadership
    • 2022 Voting
    • 2021 Winners
  • Design Guide Library
  • Resources
    • 3D Cad Models
      • PARTsolutions
      • TraceParts
    • Digital Issues
      • Design World
      • EE World
    • Women in Engineering
  • Supplier Listings

How To Monitor I2C Communications Through RS232

By Aimee Kalnoskas | October 10, 2014

Share

by Electro-Tech-Online member languer

In the past when requiring to monitor I2C communications between two devices I would use a logic analyzer. Such monitoring was useful to determine if the I2C communications between devices was properly configured. Even though this is quite useful and efficient, it does require a logic analyzer, with an I2C protocol debugger. Such devices are actually pretty common and not too expensive (e.g. Saleae Logic analyzer), but sometimes these may be overkill and a small specialized device may suffice. In comes the I2C monitor. Something which:

  1. can monitor simple I2C communications between two or more devices (at up to 100kHz bus speeds)
  2. does not respond, acknowledge, or in any way modify the communication being monitored
  3. outputs the transactions through RS232

This is nothing new, in fact the ideas behind this project were born from the following projects:

I2C Bus Sniffer on AVR

Robust I2C Slave Without a Sampling Clock

 

Design

To monitor simple I2C communications between two or more devices and output these transactions through RS232 to a PC, in some of the reference designs listed before most of the work is done by the MCU. The MCU samples the SCL and SDA lines and has to determine the START and STOP conditions, as well as the normal data. The flow diagram sort of goes as follows:

i2c program flow_1

To help the MCU keep up with the data, external hardware is added to handle the Start and Stop conditions. This was done on both the “I2C Bus Sniffer on AVR” and “Robust I2C Slave Without a Sampling Clock” articles. Such implementation requires four dedicated pins: three interrupt pins (one for Start condition, one for Stop condition, one for SCL), and one standard input for SDA. In addition the MCU requires built-in USART hardware.

The next figure provide illustration of how create the two additional hardware blocks for the Start and Stop conditions needed. During normal transactions the SDA (data) line is only allowed to change when the SCL (clock) line is at a logic low. A Start and Stop condition is then defined by a change of the SDA line when the SCL line is at a logic high; the Start condition indicated when the SDA transfers from at a logic high to a at a logic low with the SCL at a logic high, and the Stop condition indicated when the SDA transfers from at a logic low to a at a logic high with the SCL at a logic high.

i2c communication example_2

Flip-Flops can be used to create a simple method to identify these conditions, and create simple pulses to indicate either condition. The next figure shows a dual D-type flip-flop configuration used to determine a Start condition.

i2c start detector_3

The following figure, on the other hand, shows a dual D-type flip-flop configuration used to determine the Stop condition.

i2c stop detector_4

These Flip-Flop hardware blocks together with the MCU can now provide the building blocks for the I2C monitor. The I2C Start command, as decoded by the flip-flop, can trigger an I/O interrupt on the MCU indicating the start of the message. The I2C Stop command, as decoded by the flip-flop, can trigger a separate I/O interrupt on the MCU indicating the end of the message.

For proper operation, the following requirements exist for the MCU:

  • MCU must be clocked at the highest MHz rate possible (this is to be able to keep up with high data rates during the interrupt routines)
  • MCU requires dedicated USART hardware/pins
  • MCU requires three interrupt pins

For the implementation Microchip’s 18F1320 PIC was chosen. This MCU has the following specifications:

  • 40MHz clock (10MHz internal – using x4 PLL)
  • Two dedicated USART pins
  • Four dedicated interrupt pins (one is shared with USART, so CCP pin is used as third)

Implementation

The following figure shows the implementation of the proposed design. For a quick prototype, the FTDI interface was replaced with an FTDI TTL cable. Oshonsoft Basic was used to code and simulate the PIC MCU operation before actual implementation and testing of the hardware. The prototype worked as expected with two caveats: (1) the maximum bus supported speed is 100kHz, and (2) if the internal buffer on the MCU overflows there is currently no indication for this. Ideally such a device would work for I2C communications up to 400kHz, but this is limited by the PIC MCU clock and the RS232 output routines. The higher I2C communications are better suited for an FPGA implementation.

i2c monitor_5

 

Click  ASM Code for pdf of full Code

 

The post How To Monitor I2C Communications Through RS232 appeared first on Micro Controller Tips.


Filed Under: TECHNOLOGIES + PRODUCTS
Tagged With: commentay
 

Related Articles Read More >

55416_commModule_APL_300dpi_cmyk
Softing introduces a hardware module for implementing Ethernet-APL field devices.
IO-Link Smart Field I/O System from AutomationDirect
50 years of bit parallel encoders from POSITAL
EXAIR 3D model and CAD Library has more than 70 extensions

DESIGN GUIDE LIBRARY

“motion

Enews Sign Up

Motion Control Classroom

Design World Digital Edition

cover

Browse the most current issue of Design World and back issues in an easy to use high quality format. Clip, share and download with the leading design engineering magazine today.

EDABoard the Forum for Electronics

Top global problem solving EE forum covering Microcontrollers, DSP, Networking, Analog and Digital Design, RF, Power Electronics, PCB Routing and much more

EDABoard: Forum for electronics

Sponsored Content

  • Global supply needs drive increased manufacturing footprint development
  • How to Increase Rotational Capacity for a Retaining Ring
  • Cordis high resolution electronic proportional pressure controls
  • WAGO’s custom designed interface wiring system making industrial applications easier
  • 10 Reasons to Specify Valve Manifolds
  • Case study: How a 3D-printed tool saved thousands of hours and dollars

Design World Podcasts

May 17, 2022
Another view on additive and the aerospace industry
See More >
Engineering Exchange

The Engineering Exchange is a global educational networking community for engineers.

Connect, share, and learn today »

Design World
  • Advertising
  • About us
  • Contact
  • Manage your Design World Subscription
  • Subscribe
  • Design World Digital Network
  • Engineering White Papers
  • LEAP AWARDS

Copyright © 2022 WTWH Media LLC. All Rights Reserved. The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of WTWH Media
Privacy Policy | Advertising | About Us

Search Design World

  • Home
  • Technologies
    • 3D CAD
    • Electronics • electrical
    • Fastening & Joining
    • Factory automation
    • Linear Motion
    • Motion Control
    • Test & Measurement
    • Sensors
    • Fluid power
  • Learn
    • Ebooks / Tech Tips
    • Engineering Week
    • Future of Design Engineering
    • MC² Motion Control Classrooms
    • Podcasts
    • Videos
    • Webinars
  • LEAP AWARDS
  • Leadership
    • 2022 Voting
    • 2021 Winners
  • Design Guide Library
  • Resources
    • 3D Cad Models
      • PARTsolutions
      • TraceParts
    • Digital Issues
      • Design World
      • EE World
    • Women in Engineering
  • Supplier Listings