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

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

penguin

  • Visitante
Re: Mis experiencias con el BUS CAN
« Respuesta #720 en: 22 de Enero de 2010, 16:10:20 »
bueno la funcion que veo parecida es output_toggle(pin)

Lo que entiendo con eso es que testea el pin ( nviando un 1??) es como un output_high y luego lo pone a output_low?

de todos modos, los unicos pines que tengo realmente referenciados son los del pic. al pic le ordeno " ves a esta direccion", referiendome a direccion del mcp y asumo que ccs no tiene por que saber si el pin 14 del MCP es el SI...

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7863
Re: Mis experiencias con el BUS CAN
« Respuesta #721 en: 22 de Enero de 2010, 16:22:38 »
Si, esa es la instruccion, cambia de estado el pin enviandolo al opuesto.
Si haces un lazo temporizado, activandolo una y otra vez, podrias leer con el osciloscopio si esos pines estan siendo activados correctamente.

Yo uso mi debugger para hacer esto.

Especialmente ya que en tu programa no utilizas standard_io para configurar tus pines y dado que muchos pines pueden quedar mal configurados si no prestas la debida atencion.
Eso mismo trate de decirte con el hecho de usar el pin C7 que esta asignado por hardware a la Usart.

Probandolos uno por uno alejas el fantasma que pueda estar ocurriendo algo extraño, y poder corregirlo si sucede algo raro...

Desde que comenzaste a consultar no veo grandes lios, solo que al usar fast_io hay que tener muchisimo cuidado como uno va configurando cada port y sus bits respectivos, igual que si trabajaras en assembler.
CCS tiene entre sus fortalezas el tener el standard_io pero se transforma en debilidad cuando te pasas al fast_io y no tienes en cuenta estos "detalles".

La prueba de hardware es lo mas recomendado...
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 #722 en: 25 de Enero de 2010, 08:11:07 »

uhm, es interesante esto que me dices acerca de standard io. La verdad es que mirando el help no da muchas explicaciones acerca de la diferencia entre standard y fast_io, a lo que opté por esta última ya que segun he leido es mas recomendable para cambios rápidos en el pin, y permite el uso de delay's.

Bien tengo implementada -no he hecho grandes lios- una función dentro del main que probara los pines que se corresponden al SPI en el PIC, y cuando vea los resultados de este test ( espero que positivos) cambiaré parasiempre a standard_io, ademas ya he declarado como quiero los 2 o 3 puertos que realmente uso. Probaré lo siguiente y comento resultados:

Código: C
  1. #use fast_io (D)
  2. /// estos #use seran para hacer un test del estado de los pines
  3. #use fast_io (A)
  4. #use fast_io (B)
  5. #use fast_io (C)
  6. #use fast_io (E)
  7.  
  8. /*
  9.  
  10.  
  11.  
  12. #USE STANDARD_IO (B)
  13. #USE STANDARD_IO (C)
  14. #USE STANDARD_IO (D)
  15.  
  16. //set_tris_A(0x00);//      XXOXXXXX
  17.  
  18. set_tris_B(0xF9);          //  XXX1X001 ->1111 1001 -> 0xF9
  19. set_tris_C(0x10);        // |SD0|Tx|D+|D-|--|X|X|X|-> 00010000=0x10
  20.  
  21. set_tris_D(0x00);     // estan los dos leds en D0 y D1
  22.  
  23.  
  24. */
  25. /// declaracion de cabeceras de funciones
  26. void test_pins_SPI(void);
  27.  
  28.  
  29.  
  30. void main(){
  31. setup_spi (SPI_MASTER|SPI_L_TO_H|SPI_CLK_DIV_16);
  32.  
  33.  
  34.  
  35.  
  36.    while(1){
  37.    
  38.    
  39.  
  40.  // prueba de los pines ocupados por SPI/////
  41.        //   pin_C7 -> SDO
  42.        //   pin_B0 -> SDI
  43.        //   pin_A5 -> !CS
  44.  
  45.  test_pins_SPI();
  46.  
  47.    } // fin while
  48.  
  49. }// fin main
  50.  
  51. //// cuerpo funcion  test de los pins ///////
  52.  
  53. void test_pins_SPI(void){
  54.    output_toggle( pin_C7);
  55.    delay_ms(400);
  56.    output_toggle( pin_B0);
  57.    delay_ms(400);
  58.    output_toggle( pin_A5);
  59.    delay_ms(400);
  60.    }
  61.  

