Mis experiencias con el BUS CAN

[MGLSOFT]

En el BUS CAN se utiliza normalmente este tipo de interconexión, Cryn.



Es un par retorcido.
También existen buses por fibra optica y por conexión inalámbrica....

[Cryn]

gracias por las respuestas. Es necesario si o si los tranceptores que mencionas? ya que por aca no existen a la venta, y pues tendria que esperar mucho tiempo, nose, se puede hacer algo sin tranceptores?

[MGLSOFT]

En realidad no se!!
Dejame averiguar...
Igual te recomiendo busques en la página de Texas y llenando una ficha de un desarrollo ellos te enviarán hasta 5 muestras de cada uno, los que yo pedí son muy buenos, formato DIP de 8 pines...

[MGLSOFT]

No, lo lamento...
Sin los transceiver solo tienes una comunicación serial entre ambos Nodos, no hay forma de determinar todos los temas de errores y deteccion de bit dominante o recesivo...



Solo queda probar entre ambos PIC conectados entre sí con los TXD de uno cableado al RXD del otro y viceversa.

Pierdes la posibilidad de manejar mas de dos nodos y es monopunto, pero no se pierde nada con intentarlo...
Probemos

Recomendaría que uses cristales de cuarzo de al menos 10 MHz en ambos Clocks, así no calculamos tu comunicación y sirven las adaptaciones que ya tengo hechas...
Si no dispones de dos cristales me dices que tienes y vemos...

[Cryn]

crees que manden muestras hasta mi pais?? ya que aca no mandan casi nada pero lo intentare

mmm, bueno no hay problema si se hace solo entre dos PIC's solo es para iniciarse, si puedo disponer de crisatales de 10MHz

gracias

[MGLSOFT]

El otro día dejé el ejemplo de código del Nodo A, usando un 18F4580.
Hoy quiero pegar aquí el código que uso en el Nodo B, que tiene un PIC16F876, conectado a través de un controlador CAN MCP2515...

El código:
Recordemos que el Nodo A envía un mensaje escribiendo el valor de los leds del Nodo B y otro mensaje (si se presiona una tecla en el Nodo A) solicitando al Nodo B la lectura de su convertidor A/D.
Cuando este recibe el primer mensaje, escribe los leds con los valores recibidos (agregué yo el envío de otro mensaje en devolución para escribir los tres leds del Nodo A, para probar el delay entre mensajes).
Cuando el Nodo B recibe el segundo mensaje, efectúa la conversión y envia el mensaje con el dato.

Ambos mensajes utilizan in ID diferente para enviarlo, de esa forma pueden ser consumidos por los Nodos que los necesiten...

Código: C

