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

0 Usuarios y 2 Visitantes están viendo este tema.

Desconectado herr_emanuelb

  • PIC10
  • *
  • Mensajes: 10
Re: Mis experiencias con el BUS CAN
« Respuesta #1005 en: 24 de Agosto de 2011, 11:32:17 »
MGLSOFT

Muchas gracias por su explicación. Voy a seguir tus consejos y intentar compilar estes ejemplos primero en MPLAB.
Mientras tanto, a respecto del FMS standard leí en algunos documentos que los IDs correctos son acrescidos de dos ceros (en hexadecimal) a su derecha.

Por ejemplo, el ID que identifica el cuentakilómetros 0x00FEC1 en verdad es 0x00FEC100, o que explica mis extrañas lecturas nel camión.

Desconectado handpic

  • Colaborador
  • PIC12
  • *****
  • Mensajes: 72
Re: Mis experiencias con el BUS CAN
« Respuesta #1006 en: 31 de Agosto de 2011, 11:20:12 »
Buenas a todos....

Como os comentaba, había intentado conectarme a un bus can con la tarjeta de ingenia. Al final lo he conseguido, pero directamente a la dirección que quería controlar y no en el coche, que parece no ser un bus can, sino otra norma ISO (peugeot 307)

He podido leer los siguientes datos que recibía de la dirección, aunque no se lo que significan:

0xC2 N 6 0x10 73FF7FFFFF

0xC2 N 6 0xF7 4FF7FFFFF

0xC2 N 6 0xE7 5FF7FFFFF

0x300 N 1 0x0

0xC2 N 6 0xD7 6FF7FFFFF

0xC2 N 6 0xC7 7FF7FFFFF

0x5E4 N 3 0xC0 1E00

algunos estan incompletos, porque el bus de datos (rs232/115000) se satura, pero las cabeceras  y el número de bytes de datos parece ser correcta, aunque no se lo que significan. si alguien quiere el archivo de datos leido completo os lo puedo pasar o subirlo (si me explicais como hacerlo).

Si he comprobado que 0xC2 parece indicar los grados y la velocidad de giro de la dirección o algo así, porque varía cuando la giro.
En un Bus CAN, los diferentes dispositivos han de inicializarse e identificarse??
¿alguien sabe como indicarle la velocidad a la dirección?
¿Me podéis aclarar como funciona la máscara y el filtro en CAN?(para torpes)

Saludos,

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7907
Re: Mis experiencias con el BUS CAN
« Respuesta #1007 en: 31 de Agosto de 2011, 11:36:47 »
Las mascaras te permiten recibir mensajes solamente de los ID que logran pasar el filtro que has realizado.
Es decir si quieres recibir mensajes con el id 0xC2, haces un filtro con esa mascara exacta y ya no recibirás ningún otro mensaje.
Lo que no se es si debes usar o no la mascara en forma de complemento, pero haz la prueba que no rompes nada. :mrgreen: :mrgreen:

Se usan en protocolos de mayor nivel para recibir en los esclavos solamente la mensajería que les compete, de ese modo con un cpu mas chico y atendiendo los mensajes compatibles con su función, el modulo trabaja mejor.

En los sniffer como predeterminado no se usan mascaras, porque la idea es que escuches todo lo que va y viene, pero si es tan rápido que no puedes recibir todo, entonces programas las mascaras para filtrar por tipos de mensajes, que normalmente tienen que ver con el rango de IDs que se asigna según el protocolo.
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado herr_emanuelb

  • PIC10
  • *
  • Mensajes: 10
Re: Mis experiencias con el BUS CAN
« Respuesta #1008 en: 31 de Agosto de 2011, 11:38:42 »
Handpic

Creo que sí, puede ser un bus CAN. Es que la especificación de CAN, define solo las capas (layers) más bajas del modelo de referencia OSI, que es constituido por 7 capas.

