I2C monitoring without Microcontroller

by Brandon   Last Updated August 01, 2018 23:25 PM

I am trying to read data from an I2C connected touch sensor. Specifically the Azotec IQS266. I plan to preprogram all of the settings the way I want them, and then not touch them again after that. In addition to this, there is really only one piece of memory that I am interested in, the track pad gesture information at TP_FLAGS (0x02, offset 0).

This brings me to the question: how could I monitor a single memory address of a single device on an I2C line, without the use of a microcontroller? Say for instance, I wanted to light up 8 LEDs according to the 8 bits of information stored at that address whenever the Azotec device produced a ready signal.

I agree that a microcontroller would make the most sense, but there are some cases where maybe you would prefer to avoid their use. Certain regulatory bodies become harder to deal with when you introduce 'software' into a design, and it may be advantageous to get simple data from an I2C capable device with a more 'hardware' based approach. Is this possible to monitor one I2C device for a specific address, and essentially convert its information to a parallel GPO output?

Answers 2

I'm not sure there is an existing product that does what you want. If you were going to design a custom solution, some options might include:

  1. Use programmable logic such as a small CPLD to implement the I2C interface and have a state machine track bus activity to capture the data you want.

  2. Like #1 but use a dedicated chip such as the PCA8584 (I2C to parallel bridge) to do the heavy lifting for the I2C protocol and have a CPLD handle the higher level activity monitoring. This chip has a snoop mode where it is guaranteed to not drive anything on the I2C bus and monitor it non-destructively.

  3. Use a microcontroller with a similar I2C snoop mode such as the LPC1769. I don't know if having this functionality implemented in hardware (on-chip) would let you circumvent the regulations about software however, since a software bug could take it out of snoop mode and introduce erroneous I2C traffic. So that's a bit of a stretch.

August 01, 2018 22:42 PM

when you introduce 'software' into a design

Software: A program interpreted by a processor.

What you need is the following:

  • query the register via I²C (the sensor doesn't "tell" by itself. It has to be asked), which means sending the same sequence of signals over the I²C bus
  • changing the state of 8 outputs, based on the signals that the sensor sends in response on the I²C bus

Bad news: that's a programmatic flow, and just by writing down the specs of what you want, we determined it's a program. You'll have to deal with software, no matter what.

If you, for example, implemented the following:

  • send sequence on SDA and SCL
  • switch over to sampling SDA when SCL changes
  • store the SDA values in a shift register
  • set the LEDs according to said shift register

cycle in logical hardware, congratulations, you've built a very application-specific processor that runs a four-step program.

It's really the point where you say that this is a job for a microcontroller. And really, what do you think, how many processor cores are in that touchpad? I'd assume it's at least one, but if I had to design one, it'll actually be two linked microcontrollers. So, if your regulatory body has a problem with microcontrollers: tough luck.

Marcus Müller
Marcus Müller
August 01, 2018 23:02 PM

Related Questions

What's usage of Inhibit pin?

Updated January 31, 2018 03:25 AM

Question about using variable reluctance sensor

Updated August 16, 2018 20:25 PM

MCU with blown GPIO?

Updated June 27, 2017 22:25 PM