[SOLUCIONADO]Dudas con 2 módulos MSSP en el mismo micro con C18

[Thulsa Doom]

Hola a todos, pues tengo un PIC18F67J50 que tiene dos módulos MSSP y quiero que por el MSSP1 esté el protocolo SPI y por el MSSP2 esté el protocolo I2C al mismo tiempo, tengo entendido que no habría conflictos entre ellos.

Estoy utilizando la libreía i2c.h y spi.h, ¿que tendría que hacer para que cada protocolo trabaje con módulo diferente?

por lógica sería para el SPI utilizar las funciones de este modo ReadSPI1() y para el I2C ReadI2C2(), ¿sería de este modo?

Una de las dudas que tengo es que cuando implemento la librería de I2C por ejemplo, me configura las patillas SDA y SCL tanto la del módulo 1 como la del 2 y eso me confunde un poco ya que en el módulo 1 ya tengo definido las patillas del protocolo SPI.

¿Qué opinan?

[Thulsa Doom]

Hola a todos, ¿nadie me puede orientar sobre el tema?.

he estado haciendo pruebas y me he dado cuenta de cosas que suceden.

Si implemento un módulo solo, por ejemplo el MSSP2 para I2C todo va perfecto, pero desde que implemente el módulo 1 (MSSP1) con el protocolo SPI pues ahí la cosa cambia.

haciendo debugger del proyecto, me he dado cuenta que en registro SSP2CON2bits.RCEN que hay que ponerlo a 1 para que empiece el protocolo I2C a funcionar no lo cambia. el programa llega hasta esta sentencia pasa por encima pero no cambia en el registro del micro, ¿alguien tiene alguna idea de por qué?

[KILLERJC]

Si no, inicializalos a mano, cambiando los registros y luego lo manejas con las librerias.

[Thulsa Doom]

Pues he hecho lo que me dices y nada, cuando llega a esta sentencia

Código: [Seleccionar]

SSP2CON2bits.RCEN = 1;           // enable master for 1 byte reception
para por encima y no cambia el bit en el registro y luego se queda en esta esperando

 

Código: [Seleccionar]

while ( !SSP2STATbits.BF );      // wait until byte received
No sé si será un bug del c18 pero ya me está rayando no se que hacer para solucinarlo

[KILLERJC]

Disculpa se me complica al no ver toda la configuracion de ambos, aunque no creo que ayude en mucho, pero esto dice sobre el RCEN

If the I2C module is active, these bits may not be set (no spooling) and the SSPxBUF may not be written (or writes to the SSPxBUF are disabled).

Podrias usar para pollear el flag de interrupcion.
PIR3 SSP2IF: Master Synchronous Serial Port 2 Interrupt Flag bit
1 = The transmission/reception is complete (must be cleared in software)


El PORTC tiene el MSSP1
y PORTD el MSSP2

Estuve revisando y si usas de la libreria:

OpenSPI1(unsigned char sync_mode, unsigned char bus_mode, unsigned char smp_phase) y OpenI2C2(unsigned char sync_mode, unsigned char slew)

No te activa ambos ? y te olvidas de andar configurandolos por vos mismo?
Y otra de las cosas, mira el codigo de leer el registro usando en la funcion ReadSPI1, se basa en el flag:

Código: C

1. unsigned char ReadSPI1( void )
2. {
3.   unsigned char TempVar;
4.   TempVar = SSP1BUF;       //Clear BF
5.   PIR1bits.SSP1IF = 0;     //Clear interrupt flag
6.   SSP1BUF = 0x00;          // initiate bus cycle
7.   //while ( !SSP1STATbits.BF );                // wait until cycle complete
8.   while(!PIR1bits.SSP1IF); //wait until cycle complete
9.   return ( SSP1BUF );      // return with byte read
10. }

Pero el de I2C en el bit BF :/

[Thulsa Doom]

Hola, esas sentencias que has puesto no son las mismas de mi driver i2c que viene por defecto el el c18 v3.47

