Un ejemplo con SPI por favor.

[Enigma]

Ummm bueno así lo tengo conectado!!!! pero igual no me funciona!

PIC                Conversor
SCK               SCLK
SDI                Sin conectar
SDO                DIN

Atte: Enigma... La llanerita de Guayana 

[cerebro]

  es por software o por hardware??

si es por soft lo que esta marcado con rojo esta de más...

#use spi(MASTER,CLK=PIN_B4, DO=PIN_B2, DI=PIN_B1, BITS=8, MODE=3, FORCE_HW, stream=BUSSPI)

y si es por hard

creo que no es necesario ese

#use spi

y utilizar el

setup_spi

[MGLSOFT]

y para enviar el dato al conversor he usado está instrucción...

spi_write( dato );

Donde dato es la variable que recojo del conversor analógico digital del pic, es decir:

dato=(ADC*5)/255;                  // Convierto a analógico

Creo que hay un error aquí...

Si yo no entiendo mal, ese es un conversor D/A.
Por lo tanto deberías primero convertir tu valor en la palabra dato y recién después enviarla.
Por lo que entiendo ese conversor no se lee, solo se escribe por SPI.

[Suky]

es por software o por hardware??

si es por soft lo que esta marcado con rojo esta de más...

#use spi(MASTER,CLK=PIN_B4, DO=PIN_B2, DI=PIN_B1, BITS=8, MODE=3, FORCE_HW, stream=BUSSPI)

y si es por hard

creo que no es necesario ese

#use spi

y utilizar el

setup_spi

No, indica que debe ser por software, en ese caso debe cambiarlo por FORCE_SW

[Enigma]

Ya va pero s lo hago por hardware, porque no es necesario la instrucción:

#use spi(MASTER,CLK=PIN_B4, DO=PIN_B2, DI=PIN_B1, BITS=8, MODE=3, FORCE_HW, stream=BUSSPI)

Con está instrucción no debo definir los pines que me van a hacer la comunicación...??? Ayyy estoy confundida....


Si MGLSOFT tienes razón.... debo convertirlo!!!!

Y bueno ya hice eso y nada.... 

Será que este conversor no se simula en proteus??... Porque creo que la conexión del dispositivo está bien...

Ahora he visto algo, el CLK siempre se mantiene en bajo.... este no ebria oscilar entre bajo y alto??? Y SDO siempre está en alto!!!!

Atte: Enigma... La llanerita de Guayana   

[cerebro]

 
 vamos desde el principio y recurrimos a la fuente de sabiduría infinita (la hoja de datos del micro  )

copio y pego tal cual la pagina 89

Código: [Seleccionar]

SPI mode allows 8 bits of data to be synchronously
transmitted and received simultaneously. To
accomplish communication, typically three pins are
used:
• Serial Data Out (SDO) RB2/SDO/RX/DT
• Serial Data In (SDI) RB1/SDI/SDA
• Serial Clock (SCK) RB4/SCK/SCL
Additionally, a fourth pin may be used when in a Slave
mode of operation:
• Slave Select (SS) RB5/SS/TX/CK


When initializing the SPI, several options need to be
specified. This is done by programming the appropriate
control bits in the SSPCON register (SSPCON<5:0>)
and the SSPSTAT register (SSPSTAT<7:6>). These
control bits allow the following to be specified:
• Master mode (SCK is the clock output)
• Slave mode (SCK is the clock input)
• Clock Polarity (Idle state of SCK)
• Clock Edge (output data on rising/falling
edge of SCK)
• Clock Rate (Master mode only)
• Slave Select mode (Slave mode only)
Hablemos del hardware, el micro posee un puerto serial sincrónico (SSP) que puede ser utilizado tanto en modo  SPI o en modo I2C, los pines del puerto ya están preestablecidos en su arquitectura y los detalla la hoja 89. Para utilizar el modulo faltaría configurar el puerto afectando los registros (SSPCON y SSPSTAT) eso lo hacemos en asembler o utilizamos la función setup_spi(). Las funciones que vamos a utilizar seria spi_write y spi_read.

