Verständnisfrage HW I2C ATmega8

[Michael D. (etzen_michi)]

Nabend.


Ich bastel mir grad einen kleinen I2C Slave zusammen und frage mich 
jetzt ob ich das richtig verstehe:

Wenn der Slave mit seiner Adresse + W angesprochen wird steht im TWSR 
0x60
Nun kann man sagen ob nach dem Empfang des ersten Byte (welches 
anschließend empfangen wird) Ack oder Nack gesendet werden soll.

Man kann aber nicht! vor dem senden des Ack/Nack überprüfen ob man da 
einen gültigen Befehl hat.


Sehe ich das so richtig?
Ist das normal so?
Wird das Nack dann beim zweiten Byte/Adresse+R gesendet?

Vielen Dank im Vorraus

Klimper zwischenzeitlich die I2C Specs durch...


PS: Seite 185

[Gastino G. (gastino)]

Michael D. schrieb:
> Sehe ich das so richtig?

Wenn ich mich recht erinnere, ja.

Der ATmega als I2C-Slave macht keinen Spaß, insbesondere dann, wenn er 
auch noch zeitweise Master sein soll.

[Michael D. (etzen_michi)]

Deine Antwort höert sich an als wenn du dafür einen besseren Baustein 
kennen würdest.
Nach der Atmel Homepage ist das leider nicht wirklich ersichtlich wie 
gut sich die einzelnen Chips für I2C eignen.


Welche Chips würdest du empfehlen:

1x I2C wenig rechnen, wenig Daten, Verwaltet alles
1x I2C Daten empfangen und auf Display anzeigen (Display braucht 8 + 
5pins) speicherintensiv
2x I2C Daten empfangen und je nachdem funktionen auf zweiten I2C als 
Master
1x I2C Daten empfangen und berechnungen druchführen

[Gastino G. (gastino)]

Da bei mir der ATmega so eine Art "Standard-Controller" ist, habe ich 
mich nicht groß mit Alternativen beschäftigt. Letztendlich läuft er bei 
mir auch als Master und Slave gleichzeitig, das war aber recht 
umständlich zu programmieren und wäre ohne Logic-Analyzer wahrscheinlich 
auch fast aussichtslos gewesen.

Ein kurzer Blick in die Datenblätter der XMega-Familie (vor einer Weile) 
hat mir gezeigt, dass dort auch am I2C-Interface kräftig geschraubt 
wurde. Ich gehe mal davon aus (weiß es aber leider mangels Erfahrung 
nicht), dass die sich besser eignen.
Die haben aber den Nachteil, dass sie nicht als DIP verfügbar sind und 
auch nicht mit 5 V Betriebsspannung betrieben werden können (was sie für 
meine Anwendungen nicht besonders brauchbar bzw. handlich macht).

[Michael D. (etzen_michi)]

Ich finde das Programmieren des I2C nicht so schwer ...


Ich mache das über einen SwitchCase,


Hier ein auszug eines "Halb"fertigen Masters wo ich gerade den Slave 
hinzufüge:

ISR(TWI_vect){
     switch(TWSR) {

          case 0x08:
               TWDR=Slave;
               TWCR= 1<<TWEN | 1<<TWIE | 1<<TWINT;
               break;

          case 0x18:
               TWDR=Command[CountCommand-1];
               
               if(CountCommand--==0) {
                    TWCR= 1<<TWEN | 1<<TWIE | 1<<TWINT | 1<<TWSTA;
                    } else {
                    TWCR= 1<<TWEN | 1<<TWIE | 1<<TWINT;
               }
               break;

          case 0x28:
               TWDR=Command[CountCommand-1];
               
               if(CountCommand--==0) {
                    TWCR= 1<<TWEN | 1<<TWIE | 1<<TWINT | 1<<TWSTA;
                    } else {
                    TWCR= 1<<TWEN | 1<<TWIE | 1<<TWINT;
               }
               break;

          case 0x10:
               TWDR=Slave+1;
               TWCR= 1<<TWEN | 1<<TWIE | 1<<TWINT;
               break;

          case 0x40:
               if(--CountByte==0) {
                    TWCR= 1<<TWEN | 1<<TWIE | 1<<TWINT;
                    } else {
                    TWCR= 1<<TWEN | 1<<TWIE | 1<<TWINT | 1<<TWEA;
               }
               break;

          case 0x50:
               Byte[CountByte]=TWDR;               
               if(--CountByte==0) {
                   TWCR= 1<<TWEN | 1<<TWIE | 1<<TWINT;
                   } else {
                   TWCR= 1<<TWEN | 1<<TWIE | 1<<TWINT | 1<<TWEA;
               }
               break;

          case 0x58:
               Byte[CountByte]=TWDR;
               TWCR= 1<<TWEN | 1<<TWINT | 1<<TWSTO;
               flag=1;
               break;

          case 0x60:
               TWCR= 1<<TWEN | 1<<TWIE | 1<<TWINT | 1<<TWEA;
               break;

          case 0x80:
               Command[CountCommand++]=TWDR;
               TWCR= 1<<TWEN | 1<<TWIE | 1<<TWINT | 0<<TWEA;
               break;

          default:
               LCD_Hex(TWSR);
               LCD_Hex(TWDR);
               LCD_Hex(Command[--CountCommand]);
               LCD_Hex(Byte[--CountByte]);
               TWCR=0x00;
               flag=1;
               break;

     }
}

Kritik immer erwünscht.
Das gleiche gilt für Info wenn jemand sieht wo es bei diesem System 
hackt.
default nutze ich immer um mir die Daten auf einem LCD anzeigen zu 
lassen um zu wissen was gerade genau los ist.

Mir fällt auch gerade auf das ich kein Stop habe wenn ich nur Daten 
senden will sondern immer aufs Empfangen gehe.

[Michi (Gast)]

Hallo Michael,

Was ich wärmstens empfehlen kann ist dieser Artikel:

Beitrag "DCF77-TWI(I2C)-Slave"

Hier findest du Funktionen und sehr gute Beispiele, wie man Attiny's mit 
USI als I²C-Slave verwenden kann!

Gruß
Michi