Expansor UART (5 puertos a 11 puertos)

Tengo una placa que me gustaría diseñar y hay 11 dispositivos a los que solo se les puede hablar a través de UART . Estoy restringido a una gama de productos de chips uC de Microchip y he encontrado uno con 5 puertos UART. He ideado una solución basada en puentes en la que el usuario, al realizar la conexión a través de puentes a los 5 puertos disponibles, puede elegir 5 de los 11 dispositivos. He estado buscando un chip que admita UART, SPI o I2C y me brinde algunos puertos UART adicionales, pero me he quedado corto. ¿Alguien puede sugerir una solución o un producto que pueda haber encontrado?

No es crítico que los 11 dispositivos puedan conectarse al uC (eso sería bueno), pero es importante que estos dispositivos estén en la placa para un producto modular. Sin embargo, deseo que el producto sea más fácil de usar, ya que la solución basada en puentes es un poco complicada a primera vista, o eso me han dicho.

EDITAR

Bueno, lo siento, no estoy explicando el problema correctamente. Con este método, limitas las opciones del usuario. Digamos que vincula el puerto a al dispositivo 1 y 2 y el puerto b al dispositivo 3 y 4 y así sucesivamente...

Pero, ¿y si al usuario le gustaría usar el dispositivo uno y dos? Entonces el producto limita mucho al usuario. Con 5 opciones de puerto y 11 opciones para dispositivos, el coeficiente binomial produce 462 combinaciones para que el usuario elija. Eso es exagerado, no busco ese nivel. Pero con la solución basada en puentes, el puerto a puede conectarse a 9 de los dispositivos, mientras que el puerto b puede conectarse a 7 de los dispositivos, el puerto c puede conectarse a 8, el puerto d puede conectarse a 7 y el puerto e puede conectarse a 9. El número de los interruptores mux necesarios para hacer esto estarían por encima del límite.

¿Hay otra solución para darle al usuario la opción de usar (cerca de) cualquier combinación de los dispositivos?

Pensé en usar dos uC con 5 puertos UART cada uno para conectarme a 10 de los dispositivos y luego usar una solución basada en puentes mucho más pequeña para el último dispositivo, pero esta solución es demasiado complicada para la producción y costosa.

¿Hay algún chip o concepto que amplíe el control UART a 11 dispositivos?

Solíamos usar el viejo (StarTech) ST16C554 o ST68C554, creo. En mis tiempos. NXP puede estar haciéndolos ahora. Soportaron varias interfaces para el micro y proporcionaron cuatro puertos RS-232 adicionales. También fabricaron 552 dispositivos para dos puertos. Puedes mezclar y combinar para llegar a donde quieras. (Cada uno de ellos también incluía FIFO). ¿Personalmente? Agregaría más partes de PIC.
Siempre que todos los dispositivos UART remotos transmitan solo en respuesta a los comandos del host, ¿podría usar transceptores RS422/RS485? Luego, podría transportar todos los datos recibidos a un solo puerto UART en el host y solo habilitar la transmisión RS422/RS485 para un control remoto a la vez.
¿Por qué necesita usar simultáneamente cualquier combinación de UART al mismo tiempo? ¿Qué problema exactamente estás resolviendo con eso?
@Chupacabras no necesita usar simultáneamente ninguna combinación de UART, pero el sistema debe ser lo suficientemente modular para brindarle al usuario cualquiera de los 11 dispositivos en el tablero y, en este punto, puede usar 5 de ellos.
@GarethT. Entonces, ¿necesita comunicarse solo con 1 dispositivo UART a la vez? ¿No necesita comunicarse con varios dispositivos al mismo tiempo?

Respuestas (5)

Use algunos circuitos integrados de puente UART-SPI, como:

Puede tener tantos UART como pines GPIO de repuesto tenga para usar como líneas Chip-Select (o use un demux o decodificador y puede tener órdenes de magnitud más), limitado solo por la velocidad en baudios de su UART frente a la velocidad máxima que puede ejecutar su SPI.

