Saturday, October 8, 2011

I2C Snooper Board

While working at my current employer, my group had a need for an I2C bus monitor. There are quite a few devices that we use on a daily basis that communicate with the I2C bus protocol, so having a monitoring tool would be useful.  After searching the web for products, it became apparent that if you wanted a monitor that would be able to snoop at both standard (100kHz) and fast (400kHz) modes without being intrusive to the bus, you would need to spend a bit of money. 

An example of this would be one from Equinox http://www.equinox-tech.com/products/details.asp?ID=336 that sells for $4000.  Some of the other models we looked at were less expensive but could not capture data at 400kHz, or would stall the bus by pulling the clock line low in order to keep up with the data transfer.  So, why not custom build one that would cost a fraction of the cost with the same functionality, and be able to customize it further when needed.

Capture Board
Initially, I designed a board that would communicate over the serial port and not require any additional drivers.  The user interface was implemented in the microcontroller and had a DOS-like feel to it.  Below are a few screen captures of the first cut:

I2C Bus Capture Firmware Running on the ATMega128 (Help Screen)



Reading and Writing Data to EEPROMs



Data Capture in I2C Standard Mode (100kHz)



This was fine, but there were one shortfall that was known before proceeding.  If you wanted to capture data at bus speeds above 100kHz, you would need to buffer the data since the serial port would not be able to handle the data stream in real-time.  The problem with buffering the data is if you are recording over a long period of time, with heavy bus traffic, you will eventually run out of buffer space.  Since this was most likely the type of scenario we would encounter, an alternative approach was needed.  So, to make a long story short, I decided to add a USB chip to the device to up the speed.

I2C Snooper Take Deux

I wanted to keep the basic functionality the same (meaning, ability to read/write and capture data) but be able to do it at 400kHz.  So, I started by adding a USB 1.1 chip by FTDI, the FT245BM.  This chip would allow me to communicate at speeds up around 1MB per second, so sending I2C bus data with some overhead even at 400kHz would not be a problem.  Since the FTDI chip was so fast, I found that I didn't need any external SRAM to pre-buffer the data, the 384 byte internal buffer was good enough.  This also meant that I wouldn't need to use the ATMega128 with external SRAM capability, so it was replaced with an ATMega32.  Actually, I could have brought the cost down further by using an ATMega8, but I wanted to have some extra internal SRAM and Flash just in case extra functionality was needed.

Here is a screen capture of the board file:


 a picture of the populated board:



The MFC Application

After the board layout was complete, I needed to write a application to interface with the board.  Initially I wanted to avoid doing this, but since I needed to add a USB driver chip, I didn't have a choice.  The software was written in VC 6.0 (using MFC) as a multithreaded application.

There are two threads which take care of the incoming data.  The first is used to strictly capture the data stream and place it directly into a thread-safe queue.  The second thread is used to remove data from the queue, parse it, and display the captured bytes to the screen.  The software framework is setup only for I2C data capture at the moment, but since the AVR controller has a built-in I2C peripheral, the software can be easily modified to act as an I2C Master or Slave device.  At the moment though, capturing data seems to be more important.  Here is a screen capture of the MFC application:

MFC Application Capturing data at 412kHz


What's left?  Well, I am currently working on triggering and filtering which will be completed in about a week.  This is rather easy to implement since all the data is available in the application.

The Cost

One of the main reasons for starting this project was to try and keep the price of the unit low.  Material costs for the board, including setup and shipping charges for the prototype boards totaled $160.  The price per board is about $25.

July 10, 2005

No comments:

Post a Comment