Autor Tema: Mis experiencias con el BUS CAN  (Leído 601914 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7841
Re: Mis experiencias con el BUS CAN
« Respuesta #75 en: 18 de Noviembre de 2007, 18:27:31 »
Explico que hace este programa, sección por sección.

Atención de mensajes de otros Nodos.
En esta zona del código se leen los mensajes en el BUS CAN y se comparan con los ID para saber si es alguno de los que se estan esperando.

Código: C
  1.       if ( can_kbhit() )
  2.       {
  3.          printf("\r\n");
  4.          if(can_getd(rx_id, &buffer[0], rx_len, rxstat)) {
  5.             if (rx_id == ASK_FOR_ID_AD_B) {
  6.                printf("Channel B AD: %X\r\n",buffer[0]);
  7.             }
  8.             else if (rx_id == RESPOND_TO_LED_C_ID) {  //node C is an mcp250x0 which sends out a message upon edge detection on IO
  9.                printf("Chaning LEDs\r\n");            //in_data[0]=iointfl, in_data[1]=gpio
  10.                a_leds=~(buffer[1]);
  11.                if (bit_test(a_leds,4)) {LED1_HIGH;} else {LED1_LOW;}
  12.                if (bit_test(a_leds,5)) {LED2_HIGH;} else {LED2_LOW;}
  13.                if (bit_test(a_leds,6)) {LED3_HIGH;} else {LED3_LOW;}
  14.             }
  15.          }
  16.       }

En el ejemplo veremos que el Nodo A oficia de Master en este Bus (recordemos que el bus puede ser multi Master) y espera el dato del conversor A/D del Nodo B (variable de 8 Bits) y tambien espera leer el estado de tres pulsadores del Nodo C.
Este ultimo nodo tiene un MCP25050 que es un expansor I/O con CAN.
Cuando recibe el dato, transmite el valor del conversor A/D del Nodo B por el puerto serie (ya modificado por mi para mostrarlo en display en mis prácticas) y representa el estado de los pulsadores (dato que proviene del Nodo C) en tres leds del Nodo A.
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7841
Re: Mis experiencias con el BUS CAN
« Respuesta #76 en: 18 de Noviembre de 2007, 18:35:05 »
Segunda sección del código, el envío a otros nodos.
Esta parte del código se encarga de escribir datos en el Nodo D, que es otro MCP25050 con un display de 7 segmentos conectado), y de solicitar el dato del conversor A/D al Nodo B, que es un PIC16F876 con un MCP2515.

Código: C
  1.       if (BUTTON_PRESSED) {
  2.          while (BUTTON_PRESSED) {}
  3.          delay_ms(200);
  4.  
  5.          //ask for AD on port B
  6.          printf("\r\n\r\nAsking for A/D reading on Port B...");
  7.          can_putd(ASK_FOR_ID_AD_B, 0, 1, 1, 1, 1);
  8.  
  9.          //change LEDs on port C
  10.          buffer[0]=0x1E;            //addr of gplat on 25050
  11.          buffer[1]=0x0E;            //mask
  12.          buffer[2]=~(c_leds << 1);  //new gplat values
  13.          printf("\r\nIncrementing LED on Port C");
  14.          can_putd(WRITE_REGISTER_C_ID, &buffer[0], 3, 1, 1, 0);
  15.          c_leds++;
  16.          if (c_leds > 7) {c_leds=0;}
  17.       }
  18.  
  19.          //change lcd segment on port d
  20.          i=read_adc();
  21.          curr_lcd_output=i/26;   //scale to 0-9
  22.          if (curr_lcd_output != last_lcd_output) {
  23.             last_lcd_output=curr_lcd_output;
  24.             printf("\r\nChanging 8-seg LCD on D to current A/D reading (%X, %X)",i,curr_lcd_output);
  25.             buffer[0]=0x1E;                    //addr of gplat
  26.             buffer[1]=0x7F;             //mask
  27.             buffer[2]=lcd_seg[curr_lcd_output];                //new gplat values
  28.             can_putd(WRITE_REGISTER_D_ID, &buffer[0], 3, 1, 1, 0);
  29.          }
  30.    }
  31.  

