AYUDA-Duda de si el proteus simula bien

[Thulsa Doom]

Hola a tod@s, resulta que estoy implementando por hardware el protocolo de comunicación SPI entre un pic 18F876 y un max6675 y no sé si el proteus está simulando bien o soy yo que no doy con la configuración del protocolo.

Esta es la señal del osciloscopio virtual del proteus:



Como se puede apreciar en la captura, la señal DO de salida del pic corresponderá con la entrada del max SC, línea amarilla
                                                        la señal CLK de salida del pic corresponde con la entrada del pic CLK, línea azul,
                                                        la señal DI de entrada del pic corresponde en la salida max con SO, línea roja
Se supone que la señal DO esta siempre a positivo y se pasa a negativo para habilitar el envío de datos desde el max y en la imagen se ve que siempre está a 0 menos un pequeño pulso.

Cada vez que se pasara el CS a 0, entraría en funcionamiento el CLK del pic enviando un tren de 16 pulsos y como se ve, no solo no lo envía si no que lo divide.

Gracias compañer@s

[MGLSOFT]

Hay una herramienta mejor que el osciloscopio, que es el SPI debugger, que creo te vendrá mejor que lo que ahora haces.
También hay una para I2C.

[AngelGris]

  El pin SDO del PIC es para enviar datos hacia el dispositivo SPI. Y tendría que quedar conectado a un pin DI o SDI del dispositivo.
Para hacer la función de CS (o SC no sé como está escrito) tenés que usar otro pin del PIC y trabajarla manualmente.

[Thulsa Doom]

Vale, entendido, pues gracias a tu ayuda en parte ya funciona, pero no del todo como quiero., solo con añadir la función ENABLE=pin , por ese pin que designo yo, ya sale el pulso correcto

Resulta que el compilador CCS C tiene una librería para integrar el protocolo SPI, el pic puede trabajar de dos formas, implementando el protocolo por software que me funcionaría de esta manera:



o Por hardware, que a mi entender es lo ideal, pero cuando lo fuerzo a que trabaje con hardware la gráfica del osciloscopio que sale es esta:



Si observo que el tiempo es diferente una de otra, siendo más rápida la de hardware, pero por más que modifico los baudios no cambia demasiado.
¿Alguna sugerencia?

[AngelGris]

  Como comentó MGLSOFT, el SPI Debugger es mucho mejor para analizar dicho bus.

  En cuanto a las gráficas, la de Hard se corresponde bien con el protocolo SPI ya que cuando el pin CS está en bajo es cuando aparecen los pulsos de sck y también los datos sobre el puerto.

  ¿Qué baudios modificas?

[Thulsa Doom]

Es que según el datasheet del fabricante del maxim, esa imagen del osciloscopio no coincide, la de arriba si.
el fabricante especifica que la lectura del dispositivo tiene que ser en un tiempo limitado y tiene que ser con 16 pulsos de reloj, el osciloscopio solo muestra esos 16 pulsos pero por separado, en dos paquetes de 8bit.

lo del SPI debuger, puesto el pic en modo spi software si funciona pero en hadware se bloquea el proteus.

los baudios lo modifico en la cabecera en #use SPI(BAUD=n) he probado muchos diferentes

EDITADO: rectifico, ya funciona el SPI debugger lo que no pilla la palabra de 16 bit entera, solo envía 8 bits y recibe 8 bits en cada activación de ss y deberían de ser 16bits según el fabricante del maxim6675

[AngelGris]

  ¿Me podrías indicar cuál es el dispositivo? Así puedo leer el datasheet e intentar ayudarte mejor.

  ¿CCS no tiene una función llamada setup_spi? Porque yo me hice una función con dicho nombre (para el compilador HiTech) y creo que lo había hecho para que sea igual a la de CCS.  Para establecer la velocidad del bus se podían utilizar uno de los siguientes tres parámetros
    SPI_CLK_DIV4 o SPI_CLK_DIV16  o SPI_CLK_DIV64

  Hay cuatro modos de comunicación SPI, tal vez no está el mismo modo en el PIC que en el debugger (eso me ocasionó varios problemas a mí)

  Te muestro la parte de un código en el que ayudé a edu1989 a obtener unos datos de un sensor de temperatura TC77. Había que leer 16 bits y la lectura la hicimos de este modo

Código: C

