Monitoreo I2C sin microcontrolador [cerrado]

Estoy tratando de leer datos de un sensor táctil conectado a I2C. Concretamente la Azotec IQS266 . Planeo preprogramar todas las configuraciones de la manera que quiero, y luego no volver a tocarlas después de eso. Además de esto, en realidad solo hay una pieza de memoria que me interesa, la información de gestos del trackpad en TP_FLAGS (0x02, desplazamiento 0).

Esto me lleva a la pregunta: ¿cómo podría monitorear una sola dirección de memoria de un solo dispositivo en una línea I2C, sin el uso de un microcontrolador? Digamos, por ejemplo, que quería encender 8 LED de acuerdo con los 8 bits de información almacenados en esa dirección cada vez que el dispositivo Azotec producía una señal de listo.

Estoy de acuerdo en que un microcontrolador tendría más sentido, pero hay algunos casos en los que tal vez prefiera evitar su uso. Ciertos organismos reguladores se vuelven más difíciles de tratar cuando se introduce 'software' en un diseño, y puede ser ventajoso obtener datos simples de un dispositivo compatible con I2C con un enfoque más basado en 'hardware'. ¿Es posible monitorear un dispositivo I2C para una dirección específica y, esencialmente, convertir su información en una salida GPO paralela?

Parece que el dispositivo espera que haya un maestro I2C (es decir, funciona como esclavo, p13 de la hoja de datos, primer párrafo), por lo que no puedo ver nada más que construir un FPGA para obtener la información.
Debería ser bastante factible con chips lógicos digitales, pero lo que se te ocurra será más caro y mucho más grande que un microcontrolador, ¿es aceptable?
Es muy poco probable que encuentre un dispositivo dedicado para hacer esto, al menos no uno que no requiera algún tipo de software. Es posible, si el comando es bien conocido, conectar la lógica TTL discreta para hacer esto, pero la complejidad de dicho diseño será alta. En términos generales, estos dispositivos de interfaz simple son el dominio de PLD/FPGA, PIC y, para grandes volúmenes, ASIC. De lo contrario, si se trata de un proyecto crítico, será mejor que elimine una capa más de abstracción e implemente un controlador de trackpad personalizado con una interfaz analógica o paralela adecuada para su aplicación.
Podría mirar los CPLD. Pero pueden tener las mismas regulaciones que los microcontroladores.
Voto para cerrar esta pregunta como fuera de tema porque permitir el toque capacitivo (y peor aún, los gestos táctiles ) pero prohibir el software con el propósito limitado de interpretarlo es un análisis de riesgo absurdamente ilógico.
Desafortunadamente, 'absurdamente ilógico' describe el estado actual de clasificación entre software y hardware cuando se fabrica un dispositivo médico. Aún así, estas son las consideraciones/restricciones que tengo que diseñar. Realmente preferiría usar un Micro y terminar con eso. Pero sería interesante si hubiera una forma de evitarlo.
El cumplimiento de la FDA puede hacer que uno se vuelva absurdo, @Chris.
Para ser franco, si los requisitos externos le prohíben usar software, entonces es una acción irresponsable de su parte dar su consentimiento para usar algo que se puede demostrar que es incluso menos confiable y, de hecho, se demuestra de manera rutinaria que es francamente raro. ¿Seguramente has visto un dispositivo táctil generar eventos falsos y numerosos gestos falsos? La única forma remotamente razonable de usar el tacto en un sistema crítico es agregar una gran cantidad de software para confirmar mediante la interacción adicional del usuario que la acción es realmente lo que el usuario desea.
Parece que no te gustan los gestos, es justo. Y sí, hay numerosos ejemplos de dispositivos táctiles que generan falsos positivos, pero no estoy seguro de que todas las actividades táctiles deban requerir un '¿Realmente quisiste decir X?' confirmación de estilo por parte del usuario. Al final del día, no sé lo que no sé, y es posible que haya alguna alternativa fácil que me permita hacer este trabajo sin un micro. No creo que esté fuera de tema, creo que explorar un caso de uso extraño como este sería un propósito de este foro. Además, puede que no esté de acuerdo con las normas de la FDA, pero mi trabajo es seguir
No. Si quiere llamarse ingeniero, tiene la responsabilidad de negarse a construir algo inapropiado. Si el software no es seguro para esta aplicación, el toque lo es diez veces más, y especialmente si no se permite el uso del software para verificar la cordura de los eventos táctiles.
Lo incorrecto puede estar abierto a interpretación aquí, no tiene idea de qué otras salvaguardas están integradas en el sistema
Las protecciones de seguridad pueden manejar eventos falsos y perdidos, o no pueden. Si pueden, el software en la cadena táctil específicamente es razonable. Si no pueden, el contacto es absolutamente inadmisible y es una violación del deber profesional ayudar a construirlo para ese propósito.
Francamente Chris, estoy de acuerdo contigo. Tal vez debería haber formulado la pregunta como "¿Hay alguna alternativa a esto que probablemente voy a hacer (usar un micro) que no haya pensado?" Pero no creo que la pregunta en sí esté completamente desprovista de mérito. Estoy haciendo un trabajo y buscando opciones. eso es todo. Las respuestas a continuación, que han señalado los extremos a los que tendría que llegar, son muy instructivas, mucho más que simplemente decir "mala pregunta, fuera de tema, apáguelo".
La razón por la que está fuera de tema es porque la búsqueda de la pregunta es un intento inadecuado de cumplimiento falso; el problema es completamente artificial , impulsado solo por estas limitaciones de intentar engañar a un regulador para que acepte algo que cumple superficialmente con la letra pero no con la intención del regulación, no una que ocurra en el diseño responsable . Debe rechazar esto, no porque las alternativas al software sean difíciles , sino porque son incluso más irresponsables que el software que implementa el filtrado de cordura.
No tengo los años de experiencia para cuestionar a las personas que hicieron estas regulaciones. Pero sé lo que pasa y lo que no. Eso es todo lo que tengo al principio de mi carrera. Continuaré presionando a mi gerente para soporte de software porque, como dije, soy de la misma opinión que es una mejor ruta. Pero bueno, alguien podría haber dicho: "¿No conoces la parte XYZ de TI? ¡Su único trabajo es almacenar en búfer una dirección de memoria cargada de registro de un dispositivo I2C!" Y entonces eso hubiera estado bien. Las respuestas que muestran cuán complicada es la realidad fortalecen mi argumento con mi gerente
Es una parte crítica de su trabajo como ingeniero cuestionar. Su hipotético motor I2C de función fija no habría estado remotamente "bien", ya que aún deja sin abordar el mayor riesgo de la gran falta de confiabilidad del tacto. Si no está preparado para decir "no" y alejarse, no está en condiciones de hacer este tipo de trabajo.
Bueno, ahora realmente estamos fuera de tema, y ​​no tengo el representante para moverme al chat.
No estamos ni remotamente fuera de tema. De hecho, estamos en el tema más importante posible . Todo lo demás es secundario a ser responsable en sus esfuerzos.
Ok amigo, la próxima vez que vea si hay alternativas a un diseño que desconozco, ¿qué debo hacer? Me puse en contacto con proveedores, realicé mi búsqueda en Google e IEEE y, como último esfuerzo, pensé que podría publicar algo aquí en mi tiempo libre y ver si la gente creativa de Stack Exchange tenía alguna idea loca. ¿Cuál es el mejor camino para buscar alternativas de diseño?
Cuando el objetivo es sortear las normas de seguridad, debe decir "no" y no buscar esquivas inteligentes. Las alternativas son para problemas técnicos . Por el contrario, su pregunta equivale a "queremos hacer algo extremadamente irresponsable, pero el regulador lo está dificultando, por favor, ayuda".
Entendido. Gracias. Pero no sabría si hay una alternativa legítima o un 'esquivar' hasta que pregunte. Está claro ahora, gracias a las otras respuestas.
@Brandon Solo una nota al margen: si usted es el fabricante del dispositivo y está en el mundo IEC 62304, tenga en cuenta que todo el software se basa en la evaluación de riesgos, que necesitará de todos modos para un producto médico . El estándar no especifica qué es un riesgo aceptable, depende del fabricante determinarlo. Si la pantalla táctil no es crítica, entonces podría usar el software en Clase A y no tener tantos dolores de cabeza.

