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

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

Desconectado Suky

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 6759
Re: Mis experiencias con el BUS CAN
« Respuesta #660 en: 08 de Diciembre de 2009, 17:14:32 »
Pero haciendo
Código: C
  1. #define CAN_DO_DEBUG FALSE

soluciona el problema :mrgreen:
No contesto mensajes privados, las consultas en el foro

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7842
Re: Mis experiencias con el BUS CAN
« Respuesta #661 en: 08 de Diciembre de 2009, 17:24:43 »
NI (mezcla de No con sI).
Aun asi no esta declarando las salidas o entradas necesarias, por eso insisto en que retorne a Standard_IO().
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado Suky

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 6759
Re: Mis experiencias con el BUS CAN
« Respuesta #662 en: 08 de Diciembre de 2009, 17:28:05 »
NI (mezcla de No con sI).
Aun asi no esta declarando las salidas o entradas necesarias, por eso insisto en que retorne a Standard_IO().
A... Si, si! Eso también tiene que solucionarlo. Y en el caso que quiera usar debug puede usar USART por software.


Saludos!
No contesto mensajes privados, las consultas en el foro

penguin

  • Visitante
Re: Mis experiencias con el BUS CAN
« Respuesta #663 en: 09 de Diciembre de 2009, 10:54:54 »
buenas!
hombre, el tema violencia casi que lo descarto :D
Volbiendo a las andadas: he cambiado a probar por soft. Si pruebo por soft, tal como decis, he puesto  la linea
Código: C
  1. #use spi  (MASTER,BITS=32,FORCE_SW)
