1

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?

Brandon
  • 21
  • 3
  • It seems the device expects there to be an I2C master (i.e. it operates as slave, p13 of datasheet, first para) so I can't see anyway short of building an FPGA to get the info out of it. – danmcb Aug 01 '18 at 22:32
  • 2
    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? – user253751 Aug 01 '18 at 22:32
  • It is very unlikely that you will find a dedicated device to do this, at least not one that doesn't require some kind of software. It is possible, if the command is well known to wire up discrete TTL logic to do this, but the complexity of such a design will be high. Generally speaking, such simple interface devices are the domain of PLD/FPGA, PIC, and, for large volumes - ASIC. Otherwise, if this is a critical project you will be better off peeling away one more layer of abstraction and implement a custom trackpad controller with analog or parallel interface suitable for your application. – crasic Aug 01 '18 at 22:34
  • 1
    You could look at CPLDs. But they might have the same regulations as microcontrollers. – user253751 Aug 01 '18 at 23:08
  • 5
    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 – Chris Stratton Aug 02 '18 at 00:01
  • 1
    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 – Brandon Aug 02 '18 at 00:52
  • 1
    FDA compliance can make one go absurd, @Chris. – Nick Alexeev Aug 02 '18 at 00:52
  • To be blunt, if you're prohibited by external requirements from using software, then it's an **irresponsible** action on your part to consent to use something demonstrably even *less* trustworthy, and in fact routinely demonstrated to be downright flakey. Surely you've seen a touch device generate false events, and numerous false gestures? The only remotely reasonable way to use touch in a critical system is by adding *a lot of software* to confirm by additional user interaction that the action is *really* what the user wants. – Chris Stratton Aug 02 '18 at 00:54
  • You seem to not like gestures, fair enough. And yes, there are numerous examples of touch enabled devices generating false positives, but I'm not sure every touch enabled activity should require a 'Did you really mean to X?' style confirmation from the user. At the end of the day, I don't know what I don't know, and its possible there was some easy alternative out there that would let me do this job without a micro. I don't believe that is off-topic, I think exploring a strange use-case like this would be a purpose of this forum. Also, I may not agree with FDA regs, but my job is to follow – Brandon Aug 02 '18 at 01:02
  • No. If you want to call yourself an engineer, you have a responsibility to *refuse* to build something improper. If software is unsafe for this application, touch is ten times moreso, and especially so if using software to sanity check the touch events is not permitted. – Chris Stratton Aug 02 '18 at 01:04
  • Improper may be open to interpretation here, you have no idea what other safe-guards are built into the system – Brandon Aug 02 '18 at 01:05
  • Either the safe guards can handle false and missed events, or they cannot. If they can, software in the touch chain specifically is reasonable. If they cannot, **touch is utterly impermissible** and it is a violation of professional duty to assist in building it for that purpose. – Chris Stratton Aug 02 '18 at 01:06
  • Frankly Chris, I agree with you. Maybe I should have phrased the question as "Is there an alternative to this thing that I'm probably going to do (use a micro) that I haven't thought of?" But I don't think the question itself is completely devoid of merit. I'm doing a job and looking for options. thats it. The answers below which have pointed out the lengths that I would have to go to are very instructive, much more so than just saying "bad question, off topic, shut it down" – Brandon Aug 02 '18 at 01:09
  • The reason it's off topic is because the quest of the question is an improper attempt at fake compliance - the problem is entirely *artificial* - driven only by these constraints of attempting to deceive a regulator into accepting something that superficially meets the letter but not *intent* of the regulation, not one that occurs in *responsible* design. You need to refuse this, not because the alternatives to software are *hard* but because they are *even more irresponsible* than software implementing sanity filtering. – Chris Stratton Aug 02 '18 at 01:14
  • I dont have the years of experience to question the people who made these regulations. But I know what passes and what does not. Thats all I have this early in my career. I'll continue pushing my manager for software support because, as I said, I am of the same opinion that it is a better route. But hey, someone might have said "Oh don't you know about XYZ part from TI? Its sole job is to buffer out a register loaded memory address of an I2C device!" And then that would have been fine. The answers showing how complicated the reality are strengthen my argument with my manager – Brandon Aug 02 '18 at 01:19
  • It is a critical part of your job as an engineer to question. Your hypothetical fixed-function I2C engine would not have been remotely "fine", as it still leaves the greater risk of the gross unreliability of touch unaddressed. If you're not prepared to say "no" and walk away, you are not in a position to do this type of work. – Chris Stratton Aug 02 '18 at 01:20
  • Well now we really are off topic, and I don't have the rep to move to chat. – Brandon Aug 02 '18 at 01:24
  • We're not remotely off topic. In fact, we are on the most important *possible* topic. Everything else is secondary to being responsible in your endeavors. – Chris Stratton Aug 02 '18 at 01:25
  • Ok buddy, next time I'm seeing if there are alternatives to a design that I'm unaware of, what should I do? I've contacted vendors, done my google and IEEE searching, and as a last ditch effort, I thought I might post something here in my free time and see if the creative folks of stack exchange had some crazy idea. what is the better path for looking for design alternatives? – Brandon Aug 02 '18 at 01:27
  • When the goal is routing around safety regulation, you should say "no" not look for clever dodges. Alternatives are for *technical* problems. In contrast, your question amounts to "we want to do something grossly irresponsible but the regulator is making it hard, please help" – Chris Stratton Aug 02 '18 at 01:30
  • Gotcha. Thanks. But I wouldn't know if there is a legit alternative or a 'dodge' till I ask. Its clear now, thanks to the other answers. – Brandon Aug 02 '18 at 01:31
  • @Brandon Just a side note: If you're the manufacturer of the device, and you're in the IEC 62304 world, keep in mind that all software is based on the risk assessment, which you'll need anyway for a medical product. The standard doesn't specify what is acceptable risk, it's up to the manufacturer to determine that. If the touchscreen is non-critical, then you could do the software in Class A and not have as much headaches. – AndrejaKo Aug 02 '18 at 07:30

5 Answers5

3

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.

1

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.

Henry Crun
  • 5,273
  • 11
  • 12
0

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
  • 88,280
  • 5
  • 131
  • 237
  • 3
    A sequential operation implemented with hardware isn't considered software. – user253751 Aug 02 '18 at 00:37
  • 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 – Brandon Aug 02 '18 at 00:49
  • @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. – Ale..chenski Aug 02 '18 at 01:13
  • Yup, its dumb. Its not my rule – Brandon Aug 02 '18 at 01:13
  • @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. – Ale..chenski Aug 02 '18 at 01:20
  • That kind of makes sense to me. I interpreted it as almost a traceabillity issue. You can run all possible inputs into a simple digital circuit and observe the outputs. An FPGA implements a simple digital circuit, so you should be able to do the same thing, but maybe the unused gates could cause some weird edge-case. And then software is some level abstracted above that... But I like your point about external tampering – Brandon Aug 02 '18 at 01:23
  • Provability of correctness is the central issue. (Tampering is a separate issue). State machines can be unprovable for the same reason that software is. State complexity is the issue. Now this task can be done by straight sequence, so it is provably correct if done that way. (even if you use an mcu to implement it) – Henry Crun Aug 02 '18 at 07:59
0

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.

Ale..chenski
  • 38,845
  • 3
  • 38
  • 103
  • 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. – Chris Stratton Aug 02 '18 at 01:16
  • 2
    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. – Henry Crun Aug 02 '18 at 07:27
0

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).

filo
  • 8,801
  • 1
  • 25
  • 46