Esto parece prometedor, investigaré cada uno de ellos. Gracias.
El SC16IS7xx está en el camino correcto con SPI o I2C a dos UART, es excelente, ya que necesitaría tres de ellos para hacer todo, pero desafortunadamente, el costo de uno solo de ellos es demasiado alto. Si hay un chip que pueda tomar SPI o I2C y dar 4 o 6 UART, estaría muy emocionado.
@GarethT. En este día, creo que ese sería otro de tus 5-UART PIC. Solo programalo, eso es todo.
@jonk Realmente he estado considerando esa opción, pero es un poco exagerada para la tarea y cuando las placas vienen a reparar y no es una solución fácil, siempre culpan al uC o al chip de memoria. Si hay dos de ellos en el siguiente lote de tableros, puedo ver el fin del mundo en sus ojos.
@GarethT. Seguro. Como dije, solíamos usar los dispositivos ST16C554 o ST68C554 (diferentes interfaces). Funcionaron bien para crear una gran cantidad de puertos de E/S asíncronos en serie. Pero sospecho que son bastante exclusivos, en estos días, porque ahora es más barato/más fácil y más potente y conveniente usar MCU. Pero hoy tampoco estoy en el negocio. Así que no puedo decirte qué hacen los demás cuando necesitan docenas de esos puertos. Pero tampoco veo ninguna respuesta de dispositivo multi-asincrónico realmente buena todavía. Así que tal vez esa es la forma de las cosas, ahora. ¿Qué opinas, viendo lo que has visto hasta ahora? (+1, por cierto.)
@jonk Lancé el SC16IS752; SC16IS762 a mi jefe y estaba interesado en el chip, pero para otros proyectos con menos requisitos de puerto UART. Gracias por tu ayuda en esto. Sí, parece que sería necesario el uso de dos PIC32 programables para lograr los resultados que queremos. Después de examinar el SC16IS752, veo que tiene RS485, ¿diría que este chip puede manejar todos los requisitos del protocolo RS485 (distancia)? Con eso quiero decir, ¿podría reemplazar la funcionalidad del SN75175A? No veo los controladores para SR485 en la hoja de datos del SC16IS752.
AFAIK, el soporte "RS485" en ese dispositivo es solo para administrar el control de dirección RX/TX en una línea semidúplex. No se incluyen controladores/receptores de línea y aún necesitaría un 75175/MAX485/lo que sea.

Puede usar circuitos integrados de interruptores analógicos (multiplexores analógicos) para reemplazar los puentes manuales.

Si tiene 5 puertos UART, puede multiplexar 1 de esos puertos a 8 puertos UART multiplexados. Necesita usar interruptores de 8 canales, como DG4051E .

Sí, ya lo he investigado, pero requiere una cantidad ridícula de Mux IC para reemplazar lo que he hecho con la solución basada en puente porque también existe la línea RTS, así como la línea TX y RX.
Entonces, necesita cambiar 3 líneas de señal y tiene 5 UART. No necesitas una cantidad ridícula de muxes. Todo lo que necesitas son 3 chips y tener uno de esos puertos UART multiplexados (por lo que tendrás 4 puertos UART + 8 multiplexados). Entonces 3 piezas. de multiplexores de 8 canales, como DG4051E (elegidos al azar).
Por favor vea la pregunta editada.
@GarethT. Ha cambiado drásticamente los requisitos en su pregunta. No mencionó que desea usar simultáneamente cualquier combinación de UART al mismo tiempo.
Sí, por eso me disculpé. Lo siento.

controlar un registro de desplazamiento SIPO (p. ej., 74hc595) desde 2 pines GPIO conectar la entrada ~OE a la salida UART

usando el reloj GPIO en un patrón que representa el dispositivo con el que desea hablar, luego use el UART para enviar

si hay un pull up en su lugar, el puerto con un bit cero hará eco de la salida UART.

para el extremo receptor, use una puerta/puertas para combinar la señal del dispositivo UARTS.

Creo que está utilizando el protocolo y/o la topología incorrectos para su caso. Sugeriría usar transceptores RS-485 y construir una topología de bus. Si tiene 11 dispositivos posibles, puede usar 4 líneas para habilitar uno de ellos.

