USI ATtiny85 Assembler

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...

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.