5 votos

¿Cómo programo 2 nodos CAN para transmitir continuamente en sucesión?

Supongamos que tengo tres nodos: a, B y C. se sabe que cuando dos nodos de transmitir al mismo tiempo, el nodo que tiene el menor SID prevalecerá sobre el autobús y el otro nodo tendrá que dar el autobús para el primer nodo. Lo que yo quiero hacer es que el nodo B y C envían continuamente PUEDE enmarcar a Un nodo de la sucesión (por ejemplo, el nodo B -> nodo, el nodo C -> nodo, el nodo B -> nodo). ¿Sólo se puede asignar una menor SID a B de C y acaba de hacer el siguiente fragmento de código?

El Nodo B

while(1) sendCANmsg(data, NODE_A, sizeof(data), RTR_OFF);

El Nodo C

while(1) sendCANmsg(data, NODE_A, sizeof(data), RTR_OFF);

Dentro de la sendCANmsg, aquí está el fragmento de código:

TXB0CONbits.TXREQ = 1;  // Request Message Transmission
while (TXB0CONbits.TXREQ); // Wait until message is sent.

Por cierto, estoy usando PIC18F25k80 en la aplicación de esta. Sólo estaba pensando que después de que el nodo B envía el mensaje, cuando el nodo C es aproximadamente de enviar su mensaje. El nodo B volverá a ganar el autobús de arbitraje dando así el nodo C no hay posibilidad de transmisión. Así que el remedio que sólo puedo pensar es la inserción de un pequeño retraso, como:

while(1) {
    sendCANmsg(data, NODE_A, sizeof(data), RTR_OFF);
    delay_us(10);
}

O estoy equivocado? :)

15voto

James Puntos 71

Puesto que este método trae el autobús cerca de un 100% de utilización, vamos a suponer que estos 3 nodos son los únicos en el autobús. Basado en el tiempo de retardo de 10 µs, vamos a suponer también que la velocidad de bus es 500kbps (es decir, 5 bits de retraso, o 1 poco corto de la post-arbitraje de espera entre los mensajes).

Si el método funciona o no, depende en gran medida de los detalles de la implementación de su poder controlador. Una manera más confiable para lograr esto sería tener el nodo B y C a la espera de leer cada uno de los otros del mensaje antes de enviarlo (con el nodo B inicialmente la transmisión sin espera). I. E.:

  1. Wakeup
  2. El nodo C, espera en el mensaje B
  3. El nodo B se transmite
  4. El nodo B, espera en el mensaje C
  5. El nodo C se transmite
  6. El nodo C, espera en el mensaje B
  7. Etc.

Para dar cuenta de la desincronización, cada período de espera debe tener un tiempo de espera, después de que el nodo transmite independientemente de si se recibe el otro nodo del mensaje.

Esto, incluso, la utilización del bus y salir de cada controlador capaz de realizar otras tareas mientras espera a que el mensaje (en lugar de continuamente tratando de transmitir en el caso de un arbitraje de la pérdida).

Tenga en cuenta que este es un uso no convencional de PUEDE. Usted puede ser mejor servido con un protocolo más simple, como el SPI (nodo tendría un sondeo B y C, pero no tendría que ser ningún arbitraje, y todo podría ser DMA y/o interrupción).

3voto

RelaXNow Puntos 1164

En primer lugar, los nodos no tienen Identificadores de los mensajes.

Esto es complicado, y no es lo que fue diseñado. Debería funcionar si cada nodo delibrately demoras un poco después de cada éxito de la transmisión. No recuerdo si el PIC 18F25K80 de hardware le permite saber cuando una trama se envía realmente, pero probablemente no. El otro nodo sólo se necesita una pequeña ventana para ver el final de la trama y empezar a transmitir. Una vez que este segundo nodo empieza a transmitir, el primero será el retraso de su mensaje, hasta la próxima final de la trama de forma automática de todos modos.

Sin embargo, esto suena como un abuso de la CAN bus, y una mejor respuesta podría ser que una re-pensar la arquitectura general.

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X