Intercambio de datos por cable de 5 metros

Tengo un microcontrolador que necesita comunicarse a través de un cable, que será de aprox. 5m de largo, con otro microcontrolador muy pequeño. Los dispositivos se utilizarán al aire libre en diversas condiciones. La tasa de datos no será muy alta. Cuando conecta el uC pequeño con el cable al uC grande, se envía una cadena de identificación y actualizaciones de batería periódicas (cada minuto) desde el uC pequeño.

Pensé en I2C pero no estoy seguro de si está diseñado para tales necesidades. CAN también es posible, pero creo que es un poco exagerado para mis necesidades. ¿Alguien tiene buenas ideas?

EDITAR: quiero usar la menor cantidad posible de pines para el cable.

Preferiría RS422 o RS485 personalmente.
@Majenko Quiero usar la menor cantidad posible de pines para los cables.
Half-duplex RS-485 requiere un mínimo de solo dos cables, aunque se recomienda una conexión a tierra común.
(1) Estoy de acuerdo en que I2C no fue diseñado para tal caso de uso. Es bueno que estés prestando atención a esas cosas desde el principio. Menos posibilidades de que termines como ese tipo . (2) Redacción sobre RS-485 desde la perspectiva de Arduino . (nota estilística) Los acrónimos aceptados para microcontrolador son uC, o MCU (unidad de microcontrolador) o μC (elegante). MC podría significar megacontrolador.
Alternativamente, dado que esta es solo una red de dos dispositivos de menos de 50 pies, el buen RS-232 funciona bien y requiere solo tres cables para dúplex completo (TX, RX y tierra).
@PeterK se me adelantó, pero RS232 suena como una buena opción para esto, 2 pines de datos + terreno común es lo mejor que puede obtener para dúplex completo sin agregar mucha complejidad a la electrónica de envío / recepción ( el dúplex completo de un solo cable podría lograrse con señalización filtrada por frecuencia de estilo rf, pero parecería realmente un desperdicio aquí)
@PeterK Muchas gracias por tu respuesta. ¡Comenzaré a leer sobre cómo probarlo con arduinos!
Suena como si fuera solo el pequeño uC el que está hablando. ¿Hay alguna necesidad de comunicación en la otra dirección, en absoluto? ¿O es estrictamente unidireccional? También estoy pensando en las condiciones externas que desea admitir y los costos y la disponibilidad y qué tan bien encajan las cosas con el software y el hardware periférico disponible en la uC. Las condiciones de contorno pueden abundar aquí. ¿Puede agregar más discusión sobre estas cosas, incluidas las condiciones externas y cómo se transportará y usará el cable en la práctica? La señalización RS-232 y RS-485 es obvia. Pero hay otras opciones en mente.
Si el pequeño está haciendo actualizaciones periódicas, entonces puede hacer rs232 de un solo lado. TX y Gnd solamente. Dicho esto, ¿has pensado en bluetooth? 15 pies es fácil.
Bluetooth sería la menor cantidad de pines posible. 0.
@jonk sí, por el momento, el gran microcontrolador solo escucha, pero tal vez en el futuro quiera integrar la comunicación bidireccional. El cable tiene que ser muy robusto porque se transportará en bolsas y carros. también será en terreno muy accidentado. estará en uso diario en la nieve y la lluvia, pero también en los calurosos días de verano.
Entonces. ¿Qué opinas de usar coaxial? Es un material bastante robusto e incluso puedes obtener material blindado, si es necesario. Puede realizar transferencias bidireccionales a través de un cable compartido. Pero eso ya lo sabes de I2C, supongo. Sin embargo, principalmente estoy pensando aquí en una señalización robusta. A prueba de balas. (CAN es así, pero como dijiste, puede ser excesivo. Pero joder, puedes hacer un cortocircuito de CAN contra la batería del automóvil y aún sobrevive. CAN es una buena medicina cuando quieres 'a prueba de balas').
@jonk, el bus CAN puede parecer un poco exagerado, pero también solo requeriría 2 pines y 3.3v, ¿verdad? Creo que también necesito un transceptor para mi arduino.
Creo que CAN viene en variedades de 3.3V y 5V y las variedades de 5V que he visto vienen con un riel separado permitido para que funcionen bien con 3.3V uC incluso cuando se usa señalización de 5V. Por ejemplo, vea el Microchip MCP25625. Consulte también el artículo de TI "SLLA337" sobre CAN de 3,3 V.
@jonk muchas gracias! Probaré el bus CAN y también el MAX3232.
Supongo que realmente estoy pensando en el cableado y los conectores como el gran problema. Es posible que desee cosas muy fáciles de usar y que funcionen todo el tiempo. Estoy pensando en la línea de esos conectores XLR de micrófono de fuente de alimentación fantasma. Los tienen con y sin funciones de bloqueo y son bastante resistentes. También está disponible parte del cableado del micrófono. Solo un pensamiento. No tengo idea de cómo les iría afuera, pero los músicos deben hacer cosas cuando hace mal tiempo. Así que tal vez está bien.
Otro enfoque podría ser usar enchufes de cableado doméstico y cablear cables especiales usando un cable de enchufe de extensión exterior y conectores macho en ambos extremos. También hay elegantes conectores de bloqueo de 30 A para eso, y en variedades de 3 y 4 conductores. No demasiado caro. Disponible en Home Depot y Lowes. Bueno, ese es mi último pensamiento por ahora.
@jonk muchas gracias por tu ayuda! la idea xlr no es una mala idea. Echaré un vistazo a eso, pero puedo imaginar que el conector es realmente grande.
@perotom: grande es bueno cuando estás afuera con gente torpe que ayuda a conectar las cosas. También me gustan los conectores de bloqueo, para cosas como estas. Bueno, solo un pensamiento a considerar.