Las advertencias que veo para esta opción son:

  • Comunicación semidúplex (sin Rx/Tx simultáneos)
  • Puede interactuar solo con un dispositivo a la vez (topología de bus)
  • Tu uC será como un maestro. Debe habilitar un dispositivo e iniciar la comunicación con él. (los transceptores están configurados para escribir o leer desde el bus)

No vi ningún detalle en sus preguntas sobre cómo estas limitaciones pueden afectar su sistema o si vale la pena. Espero que esto pueda ayudar.

En un diseño desde cero, seguro, aunque en la misma placa normalmente no se necesita RS485, todo se puede hacer de un solo extremo a nivel lógico utilizando las habilitaciones de salida de los UART. Pero parece bastante fuerte que las cosas con las que el autor de la pregunta quiere hablar ya son diseños fijos, por lo que cambiar su firmware para implementar un bus compartido direccionable probablemente no sea una opción.
No estoy hablando de direcciones, solo habilite líneas para cada transceptor. Esto implica menos cambios de firmware que probar un bus I2C; solo necesitará 1 uart en su host uC.
Si la MCU principal controla los transceptores, entonces esta es solo una forma incómoda de construir un multiplexor. Omita el diferencial, omita la preocupación de medio dúplex y simplemente siga las sugerencias existentes para construir un mux. El punto de RS485 real es que los dispositivos mismos escuchan su dirección y prestan atención a los siguientes datos o permiten que su transceptor responda después, y que la señalización es diferencial. Ninguno encaja realmente con su propuesta revisada para esta aplicación.
RS485 solo define una interfaz eléctrica, sin direccionamiento. Por esa razón, sugiero habilitar los transceptores desde el uC, ya que el direccionamiento implica firmware adicional. El único cambio que necesita es: en lugar de usar UART X para el dispositivo Y, habilite el transceptor Y y use UART1. Veo esta opción factible como dijo el OP: "Tengo una placa que me gustaría diseñar..."
Claro, pero persiste en ignorar el hecho obvio de que hacerlo de esa manera es inútilmente complejo y más restrictivo que usar los multiplexores que otros ya propusieron. Su esquema no ofrece ventajas sobre eso, y muchas desventajas en comparación con él. RS485 solo es útil cuando se usa para hacer cosas que no se aplicarían aquí.
Como puede leer en mi publicación, enumero 3 desventajas de usar esto, y solo una respuesta sugiere usar mux analógico y OP ya respondió. Las ventajas dependen de lo que sea valioso para usted: UART utilizados, pines utilizados, área de PCB, escalabilidad, modularidad, costo, esfuerzo de hardware o firmware, etc.
Exactamente ninguno de esos factores le da la ventaja a su idea demasiado compleja. Lo que estás describiendo es lógicamente un mux; pero la forma en que construye uno de manera eficiente es a partir de mux o chips de conmutación, no de controladores y receptores diferenciales.
Claro, lógicamente es un mux, y esa es la respuesta corta a la pregunta OP, necesita un mux. Y para un mux, las limitaciones son las mismas que describí. Creo que se podrían dar más ventajas y desventajas con detalles como si los dispositivos UART pueden iniciar una comunicación, si se agregarán más dispositivos, si se planea cambiar la topología, etc., ya que el OP no brinda estos detalles. Sin embargo, mi principal consejo es reconsiderar la topología si tiene algún control sobre cómo interactuar con los dispositivos y está en etapa de diseño.

Como alternativa, PSoC podría ayudarte

aquí hay un ejemplo con 11 UART en un PSoC 5lp

https://hackaday.io/project/11974-averaging-many-gpses/log/39157-11-serial-ports-with-psoc5

Solo una sugerencia, asegúrese de que su sistema pueda manejar los puertos seriales adicionales y los datos que deberán procesarse. No sé qué tan rápido o cuántos datos están pasando a través de estos y puede que estés bien.
Expansor UART (5 puertos a 11 puertos)
RespuestasAquíPolítica de privacidad1y, 1v