Monitoreo I2C sin Microcontrolador [cerrado]

No estoy seguro de que exista un producto que haga lo que usted quiere. Si iba a diseñar una solución personalizada, algunas opciones podrían incluir:

1. Use una lógica programable como un CPLD pequeño para implementar la interfaz I2C y haga que la actividad del bus de seguimiento de la máquina del estado capture los datos que desea.

2. Me gusta # 1 pero usa un chip dedicado como el PCA8584 (I2C a puente paralelo) para hacer el trabajo pesado para el protocolo I2C y tener un CPLD que maneje el nivel superior de monitoreo de actividad. Este chip tiene un modo snoop en el que se garantiza que no debe conducir nada en el bus I2C y monitorearlo de forma no destructiva.

3. Use un microcontrolador con un modo de espionaje I2C similar, como el LPC1769. No sé si tener esta funcionalidad implementada en hardware (en chip) le permitiría eludir las regulaciones sobre el software, ya que un error de software podría sacarlo del modo snoop e introducir tráfico I2C erróneo. Eso es un poco exagerado.

Su solución de hardware puro es: 1 eprom SST39VF010, 1x 74hc4060, 1x 74HC4094. 2xR, 2xC. Costo ~ $ 1 Los pines eprom pins serán SDA, SCL, CLK4094, RST4094. 4094 datos se conectan a SDA. El flujo de bits que lee su Azotec se almacena en el flash, y el contador 4060 lo registra en un bucle sin fin. Cuando se están leyendo los datos de Azotec, los sincroniza en el 4094. El flujo de bits necesitará 20-30 bytes por byte I2C, en una estimación de ~ 256 bytes.

(Silego greenpak mixed logic + SPI memory podría ser una solución de 2 chips).

El producto Azotec en sí mismo es probablemente algo con firmware interno, como la mayoría de los dispositivos esclavos I2C complejos, por lo que su idea subyacente se vuelve un tanto discutible.

Una casa intermedia es utilizar un micro pequeño exactamente como el contador eprom +, pero en lugar de leer y escribir mediante programación, simplemente descarta en serie un flujo de bits de control que hace lo que usted desea. El microprograma se convierte en un simple bucle de volcado, tal vez solo 20 palabras. Se puede implementar con una complejidad ciclomática de 1 usando un registro de desplazamiento externo de LED o 2 (quizás 1) cuando se manejan leds desde el micro, y se puede demostrar formalmente que es correcto. El flujo de bits es una secuencia almacenada invariable sin ramificaciones, por lo que se puede probar que es correcta mediante una prueba exhaustiva de la única secuencia posible.

Nuestro producto BL233C es capaz de ser un redirector I2C independiente para hacer lo que quiera, leyendo un sensor I2C , procesándolo mínimamente y escribiendo en otro dispositivo de visualización I2C.

También tiene un firmware subyacente, por supuesto, pero al igual que el sensor, puede parecerle a un revisor un chip confiable (bueno, por supuesto que lo es), en lugar de un sistema de software. Esto no es irrazonable: los especialistas como nosotros y Azotech deberían tener productos más maduros y, por lo tanto, más depurados que su propio programa cuando se implementa inicialmente.

  

cuando introduces 'software' en un diseño

Software: un programa interpretado por un procesador.

Lo que necesitas es lo siguiente:

• consultar el registro a través de I²C (el sensor no "dice" por sí mismo. Debe preguntarse), lo que significa enviar la misma secuencia de señales a través del bus I²C
• cambio del estado de 8 salidas, en función de las señales que el sensor envía en respuesta en el bus I²C

Malas noticias: eso es un flujo programático, y solo al escribir las especificaciones de lo que desea, determinamos que es un programa. Tendrás que lidiar con el software, sin importar qué.

Si, por ejemplo, implementó lo siguiente:

• enviar secuencia en SDA y SCL
• cambie a SDA de muestreo cuando SCL cambie
• almacenar los valores SDA en un registro de desplazamiento
• configurar los LED de acuerdo con dicho registro de desplazamiento

ciclo en hardware lógico, felicitaciones, has construido    un procesador muy específico de la aplicación que ejecuta un programa de cuatro pasos.

Es realmente el punto en el que dice que este es un trabajo para un microcontrolador. Y realmente, ¿qué piensas, cuántos núcleos de procesador hay en ese panel táctil? Asumiría que es al menos uno, pero si tuviera que diseñar uno, en realidad serían dos microcontroladores vinculados. Entonces, si su organismo regulador tiene un problema con los microcontroladores: mala suerte.

La solución basada en hardware para su pequeña secuencia de control I2C se llama "FPGA no volátil", o un buen CPLD. Usted diseña un convertidor en serie en cualquier VHDL, asigna / configura una parte de la memoria dentro de CPLD y crea un pequeño secuenciador para ejecutar los bytes de sus datos I2C predefinidos. Todo es una máquina de estado precompilada, sin software.

Si una reprogramación no autorizada es una preocupación principal, un FSM basado en ROM puede ser una solución.

La alternativa al "software" en una máquina digital es una máquina de estado finito. Esto se ha tratado aquí . Si realmente desea evitar tanto el software como el FSM, entonces tendrá que ser totalmente analógico (por ejemplo, LM3914 para controlar los LED).