Prevención de la alimentación parasitaria de FT232RL por ATMega328P

Tengo una placa alimentada por batería con un ATMega328P y algunos otros periféricos como tarjeta SD, RTC, sensores, etc. El diseño de la placa es para tener la menor potencia posible, manteniendo el ATMega328P como MCU. La placa utiliza el cargador de arranque Arduino, etc.

Agregué un chip FT232RL USB a UART al diseño, para brindar mejores comunicaciones en serie que tener que tener un convertidor en serie externo. El FT232RL tiene una entrada de 5V desde el USB con un generador de 3.3V a bordo que conecté al suministro 3.3VIO que necesita. Entonces, el FT232RL se alimenta desde el USB cuando está conectado. El circuito de alimentación de la batería está separado. TX y RX están conectados al ATmega328P RX y TX.

ingrese la descripción de la imagen aquí

El problema es que cuando se desconecta la alimentación del FT232RL, el chip sigue consumiendo energía parásita a través de las líneas RX y TX del ATmega328P. Se usa otro pin ATmega328P para detectar TX desde el chip, por lo que el ATmega328P puede apagar la serie en cualquier momento. Incluso con la serie apagada y TX configurado en 0 V, y RX en la entrada, el FT232RL aún consume algo de energía de RX, más aún si los pull-ups están habilitados. Esto aumenta el consumo de energía.

Mi solución es (cuando no se detecta actividad en serie)

  • Deshabilitar puerto serie
  • Establecer TX a 0V
  • Establezca RX en la entrada y agregue una resistencia desplegable externa.

Sin embargo, esto parece un poco poco elegante. ¿Existe una solución de hardware que funcione? ¿Cualquier otra sugerencia?

Creo que la solución más "elegante" no es tener el FTDI a bordo, sino usar una placa de conexión FTDI para la conexión USB. Si desea lograr una potencia realmente baja, generalmente cuantos menos componentes, mejor.
¿Bajar Sleep y PWREN para cumplir con el consumo de corriente del modo de suspensión USB de 70 µA? Parece la mejor opción, a falta de puentes / interruptores DIP en RX y, opcionalmente, TX.
@RJR desde la perspectiva del usuario, es más fácil tener un cable USB genérico que una placa de conexión IMO. Además, el FTDI no está alimentado la mayor parte del tiempo (excepto cuando está conectado a USB o por la energía parásita), por lo que no hará ninguna diferencia en el consumo de corriente.
@Passerby Si mantengo RESET activo, no obtendré ningún byte RX cuando el usuario se conecte. PWREN es en realidad una salida.
¿Puedes usar un interruptor para desconectar las líneas? Incluso un interruptor eléctrico que se activa mediante el USB +5 funcionaría. O use uno de los ATMega más modernos con USB incorporado: el ATmega32u4 utilizado en el Arduino Leonardo sería la opción más obvia.
@RJR Podría usar un interruptor, pero me preocuparía que el usuario olvidara volver a cambiarlo. Investigué el ATmega32uX, pero en cantidades más grandes, uno debe comprar un bloque de ID de proveedor / dispositivo del grupo USB, a menos que me equivoque.
Cierto sobre la identificación del proveedor de USB. Sin embargo, si el hardware es 'FOSS' (código abierto), hay identificaciones de proveedores que puede usar de forma gratuita. Ver aquí por ejemplo.

Respuestas (1)

Puede colocar un par de optoacopladores entre el chip FTDI y la MCU de Atmel. De esa manera, no solo se desharía de la ruta de alimentación parásita, sino que la parte Atmel de su circuito (y todo lo que esté conectado a ella) también se separaría galvánicamente del host USB como beneficio adicional.

Incluso las resistencias en serie en RX, TX (p. ej., 1k) deberían reducir significativamente el consumo.
Optos suena bien, pero agrega un poco de costo a una placa que de otro modo sería barata (¿a menos que pueda sugerir alguna?).
@geometrikal: si le preocupa el precio, puede reemplazar su costoso FT232 con alguna variante más barata (CH341, por ejemplo), y por la diferencia de precio, podría colocar fácilmente cualquier circuito en el medio ...
Aparte de eso, no existe una solución simple y "elegante" con un precio de ~0. La solución con un precio de ~0 es la "poco elegante" que ya ha encontrado: detectar la alimentación USB y apagar completamente las líneas de E/S en serie.
@LaszloValko Hola, gracias por el consejo sobre una alternativa más barata.
Prevención de la alimentación parasitaria de FT232RL por ATMega328P
RespuestasAquíPolítica de privacidad1y, 0v