Respuestas (5)

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 lógica programable como un CPLD pequeño para implementar la interfaz I2C y tener una actividad de bus de seguimiento de máquina de estado para capturar los datos que desea.

  2. Como el n. ° 1, pero use un chip dedicado como el PCA8584 (I2C a puente paralelo) para hacer el trabajo pesado para el protocolo I2C y haga que un CPLD maneje el monitoreo de actividad de nivel superior. Este chip tiene un modo snoop en el que se garantiza que no conducirá nada en el bus I2C y lo monitoreará de forma no destructiva.

  3. Utilice un microcontrolador con un modo snoop I2C similar, como el LPC1769. Sin embargo, no sé si tener esta funcionalidad implementada en el hardware (en el chip) le permitiría eludir las regulaciones sobre el software, ya que un error de software podría sacarlo del modo snoop e introducir un tráfico I2C erróneo. Así que 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 serán SDA, SCL, CLK4094, RST4094. Los datos 4094 se conectan a SDA. El flujo de bits que lee su Azotec se almacena en la memoria flash y el contador 4060 registra su salida en un ciclo sin fin. Cuando se leen los datos de Azotec, los registra en el 4094. El flujo de bits necesitará de 20 a 30 bytes por byte I2C, aproximadamente ~ 256 bytes.

(La lógica mixta Silego greenpak + la memoria SPI podría ser una solución de 2 chips).

Lo más probable es que el producto Azotec en sí sea algo con firmware interno, como la mayoría de los dispositivos esclavos I2C complejos, por lo que su idea subyacente se vuelve algo discutible.