1. /////////////////////////////////////////////////////////////////////////
2. ////                         EX_CAN_CCS_B.C                          ////
3. ////                                                                 ////
4. //// Example of CCS's MCP2510 CAN library.  This example was tested  ////
5. //// using MCP250xxx CCS's CAN Prototype board.                      ////
6. ////                                                                 ////
7. //// This example provides the firmware for the B node in CCS's      ////
8. //// CAN prototyping board.  Node B responds to CAN ID 0x202         ////
9. //// by setting the 3 LEDs to the value transmitted by Node A.       ////
10. //// Node B also repsonds to requests from CAN ID 0x201 by           ////
11. //// transmitting an A/D reading.                                    ////
12. ////                                                                 ////
13. //// Using a serial port, this example also shows all traffic on the ////
14. //// CAN bus as received by the MCP2510.                             ////
15. ////                                                                 ////
16. //// For more documentation on the MPC2510 CAN library, see          ////
17. //// can-mcp2510.c                                                   ////
18. ////                                                                 ////
19. //// For more documentation on the CCS Can Prototype board see       ////
20. //// ex_can_ccs_a.c                                                  ////
21. ////                                                                 ////
22. ////  Jumpers:                                                       ////
23. ////     PCM,PCH    pin C7 to RS232 RX, pin C6 to RS232 TX           ////
24. ////                                                                 ////
25. ////  This example will work with the PCM compiler.                  ////
26. /////////////////////////////////////////////////////////////////////////
27. ////        (C) Copyright 1996,2003 Custom Computer Services         ////
28. //// This source code may only be used by licensed users of the CCS  ////
29. //// C compiler.  This source code may only be distributed to other  ////
30. //// licensed users of the CCS C compiler.  No other use,            ////
31. //// reproduction or distribution is permitted without written       ////
32. //// permission.  Derivative programs created using this software    ////
33. //// in object code form are not restricted in any way.              ////
34. /////////////////////////////////////////////////////////////////////////
35.  
36. #include <16F876.h>
37. #device ICD=TRUE
38. #device adc=8
39. #fuses HS,NOPROTECT,NOLVP,NOWDT
40.  
41. #use delay(clock=10000000)
42. #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
43.  
44. #define CAN_DO_DEBUG TRUE
45.  
46. #define Set_250K_Baud TRUE  /// Aqui configuro que velocidad del BUS utilizo
47. #include "can-mcp2510.c"
48.  
49. #define PIN_LED1  PIN_A1
50. #define PIN_LED2  PIN_A2
51. #define PIN_LED3  PIN_A3
52.  
53. #define LED1_LOW  output_low(PIN_LED1)
54. #define LED1_HIGH output_high(PIN_LED1)
55. #define LED2_LOW  output_low(PIN_LED2)
56. #define LED2_HIGH output_high(PIN_LED2)
57. #define LED3_LOW  output_low(PIN_LED3)
58. #define LED3_HIGH output_high(PIN_LED3)
59.  
60. #define BUTTON    PIN_E2
61.  
62. #define BUTTON_PRESSED  !input(BUTTON)
63.  
64. int16 ms;
65.  
66. #int_timer2
67. void isr_timer2(void) {
68.    ms++; //keep a running timer that increments every milli-second
69. }
70.  
71. #define RESPOND_TO_ID_AD   0x201
72. #define RESPOND_TO_ID_LED  0x202
73. #define Escribe_LEDs_A_ID  0x303
74.  
75. void main() {
76.    struct rx_stat rxstat;
77.    int32 rx_id;
78.    int buffer[8];
79.    int rx_len;
80.  
81.  
82.    int i;
83.  
84.    setup_port_a(RA0_ANALOG);
85.    setup_adc(ADC_CLOCK_INTERNAL);
86.    set_adc_channel(0);
87.  
88.    for(i=0;i<8;i++) {
89.       buffer[i]=0;
90.    }
91.  
92.    LED1_HIGH;
93.    LED2_HIGH;
94.    LED3_HIGH;
95.    printf("\r\n\r\nEJEMPLO CAN DE CCS\r\n");
96.    delay_ms(1000);
97.    LED1_LOW;
98.    LED2_LOW;
99.    LED3_LOW;
100.  
101.    setup_timer_2(T2_DIV_BY_16,53,3);
102.  
103.    can_init();
104.  
105.    enable_interrupts(INT_TIMER2);   //enable timer2 interrupt
106.    enable_interrupts(GLOBAL);       //enable all interrupts (else timer2 wont happen)
107.  
108.    printf("\r\nMarchando...");
109.  
110.    while(TRUE)
111.    {
112.  
113.       if ( can_kbhit() )   //if data is waiting in buffer...
114.       {
115.          if(can_getd(rx_id, &buffer[0], rx_len, rxstat)) { //...then get data from buffer
116.             if (rx_id == RESPOND_TO_ID_LED) {
117.                printf("Cambiando los LEDs\r\n\r\n");
118.                if (bit_test(buffer[0],0)) {LED1_HIGH;} else {LED1_LOW;}
119.                if (bit_test(buffer[0],1)) {LED2_HIGH;} else {LED2_LOW;}
120.                if (bit_test(buffer[0],2)) {LED3_HIGH;} else {LED3_LOW;}
121.  
122.                //change leds on port b
123.                printf("\r\n\r\nEnvía los valores al Nodo A");
124.                can_putd(Escribe_LEDs_A_ID, &buffer[0], 1, 1, 1, 0);
125.                //can_putd(Escribe_LEDs_A_ID, &buffer[1], 2, 1, 1, 0);
126.             }
127.             if (rx_id == RESPOND_TO_ID_AD) {
128.                i=read_adc();
129.                printf("Enviando lectura del conversor AD: %X\r\n\r\n",i);
130.                can_putd(RESPOND_TO_ID_AD, &i, 1,1,1,0); //put data on transmit buffer
131.             }
132.          }
133.       }
134.    }
135. }