penguin

  • Visitante
Re: Mis experiencias con el BUS CAN
« Respuesta #723 en: 25 de Enero de 2010, 13:15:13 »
bueno he hecho un cambio a la slineas del programa, que son
Código: C
  1. #include <18F4550.h>
  2. #include <stdlib.h>
  3. #include "spi_MCP2510.c"
  4. #use delay(clock=48000000) //clock a 48 MHz
  5. #fuses XTPLL,PLL5,NOWDT,NOPROTECT,USBDIV,CPUDIV2
  6. #byte  porta = 0xf80
  7. #byte   portb = 0xf81
  8. #byte   portc = 0xf82
  9. #byte   portd = 0xf83
  10. #byte   porte = 0xf84
  11.  
  12.  
  13.  
  14.  
  15. /// estos #use seran para hacer un test del estado de los pines
  16. #use fast_io (A)
  17. #use fast_io (B)
  18. #use fast_io (C)
  19. #use fast_io (D)
  20. #use fast_io (E)
  21.  
  22.  
  23. // quizas el problema ha estado aqui siempre, el no usar pines como input/output especifico
  24. /*
  25. #use standard_io (E)
  26.  
  27. #USE STANDARD_IO (A)
  28. #USE STANDARD_IO (B)
  29. #USE STANDARD_IO (C)
  30. #USE STANDARD_IO (D)
  31. #USE STANDARD_IO (E)
  32. */
  33.  
  34.  
  35. void main(){
  36. setup_spi (SPI_MASTER|SPI_L_TO_H|SPI_CLK_DIV_16);
  37.  
  38. set_tris_B(0x00);          //  XXX1X001 ->1111 1001 -> 0xF9
  39. set_tris_C(0x00);        // |SD0|Tx|D+|D-|--|X|X|X|-> 00010000=0x10
  40. set_tris_D(0x00);     // estan los dos leds en D0 y D1
  41.  
  42.  
  43.  
  44.    while(1){
  45.    
  46. // prueba de los pines ocupados por SPI/////
  47. //   pin_C7 -> SDO//
  48. //   pin_B0 -> SDI//
  49. //   pin_A5 -> !CS//  */
  50.  
  51.    output_toggle( pin_C7);
  52.    delay_ms(400);
  53.    output_toggle( pin_B0);
  54.    delay_ms(400);
  55.    output_toggle( pin_A5);
  56.    delay_ms(400);
  57.  
  58.  
  59.    } // fin while
  60. }// fin main
  61.  


y no obtengo resultado ninguno, o sea, el estado es siempre en cero del pin, por ejemplo, SDO ( quizas no esta bien configurado el test??) o que el pic realmente esta mal...

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7863
Re: Mis experiencias con el BUS CAN
« Respuesta #724 en: 25 de Enero de 2010, 15:09:04 »
Prueba tus pines con este programa, no otro.... :mrgreen: :mrgreen:

Código: C
  1. #include <18F4550.h>
  2. #include <stdlib.h>
  3. //#include "spi_MCP2510.c"
  4. #use delay(clock=48000000) //clock a 48 MHz
  5. #fuses XTPLL,PLL5,NOWDT,NOPROTECT,USBDIV,CPUDIV2
  6.  
  7. void main(){
  8.  
  9.    while(1){
  10.  
  11.    output_toggle( pin_C7);
  12.    delay_ms(400);
  13.    output_toggle( pin_B0);
  14.    delay_ms(400);
  15.    output_toggle( pin_A5);
  16.    delay_ms(400);
  17.  
  18.  
  19.    } // fin while
  20. }// fin main
  21.  

Luego dime que pasa.
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 #725 en: 26 de Enero de 2010, 13:22:25 »

uhm, he tenido un susto porque habia puesto el inicio de spi. Bueno, después de probar, veo que el pic está correcto, es decir, se suceden los 1's y los 0's en cada pin. Bien, no es problema de HW pués.

