[ASM] Hardware TWI-MASTER Interrupt basierend für Mega AVR

[Steffen H. (avrsteffen)]

Während meines momentan laufenden Projektes ist dieses TWI Modul 
entstanden, welches ich euch nicht vorenthalten möchte.

Natürlich wieder in ASM. Vielleicht kann es irgendjemand gebrauchen und 
ich konnte damit weiter helfen.

Ich habe mal noch ein Beispiel mit angehangen, damit man weiß wie das 
Modul benutzt werden kann.

Grüße Steffen

[Steffen H. (avrsteffen)]

Ich habe jetzt gerade ein Problem erkannt:

Wenn der TWI Interrupt durch irgend einen anderen Interrupt aufgehalten 
wird, dann verzögert sich komischerweise auch die Stop-Bedingung. Dieses 
Verhalten ist allerdings in keinem Datasheet nachzulesen.

Das TWI_busy Flag wird schon dann gelöscht, wenn die TWI-Hardware als 
nächste Aktion ein STOP ausführen soll.
 Dadurch weiß man natürlich nicht, ob die TWI-Hardware die 
STOP-Bedingung auch schon auf den BUS gebracht hat. Wenn man dann im 
ungünstigsten Fall sofort auf ein gelöschtes TWI_busy Flag reagiert und 
eine neue Datenübertragung per START einleitet, ist die Zeit zwischen 
STOP und START auf dem I2C Bus sehr kurz. Und wahrscheinlich so kurz, 
dass der Slave dies nicht mehr verarbeiten kann und ein NACK auf die 
gültige Adresse sendet!

Hab das Problem mal im Anhang grün eingekreiselt.

In welcher Specs/Appnote von Atmel findet man die TWI Hardware Timings? 
Oder wie könnte man dieses Problem lösen?

Steffen

[Steffen H. (avrsteffen)]

Hallo,

Ich suche immer noch nach Spezifikationen/Timings der AVR Controller.

Hat jemand einen Tip? Wo hat ATMEL sowas versteckt?

[Bernhard S. (bernhard)]

@Steffen

>Wenn der TWI Interrupt durch irgend einen anderen Interrupt aufgehalten
>wird, dann verzögert sich komischerweise auch die Stop-Bedingung.

Das muss auch so sein, denn der µC kann nur einen Interrupt zur gleichen
Zeit abarbeiten. Natürlich kann man "verschachtelte" Interrupts zulassen
durch "SEI" in der Interrupt-Routine.

Ich füge gern eine angemessene Pause nach einem STOP ein, damit die 
SLAVES
auf STOP regaieren könnnen, es kann vorkommen, dass nach einem Stop
der SLAVE noch Daten verarbeiten muss. Gib ihnen die Zeit ;-)

Gruß

Bernhard

[Steffen H. (avrsteffen)]

Hab's gefunden. TWI Characteristics steht in jedem AVR Datasheet unter 
Electrical Characteristics.

Übrigens, die Zeit zwischen STOP -> START nennt sich laut Datasheet 
tBuf und sollte mindestens _1.3µs_ lang sein.

[Steffen H. (avrsteffen)]

Hmm, ich muss jetzt zusehen dass mein TWI_busy erst durch einem realen 
"STOP" auf dem Bus zurückgesetzt wird. Da Hardwareseitig ja kein 
Interrupt durch beendeter Aktion "STOP" auf dem Bus ausgeführt wird muss 
man das irgendwie anders detektieren. Mal sehen wie ich das machen kann. 
Ich denke dabei an einen wait to PIN CHANGE INTERRUPT auf SDA wenn die 
Aktion "twi_stop" in das TWCR eingetragen wird.

Na mal sehen, ob das klappt

[Steffen H. (avrsteffen)]

Hallo,

So geht es. Mittels Pin_Change Interrupt auf den SDA Pin.
Das TWI_busy Flag wird jetzt erst bei einer STOP-Bedingung auf dem Bus 
gelöscht.
Somit kann man nun gleich nachdem das TWI_busy Flag wieder '0' ist einen 
neuen TWI-Start auslösen.

LG
Steffen

[Obermayer F. (Firma: tbd) (foikei)]

Hallo Steffen,

konnte deine Routine gebrauchen, vielen Dank!

Dein Problem mit der STOP-Bedingung bzw. die Lösung dessen verstehe ich 
nicht ganz.
Aus meiner Sicht ist das mit dem PinChang-Int etwas übertrieben.

Ginge das nicht auch so (Auszug aus der TWSI-ISR)?

twi_process_stop:
        ;TWI-Commando laden
  ldi      r16, twi_stop_cmd
        ;TWI-Commando ausgeben
  sts                     TWCR, r16
        ;Flags setzen/löschen
        lds      r16, (SR_TWI_STATE)
  cbr      r16, (1<<TWI_busy)
  sbr      r16, (1<<TWI_ready)
  sts      (SR_TWI_STATE), r16
        rjmp                    TWI_int_end1
TWI_int_end:
  sts      TWCR, r16
TWI_int_end1:
  pop      XH
  pop      XL
  pop      r17  
  pop      r16
  pop      Copy_SREG
  out      SREG, COPY_SREG
  pop      Copy_SREG
  reti

Oder übersehe ich da was?

mfg
foikei

[Steffen H. (avrsteffen)]

Hallo Florian,

Das mit dem PIN CHANGE Interrupt war für mich die einzige Lösung um zu 
sehen, wann die TWI Hardware den STOP auf den Bus gebracht hat. Denn nur 
vom einschreiben des STOP-Befehls in das TWI-Control-Registers [TWCR] 
weiß man ja nun nicht, ob die Hardware auch sofort reagiert.

Das heißt:
Um das TWI_BUSY_FLAG für den Start der nächsten TWI Übertragung zu 
nutzen muss man diesen Umweg gehen. Denn nur mit der Version mit PIN 
CHANGE Interrupt und Auswertung der STOP Bedingung direkt am PIN wird 
das TWI_BUSY_FLAG auch erst dann zurück gesetzt und nicht schon zuvor.

Siehe hier:
Beitrag "Re: [ASM] Hardware TWI-MASTER Interrupt basierend für Mega AVR"

Gruß Steffen

[Michael (Gast)]

Hallo Steffen und Florian,

ich finde diese Frage auch sehr interessant, da mein ATmega8A leider 
keinen PinChangeInterrupt kann.

@Steffen: Welche Sorte Interrupts hat denn bei Dir das Stop Signal auf 
dem Bus verzögert? Oder ein Schlafmodus?
Ich verstehe jedenfalls nicht, wie ein Interrupt, die TWI 
Hardware-Einheit vom Senden des Signal abhalten sollte. Die arbeitet 
doch selbständig, oder nicht?

Gruß,
Michael