Por lo que entiendo, las funciones sirven para generar el estado de "respuesta" y "no respuesta".
Eso debería ser cuando tu master quiera responder o no al dispositivo. Lo extraño también es que debas utilizarlas cuando es el turno del dispositivo de responder o no.
Quiero decir que, en teoría, no debería estar, por ejemplo, el primer "SWAckI2C()" ya que en ese momento es el dispositivo quien tiene que responder y no el master.
Tengo unas rutinas de I2C por soft para HiTEch y me comuniqué con memorias y otros dispositivos sin problemas y sólo usaba mis funciones de ACK cuando era el master quien tenía que responder.
Pregunta al margén, ¿Estás utilizando las resistencias de tipo pull-up de proteus para el bus I2C? No tienen que ser del tipo genérica sino del tipo pull-up sino te puede dar cualquier clase de conflictos el proteus.
Pues coincido con usted, es más cuando implemento el i2c por hardware no utilizo los Ack si no los dos del final como muestra la captura del datasheet del fabricante y va perfecto.
Pero si lo intento hacer por software el resultado es nefasto y haga lo que haga el penúltimo Ack lo envío como un NotAck.
cuelgo el código modificado para dejarlo más claro.
/* Funsión que lee el valor de los registros TH y TL en una resolución de 0.50 ºC*/
float read_temp_normal_precision(unsigned char address){ // Returns degrees ºC (0 a 257)
unsigned char ReadTemp_TH, ReadTemp_TL;
float ReadTemp;
//Read Temperature (AAh)
SWStartI2C();
SWWriteI2C(0x90 | (address<<1)); //Establecemos la comunicación como escritura
SWWriteI2C(0xAA); //Enviamos el comando
SWRestartI2C(); //Reseteamos el protocolo, sin esto no funciona la lectura
SWWriteI2C(0x91 | (address<<1)); //Establecemos la lectura de registro de temperatura del DS1621
ReadTemp_TH = SWReadI2C();
SWAckI2C(); //El Master envía el bit ACK
ReadTemp_TL = SWGetcI2C();
SWNotAckI2C(); //El master envía el bit NOACK
SWStopI2C();
//Código donde se unen los dos byts en un float
ReadTemp = ReadTemp_TH;
if(ReadTemp_TL == 0b10000000)
{
ReadTemp += 0.5;
}
return(ReadTemp);
}
Y si implemento el código tal cual está como en la parte de arriba, el penúltimo Ack lo envía cómo un NotAck y el último lo envía como un Ack debiendo der un NotAck, ósea que lo invierte
Cuelgo una captura de la ventana i2c del proteus, donde se puede ver en el recuadro rojo un ciclo de lectura del dispositivo DS1621
es más he implementado esto en un chip físico y tengo el mismo resultado que en el proteus, no sé si será problema de velocidad del bus que al igual va más rápido de lo que soporta, pero claro eso me pasa en simulación tanto como en hardware real, No entiendo nada
A su otra pregunta, Si estoy utilizando resistencias de pull-ups, pues he utilizado las propias del chip en el puerto B, y otras como resistencias normales tanto como las de pull-ups del proteus y el resultado es el mismo.
En el montaje por hardware al principio no me funcionaba pero era por culpa de las resistencias, las añadí y se le saco el problema
