Si además quieres enviarnos un Artículo para el Blog y redes sociales, pulsa el siguiente botón:
Buenas noches,
Preguntaba si me podrías ayudar en relación a un proyecto que estoy realizando de Domótica utilizando microcontroladores PIC de gama media PIC16F876.
Utilizando las rutinas I2C (lectura y escritura) no consigo establecer la comunicación entre un Master y dos esclavos entradas. El Master lee del 1º esclavo perfectamente pero cuando intenta leer del 2º esclavo se pierde.
Lo curioso es que si funciona correctamente si utilizo un Master y dos esclavos salidas, es decir el Maestro escribe un byte sobre el esclavo. He intentado de todo y no consigo
solucionarlo. Sin embargo las rutinas funcionan (están muy probadas) con módulos PCF 8574, Eeprom............. como comento solo cuando se trata de más de un Slave entrada. Si conoces
la respuesta o bien alguna página donde exista un proyecto con varios PIC 16F876 con I2C, te lo agradecería. Tengo que entregar el proyecto muy pronto.
La conclusión a la que he llegado es:
El maestro lee basura (N11 N11 N11...) porque el segundo eslavo es incapaz de detener la señal de reloj SCL y al tardar en localizar el dato, finalmente no existe esa sincronización y la información se pierde.
Mi pregunta es: como se consigue detener la señal de reloj SCL., cuando intenta leer el Maestro del segundo esclavo? . Tengo el programa configurado de tal forma, que el Maestro lee de los esclavos solo cuando estos cambian de estado (PORTB). Se produce una interrupción en el Maestro y entonces lee del primer y segundo esclavo.
He intentado todo desde mis reducidos conocimientos I2C, configuración registros MSSP, utilizando retardos, ...etc y nada. Donde podría encontrar una rutina/ejemplo/publicación
/información (a parte del Datasheet que no me resuelve nada) donde me explique como detener la señal SCL para que sincronice perfectamente con cada uno de los dispositivos. Es decir poder controlar la señal SCL y SDA. Creo que es lo que no domino hacer.
Un saludo, (gracias)
Walter Pérez 😯
Asi, sin conocer el hardware ni el software que estás utilizando es difícil de aconsejar soluciones...
¿Están correctamente direccionados los esclavos? No puedes poner dos en la misma dirección: intentarán comunicar a la vez y se producirá un error.
¿Has probado a conectar solo el segundo esclavo?. Aparentemente el problema es de arbitrio de bus. El primer esclavo interfiere en la comunicación del segundo, el maestro no puede detectar ACK porque algún esclavo está interfiriendo.
¿Usas el módulo interno I2C o el proceso es por software?
¿El software del PIC es el mismo para los que hacen de entradas y de salidas? El bit de ACK es inmediatamente posterior al de RW, si no dejas flotante SCL no puedes recibir el bit ACK. En escritura es el esclavo el que genera ACK, pero en lectura es el maestro.
No es necesario detener SCL, la gestión del bus se hace automáticamente mediante las diecciones de los dispositivos y los bits de aranque, parada y ACK. Lo que tiene que ocurrir es que todos los dispositivos respondan correctamente a estas órdenes.
Si solo da problemas con el segundo esclavo y estos problemas son solo en la lectura, es probable que el fallo no se deba al bus o a las conexiones (ya que la escritura la hace bien) y que el fallo este en la programacion de el segundo esclavo. revisa ese punto, sobretodo si el bus lo has implementado por soft
Adjunto software del Master y los dos esclavos entradas. El programa está simulado con el Proteus (adjunto pantallaso).
El programa está configurado de tal forma que si cualquiera de los dos esclavos cambia de estado en su PORTB, activa una patita RC5, que a su vez genera una interrupción en el Master. Entonces este, según si activa el RB7 o RB6, lee una dirección u otra de cada esclavo. El Master recibe la siguiente cadena cuando lee del primer esclavo; S 01 A 73 N P (siendo 01 la dirección del esclavo y 73 el PORTB). Pero cuando procede a leer del segundo esclavo, recibe basura N 11 N 11 N 11.... A la inversa, el Master lee correctamente del segundo esclavo ( S 11 A 41 N P), siendo 11 la dirección y 41 el dato del PORTB. Nuevamente si intento leer seguidamente del pimero, recibo basura N 01 N 01 N 01 ....
Lo que he analizado es que cuando leo de un esclavo el otro también carga su dirección en la rutina MSSP HANDLER, y es incapaz de rechazar la dirección que no le corresponde y es entonces cuando los flags BF y SSPOV están llenos y es incapaz cuando realmente el Master quiere leer de él, de generar por hardware el bit ACK porque el buffer está lleno. Si realmente cuando su direcciión no coincide porque se carga con la dirección?????
He utilizado las rutinas de tratamiento de Alejandro, de esta web, pero no se si tengo que modificar algo. Las rutinas están en los documentos adjuntos.
Espero puedan ayudarme con esta explicación.
Gracias por la ayuda