Ademas incrementa la cuenta de leds en el Nodo C, en los leds conectados a ese nodo.
Olvide decir que este codigo solo se ejecuta con intervención del usuario, ya que debe presionar un pulsador para obtener esta funcionalidad... :mrgreen:
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado stk500

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 4854
Re: Mis experiencias con el BUS CAN
« Respuesta #77 en: 18 de Noviembre de 2007, 18:36:49 »
 :-/ adelante marcos :-/

muchas suerte  :-/ :-/

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7841
Re: Mis experiencias con el BUS CAN
« Respuesta #78 en: 18 de Noviembre de 2007, 18:38:53 »
Ultima sección, escritura de los leds del Nodo B.

Esta sección del codigo se ejecuta solo si el Bus no esta ocupado y cuando se cumplieron 2 segundos.

Código: C
  1.       if ( can_tbe() && (ms > 2000))       //every two seconds, send new data if transmit buffer is empty
  2.       {
  3.          ms=0;
  4.  
  5.          //change leds on port b
  6.          printf("\r\n\r\nSet LEDs on Port B to %U",b_leds);
  7.          can_putd(SET_LED_ID_B, &b_leds, 1, 1, 1, 0);
  8.          b_leds++;
  9.          if (b_leds > 7) {b_leds=0;}
  10.       }
  11.  

Como verán este solo ejemplo muestra la interactividad del BUS, donde todos los nodos pueden leer o escribir datos desde o hacia otro Nodo del BUS. :mrgreen:
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado LABmouse

  • Moderador Local
  • DsPIC30
  • *****
  • Mensajes: 3574
    • Juntos es mejor
Re: Mis experiencias con el BUS CAN
« Respuesta #79 en: 18 de Noviembre de 2007, 20:54:55 »
Amigo Marcos... Este hilo es estupendo, déjame le pongo su debida Chincheta por la importancia para todos!!

SALUDOS y ABRAZOS AMIGO!!!

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 17670
    • MicroPIC
Re: Mis experiencias con el BUS CAN
« Respuesta #80 en: 19 de Noviembre de 2007, 03:17:15 »
Marcos, ¿podrías explicar el significado de los parámetros en estas funciones?

can_getd(rx_id, &buffer[0], rx_len, rxstat);
can_putd(SET_LED_ID_B, &b_leds, 1, 1, 1, 0);

Gracias guapetón  :D
Un saludo desde Sevilla, España.
Visita MicroPIC                                                                                        ɔ!doɹɔ!ɯ ɐʇ!s!ʌ

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7841
Re: Mis experiencias con el BUS CAN
« Respuesta #81 en: 19 de Noviembre de 2007, 08:45:49 »
Marcos, ¿podrías explicar el significado de los parámetros en estas funciones?

can_getd(rx_id, &buffer[0], rx_len, rxstat);
can_putd(SET_LED_ID_B, &b_leds, 1, 1, 1, 0);

Gracias guapetón  :D
Como no, Maestro Manolo!!
Pongo los encabezados de las funciones, y los explicamos un poco...
Código: C
  1. ////////////////////////////////////////////////////////////////////////
  2. //
  3. // can_getd()
  4. //
  5. // Gets data from a receive buffer, if the data exists
  6. //
  7. //    Parameters:
  8. //      id - ID who sent message
  9. //      data - pointer to array of data
  10. //      len - length of received data
  11. //      stat - structure holding some information (such as which buffer
  12. //             recieved it, ext or standard, etc)
  13. //
  14. //    Returns:
  15. //      Function call returns a TRUE if there was data in a RX buffer, FALSE
  16. //      if there was none.
  17. //
  18. ////////////////////////////////////////////////////////////////////////
  19. int1 can_getd(int32 & id, int * data, int & len, struct rx_stat & stat)

