- LiTime Speicher und Akkus         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 19

Thema: I²C - Stop Bestätigung?

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    26.05.2005
    Ort
    Kaiserslautern
    Beiträge
    794

    I²C - Stop Bestätigung?

    Anzeige

    LiFePo4 Akku selber bauen - Video
    Hi,

    wollte euch mal fragen, ob ihr wisst, wie ich bei dem I²C Protokoll in nem AVR (HW) gucken kann, ob die STOP Bestätigung gesendet wurde, bzw. auf was ich danach warten muss, bevor das nächste START kommt.

    Vielen Dank für eure Hilfe

    Gruß, Lasse

  2. #2
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    10.08.2004
    Ort
    Großbardorf
    Alter
    36
    Beiträge
    674
    Willst du direkt nach dem STOP wieder ein START schicken? Dann kannst du auch einen sogenannten "repeated start" machen. Das bedeutet, du sendest einfach wieder ein START, ohne davor ein STOP zu senden, so kann man z.B. die Addressierung ändern, ohne, dass der AVR die Kontrolle über den TWI-Bus evtl. an einen anderen µC verliert.

    Falls du aber doch ein STOP senden willst, kannst du meines Wissens nach durch das Bit TWSTO im TWCR feststellen, ob STOP gesenden wurde. Dieses Bit wird ja gesetzt, um ein STOP zu senden. Und, wenn das Bit nicht mehr gesetzt ist, ist die Übertragung fertig.

  3. #3
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    26.05.2005
    Ort
    Kaiserslautern
    Beiträge
    794
    Hi,
    danke für die Antwort.

    Ich möchte kein Repeated Start machen, sondern wirklich wissen, wann mein STOP fertig ist.

    Ist da die Variante mit TWSTO wirklich richtig? Weil beim Start wartet man ja einfach ab, dass TWINT gesetzt wird. Beim STOP scheint(!) diese Variante aber nicht zu funktionieren.

    edit: kleine Zwischenfrage: Sehe ich das richtig, dass ich bei nur einem Master kein STOP brauche, sondern nur Repeated Start einsetzen kann?

    Gruß, CowZ

  4. #4
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    10.08.2004
    Ort
    Großbardorf
    Alter
    36
    Beiträge
    674
    Ist da die Variante mit TWSTO wirklich richtig?
    Ob sie wirklich richtig ist, weiß ich nicht, aber bei mir funktionierts damit.

    Weil beim Start wartet man ja einfach ab, dass TWINT gesetzt wird. Beim STOP scheint(!) diese Variante aber nicht zu funktionieren.
    Beim STOP verwendet man ja auch nicht die Methode mit TWINT, sondern mit TWSTO.

  5. #5
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    26.05.2005
    Ort
    Kaiserslautern
    Beiträge
    794
    Ja, bei mir funktionierts auch

    Die Frage, ob das "richtig" ist, bleibt natürlich. Könnte ja auch nur n netter workaround sein oder so. Aber trotzdem erstmal danke dafür

    Gruß, CowZ

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    10.08.2004
    Ort
    Großbardorf
    Alter
    36
    Beiträge
    674
    Writing the TWSTO bit to one in Master mode will generate a STOP condition on the Two-wire Serial Bus. When the STOP condition is executed on the bus, the TWSTO bit is cleared automatically.
    Das steht im Datenblatt des ATMega8 in der Definition des TWSTO-Bits im TWCR-Register.
    Meiner Meinung nach stützt das unsere Vermutung.

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    22.05.2005
    Ort
    12°29´ O, 48°38´ N
    Beiträge
    2.731
    Hallo,

    hast Du da schon mal reingeguckt:
    https://www.roboternetz.de/wissen/index.php/TWI_Praxis
    da hab ich das durch setzen der Register gemacht.

    Nach dem STOP warte ich nicht mehr, denn bis zum nächsten START, sollte es auf jeden Fall gesendet sein, solange das START nicht direkt gleich die Zeile danach kommt.
    Ein STOP ist ja nur die beiden Leitungen loszulassen, kann man ja mal ausrechnen wieviel Takte der AVR macht, bis das geschehen ist.

    Normalerweise fragt man das Statusregister ab nachdem TWINT gesetzt ist, und kann dann entscheiden was passiert ist, in Abhängigkeit was man eigentlich vor hatte.
    Für STOP gibts aber keinen speziellen Status.
    Steht auch nix besonderes im DB was passiert nach dem STOP.

    Edit:
    ich seh grad, das steht doch drin:
    "Note that TWINT ist NOT set after a STOP condition has been sent."

  8. #8
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    26.05.2005
    Ort
    Kaiserslautern
    Beiträge
    794
    Hi,

    die Definition des TWSTO ist sehr hilfreich, danke

    Nicht auf das Ende des Stops zu warten empfinde ich als "Katastrophe" Vorallem, da du dir nicht sicher sein kannst, mit welcher Geschwindigkeit der Bus läuft (da diese von den Slaves gedrosselt werden kann).

    Daher ist die Lösung mit TWSTO wohl optimal Danke

    Gruß, CowZ

  9. #9
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    22.05.2005
    Ort
    12°29´ O, 48°38´ N
    Beiträge
    2.731
    Warum soll das eine Katastrophe sein,
    wenn's so eilt ein Start auf ein STOP zu senden, kann man das doch auch gleich als ein Befehle machen, ist zumindest im AVR so vorgesehen !
    Also gleichzeitiges setzen von TWSTO und TWSTA nach der letzten Aktion.

    Ich denke es gibt auch nichts was ein abgesetztes STOP noch verhindern könnte.

    Und in einem normalen Ablauf dauerts doch ein paar Takte, bis sich wieder entscheidet, das was gesendet werden soll, und da ist das Stop schon durch.
    Chaos könnte dann nur noch passieren, wenn zB. in verschiedenen ISRs etwas am TWI gemacht wird, die sich nicht synchronisieren.

  10. #10
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    26.05.2005
    Ort
    Kaiserslautern
    Beiträge
    794
    Hi

    Manchmal kann man eben nicht wissen, ob im nächsten Takt schon wieder ein START kommt, oder eben nicht. Und daher sollte man imho auf das Ende des STOPS warten. Ob das nun irgendwas stört oder nicht, kann ich nicht einschätzen, aber ich finde es einfach unschön

    Gruß, CowZ

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiTime Speicher und Akkus