Ahora CCS a partir de las últimas versiones ha implementado SPI por software (si vas a una versión más viejita ni siquiera existía #use spi), de manera que #use spi se utiliza para comunicación por soft osea CCS ocupa recursos e implementa la comunicación a lo bestia dentro del micro. Por eso es necesario explicarle que pines queremos nosotros que sean el clock, la entrada de datos y la salida de datos.

 También podemos usar #use spi para configurar la comunicación y forzarlo a que sea por hardware como indica el ejemplo del CCS
 

Código: [Seleccionar]

#use spi(FORCE_HW, BITS=16, stream=SPI_STREAM)

// uses hardware SPI and gives this stream the name SPI_STREAM
Aca podemos utilizar la funcion spi_xfer.

Fijate la diferencia entre SPI_READ ( o SPI_WRITE) y SPI_XFER

SPI_READ
Availability:
 This function is only available on devices with SPI hardware.

SPI_XFER
Availability:
 All devices with SPI support.

 
Pero de ninguna manera fozarlo por hard y pasarle los pines que queramos como entradas o salidas, se entiende?  .

Saludos!! 

[Enigma]

Si esa parte del Datasheet me la había leído ya!!! y como tres veces cuando las instrucciones no me empezaron a funcionar en el CCS, ahora lo que tu me tratas de decir es que no es necesario que declare los pines del SPI cuando lo mando a trabajar por hardware???.... Bueno esa instrucción ya la había probado antes y pues no me funcionó en realidad no se que estoy haciendo mal en el programa vale!!!!!


Atte: Enigma... La llanerita de Guayana

[Gonzalo_BlackHawk]

Preguntas para alguien que halla utilizado el SPI por SW:

¿Que velocidades de transmisión se pueden alcanzar ?
¿Requiere mucha memoria para su utilización ?
¿Cual es el límites de bytes que se pueden transmitir en un mismo envio?

El SPI por hardware es bastante rápido si se programa bien, he logrado conseguir 5 Mbps en transmisión full duplex para una frecuencia de oscilador de 20 MHz con un polling de 10 us entre bytes (Que estoy seguro que se puede bajar más). El problema del SPI por HW es que el compilador CCS lo tiene mal implementado en sus librerías , que el buffer de transmisión es de solo 1 byte y que además obviamente uno esta atado a utilizar los pines preestablecidos. Sin embargo si se tienen los pines disponibles y si se tiene ganas de crear un libreria desde cero para controlar el modulo SSP, entonces el jugo vale la exprimida.

Saludos.

[Enigma]

Estás preguntando??? No entiendo!!!

Atte: Enigma... La llanerita de Guayana

[MGLSOFT]

#USE SPI

--------------------------------------------------------------------------------

 

Syntax:
 #use spi  (options)

 
 
Elements:
 Options are separated by commas and may be:

MASTER
 Set the device as the master. (default)
 
SLAVE
 Set the device as the slave.
 
BAUD=n
 Target bits per second, default is as fast as possible.
 
CLOCK_HIGH=n
 High time of clock in us (not needed if BAUD= is used). (default=0)
 
CLOCK_LOW=n
 Low time of clock in us (not needed if BAUD= is used). (default=0)
 
DI=pin
 Optional pin for incoming data.
 
DO=pin
 Optional pin for outgoing data.
 
CLK=pin
 Clock pin.
 
MODE=n
 The mode to put the SPI bus.
 
ENABLE=pin
 Optional pin to be active during data transfer.
 
LOAD=pin
 Optional pin to be pulsed active after data is transferred.
 
DIAGNOSTIC=pin
 Optional pin to the set high when data is sampled.
 
SAMPLE_RISE
 Sample on rising edge.
 
SAMPLE_FALL
 Sample on falling edge (default).
 
BITS=n
 Max number of bits in a transfer. (default=32)
 
SAMPLE_COUNT=n
 Number of samples to take (uses majority vote). (default=1
 
LOAD_ACTIVE=n
 Active state for LOAD pin (0, 1).
 
ENABLE_ACTIVE=n
 Active state for ENABLE pin (0, 1). (default=0)
 
IDLE=n
 Inactive state for CLK pin (0, 1). (default=0)
 
ENABLE_DELAY=n
 Time in us to delay after ENABLE is activated. (default=0)
 
DATA_HOLD=n
 Time between data change and clock change
 
LSB_FIRST
 LSB is sent first.
 
MSB_FIRST
 MSB is sent first. (default)
 
STREAM=id
 Specify a stream name for this protocol.
 
SPI1
 Use the hardware pins for SPI Port 1
 
SPI2
 Use the hardware pins for SPI Port 2
 
FORCE_HW
 Use the pic hardware SPI.
 

 
 
Purpose:
 The SPI library contains functions to implement an SPI bus.  After setting all of the proper parameters in #use spi, the spi_xfer() function can be used to both transfer and receive data on the SPI bus.

 

The SPI1 and SPI2 options will use the SPI hardware onboard the PIC. The most common pins present on hardware SPI are: DI, DO, and CLK. These pins don’t need to be assigned values through the options; the compiler will automatically assign hardware-specific values to these pins. Consult your PIC’s data sheet as to where the pins for hardware SPI are. If hardware SPI is not used, then software SPI will be used. Software SPI is much slower than hardware SPI, but software SPI can use any pins to transfer and receive data other than just the pins tied to the PIC’s hardware SPI pins.

 

The MODE option is more or less a quick way to specify how the stream is going to sample data. MODE=0 sets IDLE=0 and SAMPLE_RISE. MODE=1 sets IDLE=0 and SAMPLE_FALL. MODE=2 sets IDLE=1 and SAMPLE_FALL. MODE=3 sets IDLE=1 and SAMPLE_RISE. There are only these 4 MODEs.

 

SPI cannot use the same pins for DI and DO.  If needed, specify two streams: one to send data and another to receive data.

 

The pins must be specified with DI, DO, CLK or SPIx, all other options are defaulted as indicated above.
 
Examples:
 #use spi(DI=PIN_B1, DO=PIN_B0, CLK=PIN_B2, ENABLE=PIN_B4, BITS=16)

// uses software SPI

 

#use spi(FORCE_HW, BITS=16, stream=SPI_STREAM)

// uses hardware SPI and gives this stream the name SPI_STREAM

 
/quote]

Esta es la definicion de Use_SPI
Saquen sus conclusiones...

[Gonzalo_BlackHawk]

Estás preguntando??? No entiendo!!!

Atte: Enigma... La llanerita de Guayana

Si, mis dudas son acerca del SPI por SW, yo solo opino de mi experiencia con el SPI por HW.

[Enigma]

Rayos he pasado toda la noche, cambiando instrucciones, leyendo tutoriales, definiciones, cambiando el programa y nada!!! He vuelto a lo mismo!!! Será el proteus que no simula...?


Atte: Enigma... La llanerita de Guayana

[MLO__]

El proteus tiene un SPI Debugger

[Enigma]

Si lo se, ya lo ejecute.... y miren lo estados que me salen....




Atte: Enigma... La llanerita de Guayana

[MLO__]

Ese warn del logic contentions, refiere a los pines del SPI?