Una casa a mitad de camino es usar un pequeño micro exactamente como el eprom+counter, pero en lugar de leer y escribir mediante programación, simplemente descargas en serie un flujo de bits de control que hace lo que quieres. El microprograma se convierte en un simple ciclo de volcado, quizás de solo 20 palabras. Se puede implementar con una complejidad ciclomática de 1 usando un registro de desplazamiento de LED externo o 2 (quizás 1) cuando se manejan los LED desde el micro, y se puede demostrar formalmente que es correcto. El flujo de bits es una secuencia almacenada invariable sin bifurcaciones, por lo que se puede demostrar que es correcta mediante pruebas exhaustivas de la única secuencia posible.

Nuestro producto BL233C es capaz de ser un redirector I2C independiente para hacer lo que desee, leer un sensor I2C, procesarlo mínimamente y escribir en otro dispositivo de visualización I2C.

Por supuesto, también tiene firmware subyacente, pero al igual que el sensor, puede parecerle a un revisor como un chip confiable (bueno, lo es, por supuesto), 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, mejor depurados que los que tendría su propio programa cuando se implementó inicialmente.

¡Ay, me gusta esto! Dispositivo interesante.

cuando introduces 'software' en un diseño

Software: Un programa interpretado por un procesador.

Lo que necesitas es lo siguiente:

  • consulta el registro a través de I²C (el sensor no "dice" por sí mismo. Tiene que ser preguntado), lo que significa enviar la misma secuencia de señales a través del bus I²C
  • cambiar el 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: es un flujo programático y, con solo escribir las especificaciones de lo que desea, determinamos que es un programa. Tendrás que lidiar con el software, pase lo que pase.

Si, por ejemplo, implementaste lo siguiente:

  • enviar secuencia en SDA y SCL
  • cambie a SDA de muestreo cuando cambie SCL
  • 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, ha construido un procesador muy específico de la aplicación que ejecuta un programa de cuatro pasos.

Es realmente el punto donde dices que este es un trabajo para un microcontrolador. Y realmente, ¿qué piensas, cuántos núcleos de procesador hay en ese panel táctil? Supongo 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.

Una operación secuencial implementada con hardware no se considera software.
Ese es un buen punto. Honestamente, todo esto surge de las interpretaciones muy diferentes de lo que es 'hardware' frente a lo que es 'software', particularmente en el mundo de los dispositivos médicos dirigidos por ISO. Todo es bastante gris (algunas personas han tenido máquinas de estado implementadas con FPGA interpretadas como hardware, mientras que otras las han interpretado como software debido a lo que ha creado ese código), solo estoy explorando mis opciones
@Brandon, siguiendo esta lógica, "... como software debido a lo que ha creado ese código" , cada IC de hardware es "software", porque el diseño de todos los pasos de lógica/máscaras/fabricación duros se realiza mediante el uso de grandes paquetes de software.
Sí, es tonto. no es mi regla
@Brandon, supongo que la distinción/preocupación podría ser si el "microcódigo" grabado puede ser manipulado o alterado externamente. Esta podría ser una preocupación válida. Entonces, un controlador de máquina de estado hecho de memoria programada de máscara personalizada única podría ser una solución.
Eso tiene sentido para mí. Lo interpreté casi como un problema de trazabilidad. Puede ejecutar todas las entradas posibles en un circuito digital simple y observar las salidas. Un FPGA implementa un circuito digital simple, por lo que debería poder hacer lo mismo, pero tal vez las puertas no utilizadas podrían causar un caso extremo extraño. Y luego, el software está un poco abstraído por encima de eso... Pero me gusta su punto sobre la manipulación externa
La demostrabilidad de la corrección es el tema central. (La manipulación es un tema aparte). Las máquinas de estado pueden ser improbables por la misma razón que lo es el software. La complejidad del estado es el problema. Ahora bien, esta tarea se puede realizar en secuencia directa, por lo que es probable que sea correcta si se realiza de esa manera. (incluso si usa un mcu para implementarlo)

La solución basada en hardware para su pequeña secuencia de control I2C se denomina "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 reprogramabilidad no autorizada es la principal preocupación, un FSM basado en ROM puede ser una solución.

No es verdad. Una configuración de FPGA es definitivamente "software" y, obviamente, cuando considera el alcance de la tarea de hacer que esto sea prácticamente utilizable.
Si considera que el meollo del asunto es la demostrabilidad, entonces los FPGA no son demostrables (debido a las capas ocultas del compilador). De la misma manera, se puede usar un microprocesador para implementar un sistema que tiene una complejidad ciclomática de 1, es decir, un único camino que no se ramifica, y por lo tanto se puede demostrar que es correcto.

La alternativa al "software" en un digital es una máquina de estado finito. Esto ha sido discutido aquí . Si realmente desea evitar tanto el software como el FSM, tendrá que volverse totalmente analógico (p. ej., LM3914 para controlar los LED).

Monitoreo I2C sin microcontrolador [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v