¿Bus serie simple direccionable para distancias medias utilizando microcontroladores PIC?

CAN es definitivamente el camino a seguir. Hay muchos PIC que tienen un periférico CAN incorporado. La interfaz eléctrica y hasta la capa de paquetes, incluida la generación y comprobación de la suma de comprobación, está integrada en el hardware. El hardware también maneja la detección de colisiones y el reintento de transmisión. A 20 metros debería poder ejecutar el bus CAN a 1 Mbit / s, pero si la velocidad no es una prioridad, puede hacerlo con bastante seguridad a 500 kbits / s.

RS-485 es muy anticuado y te hace hacer mucho más en firmware. La especificación RS-485 solo le informa los niveles de señalización y le deja el resto a usted. Puede usar el hardware de UART para al menos enviar y recibir bytes completos, pero aún necesita hardware externo para cambiar explícitamente cada nodo entre transmisión y recepción, y luego un firmware que sepa cuándo cambiar. CAN puede parecer intimidante la primera vez que lee sobre el periférico en la hoja de datos, pero después de escribir todas las capas de protocolo para una interfaz de comunicación de múltiples nodos robusta , habrá gastado mucho más esfuerzo que usar CAN. Con CAN, usted envía y recibe paquetes completos que contienen una ID de 11 o 29 bits y hasta 8 bytes de datos. El hardware se encarga de enviarlos y recibirlos a nivel de paquetes, y no tiene que preocuparse por quién envía cuándo, maestro o esclavo, etc.

No escuches a las personas que se atascaron en la década de 1990 y siguen usando RS-485. Hay una mejor manera, y ha existido por un tiempo. Debe tener en cuenta que muchos de los protocolos principales que fueron RS-485 en el pleistoceno ahora tienen versiones más nuevas que usan CAN. Estos incluyen buses de comunicación automotriz y a bordo.

RS-485 es bastante bueno. Requiere chips de conductor separados, pero el uso de dichos chips ayudará a proteger al PIC de cualquier maldad eléctrica en el autobús.

Si va a haber un solo maestro, sugeriría que los dispositivos esclavos se codifiquen de manera tal que esencialmente nunca hablen, excepto en respuesta inmediata a una transmisión del maestro. Si el maestro puede solicitar una operación que podría tomar un tiempo, se debe dividir en dos comandos: "Comenzar a hacer XX" y "Diga si ha terminado". Diseñar protocolos de esta manera minimiza la complejidad de las interacciones de tiempo entre el maestro y los esclavos. El maestro debe tener una lógica de tiempo de espera para el escenario en el que trata de hablar con un esclavo, pero no obtiene respuesta, pero los esclavos no necesitan una lógica de tiempo de espera (excepto quizás para una función de vigilancia de maestro). Si el maestro envía con éxito algo al esclavo, pero la respuesta del esclavo se ve engullida por algún fallo eléctrico aleatorio, el maestro, sin escuchar la respuesta del esclavo, repetirá su solicitud; El esclavo, al oír la retransmisión, reenviará su respuesta. Desde la perspectiva del esclavo, el acuse de recibo puede inferirse por la falta de una solicitud de retransmisión del maestro.