sin decir que patillas uso, porque para eso ya esta el can-mcp2551.c
( que por cierto, he probado cambiar a las patillas de mi pic, y sin cambiar tambien). Cuando funciona por soft pues, se halla el mismo problema ( tambien he cambiado opciones como #define CAN_DO_DEBUG TRUE y #define CAN_DO_DEBUG FALSE).

Mi pic no se inmuta si es por SW o por HW ( eso si , el cambio de patillas se hace efectivo). Persiste el problema en mi SCK. Parecen interferencias, pero son ya unas cuantas soldaduras para mejorar circuito, y siguen ahí... no se me ocurre que hacer

Desconectado Suky

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 6759
Re: Mis experiencias con el BUS CAN
« Respuesta #664 en: 09 de Diciembre de 2009, 11:40:47 »
La definición del SPI tienes que hacerla así:

Código: C
  1. //IO pins connected to MCP2510
  2. #ifndef EXT_CAN_CS
  3.   #define EXT_CAN_CS   PIN_A5
  4.   #define EXT_CAN_SI   PIN_B0
  5.   #define EXT_CAN_SO   PIN_C7
  6.   #define EXT_CAN_SCK  PIN_B1
  7. #endif
  8.  
  9. #use spi(MASTER,CLK=EXT_CAN_SCK, DO=EXT_CAN_SO, DI=EXT_CAN_SI, BITS=8, MODE=3, FORCE_SW)

Si no, no se sabe que pines se utiliza. El modo no se si es el correcto para la aplicación, eso revisar.


Saludos!
No contesto mensajes privados, las consultas en el foro

penguin

  • Visitante
Re: Mis experiencias con el BUS CAN
« Respuesta #665 en: 09 de Diciembre de 2009, 15:05:26 »

Hola!
Bueno no era un problema de mi libreria hardware, simplemente es que no sabia leer el osciloscopio digital.Aprendemos con el analogico y luego el digital... pues tiene sus cosas. Al ver la grafica, el osciloscopio ( digital) va muestreando, y en "in time" se solapan las señales. Eso pasa con los analogicos. Pero con el digital existe una teclita ( una teclita !!!) que hace que se muestre el primer muestreo ( o la primera tanda), asi no se ven solapada la señal. Es decir, al menos yo, en un analogico no sabria ver que señal me muestra el osciloscopio.

Ahora me queda averiguar si ese seguido de unos y ceros ( el frame) se corresponde a lo que espero ver en un extended frame de CAN ( lo que sale en el datasheet del mcp), que a pesar de disfrutar del digital, sigue siendo algo complicadillo de ver.

Desconectado sergio_silva

  • PIC10
  • *
  • Mensajes: 6
Re: Mis experiencias con el BUS CAN
« Respuesta #666 en: 16 de Diciembre de 2009, 20:29:27 »
Hola!

Finalmente terminei lo codigo del PIC que recibe da CAN-BUS e comunica com el PC ( el terminal).

Código: [Seleccionar]

#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 rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)

#include "can-18F4580.c"

#define PIC_ID 25//identificação deste PIC

void main()
{

    //recv message
    struct rx_stat rxstat;
    int32 rx_id;
    int in_data[8];
    int rx_len;
   
    int data = 9;
    int out_data[8];
    int i = 0;
    int8 buffer[8];
   
    //clear recv buffer
    for(i=0;i<8;i++)
    {
    in_data[i]=0;
    }

    can_init();
    //can_set_mode(CAN_OP_LISTEN);
   
    while(TRUE)
    {
   
        // mensagem recebida
        if ( can_kbhit() )
        {       
           if(can_getd(rx_id, &in_data[0], rx_len, rxstat))   //se existem dados no buffer in_data, guarda os dados recebidos nas variáveis
           {
              if(rx_id == PIC_ID)  // Se a mensagem é para este PIC
              {
                 data =~ (in_data[0]);                 
                 if(bit_test(data, 4))
                    printf("Botão 1 está OFF.\n");
                 if(bit_test(data, 5))
                    printf("Botão 1 está ON.\n");
                 if(bit_test(data, 6))
                    printf("Botão 2 está OFF.\n");
                 if(bit_test(data, 7))
                    printf("Botão 2 está ON.\n");               
              }
           }
        }//fim do tratamento da mensagem recebida
         
        buffer[0] = getc();
        if(buffer[0] == "0"  )//liga Led 1
        {
           out_data[0] = 0;
           can_putd(26, &out_data[0], 1, 1, 1, 0);
        }
        if(buffer[0] == "1" )//desliga Led 1
        {
           out_data[0] = 1;
           can_putd(26, &out_data[0], 1, 1, 1, 0);
        }
        if(buffer[0] == "2")//liga Led 2
        {
           out_data[0] = 2;
           can_putd(26, &out_data[0], 1, 1, 1, 0);                 
        }
        if(buffer[0] == "3")//desliga Led 2
        {
           out_data[0] = 3;
           can_putd(26, &out_data[0], 1, 1, 1, 0);
        }           
    }
}

Eu quería que cuándo no PC alguien enviar una instrucción para ligar / desligar los leds, el PIC tivesse una funcion qué eran chamada automáticamente, como las interrupciones, pero en mi codigo eu tenho la funcion -  buffer[0] = getc(); - dentro del ciclo while(TRUE).

Saludos, Sérgio Silva

penguin

  • Visitante
Re: Mis experiencias con el BUS CAN
« Respuesta #667 en: 18 de Diciembre de 2009, 13:13:50 »
Buenas!
Llevo ya algunos post, asi que seguramente os será familiar mi circuito. Pretendo comunicar mi PIC18F4550 con su CAN Controller MCP2510, y a su vez éste con el Transeiver MCP2551. Modifiqué la librería can-mcp2510.c/.h para resolverla por hardware (la de CCS es por soft).
De ahí atestiguo que existe comunicación del PIC al Controller, via SPI. Pero... mi gozo en un pozo, ahí termina todo.

 Por las patillas Tx,Rx del controller no hay nada, asi que por CAN_H y CAN_L lo único que puedo ver son alrededor de 3 V permantes, o sea, estado recesivo, que no pincha ni corta el sistema. Bien, dado que tanto el pic como el controller tienen cristal de 20 Mhz (ambos funcionan correctamente, es decir, hay señal de reloj de 20 Mhz), SPI envia correctamente datos por SDO ( del PIC) a SI del controller, no entiendo por que no recibe señal.
Entonces mis preguntas son:
1) Por qué?!!!!
2) Si el medio no está accesible ( no he programado nada a propósito para que controle el sistema), qué situación es la que lo provoca?
3) Mi resistencia de terminacion ( entre CAN_H y CAN_L) es de 56 Ohmios, puede provocar que el controler no envie nada al transceiver? ¿ Influye un valor tan bajo?
4)Y si es asi, en base a que debo poner un valor u otro? ( se que guarda relacion con velocidad de transmision, que la he dejado a 125Kbps).

