I2C: Fehlerhandling

Hallo Kollegen,

kleine Frage: Wenn ich versuche mit einem I2C Slave zu sprechen und es kommt bsp. anstatt eines mt_data_ack ein mt_data_nack, hab ich ja ein Problem. Wie bringe ich den Bus dann wieder in einen Ok zustand? Muss ich einfach eine Stop Condition senden und es später nochmal probieren?

PseudoCode:

Code:

---

      //  sent byte from the queue
        send_byte(data);

.....

        // check if the data was accepted
        if(!is_answer_tw_mt_data_ack())
        {
            // data was declined, set a flag for the user
            send_stop_condition();
            m_error_code = rx_no_answer_tw_mt_data_ack;
            return;
        }

---

Ist das die richtige Methode den Atmega I2C Master wieder in einen guten Zustand zu bringen?

Edit: Das hab ich daszu im Datasheet des Atmega168 gefunden auf Seite 219

Zitat:

---

7. The application software should now examine the value of TWSR, to make sure that the
data packet was successfully transmitted, and that the value of the ACK bit was as
expected. If TWSR indicates otherwise, the application software might take some special
action, like calling an error routine. Assuming that the status code is as expected, the
application must write a specific value to TWCR, instructing the TWI hardware to transmit
a STOP condition. Which value to write is described later on. However, it is important that
the TWINT bit is set in the value written. Writing a one to TWINT clears the flag. The TWI
will not start any operation as long as the TWINT bit in TWCR is set. Immediately after
the application has cleared TWINT, the TWI will initiate transmission of the STOP condition.
Note that TWINT is NOT set after a STOP condition has been sent.

---

Hallo schorsch_76

Hat der I2C Master ein Slave gefunden, sind Abfragen nur mit diesem möglich.
Möchtest du den Bus wieder freigeben Muss ein Stop kommen.
In Bascom mit Befehl [I2cstop]

Mit freundlichen Grüßen
fredred

Ja, klar. Wenn ich die Kommunikation mit einem Slave gestartet hab, dass ich nur mit diesem sprechen kann. Allerdings kann nach einem Repeated Start auch wieder mit einem anderen Slave gesprochen werden.

Na ich handhabe das jetzt so wie ichs mal aus dem Datasheet ableiten kann. Falls ein Slave nicht richtig antwortet ein Stop Command schicken.

Meinem Ziel komme ich schon immer näher. ;) Es soll halt der eine Part A weiterlaufen können falls Part B ausfällt.