Cuando hago un SPI_write(), según leo aquí, espera dar una respuesta por el pin SDI (PIC) desde el SDO(MCP). Yo no quiero eso, simplemente quiero que solo escriba, y que sólo lea cuando se lo mando. ¿ He de hacerpues  esas 2 ordenes mediante ensamblador ? ( dios, dime que no...:D )

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7863
Re: Mis experiencias con el BUS CAN
« Respuesta #726 en: 26 de Enero de 2010, 15:09:33 »
Hagas lo que hagas, no declares mas :


#use fast_io (A)
#use fast_io (B)
#use fast_io (C)
#use fast_io (D)
#use fast_io (E)

Tampoco lo hagas con standard_io()

No declares la direccion de los puertos tampoco con set_tris_B(0x00) o los otros puertos.

Es absolutamente INNECESARIO si vas a usar standard_io() en todos tus puertos.
Incluso tampoco necesitas declararlo a standard_io() ya que es el modo por defecto como arranca el compilador...


Respecto a lo otro, cuando haces un pedido de un dato, debes quedarte esperando que el MCP te conteste.

La unica forma de evitar tanto ida y vuelta es CABLEAR todas las señales e interrupciones del MCP. :mrgreen: :mrgreen: :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 #727 en: 26 de Enero de 2010, 16:42:22 »
vaya, cuando hacia set_tris() "sabia lo que hacia" jeje. Entonces, que una entrada sea (funcione) como input/output, al no poner esa instrucción, ¿ queda como está configurada automaticamente por el propio hardware? Es decir, si en el data pone que es I/O, en efecto será I/O a no se que le digamos lo contrario ( o sólo I, o sólo O).

Una nota curiosa: si pongo delay junto con declaracion de #use standard_io() o #use fast_io() solo me leia, o sacaba por SDO (MCP) 5 pulsos de SCK con sus correspondientes bits de datos ( que no se que eran).

Otra nota curiosa: la única vez que logro que parpadeen los leds, es al usar output_toggle(), y claro esá, sin definir ninguna #use x_io(). Si hago esto :
Código: C
  1. while(1){
  2.    write_MCP2510(direccion_buffer0_tx,dato1);  // OK
  3.    lectura=read_returns_Data_MCP2510(direccion_buffer0_tx);       //OK
  4.    if (lectura==dato1)
  5.       output_high(pin_d0);
  6.    else output_high(pin_d1);
  7.         output_low(pin_d1);
  8.    } // fin while
  9.  
no parpadea el led conectado a pin D1. Si, se enciende pq ni de largo el dato que meto es el que lee, pero...¿ por que no parpadea?  a ver si eso guarda relación con el problema...

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7863
Re: Mis experiencias con el BUS CAN
« Respuesta #728 en: 26 de Enero de 2010, 16:55:08 »
Aun en el caso que el programa pasara por el encendido del led en:

Código: C
  1. #
  2.   if (lectura==dato1)
  3.      output_high(pin_d0);
  4.   else output_high(pin_d1);
  5.        output_low(pin_d1);
  6.   } // fin while

Solo tarda unos pocos microsegundos en apagarlo nuevamente, salvo que le agregues como prueba un delay_ms(300) antes del encendido ni el led se va a enterar que tenia que encender... :mrgreen:
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7863
Re: Mis experiencias con el BUS CAN
« Respuesta #729 en: 26 de Enero de 2010, 16:59:08 »
Si le sacas los retardos o los comentas en el programa con los output_toggle() tampoco deberias ver que se enciendan leds, incluso no podrias verificarlo con el osciloscopio, por la alta frecuencia del encendido y apagado.
Encima el ojo humano tiene retardo visual y memoria optica, por lo tanto aun haciendo retardos de 10 mseg no verias nada aun, aunque si podrias registrarlo con el osciloscopio en este caso... :D :D
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 #730 en: 27 de Enero de 2010, 07:49:42 »
Si exacto, asi lo hacia, pero si pongo ese o esos delay...se lia gorda. Es decir, si no pongo el delay, mi led no parpadea ( que es lo que me gustaria, aunque realmente no es necesario) y por SCK veo que manda 5 pulsos correspondientes a las 5 instrucciones.

