Estoy investigando si el bus CAN funcionará para los proyectos que estoy construyendo en este momento.
Quiero crear un grupo de controladores de entrada / salida que acepten los comandos / buffer, los ejecuten y luego informen el progreso. Mi sensación es que una configuración de maestro y esclavo no funcionará mejor para el proyecto, pero no estoy seguro de si el bus CAN funciona con ese principio.
Un bus CAN es multi-maestro y automáticamente libre de arbitraje. El punto es que no necesita un solo controlador principal o principal para ocuparse de todo. Cada mensaje que se envía tiene una prioridad, y los mensajes de mayor prioridad superan a los de menor prioridad (un mensaje de menor prioridad esperará hasta que no se envíe un mensaje de alta prioridad). Así que no hay esclavos. Es algo similar a una red de igual a igual, ya que está descentralizada. La razón por la que se hace esto es para reducir los puntos de falla. Si un solo controlador principal fallara, también lo haría toda la red. Si no hay un controlador central, un solo componente puede fallar y el resto del sistema seguirá funcionando.
Para su red, debe asignar prioridades a cada comando enviado según lo que sea más importante. El artículo de Wikipedia es bastante bueno: enlace
CAN solo tiene masters. Un nodo transmite a la vez: si varios nodos son una transmisión aproximadamente al mismo tiempo, chocarán y el nodo que transmita la ID más baja ganará el arbitraje. Los otros nodos escucharán el mensaje del nodo ganador y luego, después de un tiempo de inactividad, volverán a intentar sus propias transmisiones.
Y, por supuesto, no hay nada que le impida crear algún tipo de protocolo maestro / esclavo además del movimiento de mensajes de bajo nivel que CAN le proporciona.
CAN es un protocolo de bajo nivel, en algún lugar alrededor de la capa de enlace de datos del modelo OSI (capa 2) . Por lo tanto, solo se refiere a la transferencia de marcos de datos genéricos. CAN no especifica una topología de red, ni cómo se pasan los datos, ni la naturaleza de los datos, etc., etc.
Entonces, CAN no es un protocolo maestro / esclavo por la misma razón que UART no lo es.
Además de los marcos de protocolo CAN estándar, necesita capas más altas que definan la comunicación. Los más comunes para CAN son:
Estos funcionan de maneras completamente diferentes.
CANopen, por ejemplo, no define un maestro en lo que respecta al tráfico de datos. La comunicación de datos entre nodos en el bus es solo una preocupación de los nodos involucrados: no hay tráfico de datos de dirección maestra y cada nodo puede configurarse para hablar / escuchar a cualquier otro nodo.
Pero CANopen define un maestro "administrador de red", que está a cargo de supervisar los nodos en el bus: asegurarse de que comiencen correctamente y permanezcan activos y funcionales, etc.
Lea otras preguntas en las etiquetas communication can