la que tengo yo es esta:

Código: [Seleccionar]

#if defined (I2C_V3) || defined (I2C_V6) || defined (I2C_V6_1)
unsigned char ReadI2C2( void )
{

if( ((SSP2CON1&0x0F)==0x08) || ((SSP2CON1&0x0F)==0x0B) ) //master mode only
  SSP2CON2bits.RCEN = 1;           // enable master for 1 byte reception
  while ( !SSP2STATbits.BF );      // wait until byte received 
  return ( SSP2BUF );              // return with read byte
}
#endifNo sé de donde has sacado esa función, de todas maneras la he probado y me da error de compilación

Estoy implementado en el MSSP1 el protocolo SPI y en el MSSP2 el protocolo I2C.

Estoy utilizando las librerías TCP/IP de microchip y quiero meterle un termómetro digital en el MSSP2 ya que el 1 está la memoria 25LC1024 y el EMC28J60

Una de las cosas que he hecho es montar un proyecto nuevo con solo estos dos protocolos implementados tal como dije y que lea el termómetro y lea la memoria y después de unos enganches ahora ya funciona.

Paso esas mismas librerías del proyecto de prueba al proyecto TCP/IP y al principio no funcionaba.

(esto es un poco lioso voy a procurar ser lo más claro posible)

mientras corría el proyecto en modo debugger para ver los valores de los registros y de los puertos, observé que cuando llegaba a la sentencia de estarti2c2, no activaba el bit SSP2CON2bits.SEN = 1;, así como restart12c2 (SSP2CON2bits.RSEN = 1; ), ReadI2C2 (SSP2CON2bits.RCEN = 1;) y StopI2C2(SSP2CON2bits.PEN = 1;) , la flecha verde pasaba por encima pero el bit no cambiaba en el registro, lo que hice fue saque esa sentencia de la función y la puse directamente en el driver del dispositivo y empezó a funcionar pero no del todo bien, (ahora lo explico).

una vez que empezó a funcionar le saque esas sentencias y les dejé las originales de la librería y para mi sorpresa seguía trabajando bien.

ahora lo que hace es que no lee el dato del termómetro, el dato que sale es todo 1, ósea 1111111, mirando los registros del puerto D el bit SLC2 (D6) si cambia de estado pero el SDA2 (D5) no cambia, está siempre a 1 cosa que en el proyecto de prueba que hice anteriormente si cambia y lee bien el valor.

Por todo ello pienso que este compilador tiene algún bug relacionado con esto porque no se comporta de un modo lógico si no errático y ahí ya no sé como lo puedo solucionar

[KILLERJC]

Perdon la funcion es del SPI, La del I2C es la misma que pasaste vos

mientras corría el proyecto en modo debugger para ver los valores de los registros y de los puertos, observé que cuando llegaba a la sentencia de estarti2c2, no activaba el bit SSP2CON2bits.SEN = 1;, así como restart12c2 (SSP2CON2bits.RSEN = 1; ), ReadI2C2 (SSP2CON2bits.RCEN = 1;) y StopI2C2(SSP2CON2bits.PEN = 1;) , la flecha verde pasaba por encima pero el bit no cambiaba en el registro, lo que hice fue saque esa sentencia de la función y la puse directamente en el driver del dispositivo y empezó a funcionar pero no del todo bien, (ahora lo explico).

El Start/Stop bit se limpia por HW, asi que imagino que cuando manda el bit de start es tan rapido que el mismo HW lo pone a 0.

RCEN: Receive Enable bit (Master Receive mode only)(2)
1 = Enables Receive mode for I2C
0 = Receive Idle

PEN: Stop Condition Enable bit(2)
1 = Initiates Stop condition on SDAx and SCLx pins. Automatically cleared by hardware.
0 = Stop condition Idle

Y el otro es igual.

(2): If the I2C module is active, these bits may not be set (no spooling) and the SSPxBUF may not be written (or writes to the SSPxBUF are disabled).

No se a que se refiere con activo. imagino que debe ser si esta mandando algo, y ante eso no cambiaria