Si le pongo dichos delay_ms(), en efecto, parpadea, pero cuando digo que la lia gorda ... se queda ahí, el programa entero esta en delay, se fastidia el envio repetitivo de bytes...
« Última modificación: 27 de Enero de 2010, 07:58:29 por penguin »

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7863
Re: Mis experiencias con el BUS CAN
« Respuesta #731 en: 27 de Enero de 2010, 08:13:12 »
Es que ya no puede cumplir con la velocidad de comunicacion predeterminada del Bus SPI!!!
Lo de la temporizacion del led era solo para que veas que funciona, no para que lo dejes en el programa!!

Acostumbrate a la idea que cuando manejas comunicaciones por algun bus de datos, sea SPI, I2C, Can o cualquier otro, debes RESPETARSE las velocidades o nada va a funcionar.

Para darte una idea, el bus SPI puede llegar a velocidades de hasta 1 megabit por segundo.
Dime como verias aun con osciloscopio cuanto de bien o mal anda ese bus, salvo que dispongas de un osciloscopio especializado en comunicaciones.

Saca el manejo de ese led de alli, de otra forma no funcionara nada.
Te recomiendo que compres o te armes un debugger ICD, podria ser el ICDs-40 o el ICDU-40 que andan los circuitos por el foro, usa el buscador y lo encontraras.

Si tienes 2 pines libres del pic, deberias conectarlos a un port serie a traves de un MAX232 y hacer debug utilizandolos, solo recibirias lo que esta pasando en el bus y que va y que viene en el, mirandolo en pantalla.
Si utilizaras la libreria original de CCS podrias aprender a usarlo y luego recien podrias aprender a hacer la tuya.

Si no estableces una comunicacion por CAN estable dudo que aprendas a utilizarla y mas aun dudo que tengas exito en tu primer intento.

En este hilo hubo un usuario (Electrolinux) que estuvo haciendo su propia libreria para el compilador GCC, podrias buscar esa documentacion y utilizarla, incluso tradujo todo al español. :mrgreen: :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 #732 en: 29 de Enero de 2010, 12:47:36 »
respecto la velocidad de acuerdo, pero lo de poner un max 32... no me convence nada esa solucion, ha de ser algo asi como una gran chorrada que esta escondida. Sigo los pasos ( o eso creo) que propone el data..los datasheet.

Estoy viendo algo, si quiero elejir el pic como esclavo, el pin A5 es entrada. Ese pin lo uso como mi chip select ( coincidencias...) pero... vamos a ver...deberia ser una entrada input/output normal y corriente, ya que segun data:

SSPM3:SSPM0: Master Synchronous Serial Port Mode Select bits
(...)
0001 = SPI Master mode, clock = FOSC/16

eso quiere decir que no activo el slave, sino que esta activado como master
Hay problemas con eso?? Ya es lo unico que se me ocurre.


Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7863
Re: Mis experiencias con el BUS CAN
« Respuesta #733 en: 29 de Enero de 2010, 15:06:29 »
Creo que estas agotando lo que me queda de paciencia... :5] :5] :5]

No te han enseñado a trabajar con Metodo??   :shock: :shock: :shock: :x :x

Ya lograste comunicarte y funcionar con las librerias de CCS??   :x :x

NO?? Entonces hazlo.  :huh: :huh: :z) :z)

Cuando hayas hecho eso recien alli puedes seguir con el desarrollo de tu libreria propia, rompiendote el coco porque SABES que lo tuyo ya funciono con lo que todos sabemos que anda.   ;-) ;-) ;-) ;-)

Cuando tengas avances en ese sentido sigue consultando, de otro modo desperdicias mi tiempo que podria dedicarselo a ayudar a otro que si haga caso... :5] :5] :5]
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 #734 en: 29 de Enero de 2010, 18:13:40 »


uhm, es interesante esto que me dices acerca de standard io. La verdad es que mirando el help no da muchas explicaciones acerca de la diferencia entre standard y fast_io, a lo que opté por esta última ya que segun he leido es mas recomendable para cambios rápidos en el pin, y permite el uso de delay's.

Bien tengo implementada -no he hecho grandes lios- una función dentro del main que probara los pines que se corresponden al SPI en el PIC, y cuando vea los resultados de este test ( espero que positivos) cambiaré parasiempre a standard_io, ademas ya he declarado como quiero los 2 o 3 puertos que realmente uso. Probaré lo siguiente y comento resultados:


 

anything