Ayuda para decidir entre RS485 o CAN [cerrado]

PROBLEMA

Estoy construyendo un tablero de control de robot para conectarlo a una Raspberry Pi como pasatiempo. Me gusta tener tableros especializados para varias funciones y estoy explorando soluciones para el bus de comunicación. En el pasado probé:

  • UART de 5V: problemas con el ruido
  • I2C: simplemente no funciona con ruido
  • Fibras ópticas de plástico POF: frescas pero caras y grandes
  • RS485 sobre cables de audio con conectores jack de 3,5 mm con protocolo personalizado: Funciona a las mil maravillas. Me gusta lo económicos que son los conectores y los cables.

A continuación, una imagen de referencia de uno de los robots que hice en el pasado usando un bus RS485 con protocolo personalizado sobre cables de audio con conector de 3,5 mm.

Placas de motor con bus RS485 mediante jacks de audio de 3,5 mm

A continuación, una imagen como referencia de mi última versión del sombrero de robot Raspberry Pi. Quiero agregar una pantalla y conectores para un bus de comunicación, agregar un mejor regulador de potencia y mover los controles del servo y del motor a las placas esclavas.

ingrese la descripción de la imagen aquí

IDEAS

Estoy pensando en implementar un bus CAN o un bus RS485 con un protocolo menos personalizado que tiene algún uso en el mercado.
Aquí un ejemplo de un esclavo que usa el bus CAN
Aquí un ejemplo de un esclavo que usa el bus RS485 con sus protocolos personalizados.

Especificaciones:

  • Tres cables (dos de datos + un blindaje), por lo que puedo usar cables de audio y conectores de 3,5 mm para mis esclavos
  • Quiero que el autobús sea menos personalizado, para poder adjuntarlo a los tableros adicionales existentes
  • Ancho de banda de 1 Mb/s
  • Resistente al ruido

PREGUNTA

Me gustaría sugerencias sobre qué bus usaría en esta aplicación, en particular si hay un bus que no he tenido en cuenta, sugerencias sobre un protocolo estándar sobre el bus RS485 o sus razones por las que elegiría un bus CAN. ¡Gracias por tus aportes!

SOLUCIÓN

No se utilizan protocolos dominantes con RS485 y CAN tiene una gran sobrecarga de tramas de datos.
Decidí implementar dos conectores Jack de 3,5 mm de 3 pines con un transceptor RS485 conectado a un AT4809 para el hardware. Sobre el bus RS485 reutilizaré mi protocolo maestro-esclavo personalizado.

A continuación un esquema y colocación inicial de componentes.Esquemas y Colocación Inicial

RS-485 solo requiere un transceptor en el rpi, CAN requiere un controlador sobre spi/i2c. Elija RS-485, va directamente en el encabezado gpio. Además, ambos buses aún requieren una tierra "común", por lo que, en teoría, un blindaje opcional de 3 cables. Sin embargo, esta es una pregunta más adecuada para un foro, como EEVblog.
Todavía puede usar CAN PHY y transmitir datos UART en él, no se requiere un controlador CAN a menos que sea necesario usar el protocolo CAN. De la misma manera, RS-485 no es necesariamente igual al protocolo UART, incluso si se usa normalmente con él.
Preguntaría por qué hay tanto ruido que todos los demás protocolos de comunicaciones no funcionan. Motores, claro, pero el efecto se puede reducir con amortiguadores y filtros. Y un buen filtrado y detección debería reducir el efecto del ruido en las líneas de señal de comunicaciones. De lo contrario, es posible que esté enmascarando un problema con comunicaciones de grado industrial, solo para que el ruido cause problemas en otros lugares.
Llegas tarde a la fiesta, pero una de las razones por las que tienes problemas con el ruido es que el cableado es horrible. Algunos conductos de cables donde los cables se mantienen alejados de la electrónica de potencia y de accionamiento del motor mejorarían mucho la EMC. Lo que tiene actualmente es básicamente unas 20 antenas de color amarillo que captan todas las EMI de las placas y los motores. Pero entonces no estoy seguro de qué tan bueno es Rasp Pi para aplicaciones intensivas de EMI en primer lugar (¿podría necesitar un filtro pi? har har...). Sin embargo, RS-485 o CAN es el camino correcto.

Respuestas (1)

Me temo que estás comparando manzanas con naranjas.

RS-485 es simplemente una forma de conducir un autobús. Toma su salida UART, la traduce a través de un transmisor RS-485, la recibe con un receptor y luego la alimenta al UART de destino. Pan comido.

CANBus es una propuesta mucho más complicada. Tienes que alimentar un controlador CAN con paquetes de datos. Luego, el controlador maneja el bus físico con un protocolo mucho más complicado para el receptor, y el receptor produce un paquete reconstruido. En efecto, los dos controladores reemplazarían sus UART.

En cuanto a la fiabilidad, CANBus es mejor. Toda la basura adicional que usa un CANBus se destina a dos cosas: seleccionar una de varias unidades que están todas conectadas al bus y detección y corrección de errores.

Cuando dice que quiere un ancho de banda de 1 Mb/s, nunca lo obtendrá de CANBus. Es cierto que puede conducir CANBus a 1 MHz, pero si envía 1 byte a la vez, solo obtendrá un efecto de 140 kb/s. Se necesitan 58 ciclos de reloj para enviar una trama CANBus de 1 byte. Es cierto que es posible conducir el bus a 5 MHz, pero eso solo te lleva a 700 kb/s efectivos.

Aunque, para ser justos, un UART impulsado a 1 MHz solo tendrá un rendimiento de 700 - 800 kb/s, dependiendo de la configuración de trama que elija, pero puede manejarlo más rápido que eso.

Consulte https://en.wikipedia.org/wiki/CAN_bus para obtener una descripción general.

También es normal que una sola fuente CANBus proporcione la alimentación de 5 voltios para todas las demás unidades. Esto significa que necesita 4 señales en su bus y un cable de audio no lo cortará.

Tu explicación es clara. No me gusta proporcionar energía junto con com porque sobrecarga el requisito de energía del maestro y los esclavos tienen requisitos de energía muy diferentes. Estaría bien si aproximadamente 1 MHz fuera la velocidad de señalización y no tuviera 1 Mb/s de ancho de banda efectivo (¡eso es mucha sobrecarga para CAN!)
Mi GD32VF103 tiene periféricos UART y CAN. ¿Recomendaría usar CAN o recomendaría un protocolo para usar en el RS485?
@05032MendicantBias: los 5 V del maestro CANBus solo se usan para controlar la parte del transceptor del controlador CANBus. Como resultado, el consumo de energía es directamente proporcional a la cantidad de transceptores conectados al bus.
@05032MendicantBias - Realmente no puedo hacer una recomendación. No sé tus métricas. Por ejemplo, ¿su periférico UART tiene capacidad RS485? Algunos lo hacen, otros no. Si no, ¿qué importancia tiene proporcionar la capa física? No obtendrá 1 Mbps de CANBus. ¿Cuánto necesitas realmente? Si supera los 140 kbs, CANBus no funciona a menos que pueda obtener una unidad de 5 Mbps. CANBus se especifica con un bus TWP de 120 ohmios: ¿qué tan cerca está esto de su cable de audio? Hay muchos otros problemas, pero simplemente no sé lo suficiente como para aconsejarte.
Ayuda para decidir entre RS485 o CAN [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v