[Thulsa Doom]

Aaaa vale, perdón por no fijarme 

Todas esas pruebas las hago en modo debugger con un ICD3 que puedo para el proceso en el momento que quiera por muy rápido que sea el micro.
he comparado los estados de los registros en el proyecto que si que funciona y en el que no funciona, y en el que funciona los registros se ponen a 1 y a 0 según como dice el protocolo de comunicación y cómo dice el datasheet.

por eso comento que cuando el programa llega a la parte donde el registro se pone a 1 no sé que pasa que no hace caso a la orden y no lo pone, como dije antes lo comparo con el  proyecto que si que funciona y ahí si que cambia de estado como debería de ser.

por eso comento que no sé si será un bug del compilador o algo.

a lo que me con activo, es cuando el registro por ejemplo el SSP2CON2bits.RSEN está a 0 y pasa a 1

esto me está agotando la paciencia llevo ya como una semana con esto y lo que no quiero es tener que implementarlo por software cuando tengo un micro que es una bestia con dos módulos MSSP y que solo puedo utilizar uno porque hay algo que me impide implementarlo.

el mismo datasheet del fabricante dice que son módulos independientes... la verdad es que no lo entiendo 

[KILLERJC]

Si son modulos independientes, lo unico que puedo llegar a notar distinto si es que lo configuraste a mano ( es decir modificando los registros ) y no con el API, es que lo estes configurando mal o se te escape algun bit.

Por eso mismo te decia que probes iniciando los modulos con la API

OpenSPI1(unsigned char sync_mode, unsigned char bus_mode, unsigned char smp_phase)
y
OpenI2C2(unsigned char sync_mode, unsigned char slew)

En ese caso la primer funcion hace uso del Puerto C y la segunda del puerto D, a su ves utiliza los registros 1 y 2 , es lo unico que cambia entre en 1 y 2 ... nada mas.

[Thulsa Doom]

Si lo he configurado con el API y a mano y el resultado es el mismo, la configuración no es el problema, se configura bien con cualquiera de los dos métodos, el problema es a la hora de la ejecución del protocolo que no cambian el valor del registro de por ejemplo el star, al no cambiar ese registro pues la comunicación no se inicia y se pilla.

si quieren puedo subir unas capturas de pantalla tanto del proyecto que funciona como del que no para que vean a lo que me refiero.

¿en serio que nadie ha tenido problemas con esto?, a que voy ha ser el único   

[KILLERJC]

Lo raro es que en un proyecto te funciona y en el otro no e.e,, no se que decirte ya :/

[Thulsa Doom]

Ya, esto me recuerda mucho a cuando intentas implementar el protocolo I2C por software y con el MPLAB IDE, aunque le digas al compilador que quieres utilizar unos pines determinados el va a lo suyo y no los cambia, pilla los de por defecto siempre hasta que de buenas a primera va y los pilla.

Cambias de ID y utilizas el MPLABX y pilla los pines que has cambiado a la primera 

El problema es que no veo una salida ha esto ya que si es problema del compilador + IDE ahí ya no puede uno hacer nada.

por eso preguntaba por si al utilizar los dos módulos en protocolos diferentes habría que hacer alguna tontería más o algo pero como leo en el datasheet que son independientes ya no sé que más puedo hacer

[KILLERJC]

El datasheet dice que son independientes, la unica solucion que quedaria es ver el ASM generado, e intentar el ejemplo mas simple de todos

[Thulsa Doom]

Ufff ahí ya me pierdo en ASM no estoy muy puesto 

[Thulsa Doom]

Hola de nuevo a todos.....

Pues no me pregunten ni por qué ni cómo pero ya está funcionando el protocolo I2C tanto por hardware como por software.

al igual será porque agregué el .lkr al proyecto, no lo tenía, los proyectos demos que viene con la librería no lo trae, lo añadí al proyecto y a la cola de archivos de el MPLAB y ya funciona. 

La verdad que me quedo así