Interfaz de gran número de UART a PC

En primer lugar, esto se ha dicho antes, pero: UART no es una interfaz de sensor adecuada aquí. Elija un sensor diferente, si es posible. Asumiré que no es posible, de lo contrario no estarías haciendo todo este esfuerzo.

Personalmente, creo que la pregunta más importante no ha sido realmente respondida por usted:

• ¿Es este un sensor que consulta y responde, después, o
• ¿El sensor enviará datos continuamente?

El primer caso podría ser el más fácil, porque le permitiría tomar un UART y multiplexarlo entre múltiples sensores, lo que significa que conecta TX al primero, habla con él, luego se vuelve a conectar al segundo, y así sucesivamente. RX se compartiría entre todos los sensores del bus, pero debido a que es un sistema de consulta/respuesta, siempre sabrá quién está hablando en ese momento (el que le preguntó).

Si es el segundo caso, bueno: necesitará algo que administre cada uno de estos en un bus más flexible.

Personalmente:

• obtenga un microcontrolador económico que pueda hablar UART por un lado e I²C por el otro, uno para cada uno de sus sensores. Los tableros deben ser pequeños y la lista de materiales sería < $3, idealmente.
• Escriba un firmware que permita consultar el sensor a través de I²C. Eso significa transmitir cosas que el "controlador" envía a través de I²C al dispositivo y almacenar los datos que el dispositivo envía a través de UART el tiempo suficiente para que el maestro los solicite. No es un firmware muy complejo, pero todavía es un poco para escribir y depurar. Es probable que si haces esto en una plataforma popular (arduino, stm32), alguien más lo haya hecho antes.
• Asigne una dirección I²C separada a cada uno de sus traductores.

No hay un número infinito de direcciones ni un ancho de banda infinito, por lo tanto, agrupe una cantidad razonable de sensores a través de I²C en un bus cada uno. Utilice un microcontrolador compatible con USB de velocidad completa (12 Mb/s) para conectar todos sus traductores y transmitir los datos a su PC. Puedes tener varios de esos.

Además, puede haber UART listos para usar que podrían usarse a través de I²C como extensores de bus.

Otro pensamiento:

Hay microcontroladores que tienen controladores Ethernet incorporados. Solo necesita un Ethernet Phy (hay una interfaz estandarizada para eso, llamada MII). ethernet

• permite un número prácticamente arbitrario de dispositivos, y
• los cables de ethernet pueden ser largos,
• Los conmutadores ethernet cuestan < 2€/puerto
• Los conmutadores Ethernet pueden agregar una gran cantidad de enlaces lentos y fáciles de diseñar de 10 Mb/s a un enlace Ethernet de 100 Mb/s o gigabit,
• ethernet en realidad está destinado a autobuses enormes ,
• y es realmente fácil de conectar: ​​simplemente escriba el software de red para su PC (sin desarrollo de controladores de ninguna manera, solo maneje paquetes de red sin procesar),
• dependiendo de lo que ofrezcan los ejemplos de los fabricantes de su microcontrolador, obtendrá una pila de ethernet completa, que incluye cosas como la detección automática simplemente dejando que su firmware envíe periódicamente paquetes de transmisión "hey, estoy aquí".

Yo iría con esa solución. El ST STM32F107RC y microcontroladores similares vienen con dicha interfaz MII y hasta 5 USART. O elija el NXP LPC1830, que es significativamente más económico, pero solo tiene 4 UART.

Eso sería

• un LPC1830 6,17€, conectando cuatro sensores UART a la vez
• una RMII fast ethernet PHY 0,80€
• Conector Ethernet con imanes integrados 2,70€ (más barato si separas los imanes y el conector, pero puede que no valga la pena el esfuerzo de montaje adicional)
• Fuentes de alimentación, discretas 2€
• PCB fabricado en China 1,50€ (puede ser más barato si panelizas correctamente)

Firmware: código de ejemplo de Ethernet de NXP, manejo de UART escrito a mano

