1
\$\begingroup\$

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?

\$\endgroup\$

closed as off-topic by Chris Stratton, Voltage Spike, Chupacabras, Turbo J, Lior Bilia Aug 3 '18 at 12:30

  • This question does not appear to be about electronics design within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    \$\begingroup\$ It should be quite doable with digital logic chips, but whatever you come up with is going to be more expensive and much bigger than a microcontroller, is that acceptable? \$\endgroup\$ – immibis Aug 1 '18 at 22:32
  • 1
    \$\begingroup\$ You could look at CPLDs. But they might have the same regulations as microcontrollers. \$\endgroup\$ – immibis Aug 1 '18 at 23:08
  • 5
    \$\begingroup\$ I'm voting to close this question as off-topic because permitting capacitive touch (and worse, touch gestures) but prohibiting software for the narrow purpose of interpreting it is absurdly illogical risk analysis \$\endgroup\$ – Chris Stratton Aug 2 '18 at 0:01
  • 1
    \$\begingroup\$ Unfortunately 'absurdly illogical' describes the current state of classification between software and hardware when your making a medical device. Still, these are the considerations/constraints I have to design to. I'd really rather just use a Micro and be done with it. But it would be interesting if there was a way around it \$\endgroup\$ – Brandon Aug 2 '18 at 0:52
  • 1
    \$\begingroup\$ FDA compliance can make one go absurd, @Chris. \$\endgroup\$ – Nick Alexeev Aug 2 '18 at 0:52
3
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

Your pure hardware solution is: 1 eprom SST39VF010, 1x 74hc4060, 1x 74HC4094. 2xR, 2xC. Cost ~$1 The eprom pins pins will be SDA, SCL, CLK4094, RST4094 . 4094 data connects to SDA. The bitstream that reads your Azotec is stored in the flash, and is clocked out in an endless loop by the 4060 counter. When the Azotec data is being read out, it clocks it into the 4094. The bitstream will need 20-30bytes per I2C byte, at a guess ~256bytes.

(Silego greenpak mixed logic + SPI memory could be a 2 chip solution).


The Azotec product itself is most likely something with internal firmware, like most complex I2C slave devices, so your underlying idea becomes somewhat moot.

A halfway house is to use a small micro exactly like the eprom+counter, but rather than programmatically reading and writing, you just serially dump out a control bitstream that does what you want. The micro program becomes a simple dump loop, maybe only 20 words long. It can be implemented with a cyclomatic complexity of 1 using an external LED shift register or 2 (perhaps 1) when driving leds from the micro, and can be formally proved to be correct. The bitstream is an invariant stored sequence with no branches, and so can be proven correct by exhaustive testing of the one possible sequence.


Our product BL233C is capable of being a standalone I2C redirector to do what you want, reading an I2C sensor, minimally processing it, and writing to another I2C display device.

It also has underlying firmware of course, but like the sensor, may appear to a reviewer as a reliable chip (well it is of course), rather than a software system. This not unreasonable - specialists like us and Azotech should have more mature and therefore better debugged products than your own program would be when initially deployed.

\$\endgroup\$
  • \$\begingroup\$ Oh I like this! Interesting device. \$\endgroup\$ – Marcus Müller Aug 2 '18 at 7:29
0
\$\begingroup\$

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.

\$\endgroup\$
  • 2
    \$\begingroup\$ A sequential operation implemented with hardware isn't considered software. \$\endgroup\$ – immibis Aug 2 '18 at 0:37
  • \$\begingroup\$ Thats a fair point. Honestly, this all comes about from the widely differing interpretations of what is 'hardware' vs what is 'software', particularly in the ISO directed medical device world. Its all pretty gray (some people have had FPGA-implemented state machines interpeted as hardware, where as others have had it interpreted as software because of what has created that code), I'm just exploring my options \$\endgroup\$ – Brandon Aug 2 '18 at 0:49
  • \$\begingroup\$ @Brandon, following this logic, " ...as software because of what has created that code", every hardware IC is "software", because design of all hard logic/masks/manufacturing steps is done by using huge software packages. \$\endgroup\$ – Ale..chenski Aug 2 '18 at 1:13
  • \$\begingroup\$ Yup, its dumb. Its not my rule \$\endgroup\$ – Brandon Aug 2 '18 at 1:13
  • \$\begingroup\$ @Brandon, I guess the distinction/concern could be if the burned-in "microcode" can be tampered with or externally altered. This could be a valid concern. Then a state machine controller made out of one-time custom mask-programmed memory could be a solution. \$\endgroup\$ – Ale..chenski Aug 2 '18 at 1:20
0
\$\begingroup\$

The hardware-based solution to your small I2C control sequence is called "non-volatile FPGA", or a good CPLD. You design a serial converter in any VHDL, allocate/configure a chunk of memory inside CPLD, and make a small sequencer to run the bytes from your pre-defined I2C data. All is a pre-compiled state machine, no software.

If a non-authorized re-programmability is of main concern, a ROM-based FSM can be a solution.

\$\endgroup\$
  • \$\begingroup\$ Not true. An FPGA configuration is most definitely "software" And rather obviously when you consider the scope of the task of making this practically usable. \$\endgroup\$ – Chris Stratton Aug 2 '18 at 1:16
  • 1
    \$\begingroup\$ If you consider that the nub of the matter is provability, then FPGA's suffer from being unprovable (because of the hidden compiler layers). By the same measure, a microprocessor can be used to implement a system that has a cyclomatic complexity of 1 i.e. a single unbranching path, and thus can be provably correct. \$\endgroup\$ – Henry Crun Aug 2 '18 at 7:27
0
\$\begingroup\$

The alternative to "software" in a digital is a finite-state machine. This has been discussed here. If you really want to avoid both software and FSM then you will have to go fully analog (eg. LM3914 to drive the LEDs).

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.