Las capas más superiores son definidas de acuerdo con la aplicación. Por ejemplo, yo estoy intentando leer datos de autobuses y camiones. He descubierto que las capas más superiores de la referencia OSI para autobuses y camiones son definidas por la norma SAE J1939, y los datos de algunos modelos dentro del J1939 siguen un standard llamado FMS Standard.
Procura informarte a respecto de que normas definen las capas más superiores para los autos de Peugeot, para poder interpretar los datos.

Para los filtros, creo que este trend, nel forum de Microchip te puede aclarar (en inglés).
http://www.microchip.com/forums/tm.aspx?m=456043&settheme=Mobile


Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7907
Re: Mis experiencias con el BUS CAN
« Respuesta #1009 en: 31 de Agosto de 2011, 11:51:46 »
Pongo la traduccion hecha por Google del post sugerido por herr_emanuelb  (muy buen aporte), tal como lo sugiere el traductor de Google:

Citar
Le sugiero que lea las siguientes observaciones al aire libre CAN2.0A / B spec en frente de usted, y una copia de la CAN dsPIC documento de referencia (de Microchip).

Dato importante 1: No creo que una identificación de la CAN es un "número". Se trata de un conjunto de bits que se utilizan para dar prioridad a un mensaje de CAN en un bus CAN.
Dato importante 2: No creo que una máscara de Rx es un "número", esto es sólo un conjunto de bits que activar o desactivar bits coincidentes en el filtro de Rx,
Hecho 3 Importante: No creo que un filtro de Rx es un "número", esto también es sólo un conjunto de bits que el motor pueda utilizará durante el proceso de recepción de mensajes.

(Ahora sería un buen momento para volver a leer los documentos CAN 2.0A / B y Microchip de Filtros y máscaras)

Para responder a tu pregunta (yo estoy usando ID ETS tratar de mantener las cosas simples) ...


    tengo la confusión en la máscara de ajuste y filtro de Identificación values.My mensaje por 7 nodos 1,2,3 ... 7

En primer lugar aplicar lo que ahora entendemos por CAN ID (ID recordar son sólo un conjunto de bits).
Tome su primera CAN mensaje de ID (1). En realidad, esta identificación se llega a enviar en el bus CAN como una serie de bits "00000000001", la CAN ID de mensaje (2) sea enviado como "00000000010".
Ok, por un nodo CAN para recibir correctamente los mensajes, el mensaje tiene que "pasar" de la CAN nodo Rx filtro.

Ejemplo 1:
Cómo establecer un nodo CAN Rx máscara y filtro para recibir sólo ID CAN 1 y CAN no ID 2?
Recuerde, pensar en la identidad como un poco a presentar (que lo es), y convertir el ID en binario (que hace las cosas fáciles si lo hace).
ID: 1 = 00000000001
ID: 2 = 00000000010

Ok, ahora (a partir de su lectura de la especificación CAN2.0A / B) se sabe que la máscara es como un interruptor para activar / desactivar el filtro de bits de Rx. Ya que es el filtro que hace el trabajo, lo primero que debe hacer es establecer el ámbito del filtro. Así que para su nodo puede recibir sólo CAN ID 1, usted quiere que su filtro para que coincida con este requisito.
FilterA = 00000000001