Hace un total de unos 13,50€ por 4 sensores, o unos 3,50€ por sensor. Necesita 25 de estos para conectar 100 sensores. Necesitas un conmutador ethernet gigabit de 24 puertos, más otro conmutador pequeño para el resto que añade unos 50€ a la factura (sin IVA).

El beneficio sería tener un sistema que pueda extender arbitrariamente. Si se siente aventurero, use una pila de IP en su microcontrolador (lwIP, µIP) y haga posible implementar sus dispositivos dentro de cualquier LAN, incluso a través de los límites de la red, como Internet, etc.

Editar : resulta que NXP envía ejemplos que hacen el baile completo de TCP/IP en la MCU. Oh, bueno, todo más simple entonces.

Buscaría usar un solo UART de un microcontrolador y multiplexarlo.

Si los dispositivos solo responden cuando se solicitan datos, entonces lógicamente puede O todas las líneas de recepción en el UART. Un multiplexor en la salida UART selecciona qué dispositivo recibe datos del micro.

Si todos los dispositivos envían constantemente sus datos, es posible que no necesite transmitirles líneas en absoluto. Tenga la línea de recepción en el único UART multiplexado. Se selecciona un dispositivo, el firmware espera para asegurarse de que esté sincronizado con el flujo de bytes, los datos capturados, el siguiente dispositivo seleccionado, etc.

Otra posibilidad más es colocar un pequeño micro en cada dispositivo y encadenarlos en lugar de la topología en estrella que está asumiendo ahora. Cada micro manejaría su dispositivo de forma privada. Se puede usar un esquema de paso de token para permitir que cada micro envíe sus datos al siguiente en la cadena, de lo contrario, pasa datos del anterior al siguiente. La PC está al final de la cadena y recopila todos los datos a través de un único puerto serie o USB.

Otra forma es similar a la anterior, pero use CAN para cada uno de los micros individuales para dejar escapar la información de su sensor periódicamente. La PC recibe todos los mensajes CAN a través de un adaptador USB a CAN.

Hay muchas formas, pero intentar configurar una PC con 100 puertos COM no es una de ellas.

Podría implementar una línea multipunto similar a RS485. Quizás deberías leer esto .

RS485 se utiliza en aplicaciones industriales de líneas muy largas y puede ser muy útil. Este artículo del EE-Times lo explica bastante bien.

Si desea simplicidad, puede implementar líneas de envío/recepción separadas y usar un protocolo de solicitud/respuesta muy simple.
La operación a 115 kbaudios debería ser posible, pero depende de la calidad de su cable de par trenzado y las distancias involucradas.

Si los sensores simplemente envían datos a una velocidad asíncrona, necesitará algún medio para acelerarlos y sincronizarlos.
Tú podrías:

1. Frontend los sensores con un pequeño micro (por ejemplo, un Arduino Pro mini) que acumula lecturas y simplemente almacena los datos en búfer o se acumula con marcas de tiempo si es necesario. El micro responde a un protocolo de solicitud/respuesta de software. La acumulación de resultados y el promedio podría reducir significativamente la cantidad de datos enviados.
2. Si sus sensores admiten DTS/RTS, entonces una interfaz RS485 implementada a través de un pequeño micro podría simplemente detener las lecturas. Esta vez utiliza el protocolo de solicitud/respuesta del software para detener el envío al sensor.

Podría considerar un sistema de conexión en cadena, algo como esto...

Cada uno de sus sensores contiene una entrada RS232 y una salida RS232, llamadas aquí rin y rout, y un microcontrolador económico con 256 bytes de RAM o más para un búfer en serie.

Cada sensor envía un mensaje de n bytes, que consta de una dirección de sensor de mensaje, una marca de tiempo (si es necesario) y la salida del sensor. Para facilitar la identificación de las posiciones de los mensajes, podría tener un '1' en el bit 7 del primer byte solamente, un '0' en el bit 7 de todos los bytes posteriores. Distribuya los bits de datos a través del bit 6..0 de los bytes del mensaje y el comienzo de un mensaje es fácil de encontrar para un receptor.

