Necesito proteger las líneas de datos de un microcontrolador PIC32 (SPI y paralelo) que se ejecuta a ~10 MHz, contra cortocircuitos a tierra/Vcc o cableado incorrecto.
Usualmente (a bajas velocidades) uso resistencias en serie para limitar la corriente y funcionó bien, pero por supuesto esto no funciona ahora debido a la velocidad.
Estoy pensando en usar el búfer/inversor de línea (algo así como 74LVC04), esto salvará la MCU pero el búfer se dañará.
Busqué muchas familias lógicas (ACT, HCT, LVC, etc.), pero ninguna proporciona protección contra cortocircuitos.
¿Hay una solución mejor?
Editar después de los comentarios: esta es una placa de desarrollo para pruebas y validación, debido a errores de codificación, los pines pueden configurarse incorrectamente. o mal cableado, conectando la salida de MCU a la salida de destino en lugar de a la entrada.
Edición n. ° 2: ¡Un PTC ( 0603L004 ) podría ser una solución, sin embargo, es lento!
Los controladores CMOS tienen un límite de corriente inherente establecido por la resistencia de encendido de la fuente de drenaje de los FET del controlador de salida, Rds (encendido). Puede deducir esto de la hoja de datos basada en Vo (h) y Vo (l) para una corriente de salida dada.
Como ejemplo, la hoja de datos del PIC32 enumera Vo(l) como 0,36 V a 6 mA, lo que corresponde a un Rds(on) de 60 ohmios. Eso es una especie de conductor débil. Cortarlo a 3,3 V daría 55 mA, que es más de lo que permite la hoja de datos (16 mA), un límite bastante ajustado. Dicho esto, un cortocircuito en un pin no necesariamente dañará la pieza.
El mayor problema a menudo es el daño por ESD. Las cosas que se salen de la placa pueden beneficiarse de diodos TVS adicionales para aumentar la robustez de ESD.
OK, con toda honestidad: entonces el propósito de la placa de desarrollo es aprender a evitar estos errores.
Las soluciones a este problema particular (necesidad de comunicaciones externas de alta velocidad resistentes a errores) generalmente implican la transición a un bus de largo alcance específico.
Su "problema" tiene una "solución" que haría que su problema original, hablando con los periféricos, sea mucho más complejo que ya no es realmente una "solución".
Si su periférico puede destruir su controlador, tenga cuidado de no conectarlo incorrectamente. Por lo general, eso no es realmente difícil, en comparación con otras trampas de ingeniería. Por ejemplo, diseñaría una placa adaptadora que tenga un lado claramente etiquetado como "señal" y un lado etiquetado como "salida" y, si es posible, dos conectores diferentes en cada uno. Problema resuelto.
Soy un ingeniero eléctrico. He trabajado en diseños basados en microprocesadores de muchos productos. Ocasionalmente he conectado mal las cosas (más veces de las que me gustaría admitir). Además, en algún momento tenemos que entregar nuestro hardware a los ingenieros de firmware y también conectan las cosas mal todo el tiempo. Nunca he visto un GPIO frito debido a un cortocircuito a VCC o GND u otra salida. Obviamente, no recomiendo hacerlo a propósito, pero lo he hecho más veces de las que puedo contar, y los ingenieros de FW también lo han hecho mal. No creo que deba preocuparse por eso a menos que vaya a exponer la salida a un voltaje mayor que VCC o menor que GND.
Lo único que he hecho en ocasiones es usar lógica externa para asegurarme de que el equipo de FW no pueda crear accidentalmente un "estado prohibido". (Como encender el lado alto y bajo de un puente simultáneamente para crear disparos).
El problema con los MCU modernos es el tamaño diminuto de los FET y las enormes tasas de aumento de la temperatura de calefacción local.
Recuerdo haber calculado dTemp/dTime de 1000 grados por microsegundo para esos (pequeños) FET, con muchos milivatios disipados en una o dos micras cuadradas, y la gran resistencia térmica de los cubos de silicio que tienen solo 1 micra por lado.
==================================
Para la protección contra sobretemperatura, cualquier sensor de temperatura debe estar dentro de las 10 micras del punto caliente. Si el punto caliente es un FET de salida submicrónica profundo, canal corto para un impulso alto, el FET puede autodestruirse antes de que se detecte una temperatura alta.
¿Solución práctica? A altas temperaturas, el FET se vuelve menos conductor. O detecte el exceso de temperatura y apague los FET (área costosa, para hacer eso).
Recuerdo historias de MCU de la era 1995 que se autodestruían cuando las salidas se acortaban.
Una forma de proteger es aislar galvánicamente el bus de la MCU mediante el uso de aisladores digitales, por ejemplo . Estos funcionan bien a altas velocidades y son más fiables que, por ejemplo, los optoacopladores. También hay piezas especializadas diseñadas específicamente para SPI, I2C, etc.
Aunque esta solución se usa principalmente cuando espera que el secundario sea ruidoso y desea evitar que EMI, sobretensiones, corrientes de tierra y otras cosas desagradables golpeen su MCU directamente.
Quizás pueda configurar primero como IO. Luego configuran la salida brevemente y leen el resultado. Si se encuentra en 0 cuando maneja un 1 o 1 cuando maneja un 0, rechace activar el SPI.
También soy EE, pero sobre todo escribo software. Estoy de acuerdo con uno de los comentaristas anteriores que dijo que debe proteger todo lo que sale de la placa de ESD. Entonces, los diodos TVS definitivamente deberían estar presentes. Si alguno de los pines en el conector tiene más de 5 V, también debe proteger sus otros pines de ese voltaje más alto.
marcus muller
marcus muller
carl gilberto
electrones
carl gilberto
electrones
TonyM