Ahora ponga la máscara para permitir que los bits del filtro que desea comprobar el ID de la CAN en contra. En nuestro caso, vamos a configurar la máscara para asegurarse de que el filtro sólo pasarán los marcos de la CAN con un ID de 1.
Máscara = 11111111111 (Todos los 1 significa que cada bit de la filterA Rx se utiliza para comprobar la entrada CAN marco de ID en contra.



Ejemplo 2:
Si desea configurar el filtro para recibir un número de (secuencial) CAN marco de ID, y luego todo lo que necesita hacer es configurar algunos de los bits de la máscara y filtro a 0.

Deseo recibir puede enmarcar 1,2 ID y 3, pero no quiero recibir CAN marco ID 4
Una vez más, siempre es mas fácil de descomponer la tarea en binario (hasta que entienda el proceso).
ID1 = 00000000001
ID2 = 00000000010
ID3 = 00000000011
ID 4 = 00000000100

Esta vez, en primer lugar establecer el filtro Máscara de hacer caso omiso de los bits del ID que son comunes a todos los identificadores quería - en este ejemplo, establezca los bits de la máscara de 0,1 = 0. Esto hará que el filtro de hacer caso omiso de los dos bits LSB de la ID de la CAN.
Máscara = 11111111100

En segundo lugar, configurar el filtro para "igualar" los bits comunes de los identificadores CAN desea.
FilterA = 00000000000

Cuando se combina la máscara y filtro, verá que usted ha creado (lo que yo llamo) una "regla de Rx".
Máscara = 11111111100
FilterA = 00000000000
Identificaciones que se aceptan: 1,2,3
ID que será rechazada: 4-2047

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

Desconectado estenolotienen

  • PIC10
  • *
  • Mensajes: 23
Re: Mis experiencias con el BUS CAN
« Respuesta #1010 en: 31 de Agosto de 2011, 15:16:47 »
Si en el código deshabilitas Debug_printf la librería deja de enviar por el puerto cada vez que transmite o recibe, lo que pasa es que nadie le contesta nada, por lo tanto es imposible saber si esta o no transmitiendo. Yo lo dejaría así, porque si en algún momento recibes algo, al menos entiendes que paso o que salio mal o si salio bien, entenderás las tramas del CANBUS.

Si miras en la placa que yo puse en los primeros puntos de este hilo, veras que le puse leds a las lineas de transmicion y recepción de cada nodo, precisamente para enterarme que pasa cuando tengo problemas de transmision o recepción.


Hola MGLSOFT,

Después del verano vuelvo a carga por donde lo dejé.

Os situo, me he creado los LEDs de TX y RX y funciona correctamente, cada segundo parpadea el LED de RX, tal como debe ser. Pero con el debugger sigue sin entrarme al if ( can_kbhit() ), el código íntegro es el siguiente:
Código: [Seleccionar]
#include <18F2580.h>


#device ICD=TRUE
#device adc=8

#FUSES NOWDT                  //No Watch Dog Timer
#FUSES WDT128                //Watch Dog Timer uses 1:128 Postscale
#FUSES HS                    //High speed Osc (> 4mhz)
#FUSES NOPROTECT              //Code not protected from reading
#FUSES BROWNOUT              //Reset when brownout detected
#FUSES BORV21                //Brownout reset at 2.1V
#FUSES PUT                    //Power Up Timer
#FUSES NOCPD                  //No EE protection
#FUSES STVREN                //Stack full/underflow will cause reset
//#FUSES NODEBUG                //No Debug mode for ICD
#FUSES NOLVP                  //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT                  //Program memory not write protected
#FUSES NOWRTD                //Data EEPROM not write protected
#FUSES NOIESO                  //Internal External Switch Over mode enabled
#FUSES FCMEN                  //Fail-safe clock monitor enabled
#FUSES PBADEN                //PORTB pins are configured as analog input channels on RESET
#FUSES BBSIZ1K                //1K words Boot Block size
#FUSES NOWRTC                //configuration not registers write protected
#FUSES NOWRTB                //Boot block not write protected
#FUSES NOEBTR                //Memory not protected from table reads
#FUSES NOEBTRB                //Boot block not protected from table reads
#FUSES NOCPB                  //No Boot Block code protection
#FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation
#FUSES MCLR                  //Master Clear pin enabled
#FUSES NOXINST                //Extended set extension and Indexed Addressing mode disabled (Legacy mode)



#use delay(clock=22110000)
#define CAN_DO_DEBUG TRUE
#define set_50k_baud
#include <can-18F4580.c>

void main()
{
struct rx_stat rxstat;
int32 rx_id;
int buffer[8];
int rx_len;
  int i;

for(i=0;i<8;i++)
{
buffer[i]=0;
}

printf("\r\n\r\nCCS CAN EXAMPLE\r\n");


can_init();
delay_ms(500);//**********************************************



while(TRUE)
{
if ( can_kbhit() )
{
printf("\n\rEntro al kbhit\n\r");
printf("\r\n");
if(can_getd(rx_id, &buffer[0], rx_len, rxstat))
{
printf("Byte 0: %X\r\n",buffer[0]);
for(i=0;i<rx_len;i++)
{
printf("Mensaje: %X\r\n",buffer[i]);
}
}
}
// delay_ms(500);
}

}

Se os ocurre algo??

Gracias!!!

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7907
Re: Mis experiencias con el BUS CAN
« Respuesta #1011 en: 31 de Agosto de 2011, 15:26:35 »
Del otro lado debe haber otro emitiendo mensajes, porque no pones el código de ese también??
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado estenolotienen

  • PIC10
  • *
  • Mensajes: 23
Re: Mis experiencias con el BUS CAN
« Respuesta #1012 en: 31 de Agosto de 2011, 16:35:48 »
Del otro lado debe haber otro emitiendo mensajes, porque no pones el código de ese también??

Es el siguiente:

Código: [Seleccionar]
#include <18F2580.h>


#device ICD=TRUE
#device adc=8

#FUSES NOWDT                  //No Watch Dog Timer
#FUSES WDT128                //Watch Dog Timer uses 1:128 Postscale
#FUSES HS                    //High speed Osc (> 4mhz)
#FUSES NOPROTECT              //Code not protected from reading
#FUSES BROWNOUT              //Reset when brownout detected
#FUSES BORV21                //Brownout reset at 2.1V
#FUSES PUT                    //Power Up Timer
#FUSES NOCPD                  //No EE protection
#FUSES STVREN                //Stack full/underflow will cause reset
//#FUSES NODEBUG                //No Debug mode for ICD
#FUSES NOLVP                  //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT                  //Program memory not write protected
#FUSES NOWRTD                //Data EEPROM not write protected
#FUSES NOIESO                  //Internal External Switch Over mode enabled
#FUSES FCMEN                  //Fail-safe clock monitor enabled
#FUSES PBADEN                //PORTB pins are configured as analog input channels on RESET
#FUSES BBSIZ1K                //1K words Boot Block size
#FUSES NOWRTC                //configuration not registers write protected
#FUSES NOWRTB                //Boot block not write protected
#FUSES NOEBTR                //Memory not protected from table reads
#FUSES NOEBTRB                //Boot block not protected from table reads
#FUSES NOCPB                  //No Boot Block code protection
#FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation
#FUSES MCLR                  //Master Clear pin enabled
#FUSES NOXINST                //Extended set extension and Indexed Addressing mode disabled (Legacy mode)



#use delay(clock=22110000)
//#use rs232(baud=115200, xmit=PIN_C6,rcv=PIN_C7)


#define CAN_DO_DEBUG TRUE
#define set_50k_baud
#include <can-18F4580.c>

void main()
{
int dato=0;

printf("\r\n\r\nCCS CAN TX EXAMPLE\r\n");

can_init();

while(TRUE)
{
can_putd(0, &dato, 1, 1, 0, 0);//****************
delay_ms(1000);//**********************************************

}

}

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7907
Re: Mis experiencias con el BUS CAN
« Respuesta #1013 en: 31 de Agosto de 2011, 16:58:22 »
Si en el código deshabilitas Debug_printf la librería deja de enviar por el puerto cada vez que transmite o recibe, lo que pasa es que nadie le contesta nada, por lo tanto es imposible saber si esta o no transmitiendo. Yo lo dejaría así, porque si en algún momento recibes algo, al menos entiendes que paso o que salio mal o si salio bien, entenderás las tramas del CANBUS.

Si miras en la placa que yo puse en los primeros puntos de este hilo, veras que le puse leds a las lineas de transmicion y recepción de cada nodo, precisamente para enterarme que pasa cuando tengo problemas de transmision o recepción.


Hola MGLSOFT,

Después del verano vuelvo a carga por donde lo dejé.

Os situo, me he creado los LEDs de TX y RX y funciona correctamente, cada segundo parpadea el LED de RX, tal como debe ser. Pero con el debugger sigue sin entrarme al if ( can_kbhit() ), el código íntegro es el siguiente:
Código: [Seleccionar]
#include <18F2580.h>


#device ICD=TRUE
#device adc=8

#FUSES NOWDT                  //No Watch Dog Timer
#FUSES WDT128                //Watch Dog Timer uses 1:128 Postscale
#FUSES HS                    //High speed Osc (> 4mhz)
#FUSES NOPROTECT              //Code not protected from reading
#FUSES BROWNOUT              //Reset when brownout detected
#FUSES BORV21                //Brownout reset at 2.1V
#FUSES PUT                    //Power Up Timer
#FUSES NOCPD                  //No EE protection
#FUSES STVREN                //Stack full/underflow will cause reset
//#FUSES NODEBUG                //No Debug mode for ICD
#FUSES NOLVP                  //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT                  //Program memory not write protected
#FUSES NOWRTD                //Data EEPROM not write protected
#FUSES NOIESO                  //Internal External Switch Over mode enabled
#FUSES FCMEN                  //Fail-safe clock monitor enabled
#FUSES PBADEN                //PORTB pins are configured as analog input channels on RESET
#FUSES BBSIZ1K                //1K words Boot Block size
#FUSES NOWRTC                //configuration not registers write protected
#FUSES NOWRTB                //Boot block not write protected
#FUSES NOEBTR                //Memory not protected from table reads
#FUSES NOEBTRB                //Boot block not protected from table reads
#FUSES NOCPB                  //No Boot Block code protection
#FUSES NOLPT1OSC              //Timer1 is not configured for low-power operation
#FUSES MCLR                  //Master Clear pin enabled
#FUSES NOXINST                //Extended set extension and Indexed Addressing mode disabled (Legacy mode)



#use delay(clock=22110000)
#define CAN_DO_DEBUG TRUE
#define set_50k_baud
#include <can-18F4580.c>

void main()
{
struct rx_stat rxstat;
int32 rx_id;
int buffer[8];
int rx_len;
  int i;

for(i=0;i<8;i++)
{
buffer[i]=0;
}

printf("\r\n\r\nCCS CAN EXAMPLE\r\n");


can_init();
delay_ms(500);//**********************************************



while(TRUE)
{
if ( can_kbhit() )
{
printf("\n\rEntro al kbhit\n\r");
printf("\r\n");
if(can_getd(rx_id, &buffer[0], rx_len, rxstat))
{
printf("Byte 0: %X\r\n",buffer[0]);
for(i=0;i<rx_len;i++)
{
printf("Mensaje: %X\r\n",buffer[i]);
}
}
}
// delay_ms(500);
}

}

Se os ocurre algo??

Gracias!!!


Que debugger usas ??
Yo pondria la orden de encender y apagar un led despues del Kbhit() a ver si realmente pasa por ahi o no.
Si el debug que esperas es por serial, podrias tener mal algo del port serial.

Por otro lado prueba activar el bit rtr en el emisor (ultimo valor de la funcion Can_Put() cen 1), esto obligara a que el esclavo responda cuando recibe un mensaje.

Quedaria asi:
Citar
can_putd(0, &dato, 1, 1, 0, 1);
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado estenolotienen

  • PIC10
  • *
  • Mensajes: 23
Re: Mis experiencias con el BUS CAN
« Respuesta #1014 en: 01 de Septiembre de 2011, 13:05:58 »
Que debugger usas ??
Yo pondria la orden de encender y apagar un led despues del Kbhit() a ver si realmente pasa por ahi o no.
Si el debug que esperas es por serial, podrias tener mal algo del port serial.

Por otro lado prueba activar el bit rtr en el emisor (ultimo valor de la funcion Can_Put() cen 1), esto obligara a que el esclavo responda cuando recibe un mensaje.

Quedaria asi:
Citar
can_putd(0, &dato, 1, 1, 0, 1);
[/quote]

Ahora ya si que me acabo de liar del todo... Resulta que en modo debugger el pintf de "CCS EXAMPLE" me lo hace correctamente, pero si lo grabo y lo arranco sin conectar el ICD no me lo hace  :shock: :shock: No se que puedo estar haciendo mal.

He puesto a 1 el bit RTR del emisor, pero sigue igual. Para probarlo tengo el printf de "Entro al kbhit()", pero nunca lo hace.

El debugger lo estoy haciendo desde el MPLAB con un ICD3.

Gracias por tu ayuda!

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7907
Re: Mis experiencias con el BUS CAN
« Respuesta #1015 en: 01 de Septiembre de 2011, 13:52:00 »
Que debugger usas ??
Yo pondria la orden de encender y apagar un led despues del Kbhit() a ver si realmente pasa por ahi o no.
Si el debug que esperas es por serial, podrias tener mal algo del port serial.

Por otro lado prueba activar el bit rtr en el emisor (ultimo valor de la funcion Can_Put() cen 1), esto obligara a que el esclavo responda cuando recibe un mensaje.

Quedaria asi:
Citar
can_putd(0, &dato, 1, 1, 0, 1);

Ahora ya si que me acabo de liar del todo... Resulta que en modo debugger el pintf de "CCS EXAMPLE" me lo hace correctamente, pero si lo grabo y lo arranco sin conectar el ICD no me lo hace  :shock: :shock: No se que puedo estar haciendo mal.

He puesto a 1 el bit RTR del emisor, pero sigue igual. Para probarlo tengo el printf de "Entro al kbhit()", pero nunca lo hace.

El debugger lo estoy haciendo desde el MPLAB con un ICD3.

Gracias por tu ayuda!

[/quote]

Una prueba mas (el que piense que todo sale de una primera vez, que no entre a este foro!!), intercambia ambas placas y sus programas, asi el que hoy recibe pasa a transmitir y viceversa.
A ver si hay algun problema de hardware...
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado handpic

  • Colaborador
  • PIC12
  • *****
  • Mensajes: 72
Re: Mis experiencias con el BUS CAN
« Respuesta #1016 en: 01 de Septiembre de 2011, 19:09:53 »


Las capas más superiores son definidas de acuerdo con la aplicación. Por ejemplo, yo estoy intentando leer datos de autobuses y camiones. He descubierto que las capas más superiores de la referencia OSI para autobuses y camiones son definidas por la norma SAE J1939, y los datos de algunos modelos dentro del J1939 siguen un standard llamado FMS Standard.
Procura informarte a respecto de que normas definen las capas más superiores para los autos de Peugeot, para poder interpretar los datos.

Para los filtros, creo que este trend, nel forum de Microchip te puede aclarar (en inglés).
http://www.microchip.com/forums/tm.aspx?m=456043&settheme=Mobile



Hola de nuevo....
Lo cierto es que no quiero conectarme al CAN del Peugeot. Ese es mi coche y con él estaba haciendo una prueba a través del conector OBD, pero con la información que tengo, creo que no tiene bus can en ese conector, usa otro estandar.
Lo que yo quiero hacer es controlar una dirección asistida de un nissan micra. Los datos que he dado son de ella, lo que pude ver que enviaba al bus. Al parecer también la monta en Renault, en el clio o así. Es para coches pequeños y va directamente sobre la barra de la dirección.
La idea es montarla en un ATV y poder controlar su dureza enviándole los valores de velocidad que normalmente reciben.
Así que lo que de verdad necesito es el estandar que usa Renault y Nissan (supongo que son los mismos, ya que son del mismo grupo y usan piezas comunes).
Gracias por el enlace.... y por la traducción....
Si averiguo algo mas os lo comentaré.

Saludos

Desconectado handpic

  • Colaborador
  • PIC12
  • *****
  • Mensajes: 72
Re: Mis experiencias con el BUS CAN
« Respuesta #1017 en: 01 de Septiembre de 2011, 20:05:40 »


Para los filtros, creo que este trend, nel forum de Microchip te puede aclarar (en inglés).
http://www.microchip.com/forums/tm.aspx?m=456043&settheme=Mobile




Creo que he entendido mas o menos lo que se dice con respecto a la mascara y el filtro.

La máscara determina que bits serán examinados por el filtro. Aquellos bits cuyo valor en la máscara es 1 serán los que se tendrán en cuenta para comparar su valor con el indicado en su misma posición en el filtro.
Combinando ambos valores, podremos tener un rango de ID aceptados y no solo un ID.

Trataré de explicar el mismo ejemplo:
para que podamos aceptar los ID con valor 1, 2 y 3, pero no el 4, deberíamos tener:
ID 1= 0b00000001
ID 2= 0b00000010
ID 3= 0b00000011
ID 4= 0b00000100

Mask     0b11111100
filter      0b00000000
Los seis primeros bits de mas peso, a "1" en la máscara, son los que se tendrán en cuenta para comparar su valor con el del filtro y, de acurerdo con su valor, deberán ser "0", es decir, que todos los IDs menores o iguales a 0b00000011 serán aceptados.
El valor de ID validado será 0b000000xx, donde xx puede tomar cualquier valor.
Los dos bits de menos peso, aunque en el filtro se indican 00, realmente no son comparados, ya que los elimina la máscara.

Supongo, no lo he probado, que sería lo mismo poner como valor de filtro 0b00000000 que 0b00000011

Saludos,

Desconectado ASTROCAR

  • PIC24F
  • *****
  • Mensajes: 664
Re: Mis experiencias con el BUS CAN
« Respuesta #1018 en: 02 de Septiembre de 2011, 08:28:59 »
Hola buenos dias, ya que se esta hablando del tema del filtrado de ID en can bus me gustaria documentarme un poco mejor para asi realizar mi propia funcion de filtraje en la libreria de can bus para maneja esos IDs deseados por cada nodo Can.

Saludos y cualkquier aporte a la causa es bien recibido.
EL APRENDER ES NADA; MEJOR ES COMPARTIR EL APRENDIZAJE

Desconectado MerLiNz

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 2463
Re: Mis experiencias con el BUS CAN
« Respuesta #1019 en: 03 de Septiembre de 2011, 15:50:15 »
Hola, buenas a todos, primero agradecer a los colaboradores del post toda la info, porque he aprendido bastante bien las dudas que tenia con el can bus.

La primera vez que entre en contacto con el can bus fue viendo un datasheet y un ejemplo de micropic, en cuanto lo vi sali corriendo porque veia muchisimos lios, pero una vez estas dentro ves que no es tan lioso, hay muchos registros, pero son muy sencillos una vez comprendes todo el funcionamiento.

Decir que en 2 dias me he currado mi primer proyecto de can-bus, donde un pic transmite a otro unos valores, y este otro los muestra en un glcd. No he usado ninguna biblioteca ya que me gusta hacer las cosas a mi gusto, unicamente he cogido de aqui, de alli, y me voy a montar mi propia libreria para C18 (mplab).

En este proyecto he usado 2 pics 18f46k80 con modulo ecan integrado, y 2 transceivers mcp2551. Decir que es bastante comodo este micro, ya que con el mismo oscilador interno te puedes hacer 64Mhz (es la frecuencia a las que los tengo trabajando) sin nada externo.

Bueno pongo el video para que veais, aunque se ve muy mal por la oscuridad, pero tambien podeis ver los mensajes can en el osciloscopio como estos van variando.


Una cosa que queria comentar que me ha sucedido, no se si es normal (yo diria que si) es que si unicamente conecto un pic y el otro lo dejo apagado (o con el modulo can off) el pic que esta enviando se pone a enviar mensajes (los mismos) reiteradamente como un loco. Y me refiero a que unicamente hago un send, y sigue mandando el mismo mensaje una y otra vez hasta que enciendo el pic2 y este activa el modulo can.

Y una duda, entre que voltajes oscila el CANH y CANL? Es que a mi me va entre 2V aproximadamente, y me parece bastante poco, alguien sabe si es normal, o como solucionarlo?
« Última modificación: 03 de Septiembre de 2011, 16:51:05 por MerLiNz »