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?
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:
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.
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.
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.
when you introduce 'software' into a design
Software: A program interpreted by a processor.
What you need is the following:
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:
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.