Cada sensor envía su propio mensaje en ruta. Cada sensor almacena en búfer todo el mensaje que recibe en rin, luego lo transmite en ruta cuando está libre para hacerlo.

El final de cada conexión en cadena de sensores entra en su PC. La PC ahora necesita solo un puerto RS232C por cadena de sensores.

(Las direcciones de los mensajes se pueden asignar automáticamente mediante un protocolo simple, pero dejaré los detalles por ahora. Avísame si quieres más sobre esto).

Otra idea es que cada sensor pueda tener dos entradas RS323C, rin1 y rin2, y transmitir mensajes de ambos en ruta, junto con su propio mensaje. De esta manera, las cadenas se pueden combinar fácilmente en una sola entrada y su PC necesita menos o más puertos RS232C según lo considere oportuno.

Esto supone que puede cambiar el diseño de su sensor, tiene una capacidad razonable con los microcontroladores y que su sistema puede tolerar el tráfico y los retrasos inherentes a esto. La marca de tiempo de sus lecturas se encarga de algo de eso, pero depende de si su aplicación host puede tolerar un ligero envejecimiento de las lecturas.

En el lado positivo, es simple, muy ampliable, facilita el cableado y es bastante rápido de implementar y probar.

La comunicación de múltiples nodos con múltiples sensores es una buena aplicación candidata para un sistema de bus CAN.

Si no puede evitar los sensores con una interfaz en serie, hay una serie de microcontroladores que incorporan controladores CAN y UART/USART. Busque en Digi-Key , Farnell , Mouser uno que se ajuste a sus necesidades. De lo contrario, vea I²C (o TWI), SPI u otros enlaces seriales de múltiples nodos (si los necesita) ya que UART/USART es solo una comunicación punto a punto, no adecuada para tal número de pares, como ya se mencionó.

Como ejemplo concreto, una búsqueda aproximada en Digi-Key informa que los microcontroladores más baratos son de Microchip, es decir, el ATmega16M1. Es una MCU automotriz con controladores CAN y UART integrados. También tiene un sensor de temperatura calibrado de fábrica, unidades ADC y DAC. Obtienes 100 unidades a alrededor de $1.5 cada una. CAN requiere un transceptor externo como ATA6560 de Atmel (~¢30 cada uno por 50 unidades), MCP2544 de Microchip (~¢60 cada uno por 50 unidades) o TJA1040 de Nxp (~$1 cada uno por 50 unidades). Todos son paquetes SMD de 8 pines y el lado bueno es que todos son compatibles con pines (casi). Si hay variaciones, se trata principalmente del pin 5, que algunos usan para alimentar la interfaz lógica, otros para proporcionar una referencia dividida (2,5 V) entre CANH y CANL.

El bus CAN proporciona robustez y extrema fiabilidad. Sus sensores solo tienen que transmitir sus datos periódicamente. Hay adaptadores CAN/USB disponibles para PC, como el analizador USB PCAN del sistema Peak ; está bien, este último está lejos de ser barato, pero entiende el punto: CAN es bastante generalizado y tiene herramientas disponibles para casi todas las plataformas.

Asegúrese de utilizar las herramientas de búsqueda paramétrica de los proveedores de componentes (Digi-Key, Mouser, Farnell) para ajustar su selección de microcontrolador y sensor. Si necesita sugerencias para la fabricación de PCB, consulte la respuesta de Marcus Müller .

En el lado del microcontrolador, todo lo que necesita es escribir cuándo enviar los datos de los sensores, ya que el hardware se encarga del resto (gestión de protocolos, detección de errores, arbitraje determinista, colisión, retransmisión...). CAN 2.0a proporciona 2048 mensajes posibles con identificadores de mensajes de 11 bits, lo que creo que debería ser suficiente para obtener datos de unos 100 sensores. De lo contrario, todavía tiene el formato de marco extendido CAN2.0b .

En el lado del software, hay bibliotecas de código abierto y/o gratuitas como OpenCAN o CANfestival si busca alguna solución estándar de la industria, como CANopen . También puede escribir su propio protocolo si lo desea.