Encendido/apagado de corriente desde la línea USB Tx

Estoy haciendo un dispositivo que tendrá contacto con el agua, por lo que los componentes electrónicos están encapsulados en epoxi. Quiero tener la opción de reprogramar el microcontrolador, así que quiero agregar puntos de contacto a los que pueda conectar microlíneas USB. El problema es que, obviamente, no puedo tener fugas de corriente por esos puntos cuando no está conectado a un USB y está en el agua. Puedo detener el flujo inverso del vin usando un diodo, pero no puedo encontrar la manera de detener la corriente de la línea tx del micro.

También probé un diodo allí, pero cuando conecto la línea tx al USB, necesito que fluya corriente desde el micro. Probé un mosfet de canal n usando un pin de E / S para controlar la puerta y tenía la línea de transmisión dividida entre drenaje y fuente, pero no parecía funcionar del todo bien.

Idealmente, me gustaría que la puerta sea automática, donde se abre cuando se conecta/detecta el USB, pero también podría usar un pin de E/S para controlar una puerta porque el micro tiene Bluetooth. Los voltajes son bajos: 5v desde USB, micro es 3.3v.

¿Cómo evito que el USB pierda corriente cuando no está en uso?

Hay conectores a prueba de agua, y algunos incluso pueden funcionar con señales de tipo USB. La versión USB < 3.0no tiene una línea Tx dedicada.
¿Botón recubierto de goma que presiona para habilitar usb? ¿O hacer que el microcontrolador deshabilite los pines USB hasta que detecte que VIN sube?
Podría agregar un optoacoplador en esa línea. Alimentado desde el USB.
Si puede vivir a toda velocidad (no a alta velocidad), un transceptor aislado puede hacer el trabajo. linear.com/product/LTM2894
¿Por qué no puedes usar una solución de software? En algunos microcontroladores, puede configurar los pines USB como GPIOS generales y activar las resistencias desplegables. Puede ejecutar los 5V desde el USB al micro y detectar cuando el USB está enchufado. Cuando detecte 5V, habilite los puertos USB.
Primero, el USB no tiene ninguna línea "Tx". En segundo lugar, un dispositivo USB no debe perder nada, VBUS es una ENTRADA y D+/D- también son entradas y no deberían tener ningún potencial. Si tienen tirones cuando no hay entrada a VBUS, entonces el dispositivo USB está roto.
Supongo que el problema es que algunas MCU con interfaz USB están activando D+ (señal para conectar) independientemente de si se aplica el VBUS (es decir, está conectado a un host) o no. Este es exactamente uno de los casos por los que las especificaciones USB establecen explícitamente que si un dispositivo USB no está conectado a un host, no debería tener voltaje en la interfaz en ningún pin.
¿Reprogramar a través de Bluetooth?
Todas las buenas respuestas, gracias por las sugerencias. Ali, no sé por qué hay voltaje/corriente en la línea D+... Estoy de acuerdo en que es raro. Podría ser un mal diseño por parte del fabricante. También me pregunto si el diodo en el vin hace que piense que el USB está conectado por alguna razón. Lo probaré esta noche.
@ Kirkx060, re: por qué hay voltaje en D+. Lo se. Esta es una falta de respeto brutal para las especificaciones USB. La mayoría de los MCU baratos tienen este defecto de diseño, principalmente porque asumen que su IC se utilizará únicamente como dispositivo "alimentado por bus" (sin host VBUS, sin alimentación, sin D + pullup), y rara vez tienen batería interna.

Respuestas (2)

La mayoría de los microcontroladores con capacidad USB utilizan E/S de uso general para esta función, por lo que puede asignarlos como entradas y ponerles resistencias de extracción debilitantes. Al contrario de lo que se indicó anteriormente, sería preferible un pulldown a un pullup, ya que eso pondría las E/S al mismo potencial que la tierra, que presumiblemente también está expuesta. Tenerlos a un potencial diferente podría significar una pequeña ruta de fuga, lo que desperdiciaría energía y potencialmente promovería la corrosión electroquímica o el grabado por contacto. Incluso con contactos húmedos con el mismo potencial, debe asegurarse de que todos sean del mismo metal.

De manera similar, debe deshabilitar el pullup de detección de velocidad USB.

Sin embargo, se enfrenta a un problema más grave, ya que es extremadamente difícil obtener un sello impermeable de grado de inmersión real entre los cables y algún compuesto epoxi al azar. Si pela los cables primero, tiene que sellar perfectamente el metal con el epoxi, y si pasa el aislamiento, es probable que el agua migre entre el cable y su aislamiento.

Puede ser preferible algo como un conector debajo de una tapa roscada con una junta comprimida. O podría usar un gestor de arranque con algún tipo de interfaz serie inductiva o incluso óptica.

Pero, por supuesto, también debe resolver el problema de obtener energía sin fugas de humedad.

Verificaré esto, pero no sé si puedo controlar los pines USB en este. Es un ble de plumas de Adafruit. No me preocupa sellar los contactos... no está sujeto a ninguna presión, solo al contacto con el agua. Además, he usado este epoxi en el pasado para sellar juntas flexibles sujetas a mucha presión y nunca tuve ningún problema. El conector debajo de un perno con junta es mi plan de respaldo.
@Chris, ¿puede respaldar su afirmación de que "la mayoría de MCU" con interfaz USB implementan pines USB como GPIO? Mi experiencia es que la mayoría de MCU tienen un USB PHY dedicado y usan pines dedicados para D+ y D- que no son reconfigurables.
Trate de leer algunas hojas de datos... Me cuesta pensar en una MCU con una interfaz de alta velocidad que no admita GPIO en los pines USB, aunque estoy seguro de que existen en alguna parte. El "problema" al que parece estar insinuando es probablemente uno exclusivo de la física de alta velocidad USB, que es bastante poco común en las MCU (que generalmente no podrían hacer nada útil con tales velocidades de datos). USB de alta velocidad se encuentra más comúnmente en SoC que en MCU, aunque hay una pequeña cantidad de MCU con implementaciones de USB de alta velocidad diseñadas para mover datos hacia/desde otras interfaces en lugar del núcleo MCU de baja potencia.
Si sabe lo que se necesita para recibir la señalización USB incluso en FS, no estaría "luchando por pensar". Para recibir correctamente los datos seriales de FS, necesita un sobremuestreo de ~5X del patrón de bits de 83 ns de longitud, o un ciclo de 16 ns para la transferencia de bits a través de GPIO. Si alguna vez realizó una programación integrada en tiempo real, sabrá que un ciclo de programa con un ciclo de 16 ns no es posible en una MCU normal, siendo la Parallax Propeller (con 8 procesadores de 32 bits especialmente conectados en cascada) una excepción. Por lo tanto, le recomiendo encarecidamente que se retracte de sus declaraciones sobre el uso de GPIO para la interfaz USB FS.
Parece estar un poco confundido acerca de cómo funcionan las MCU ordinarias. La mención es del caso normal de MCU donde los pines que implementan USB se pueden usar alternativamente como GPIO. Eso no significa que el USB se implemente golpeando el puerto GPIO, solo que hay una selección de funciones entre los dos usos posibles (o más a menudo hoy en día, bastantes posibilidades para cada pin)

¿Por qué no usar Bluetooth? Puede ser UART en el interior, tan fácil de usar, fácil de sellar, compatible con cualquier dispositivo, definitivamente más barato y más fácil que cambiar los conectores USB o sellados.

Buena pregunta, pero no creo que pueda. Aunque lo investigaré un poco más.
Tome el módulo BT de ST o Murata o TI