[MGLSOFT]

crees que manden muestras hasta mi pais?? ya que aca no mandan casi nada pero lo intentare

mmm, bueno no hay problema si se hace solo entre dos PIC's solo es para iniciarse, si puedo disponer de crisatales de 10MHz

gracias

Así me gusta!!
A no desanimarse!!

Veamos esto, deberías darme por privado una cuenta donde enviarte un codigo inicial, de esa forma tu preparas ambos PICs y armas en un circuito ambos PICs conectandolos entre si como te escribi en el otro POST...

Una vez que estan ambos con su codigo y conectados deberias poder ver algo por sus puertos serie (en cada ejemplo, para hacer debug, deberan estar conectados), utilizando el Port Monitor de CCS.
 

[Nocturno]

Marcos, según Microchip todos estos micros tienen periférico CAN:
http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=50&mid=10&lang=en&pageId=74

¿sabes si con ellos nos podemos ahorrar los transceptores?, ¿conoces la diferencia entre bus CAN y ECAN?

[elreypic2]

Exelente trabajo MGLSOFT.

Antes que nada me disculpo porque no me fue posible recuperar la informacion que te habia mencionado con respecto al CAN.

Por otro lado, sino te molesta, contestare las preguntas de Nocturno.

Pregunta 1:
¿sabes si con ellos nos podemos ahorrar los transceptores?

Respuesta 1:
No, porque los micros solo contienen el engine de CAN, asi que el transceptor es necesario, es decir el MCP2551 o algun otro.

Pregunta 2:
¿conoces la diferencia entre bus CAN y ECAN?

Respuesta 2:
ECAN es la version extendida del CAN. La diferencia radica en la longitud del identificador en el frame. Para CAN, la longitud del identificador es de 11 bits, en el caso de ECAN es de 23 bits.

Saludos y perdon si me entrometo, pero al menos quiero ayudar en algo. Y nuevamente Felicidades, un excelente tema.

Elreypic.

[MGLSOFT]

Marcos, según Microchip todos estos micros tienen periférico CAN:
http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=50&mid=10&lang=en&pageId=74

¿sabes si con ellos nos podemos ahorrar los transceptores?, ¿conoces la diferencia entre bus CAN y ECAN?

No conozco ningun micro de marca alguna que implemente al transceptor dentro del micro.
La razon es que ese transceptor es elemento de sacrificio ante brutalidades como que el BUS sea expuesto a tensiones o descargas que provoquen su destrucción, imaginate que si estuvieran incorporados al micro, en ese caso deberías cambiar el micro completo, mientras que de esta forma cambias el transceptor y asunto solucionado (luego de haber localizado la causa de la falla).
Por otro lado por las características del BUS CAN, se busca que aún en circunstancias de falla, cada componente tenga la mayor autonomía y control posibles, por lo tanto en transceptor incorporado tampoco cumple con ese precepto.
Se entiende??

Respecto a las diferencias entre BUS CAN y ECAN, creo que la nota de Microchip es mas explicativa de lo que yo sería, ademas no quiero pecar de sabelotodo, por eso prometo investigar y luego contestaré con más idea al respecto. 
La Nota

Aquí algo de las diferencias, remarco en azul las mas importantes:

CAN INTERFACE CHARACTERISTICS
• Implementation of the CAN protocols: CAN 1.2, CAN 2.0A and CAN 2.0B
• Standard and extended data frames
• 0-8 bytes data length
• Programmable bit rate up to 1 Mbit/sec
• Support for remote frames
• Double-buffered receiver with two prioritized received message storage buffers
• Six full (standard/extended identifier) acceptance filters; two associated with the high priority receive buffer and four associated with the low priority receive buffer
• Two full acceptance filter masks, one each associated with the high and low priority receive buffers
• Three transmit buffers with application specified prioritization and abort capability
• Programmable wake-up functionality with integrated low-pass filter
• Programmable Loopback mode supports self-test operation
• Signaling via interrupt capabilities for all CAN receiver and transmitter error states
• Programmable clock source
• Programmable link to timer module for time-stamping and network synchronization
• Low-power Sleep mode