Respuestas (3)

Si bien CAN puede ser un poco "exagerado", siempre es preferible si tiene esa opción. Breve comparación entre CAN y RS232/RS422/RS485:

Puede ventajas:

  • Mucho más robusto y tolerante a EMI. Pero en términos de la tecnología en sí misma y en términos de protección integrada en un transceptor estándar.
  • Funcionará bien sin cables blindados a velocidades de transmisión más bajas.
  • Manejo de errores integrado, CRC y sincronización de tramas. Por lo tanto, no hay necesidad de inventar otro protocolo oscuro y personalizado basado en UART. Lo que significa que las CPU no tienen que perder el tiempo codificando/descodificando, calculando CRC, etc.
  • Fácil de mantener y fácil de rediseñar de punto a punto en un sistema de múltiples nodos, en caso de que surja la necesidad en el futuro.

PUEDE desventajas:

  • Realmente no es una opción sensata a menos que su MCU tenga un periférico CAN en el chip. Los controladores CAN externos son una carga y una cosa del pasado.
  • Puede tener un consumo de corriente ligeramente mayor que las soluciones basadas en UART.

El costo de los transceptores CAN en comparación con los transceptores RS-xxx debería ser aproximadamente el mismo (excepto si elige transceptores viejos como MAX232 que necesitan tapas de desacoplamiento de 5x 1uF). Los niveles de voltaje de la señal no importan, hay transceptores CAN y RS-xxx para 3.3V y 5V.

El número de hilos para un sistema semidúplex será de 3 en cualquier caso. En el caso de CAN, tienes CAN H, CAN L y tierra de señal. En el caso de, por ejemplo, RS-422, tiene T +, T- y señal de tierra. Saltarse la señal de tierra realmente no se recomienda para ninguno de los dos casos, no escuche a las personas que le dicen lo contrario.

Punto menor: " ... transceptores como MAX232 que necesitan tapas de desacoplamiento de 5x 1uF " . Las tapas son para que los duplicadores de voltaje generen (aproximadamente) +7 y -7 V desde el suministro de +5 V. ¿Hay algún problema conocido con el MAX232?
@Transistor MAX202 funciona igual de bien pero solo necesita 100nF. Lo mismo para la mayoría de las segundas fuentes llamadas algo-232. Tecnología jurásica versus tecnología cretácica... elige tu dinosaurio favorito.
@Lundin, así que creo que tomaré el autobús de lata. es quizás un poco más complicado de programar pero más versátil.
@perotom Es posible que desee verificar si la MCU dada tiene controladores prefabricados disponibles. Eso te ahorrará mucho trabajo.
@Lundin, creo que Arduino tiene algunos controladores prefabricados. ¡gracias!

También votaré por RS232, pero debes tener cuidado con una cosa que nadie más ha mencionado. No dice qué microcontroladores está usando, pero lo siguiente es cierto para la mayoría de los que he usado ...

