Kurze Frage: Hat jemand schon einmal ein TWI bzw. I2C unter Verwendung der USI eines ATtiny in Assembler gemacht? Wenn ja, kannst du mal deinen Assemblercode hier dranhängen? Verstehe nicht wie sich Atmel die Funktion überhaupt gedacht hat. Was der 4-Bit Zähler im Register macht!? Wann und wie wird im Slave Mode die Adresse erkannt? Habe schon vor Jahren mal eine reine Softwarelösung programmiert gehabt und die hat auch bestens Funktioniert. Nachteil dieser reinen Softwarelösung: Der Tiny ist ständig damit beschäftigt, auf eine Adresse zu warten und kann keine anderen Arbeiten dazwischen machen. Jetzt benötige ich aber eine Lösung, die im Hintergrund auf die passende Adresse wartet und sobald die richtige Adresse empfangen wurde, einen Interrupt auslöst. Habe aber mit USI bei einem ATtiny noch nichts gemacht. Hatte sonnst immer ATmega mit "ECHTEM" TWI gehabt. Danke
Vielleicht auf den Tiny841 wechseln? Der hat einen echten I2C-Slave in 14 Pins.
A. K. schrieb: > > In deinem Programm. Ja das ist schon klar. War schlecht von mir Formuliert. Hätte besser schreiben sollen wann und wie wird erkannt, wenn eine vollständige Adresse bzw. 8Bit im USI vorliegen? Also eine Erkennung, in Register USIDR sind jetzt 8Bit vollständig empfangen wurden, jetzt dieses Byte aus USIDR raus holen und prüfen ob es die benötigte Adresse ist. Weitere Frage: Wie wird ACK gehandelt? Muß ich den SDA Pin per "Hand" auf LOW biegen oder erledigt das dass USI? Während des Empfangs eines Bytes bis zur Signalisierung, HALLO HIER IST EIN BYTE ZUR ABHOLUNG BEREIT, wäre ich in der Lage noch andere Aufgaben dem ATtiny machen zu lassen.
A. K. schrieb: > Vielleicht auf den Tiny841 wechseln? Der hat einen echten I2C-Slave in > 14 Pins. Hatte ich mir auch schon überlegt. Wenn die USI Sache zu aufwendig wird... Habe noch ein paar ATmega8 hier. Ist halt nur Schade, wenn man einen ATmega für poplige Sachen nehmen muß. Aber mal sehen, vielleicht klappt es mit dem USI ja doch noch ganz gut...
Schon mal im Forum gesucht? Mit Beispielcode in C könnte ich selber dienen, für Assembler finde ich Beitrag "Tiny2313 USI-Slave"
:
Bearbeitet durch User
Ben schrieb: > Ja das ist schon klar. War schlecht von mir Formuliert. > Hätte besser schreiben sollen wann und wie wird erkannt, wenn eine > vollständige Adresse bzw. 8Bit im USI vorliegen? Daran, das der USI-Counter überläuft und dadurch das entsprechende IRQ-Flag gesetzt wird (und sofern möglich, die entsprechende ISR durchlaufen wird). Damit das im richtigen Moment passiert, ist es dein Job, den Counter passend zu initialisieren, so dass er genau nach 8 empfangenen Bits nach einer Start/Restart-Condition überlauft. > Weitere Frage: Wie wird ACK gehandelt? Muß ich den SDA Pin per "Hand" > auf LOW biegen Natürlich. Das USI ist nur ein blödes 8Bit-Schieberegister, kombiniert mit einem Flankenzähler. I2C wird nur auf dem physical layer durch passende Konfiguration der Pins unterstützt und durch die Möglichkeit zur asynchronen Erkennung einer Start-Condition. Alles andere muss deine Software selber erledigen. Genauso wie in deiner bisherigen reinen Softwarelösung.
c-hater schrieb: > I2C wird nur auf dem physical layer durch > passende Konfiguration der Pins unterstützt und durch die Möglichkeit > zur asynchronen Erkennung einer Start-Condition. Alles andere muss deine > Software selber erledigen. Genauso wie in deiner bisherigen reinen > Softwarelösung. Hmm, da habe ich ein ganz wichtiges Feature vergessen: das USI unterstützt optional auch Clock-Stretching für die Daten. D.h.: wenn der Counter überlauft, wird SCL erstmal auf Low gezogen und bleibt da. Deine ISR kann also auch mal ein wenig verspätet starten, jedenfalls wenn auch der Master mit Clock-Stretching umgehen kann...
A. K. schrieb: > Schon mal im Forum gesucht? Mit Beispielcode in C könnte ich selber > dienen, für Assembler finde ich > Beitrag "Tiny2313 USI-Slave" Ja, das enthält tatsächlich alles Wesentliche. Ist allerdings recht stark auf einen speziellen Anwendungsfall optimiert. Einem geübten Assemblerprogrammierer sollte es aber nicht schwerfallen, aus dem Code einen universeller einsetzbaren "Treiber" abzuleiten oder halt eine für seine aktuellen Bedürfnisse optimierte Variante.
A. K. schrieb: > Schon mal im Forum gesucht? Mit Beispielcode in C könnte ich selber > dienen, für Assembler finde ich > Beitrag "Tiny2313 USI-Slave" Ja ich habe auch schon gegoogelt habe auch eine Application Note "AVR312: Using the USI Module as a I2C Slave" von Atmel gefunden. Das hat mir aber nicht wirklich meine Fragen beantworten können. Aber dein Link ist nun vollkommend ausreichend, um zu verstehen wie man mit dem USI umgehen muß. Aber so wie es nun für mich aussieht, ist die Verwendung eines ATtiny mit USI für meine Sache wahrscheinlich doch nicht so das richtige. Denn ich habe mehrere TWI-IC´s (I2C) am Bus hängen und müßte dann bei jeden Byte, was ich über den BUS sende im ATtiny prüfen, ob es das Adressbyte für den ATtiny ist. Wenn dann mehrere Bytes auf den BUS übertragen werden, wäre der ATtiny ja auch ständig damit beschäftigt jedes Byte zu kontrollieren. Und wenn ich dann den Rest noch per "Hand" machen muß, dann vergeht noch mehr Zeit im ATtiny, wo er nichts anderes machen kann... Deshalb werde ich halt doch einen ATmega nun nehmen und brauche mich mit der Stückelei von teils Hardware und teils Software herum zu ärgern. Danke an alle.
Ben schrieb: > Wenn dann mehrere Bytes auf den BUS übertragen > werden, wäre der ATtiny ja auch ständig damit beschäftigt jedes Byte zu > kontrollieren. Nur beim Adressbyte. Wenn das nicht passt, dann kann das USI wieder auf "warte auf Start Condition" reduziert werden und den Rest der Übertragung ignorieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.