TWI Nack nach zweitletztem Byte?

Hallo,

dass TWI beim Senden einer Start-Condition hängen bleibt kann aus 
verschiedenen Gründen passieren und ist absolut in Ordnung - das musst 
du durch einen TimeOut selbst abfangen.

Der Grund warum er hängen bleibt ist das interessante.
Ich vermute eher dass du bei der vorherigen Übertragung kein STOP 
gesendet hast und/oder deine Leitungen nicht auf HIGH liegen (aus 
welchem Grund auch immer)
also schau noch mal richtig nach
an dem ACK/NACK liegt es sicher nicht, denn du kannst eine Übertragung 
jederzeit durch ein STOP beenden und alle (Slaves) gehen in 
Wartestellung


Gruss

Stefan schrieb:
> an dem ACK/NACK liegt es sicher nicht, denn du kannst eine Übertragung
> jederzeit durch ein STOP beenden und alle (Slaves) gehen in
> Wartestellung

Das wage ich zu bezweifeln, mein Code sieht nämlich folgendermassen aus:

1

I2C_interface.TWIM_Start(0x1D,TWIM_WRITE);

2

I2C_interface.TWIM_Write (0x01);

3

I2C_interface.TWIM_Start(0x1D,TWIM_READ);

4

5

x_high = I2C_interface.TWIM_ReadAck();

6

x_low = I2C_interface.TWIM_ReadAck();

7

y_high = I2C_interface.TWIM_ReadAck();

8

y_low = I2C_interface.TWIM_ReadAck();

9

z_high = I2C_interface.TWIM_ReadNack(); //!!!!!hier muss ich das NACK setzen!!!!

10

z_low = I2C_interface.TWIM_ReadNack();

11

12

I2C_interface.TWIM_Stop ();

Wenn ich das NACK nicht dort setze, wo ich es im Code markiert habe, 
dann hängt der Controller und das auch, obwohl ich die Übertragung mit 
einem Stop beende.

Hallo,

Roman schrieb:
> Wenn ich das NACK nicht dort setze, wo ich es im Code markiert habe,
> dann hängt der Controller und das auch, obwohl ich die Übertragung mit
> einem Stop beende.

sollte das wirklich so sein, dann hast du was ganz Grundlegendes 
übersehen, denn ein Master darf sich nie von einem Slave blockieren 
lassen! (sofern er nicht zerstört ist)
Auch bei noch so falschen Signalen müssen alle Teilnehmer nach einer 
kurzen Ruhephase ( wenige Millisekunden)  wieder in Anfangsstellung 
gehen.

Gruss

cyblord ---- schrieb:
> Er benötigt zwingend ein NAK damit er
> aufhört zu senden und überhaupt auf ein STOP reagieren kann.


NEIN,

mit jederzeit hatte ich natürlich "byte-boundary" gemeint !!!

Peter Dannegger schrieb:
> Nö.
> Dumme I2C-Slaves gehen nie von allein in Reset. Du kannst sie auch mit
> einem SCL von 1 Bit/Jahr takten.

Also von nicht normgerechten Sachen sollten wir nicht reden !!!

Hallo,

Stefan schrieb:
> Peter Dannegger schrieb:
>> Nö.
>> Dumme I2C-Slaves gehen nie von allein in Reset. Du kannst sie auch mit
>> einem SCL von 1 Bit/Jahr takten.
>
> Also von nicht normgerechten Sachen sollten wir nicht reden !!!

ich muss mich berichtigen !!!
In der Spec steht dass es für gewöhnliche keinen Timeout für den Reset 
gibt sondern lediglich für die Erweiterung zu SMBus

Originalton: There is no limit in the I2C-bus protocol as to how
long this delay can be, whereas for a SMBus system, it would be limited 
to 35 ms.

Mein Code für ACK/NACK ist der folgende:

1

uint8_t I2C::TWIM_ReadAck (void)

2

  {

3

  TWCR = (1<<TWINT)|(1<<TWEN)|(1<<TWEA);

4

  while (!(TWCR & (1<<TWINT)));

5

6

  return TWDR;

7

  }

8

9

uint8_t I2C::TWIM_ReadNack (void)

10

  {

11

  TWCR = (1<<TWINT)|(1<<TWEN);

12

  while(!(TWCR & (1<<TWINT)));

13

14

  return TWDR;

15

  }

Ich bin jetzt ein wenig verwirrt aufgrund der unterschiedlichen 
Meinungen.
Ich gehe jetzt mal davon aus, dass das NACK nach dem lesen des 
zweitletzten Bytes vom Master gesetzt werden muss, so wie es Peter 
Dannegger bestätigt hat. Ausserdem muss zwingend vor einem Stop ein NACK 
gesendet werden, zumindest geht bei mir ansonsten gar nichts mehr mit 
TWI.