Su microcontrolador tendrá al menos una línea de transmisión de datos (TX) y al menos una línea de recepción de datos (RX). Estas líneas alternarán entre bajo y alto a medida que transmite/recibe entre niveles de voltaje de 0 V y ~ 5 V o 0 V y 3,3 V, según el dispositivo. Suponiendo que ambos microcontroladores usen los mismos niveles de voltaje, entonces, en principio, podría conectar TX de un micro a RX del otro y viceversa. Esto funciona para distancias cortas y velocidades de datos bajas, pero creo que 5 m es demasiado largo para esto y también creo que es una mala práctica hacer esto entre sistemas.

Es mejor utilizar un convertidor de nivel (como la familia MAX232 para sistemas de 0-5V o el MAX3232 para sistemas de 0-3V) en cada extremo. Estos convierten el 0 lógico a ~+12 V y un 1 lógico a ~-12 V para que su línea de comunicaciones se ajuste eléctricamente al estándar RS232.

Espero que esto ayude,

José

El microcontrolador que uso actualmente es un STM32F205 ARM Cortex M3. Un problema más es que este dispositivo es un dispositivo móvil con solo una batería de 3.3v, por lo que no tiene fuente de alimentación de 12v.
No necesitas una fuente de alimentación de 12V. Los dispositivos que mencioné generan los niveles de voltaje requeridos internamente (también necesitará 4 condensadores; los valores dependen del dispositivo, así que mire la hoja de datos para esos). Solo asegúrese de usar la versión MAX3232 que puede funcionar correctamente con un suministro de 3,3 V, el MAX232 funciona con un suministro de 5 V. Debo agregar que otras compañías además de Maxim fabrican dispositivos similares.
¿Va a estar cableado con conectores? por ejemplo, RJ45 Las tierras intercaladas reducen la impedancia de la línea y mejoran la inmunidad. Si hay riesgo de bucles de tierra o ruido de modo común, un toroidal de ferrita con bucles de cable plano o pares trenzados alrededor mejora la inmunidad al ruido. Dado que RS485 tiene una impedancia mucho más baja y está balanceado, esto también mejora en gran medida la inmunidad al ruido de CM. Entonces puede considerar cables de alambre CAT comunes con enchufes para mayor comodidad.
RS-232 es bastante obsoleto para cualquier propósito hoy en día. La única ventaja de esa chatarra vieja es que puede usarla para comunicarse con PC viejas. Aparte de eso, nunca hay una razón para elegir RS-232 sobre RS-422. Ir con UART de nivel TTL puro ni siquiera es una opción fuera de una PCB, eso es completamente poco profesional e incluso I2C sería una opción mucho mejor entonces.

Ignorando la cuestión de las mejores alternativas (realmente no lo recomiendo, pero puede funcionar), he ejecutado con éxito largas distancias I2C (entre edificios) en producción y funcionó durante años.

  • Puede reducir la velocidad del reloj I2C hasta 10 kHz y colocar filtros adicionales en las líneas para filtrar la RF.
  • Muchos de los chips están perfectamente satisfechos con corrientes superiores a 1,5 mA, funcionan con 5, 10 o 20 mA, dependiendo de lo que puedan manejar sus chips.
  • Asegúrese de utilizar chips I2C (umbrales cmos schmitt) y no SMBUS (niveles ttl), ya que son mucho más propensos al ruido.
  • alimente la alimentación por los mismos cables, tenga una derivación adecuada.
  • cables de par trenzado/apantallados. http://www.i2cchip.com/i2c_connector.html#Crosstalk
  • use el interruptor de bus para aislar este segmento de las partes I2C locales
  • darse cuenta de que se esperan errores y diseñar software a su alrededor. (es decir, repita, por ejemplo, actualice su pantalla cada pocos segundos, en lugar de dejarla durante horas entre actualizaciones)
  • Tenga cuidado con el interbloqueo del bus I2C, que puede ocurrir por el ruido que inyecta un pulso de reloj adicional, y asegúrese de que su maestro lo detecte y lo solucione. (Apuesto a que el código de stock de arduino no lo hace)

Consulte la sección 19 Interbloqueo del bus I2C en http://www.i2cchip.com/pdfs/bl233_b.pdf