Creo que es bastante explicativo, pero veamos los parametros que estamos enviando:
rx_id, como lo pide la función, indica la ID (numero hexadecimal) que identifica en forma unívoca el Nodo en el BUS.
&buffer[0], es el puntero a los datos entrantes, cuya cantidad es indicada por el siguiente parametro.
rx_len, es la cantidad de datos a recibir, cada mensaje permite enviar hasta 8 bytes.
rxstat, indica que tipo de mensaje es enviado, si usa mensaje estandar (11 bits) o extendido (29bits)

Ahora veamos la funcion Can_putd()

Código: C
  1. ////////////////////////////////////////////////////////////////////////
  2. //
  3. // can_putd()
  4. //
  5. // Puts data on a transmit buffer, at which time the CAN peripheral will
  6. // send when the CAN bus becomes available.
  7. //
  8. //    Paramaters:
  9. //       id - ID to transmit data as
  10. //          enumerated as - RXB0ID,RXB1ID,B0ID,B1ID,B2ID,B3ID,B4ID,B5ID
  11. //       data - pointer to data to send
  12. //       len - length of data to send
  13. //       priority - priority of message.  The higher the number, the
  14. //                  sooner the CAN peripheral will send the message.
  15. //                  Numbers 0 through 3 are valid.
  16. //       ext - TRUE to use an extended ID, FALSE if not
  17. //       rtr - TRUE to set the RTR (request) bit in the ID, false if NOT
  18. //
  19. //    Returns:
  20. //       If successful, it will return TRUE
  21. //       If un-successful, will return FALSE
  22. //
  23. ////////////////////////////////////////////////////////////////////////
  24. int1 can_putd(int32 id, int * data, int len, int priority, int1 ext, int1 rtr) {

en el uso de esta función en el ejemplo se usan estos parametros:
SET_LED_ID_B, si miran el codigo, es una constante que contiene la ID del Nodo
&b_leds, es el puntero a los datos que se van a enviar.
1, indica que se enviara un solo byte, en este caso envía el estado de los leds.
1, le dice al BUS que tipo de prioridad llevara este mensaje, para que el BUS lo maneje con mayor o menor prioridad.
1, un uno aqui indica al BUS que el mensaje es extendido (29 bits)
0, no usa el bit RTR (esto da para un tratado, lo dejamos para otra explicación)

Bueno, espero haya mejorado el entendimiento, por favor pidan explicaciones sobre lo que no entiendan.... :mrgreen:
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 17670
    • MicroPIC
Re: Mis experiencias con el BUS CAN
« Respuesta #82 en: 19 de Noviembre de 2007, 08:53:53 »
Claro como el agua
Un saludo desde Sevilla, España.
Visita MicroPIC                                                                                        ɔ!doɹɔ!ɯ ɐʇ!s!ʌ

Desconectado Cryn

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 4169
Re: Mis experiencias con el BUS CAN
« Respuesta #83 en: 19 de Noviembre de 2007, 18:02:25 »
Nose si es muy tarde la pregunta pero, esque estoy interesado en el tema, ya que debo hacer una aplicacion sencilla entre 2 o 3 micros que usen en BUS CAN, y esto que veo talvez sea mas trabajado, y como menciono solo quisiera iniciarme con algo sencillo, tengo a la disposicion 3 micros 18f4685, y pues del CAN nunca sape nada, jeje, hasta ahora, y si no fuera molestia me explican mas o menos en que consiste?? es como el I2C?

bueno disculpen si interfiero, un saludo, muchas gracias por la ayuda
.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7841
Como funciona el BUS CAN ? De que se trata ??
« Respuesta #84 en: 19 de Noviembre de 2007, 20:52:52 »
Que significa CAN ??

CAN (Controller Area Network)  
CAN es un protocolo de comunicaciones desarrollado por la firma alemana Robert Bosch GmbH, basado en una topología bus para la transmisión de mensajes en ambientes distribuidos, además ofrece una solución a la gestión de la comunicación entre múltiples unidades centrales de proceso.

Este bus de comunicaciones es ampliamente utilizado dentro de automóviles de alta gama (al principio, pero hoy se implementa en la mayoría de la gama media también), y su éxito lo ha trasladado a maquinaria pesada y también a la industria.

El protocolo de comunicaciones CAN proporciona los siguientes beneficios:

Es un protocolo de comunicaciones normalizado, con lo que se simplifica y economiza la tarea de comunicar subsistemas de diferentes fabricantes sobre una red común o bus.
El procesador anfitrión (host) delega la carga de comunicaciones a un periférico inteligente, por lo tanto el procesador anfitrión dispone de mayor tiempo para ejecutar sus propias tareas.
Al ser una red multiplexada, reduce considerablemente el cableado y elimina las conexiones punto a punto.
Para simplificar aun más la electrónica del coche se puede utilizar una subred más simple, que se conecta a la red CAN, llamada LIN.


 Principales características de CAN
CAN se basa en el modelo productor/consumidor, el cual es un concepto, o paradigma de comunicaciones de datos, que describe una relación entre un productor y uno o más consumidores.
CAN es un protocolo orientado a mensajes, es decir la información que se va a intercambiar se descompone en mensajes, a los cuales se les asigna un identificador y se encapsulan en tramas para su transmisión.
Cada mensaje tiene un identificador único dentro de la red, con el cual los nodos deciden aceptar o no dicho mensaje.

Dentro de sus principales características se encuentran:

  • Prioridad de mensajes.
  • Garantía de tiempos de latencia.
  • Flexibilidad en la configuración.
  • Recepción por multidifusión (multicast) con sincronización de tiempos.
  • Sistema robusto en cuanto a consistencia de datos.
  • Sistema multimaestro.
  • Detección y señalización de errores.
  • Retransmisión automática de tramas erróneas
  • Distinción entre errores temporales y fallas permanentes de los nodos de la red, y desconexión autónoma de nodos defectuosos.


CAN fue desarrollado, inicialmente para aplicaciones en los automóviles y por lo tanto la plataforma del protocolo es resultado de las necesidades existentes en el área de la automoción.
La Organización Internacional para la Estandarización (ISO, International Organization for Standarization) define dos tipos de redes CAN: una red de alta velocidad (hasta 1 Mbps), bajo el estándar ISO 11898-2, destinada para controlar el motor e interconectar la unidades de control electrónico (ECU); y una red de baja velocidad tolerante a fallos (menor o igual a 125 Kbps), bajo el estándar ISO 11519-2/ISO 11898-3, dedicada a la comunicación de los dispositivos electrónicos internos de un automóvil como son control de puertas, techo corredizo, luces y asientos.


Protocolo de comunicaciones CAN
CAN es un protocolo de comunicaciones serie que soporta control distribuido en tiempo real con un alto nivel de seguridad y multiplexación.

El establecimiento de una red CAN para interconectar los dispositivos electrónicos internos de un vehículo tiene la finalidad de sustituir o eliminar el cableado.
Las ECUs, sensores, sistemas antideslizantes, etc. se conectan mediante una red CAN a velocidades de transferencia de datos de hasta 1 Mbps.

De acuerdo al modelo de referencia OSI (Open Systems Interconnection), la arquitectura de protocolos CAN incluye tres capas: física, de enlace de datos y aplicación, además de una capa especial para gestión y control del nodo llamada capa de supervisor.

Capa física: define los aspectos del medio físico para la transmisión de datos entre nodos de una red CAN, los más importantes son niveles de señal, representación, sincronización y tiempos en los que los bits se transfieren al bus. La especificación del protocolo CAN no define una capa física, sin embargo, los estándares ISO 11898 establecen las características que deben cumplir las aplicaciones para la transferencia en alta y baja velocidad.

Capa de enlace de datos: define las tareas independientes del método de acceso al medio, además debido a que una red CAN brinda soporte para procesamiento en tiempo real a todos los sistemas que la integran, el intercambio de mensajes que demanda dicho procesamiento requiere de un sistema de transmisión a frecuencias altas y retrasos mínimos.
En redes multimaestro, la técnica de acceso al medio es muy importante ya que todo nodo activo tiene los derechos para controlar la red y acaparar los recursos.
Por lo tanto la capa de enlace de datos define el método de acceso al medio así como los tipos de tramas para el envío de mensajes
Cuando un nodo necesita enviar información a través de una red CAN, puede ocurrir que varios nodos intenten transmitir simultáneamente.
CAN resuelve lo anterior al asignar prioridades mediante el identificador de cada mensaje, donde dicha asignación se realiza durante el diseño del sistema en forma de números binarios y no puede modificarse dinámicamente.
El identificador con el menor número binario es el que tiene mayor prioridad.

El método de acceso al medio utilizado es el de Acceso Múltiple por Detección de Portadora, con Detección de Colisiones y Arbitraje por Prioridad de Mensaje (CSMA/CD+AMP, Carrier Sense Multiple Access with Collision Detection and Arbitration Message Priority).
De acuerdo con este método, los nodos en la red que necesitan transmitir información deben esperar a que el bus esté libre (detección de portadora); cuando se cumple esta condición, dichos nodos transmiten un bit de inicio (acceso múltiple).
Cada nodo lee el bus bit a bit durante la transmisión de la trama y comparan el valor transmitido con el valor recibido; mientras los valores sean idénticos, el nodo continúa con la transmisión; si se detecta una diferencia en los valores de los bits, se lleva a cabo el mecanismo de arbitraje.

CAN establece dos formatos de tramas de datos (data frame) que difieren en la longitud del campo del identificador, las tramas estándares (standard frame) con un identificador de 11 bits definidas en la especificación CAN 2.0A, y las tramas extendidas (extended frame) con un identificador de 29 bits definidas en la especificación CAN 2.0B.

Para la transmisión y control de mensajes CAN, se definen cuatro tipos de tramas: de datos, remota (remote frame), de error (error frame) y de sobrecarga (overload frame).
Las tramas remotas también se establecen en ambos formatos, estándar y extendido, y tanto las tramas de datos como las remotas se separan de tramas precedentes mediante espacios entre tramas (interframe space).

En cuanto a la detección y manejo de errores, un controlador CAN cuenta con la capacidad de detectar y manejar los errores que surjan en una red. Todo error detectado por un nodo, se notifica inmediatamente al resto de los nodos.

Capa de supervisor: La sustitución del cableado convencional por un sistema de bus serie presenta el problema de que un nodo defectuoso puede bloquear el funcionamiento del sistema completo.
Cada nodo activo transmite una bandera de error cuando detecta algún tipo de error y puede ocasionar que un nodo defectuoso pueda acaparar el medio físico.
Para eliminar este riesgo el protocolo CAN define un mecanismo autónomo para detectar y desconectar un nodo defectuoso del bus, dicho mecanismo se conoce como aislamiento de fallos.

Capa de aplicación: Existen diferentes estándares que definen la capa de aplicación; algunos son muy específicos y están relacionados con sus campos de aplicación.
Entre las capas de aplicación más utilizadas cabe mencionar CAL, CANopen, DeviceNet, SDS (Smart Distributed System), OSEK, CANKingdom.

Extraido de Wikipedia
« Última modificación: 19 de Noviembre de 2007, 20:57:06 por MGLSOFT »
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7841
Historia del BUS CAN
« Respuesta #85 en: 19 de Noviembre de 2007, 21:59:21 »
Antes del BUS CAN, una instalación interna de un vehículo tenía este formato:



Ya con la aparición del BUS CAN se adopta esta arquitectura...



Aquí vemos las particularidades del BUS...





Como se distribuyen Nodos en el BUS...

Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7841
Logica del BUS CAN
« Respuesta #86 en: 19 de Noviembre de 2007, 22:08:25 »




Como es el arbitraje cuando hay dos nodos transmitiendo a la vez...



Control a traves de bit stuffing (1 de 5)...





Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7841
Tramas del BUS CAN
« Respuesta #87 en: 19 de Noviembre de 2007, 22:15:15 »












Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7841
Tipos de Errores del BUS
« Respuesta #88 en: 19 de Noviembre de 2007, 22:18:19 »







Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7841
Protocolo CAN extendido
« Respuesta #89 en: 19 de Noviembre de 2007, 22:20:43 »






Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.


 

anything