Pongo mi main(), que en principio el programa solo quiere enviar una trama sin tener en cuenta si está ocupado el bus ( no lo está- o no debería- porqué no hay circuito de recepción).
Código: C
  1. #include <18F4550.h>
  2. #include <stdlib.h>
  3. #fuses HS,NOPROTECT,NOLVP,NOWDT,XTPLL,PLL5,NOPROTECT,USBDIV,CPUDIV2
  4. //#fuses HS,NOPROTECT,NOLVP,NOWDT,NOPROTECT,USBDIV,CPUDIV2
  5. #use delay(clock=48000000)
  6. #include <spi-can-mcp2510.c>
  7. #define CAN_DO_DEBUG TRUE
  8. #define Set_125K_Baud TRUE
  9. #byte   porta = 0xf80
  10. #byte   portb = 0xf81
  11. #byte   portc = 0xf82
  12. #byte   portd = 0xf83
  13. #byte   porte = 0xf84
  14. #byte   t1con = 0xfcd
  15. #byte   latd = 0xf8c
  16. #byte   adcon0 = 0xfc2
  17. #byte   adcon1 = 0xfc1
  18. #byte   adcon2 = 0xfc0
  19. #byte   adresl = 0xfc3
  20. #byte   adresh = 0xfc4
  21. #use fast_io (D)
  22. #byte PORTD= 0XF83
  23.  
  24. void main() {
  25.    struct rx_stat rxstat;
  26.    int32 rx_id;
  27.    int buffer[8];
  28.    int i,rx_len;
  29.  
  30.    set_tris_d(0x01);
  31.    setup_spi(SPI_MASTER | SPI_H_TO_L|spi_clk_div_4);
  32.    rx_id=0x01;
  33.    buffer[0]=0x08;
  34.  
  35.    
  36.    can_init();
  37.    enable_interrupts(GLOBAL);
  38.    can_putd(0x01,&buffer[0],8,3,TRUE,TRUE);
  39.  
  40. while(TRUE){
  41.  
  42.       output_high (pin_d1);
  43.  
  44.       if ( can_tbe()){
  45.           can_putd(0x01,&buffer[0],8,1,TRUE,0);
  46.        }
  47.    }
  48. }
  49.  
« Última modificación: 18 de Diciembre de 2009, 13:20:12 por penguin »

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7842
Re: Mis experiencias con el BUS CAN
« Respuesta #668 en: 18 de Diciembre de 2009, 14:49:34 »
Vamos por partes, como dijo Jack...

Has probado entre CanH y CanL SIN la resistencia de fin de linea??
Porque pones 56 Ohm si el valor de la resistencia debe ser de 120 Ohm??

Prueba ambas cosas y luego comentas..
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7842
Re: Mis experiencias con el BUS CAN
« Respuesta #669 en: 18 de Diciembre de 2009, 14:58:02 »
Ahora cortemos a la altura del ombligo, hundiendo el bisturi!!

La resistencia que debes cambiar, segun la velocidad del Bus, es la del pin RS del MCP2551, que por lo visto es muuuyyy alta, de 2,2 k la que pusiste.
Prueba alli con un valor entre 10 a 50 Ohm... :mrgreen:
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

penguin

  • Visitante
Re: Mis experiencias con el BUS CAN
« Respuesta #670 en: 19 de Diciembre de 2009, 11:47:43 »
Bueno, MGSOFT, asi como dices, comenzaré rajando y destripando el problema. :D El valor de resistencia que puse, creía que era un valor estándar.

Probaré lo dicho y os cometo ;)

penguin

  • Visitante