1. CS = 0;
2.     byte_alto = read_spi();
3.     byte_bajo = read_spi();
4.     CS = 1;

[Thulsa Doom]

vale, el dispositivo es una max6675, es para medir temperatura.

si que la tiene o por lo menos eso pone el manual de CCS.



te pongo lo que puse de código:

Código: [Seleccionar]

//*************programa para manejar el max6675 por el protocolo SPI *************

#INCLUDE <16f876a.h>
#FUSES xt,nowdt,noprotect
#USE delay(clock=4000000)

#define use_portb_lcd TRUE
#include <LCD.C>

#use standard_io (B)
#use standard_io (C)

#use SPI(FORCE_HW,MODE=1,STREAM=spi_stream,ENABLE=pin_C2,BITS=16)

//********************programa************************************************


void leer_dato(){
      int c;
      int16 captura, i;
      c=0xffff;
      
    captura = spi_xfer(spi_stream,c,16);
    
    printf(lcd_putc,"\fTemp=%Lu",captura);
    
}

 void main (){
            
         lcd_init();
    
        
                
      while(TRUE){
      
       leer_dato();
          
          }

se que no esta bien pero estoy haciendo pruebas sobre el protocolo, no me echen la bronca porque no soy ningún experto en la programación en C, me falta mucho todabía pero me gustaría que el protocolo funcionara para empezar a realizar el programa poco a poco, creo que es la mejor manera de aprender, a base de dolores de cabeza y frustración  
al final la recompensa será mayor  

[AngelGris]

  Este es el programita que hice, uso el compilador HiTech así que hay cosas que no son iguales al CCS, pero es tan sencillo que no va a costar nada para adaptarlo.
  Te adjunto una captura de pantalla del Proteus. El SpiDebugger lo configuré como Slave y le agregué un par de bytes para que me los envíe en la comunicación.
  Fijate que en la captura se aprecia como el SpiDebugger pone ?? ?? para el caso de la transmisión del PIC (ya que justamente no estoy transmitiendo nada) y pone correctamente los bytes transmitidos por el propio SpiDebugger

  Este es el programa

Código: C

1. #include <htc.h>
2.  
3. __CONFIG (LVPDIS & HS & BORDIS & WDTDIS);
4.  
5. #include "Def16f87xa.h"
6.  
7. #define PIC_CLK   10000000
8. #define XTAL_FREQ 10000000
9.  
10. #include "delayhd.h"
11. #include "HardSpi.c"
12.  
13. #define CS RB3
14.  
15.  
16. void main(void)
17. {
18.  
19.   TRISA = 0;
20.   TRISB = 0;
21.   TRISC = 0;
22.  
23.   setup_comparator (NC_NC_NC_NC);
24.   setup_adc (ADC_OFF);
25.   setup_adc_ports (NO_ANALOG);
26.  
27.   CS = 1;
28.   setup_spi (SPI_MASTER | SPI_IDLE_L | SPI_CLK_DIV4);
29.  
30.   CS = 0;
31.   read_spi();
32.   read_spi();
33.   CS = 1;
34.   while (1);
35. }

  Y la captura de pantalla

[Thulsa Doom]

Pues ya está solucionado, pongo captura:



resulta que tenia mal puesta la señal de CS, me lié con las especificaciones del protocolo, el manual del CCS y el datasheet del fabricante con lo cual estaba pillando la señal de donde no era, una vez hecha a mano la señal y con los parámetros correctos en #use SPI() y el pequeño programita que me has puesto (modificado por supuesto), ya capturo el dato en dos bytes, los uno y tengo la palabra de 16 bits completa y en orden.
ahora tengo que pelearme con los datos capturados para ver de que modo puedo eliminar los bits que me sobran y pillar los que me interesan
gracias

[AngelGris]

  Dejar sólo los bits que te interesan es sencillo.

  Hacés un shift a la derecha de 3 posiciones (porque según el datasheet el primer bit válido es D3). Luego hacés una and con 0b0000111111111111 (que es lo mismo que 0x0FFF) para asegurarte que los bits más altos estén en 0.

[Thulsa Doom]

Vale, supongo que será lo mismo para los bits en orden inverso, ya que el max envía los datos empezando por D15  y terminando por D0, el dato de interés va de MSB a LSB.
gracias por tu ayuda y la de los demás