ECAN INTERFACE CHARACTERISTICS
• Implementation of the CAN protocols: CAN 1.2, CAN 2.0A and CAN 2.0B
• DeviceNet™ data bytes filter support
• Standard and Extended data frames
• 0-8 bytes data length
• Programmable bit rate up to 1 Mbit/sec
• Fully backward compatible with PIC18XX8 CAN module
• Three modes of operation:
- Mode 0 – Legacy mode
- Mode 1 – Enhanced Legacy mode with DeviceNet support
- Mode 2 – FIFO mode with DeviceNet support
• Support for remote frames with automated handling
• Double-buffered receiver with two prioritized received message storage buffers
• Six buffers programmable as RX and TX message buffers
• 16 full (standard/extended identifier) acceptance filters that can be linked to one of four masks
• Two full acceptance filter masks that can be assigned to any filter
• One full acceptance filter that can be used as either an acceptance filter or acceptance filter mask
• Three dedicated transmit buffers with application specified prioritization and abort capability
• Programmable wake-up functionality with integrated low-pass filter
• Programmable Loopback mode supports self-test operation
• Signaling via interrupt capabilities for all CAN receiver and transmitter error states
• Programmable clock source
• Programmable link to timer module for time-stamping and network synchronization
• Low-power Sleep mode

[MGLSOFT]

ECAN es la version extendida del CAN. La diferencia radica en la longitud del identificador en el frame. Para CAN, la longitud del identificador es de 11 bits, en el caso de ECAN es de 23 bits.

Hola Elreypic.
Corrijo dos errores en tu respuesta:
Uno es que ambos, tanto CAN como ECAN, soportan tramas estandar y extendidas.
La trama Estandar usa identificadores de 11 bits , mientras la trama Extendida usa identificadores de 29 bits.

ECAN significa Expanded CAN, o CAN Expandido, y la diferencia fundamental es que esta preparado para ser usado dentro de una capa de protocolo de mas nivel como DeviceNet o CanOpen.

Disculpa la aclaración, pero prefiero hacerla a confundir a los que lean el hilo, ya es un tema confuso de por sí, preferiría no agregar confusión.

[Cryn]

sabes en qeu consisten cada unos de esos tres modos??

• Three modes of operation:
- Mode 0 – Legacy mode
- Mode 1 – Enhanced Legacy mode with DeviceNet support
- Mode 2 – FIFO mode with DeviceNet support

estan disponibles en el 18f4685, verdad?

crees que pueda trabajar con ellos??

[MGLSOFT]

No se bien de que se tratan, pero si leí un POST de otro forista que protesta porque las librerias de CCS no los soportan (lease: no tienen código que soporte la utilización de estos modos), por lo tanto hay que ponerse a trabajar para hacer ese codigo...

[MGLSOFT]

Para hacer DEBUG del BUS CAN hay herramientas que permiten conectarse directo al BUS y realizar varios tipos de evaluaciones, todas las herramientas que conozco son PAGAS...

Una de las prioridades que me fije al crear este hilo fué que pudieramos todos  usar herramientas  gratis para hacer los ejercicios y las experiencias, por lo tanto busqué la forma de hacer Debug en forma económica también...

La gente de CCS tiene entre sus herramientas un software llamado SIOW, que al principio venía junto con el software pero había que llamarlo desde fuera del IDE y hace ya muchas versiones esta integrado al IDE.
Esta es la herramienta que, en conjunto con un set de instrucciones que propone CCS en sus mismas librerías, utilizaré (y los invito a hacer lo mismo, para hacer Debug de nuestros ejemplos...

Una vista de SIOW y de la pantalla para configurar la velocidad, puerto, etcetera...
Si miran la pantalla de mensajes, verán los mensajes que salen del puerto serie del PIC cada vez que emite un mensaje CAN...

[luscho]

saludos marcos:
        esto esta muy pero muy bueno y avanzas a pasos agigantados, si no te seguimos todos los días, pues no perdemos, muy buena explicación, muy buenos gráficos, aunque yo aun voy en el inicio je, je, je
                                 
                         sigue adelante..........