Re: Mis experiencias con el BUS CAN
« Respuesta #671 en: 21 de Diciembre de 2009, 15:02:58 »
uhmm...todo sigue como lo dejé . De todos modos si habia que cambiar esos valores de r no es tiempo perdido tampoco. Ahora tengo una cuestión. Segun datasheeet de MCP2510,



ese bit de registro del mcp ha de estar a 1 para indicar que está libre de enviar mensajes. Si vamos a CCS, la función que determina esa misma funcion ( valga la redundancia) es can_tbe(). Bien, nos vamos hacia esa función, y sabemos que debería haber un bit llamado TXBnCTRL.TXREQ  ( o lo mas parecido) para poner a 1 en alguna ocasión.  En can-mcp.h vemos esto :
Código: C
  1. struct txbNctrl_struct {
  2.    int  txpri:2;   //0:1   //transmit priority bits
  3.    int1 void2; //2
  4.    int1 txreq;   //3   //transmit request status (clear to request message abort)
  5.    int1 txerr;   //4   //transmission error detected
  6.    int1 mloa;   //5   //message lost arbitration
  7.    int1 abtf;   //6   //message was aborted / or transmitted succesfully
  8.    int1 void7;
  9.  
Bieen.. se refleja una parte del programa donde ha de aparecer ese registro. Teniendo en cuenta que yo ( como mucha gente supongo) no defino los pines físicos ( a pesar de haber modificado la librería para su uso en HW) de esta parte del .c :

Código: C
  1. #ifndef EXT_CAN_CS
  2.    //#define EXT_CAN_CS   PIN_B1 //por defecto estos
  3.    //#define EXT_CAN_SI   PIN_C1
  4.    //#define EXT_CAN_SO   PIN_C0
  5.    //#define EXT_CAN_SCK  PIN_C3
  6.  
  7.    // cambio para usar en PIC18F4550 modo HW
  8.    #define EXT_CAN_CS   PIN_A5
  9.    #define EXT_CAN_SI   PIN_B0
  10.    #define EXT_CAN_SO   PIN_C7
  11.    #define EXT_CAN_SCK  PIN_B1
  12.  
  13. //   [b]#define EXT_CAN_RESET   PIN_B5 //CCS library does not use this pin by default
  14. //   #define EXT_CAN_TX0RTS  PIN_C4 //CCS library does not use this pin by default
  15. //   #define EXT_CAN_TX1RTS  PIN_B4 //CCS library does not use this pin by default
  16. //   #define EXT_CAN_TX2RTS  PIN_C2 //CCS library does not use this pin by default[/b]
  17. #endif
  18.  
Quiere decir que solo actuará de forma SW en la librería dada por CCS , pero en que momento lo  hace ? Es decir, como sabe CCS ( la liberia ) que relamente no hay nada en el buffer. Estoy pensando que quizas vayan por ahi los tiros, que en ningun momento se le diga desde can librería que TXBnCTRL.TXREQ  es en efecto 1.
La velocidad también podría ser, pero me ha basado en los cálculos del programa ofrecido por aqui, asi que descarto que ese sea el problema...

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7842
Re: Mis experiencias con el BUS CAN
« Respuesta #672 en: 22 de Diciembre de 2009, 09:08:50 »
Creo que te equivocas, Can_TBE() solo verifica si el MCP2515 termino de transmitir.
La funcion que realiza la transmicion es CAN_PUTD()... :mrgreen:
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

penguin

  • Visitante
Re: Mis experiencias con el BUS CAN
« Respuesta #673 en: 23 de Diciembre de 2009, 09:27:28 »
hola!
si si es cierto, pero para escribir, primero has de poder, y eso es lo que queria ver, si mi no escritura reflejada en los buffers del MCP es porque no le deja escribir. Ahora estoy probando escribir datos a algun buffer de r/w del controller a ver si me los lee después.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7842
Re: Mis experiencias con el BUS CAN
« Respuesta #674 en: 23 de Diciembre de 2009, 09:55:00 »
Puedes subir todas tus librerias actuales y programas que estas utilizando??
A ver si podemos ayudarte a depurarlos...
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.


 

anything