Eine interruptgesteuerte TWI/I2C Routine und eine Frage dazu. Pointer/Variable an IRQ?

> Wie bekomm ich den denn in den Interrupt?

Machst du doch schon (unbewusst?) mit den Variablen TWI_SendBuffer und 
TWI_ReadBuffer: Globaler Pointer, auf den du in der ISR zurgreifst.

Denk' nur dran, alle Variablen, die du in der Interruptroutine 
veränderst, als 'volatile' zu deklarieren, sonst sind merkwürdige Fehler 
vorprogrammiert.

Um welche Datenmengen handelt es sich? In vielen Fällen sind I2C Daten 
nur wenige Bytes gross. Da kann es auch sinnvoll sein, einen statischen 
Puffer an Stelle von Pointern zu verwenden.

A. K. schrieb:
> Um welche Datenmengen handelt es sich? In vielen Fällen sind I2C Daten
> nur wenige Bytes gross. Da kann es auch sinnvoll sein, einen statischen
> Puffer an Stelle von Pointern zu verwenden.

Bisher handelt es sich um eher kleine Mengen. Darum hab ich meinen 
Sendbuffer auch nur mit 10Byte,  und den ReadBuffer mit 40 Byte 
initialisiert. Meinst du das mit statisch? Oder noch sowas wie "const" 
oder "static"? Aber als const könnte ich doch nichts mehr an den Puffer 
ändern?

J. T. schrieb:
> Meinst du das mit statisch? Oder noch sowas wie "const"
> oder "static"?

Globale Daten sind statisch, d.h. permanent vorhanden und werden mit 
fester Adresse abgesprochen. Lokale Daten (ohne "static") hingegen haben 
keine feste Dauer und keine feste Adresse.

Es geht um etwas anderes. 'Statisch' im Gegensatz zu 'dynamisch 
allokiert'. Denn warum sollte man sonst Pointer verwenden wollen?

Alles was an Daten aus einer ISR rein oder raus geht, muss in 
irgendeiner Form über globale Variablen laufen. Ob so ein Datenarray 
statisch global allokiert wird, oder ob es zb in main() dynamisch 
allokiert wird und es dann einen globalen Pointer darauf gibt, ändert 
daran wenig. Irgendetwas muss global sein. Nur dass letzterer Fall 
(dynamische Allokierung + Pointer) komplexer ist als eine simple 
statische Allokierung.

Wie immer gibt es Ausnahmen. Zb wenn die Buffergrösse zur Laufzeit 
veränderbar sein soll, oder wenn man nur Abschnittweise den Buffer 
benötigt und man den wegen Speicherverbrauchs nicht statisch allokieren 
will.

Rainer B. schrieb:
> Denk' nur dran, alle Variablen, die du in der Interruptroutine
> veränderst, als 'volatile' zu deklarieren, sonst sind merkwürdige Fehler
> vorprogrammiert
Auch globale Variablen? Ich warte ja in meiner TWI-Send/Weite darauf, 
daß der vorherige Schreib/Lesevorgang beendet ist, bevor ein neuer 
beginnen kann. Wobei das irgendwie den Sinn von den Interrupts 
auffrisst. Evtl die Puffer als Ringpuffer implementieren?

Ausserdem frage ich mich, ob der TWI-Watchdog überhaupt notwendig ist. 
Eigentlich werden ja schon alle Fehler die auftreten können von der 
Statemachine abgefangen

J. T. schrieb:
> Auch globale Variablen?

Ja.

> Ausserdem frage ich mich, ob der TWI-Watchdog überhaupt notwendig ist.
> Eigentlich werden ja schon alle Fehler die auftreten können von der
> Statemachine abgefangen

Auch Timeouts? Die Implementierung mit Zählschleife ist aber 
zweifelhaft.

> Evtl die Puffer als Ringpuffer implementieren?

Das hängt von der Anwendung ab. I2C wird meist mit irgendwelchen Geräten 
im Request-Response-Done Schema verwendet. Da ergibt ein Ringpuffer 
wenig Sinn.

Karl H. schrieb:
> Es geht um etwas anderes. 'Statisch' im Gegensatz zu 'dynamisch
> allokiert'. Denn warum sollte man sonst Pointer verwenden wollen?

Ok, das hilft mir schonmal weiter. Und ja genauso hab ichs mir auch 
gedacht. Die Idee das ganze in der Main mit einem eigenen Puffer zu 
machen und dann den globalen Zeiger drauf zeigen lassen, kam ich auch 
schon, aber gestern Abend wollten mir keine Vorteile dessen mehr 
einfallen, und darum hab ichs erst mal gelassen.

J. T. schrieb:
> Wobei das irgendwie den Sinn von den Interrupts auffrisst.

Solche I2C Operationen, bei denen man im Hauptprogramm ohnehin drauf 
wartet, kann man auch ohne Interrupts implementieren. Man sollte dann 
aber genau drauf achten, dass der Code bei unerwarteten Reaktionen nicht 
einfach hängenbleibt. In einer von der Hardware geführten Statemachine 
ist das mitunter einfacher.

A. K. schrieb:
> Auch Timeouts? Die Implementierung mit Zählschleife ist aber zweifelhaft

Hab ich so gemacht, ohne groß drüber nachzudenken. Einfach nen größeren 
Prescaöer auf den Timer? Weil mit diesen Einstellungen kam der WD 
immerhin schonmal bis 4 beim Durchsteppen.

Wie implementiert man sowas denn "normalerweise"?

Juergen schrieb:
> Wenn du das nicht machst, wirst du in höheren Optimierungsstufen
> seltsame Fehler bekommen

Ja das wird auch noch interessant werden. Noch bin ich auf O-0, da er 
bei O-1 schon so viel wegoptimierte, das ich die ISR nicht mehr 
vernünftig Durchsteppen konnte.

Aber nun läufts so weit, da kann man mal anfangen mit optimieren.

Juergen schrieb:
> Es fehlt aber "volatile" an allen Variablen, die sowohl im Interrupt als
> auch im normalen Programm benutzt werden.  Alternativ kannst du auch
> Speicherbarrieren (memory barrier) verwenden.

Das interessiert mich jetzt aber: wie ersetzt man ein volatile durch 
eine Speicherbarriere? Bitte mit praktischem Beispiel.

Macht die Memory Barriere nicht nur, dass alle Load/Store Befehle 
garantiert abgeschlossen werden, bevor der Befehl danach ausgeführt 
wird?
Wenn der Compiler aber die Variable gar nicht aus dem Speicher holt 
bringt es nix.

Jan K. schrieb:
> Wenn der Compiler aber die Variable gar nicht aus dem Speicher holt
> bringt es nix.

Eben.

IMHO ist das nämlich ein ganz anderes paar Schuhe.

Ich hab auch schon mit Compiler-Barrieren experimentiert und 
erstaunlicherweise bewirken so Sachen wie

  __asm__("":::"memory");

(das ist aber keine memory-Barriere im wirklichen Sinne) daß er dann 
plötzlich ein wegoptimiertes

  if (nonVolatileGobal) {...}

plötzlich wieder hervorholt und auch brav jedesmal die Variable neu aus 
dem Speicher liest aber mir ist unwohl dabei. Ich bin mir nicht sicher 
ob er dann wirklich immer davon ausgeht daß diese leere(!) asm-Anweisung 
den kompletten Speicher als vermuteten Seiteneffekt hat und das somit 
für nonVolatileGlobal ebenfalls annimmt, ob ich mich auf sowas wirklich 
verlassen kann.

Nocheinmal die Frage, ob der Watchdog überhaupt notwendig ist. Wenn ein 
Slave nicht antwortet, weil er nicht am Bus oder gestorben oder sonst 
was ist, dann kommt ein NACK zurück --> Fehlerbehandlung

Eigentlich kommt doch in jedem Fehlerfall ein NACK zurück? Ausser 
irgendwelchen seltsamen Übertragungsfehlern, aber die erkennt das TWSR 
ja nicht, dafür müsste man wohl irgendeine Form von Prüfsumme mit 
übertragen.

Also auch keine Baustelle für nen Watchdog.

Könnt ihr mir nen Fehlerfall nennen/konstruieren, in dem der Watchdog 
wirklich notwendig wäre?

Doch noch ein kleines Problemchen....

1

case TW_MR_DATA_ACK:

2

3

          TWI_Watchdog = 0;

4

5

          if (TWI_ReadCnt < (TWI_DataSize - 1))

6

          {

7

            TWI_ReadBuffer[TWI_ReadCnt] = TWDR;

8

            TWI_ReadCnt++;

9

            TWCR = (1 << TWINT) | (1 << TWEA) | (1 << TWEN) | (1 << TWIE);

10

          }

11

          else

12

          {

13

            TWI_ReadBuffer[TWI_ReadCnt] = TWDR;

14

            TWI_Flags = 0;

15

            TWI_ReadCnt = 0;

16

            TWCR = (1 << TWINT) | (1 << TWSTO) | (1 << TWEN) | (1 << TWIE);  

17

          }          

18

        break;

irgendwie sendet er keine Stopcondition. Wenn ich es durchsteppe (auf 
dem Chip und nicht im Simulator) springt er zwar den else an, aber auf 
dem LA kommt keine Stopcondition. Auch wenn ich den if-Fall nur bis 
DataSize-2 anspringen lasse, empfängt er trotzdem 12Byte, springt beim 
durchsteppen den else-Fall an aber der Stop wird einfach nicht 
gesendet??

Weiß dazu evtl wer was zu zu sagen?

Hm... wahr wohl ein Fehlalarm... Oder ich oder mein LA hatte n Knick in 
der Linse beim Zählen :D

Ich hab jetzt mal den Buffer geleert vor dem Auslesen, dann bleiben die 
letzten Werte auch auf 0. Auch das Statusregister zeigt an, das es 
wieder bereit ist.

Wobei auf dem LA, auch wenn ich auch DataSize-2 schalte nach dem 11ten 
statt dem 12ten, ein ACK kommt. Eigentlich müsste da doch aber ein Stop 
und somit NACK sein?

J. T. schrieb:
> Hab ich so gemacht, ohne groß drüber nachzudenken.

Zählschleifen darf der Compiler ersatzlos entfernen, wenn aus seiner 
Sicht wirkungslos. Zeitverbrauch ist aus seiner Sicht keine Wirkung.

> Wie implementiert man sowas denn "normalerweise"?

In manchen Programmierumgebungen existieren fertige Delay-Funktionen.

Für Timeouts kann man einen System-Tick verwenden. In vielen Fällen habe 
ich im Programm einen Timer, der alle soundsoviel Millisekunden 
interrupted. Der kann für Tastenentprellung sein, irgendwelche Schedules 
erledigen, und was auch immer.

Dessen ISR zählt nebenbei eine Variable hoch, die so typisiert ist, dass 
sie bis zu nächsten Restart des Controllers nicht überlauft (geht auch 
anders, ist so aber einfacher). Der Code sieht dann ungefähr so aus:

1

  uptime_t timeout = uptime() + TIMEOUT;

2

  while (...) {

3

    ...

4

    if (uptime() > timeout)

5

      ...timeout...

6

    }

7

  }

> Eigentlich kommt doch in jedem Fehlerfall ein NACK zurück?

Warum?

A. K. schrieb:
> Zählschleifen darf der Compiler ersatzlos entfernen, wenn aus seiner
> Sicht wirkungslos. Zeitverbrauch ist aus seiner Sicht keine Wirkung.

Schnelle Abhilfe: Zählvariable als volatile definieren.

Schreibzugriffe auf Volatile sind per Definition eine solche Wirkung 
(observable behavior) und müssen daher erfolgen, und zwar in exakt der 
selben Anzahl und Reihenfolge wie es im Quelltext steht.

A. K. schrieb:
>> Eigentlich kommt doch in jedem Fehlerfall ein NACK zurück?
>
> Warum

Weil wenn kein Fehler vorliegt ein ACK kommt. Das Ausbleiben selbigen 
ist doch schon das NACK?

A. K. schrieb:
> Für Timeouts kann man einen System-Tick verwenden. In vielen Fällen habe
> ich im Programm einen Timer, der alle soundsoviel Millisekunden
> interrupted. Der kann für Tastenentprellung sein, irgendwelche Schedules
> erledigen, und was auch immer.
>
> Dessen ISR zählt nebenbei eine Variable hoch, die so typisiert ist, dass
> sie bis zu nächsten Restart des Controllers nicht überlauft (geht auch
> anders, ist so aber einfacher). Der Code sieht dann ungefähr so aus:

Genauso hab ich es doch implementiert?

Bernd K. schrieb:
> Schnelle Abhilfe: Zählvariable als volatile definieren.
> Schreibzugriffe auf Volatile sind per Definition eine solche Wirkung
> (observable behavior) und müssen daher erfolgen, und zwar in exakt der
> selben Anzahl und Reihenfolge wie es im Quelltext steht

Inzwischen sind nun alle globalen Variablen volatile. Ich kann wenn ich 
wieder zu haus bin, ja nochmal ne aktuelle Version hoxhladen

Tim schrieb:
> Du fängst den TWI-Statuscode $00 nicht ab.
> Dein Buffer ist 40 Byte gross. Wieso willst du 65535
> Bytes addressieren können?
>  uint16_t TWI_SendCnt = 0;
>  uint16_t TWI_ReadCnt = 0;
> uint8_t reicht, Ausserdem fehlt volatile. Besser währe es die als
>  static uint8_t TWI_SendCnt;
>  static uint8_t TWI_ReadCnt;
> im IRQ zu definieren, da du ausserhalb vom IRQ nicht
> darauf zugreifst

Die volatiles sind nun nachgelgt. Den Contergan hab ich 16 IT breit 
gemacht falls ich mal mehr als nur ein paar Byte lesen/schreiben  will. 
Bspw wenn man Speicherbausteine per I2C anspricht. Das war schon bewusst 
so gemacht.

LOL
Der letzte Beitrag war vom Handy geschrieben... Mit Contergan hab ich 
nix am Hut.

Ohne Textcontergan(Autokorrektur) hätte das hier:

J. T. schrieb:
> Den Contergan hab ich 16 IT breit
> gemacht

eigentlich so lauten sollen:

Den Counter hab ich 16 Bit breit gemacht.

Tim schrieb:
> Du fängst den TWI-Statuscode $00 nicht ab.

Danke, den hatte ich übersehen. Warum verstecken die den auch ganz am 
Ende der Tabelle. Ich hatte nur die MT und MR abgearbeitet, gesehen oh 
hab hier kommen die Slavegeschichten, dann bin ich ja fertig... :D

So hier nun nochmal die aktuelle Version, als .c und .h. Dazu noch eine 
kleine Frage. Warum klappt es, wenn ich in der main.c die .h UND .c 
includiere, aber wenn ich die .c IN der .h indluciere, und in der main.c 
dann nur die .h, klappt es nicht? Dann meckert er, er würde die globalen 
Variablen nicht finden, bzw das sie undefiniert sind. Und die Funktionen 
implizit deklariert sind. Was es halt so mit sich bringt, wenn die 
Sachen die in der .c stehen, nicht da sind.

Er ist übrigens der AVR_GCC im Atmel Studio 6.2

MfG Chaos

Tim schrieb:
> Besser währe es die als
>  static uint8_t TWI_SendCnt;
>  static uint8_t TWI_ReadCnt;
> im IRQ zu definieren, da du ausserhalb vom IRQ nicht
> darauf zugreifst.

Ich glaub, das mit dem static versteh ich irgendwie doch noch nicht 
ganz.
Ich dachte, das sagt dem Compiler, dass die Variable sich nicht ändert? 
Sollte die nicht besser als volatile innerhalb der ISR erzeugt werden? 
Wobei man dann wieder Vorkehrungen treffen müsste, dass sie nicht 
jedesmal beim Anspringen  der ISR neu initialisiert wird?

1

ISR(TWI_vect)

2

{

3

   volatile uint8_t ReadCnt = 0;

4

  .

5

  .

6

  .

7

  case foo:

8

  ...

9

  ReadCnt++;

10

  break;

11

12

  case bar:

13

  ...

14

  ReadCnt++;

15

  break;

16

}

ReadCnt würde doch jedesmal vor dem switch auf 0 gesetzt?

Und mit static würde sie sich garnicht verändern?

> jedesmal beim Anspringen  der ISR neu initialisiert wird?
und genau das verhinderst Du mit "static"

> Und mit static würde sie sich garnicht verändern?
nein, Du verwechselst "static" mit "const"

Mit static wird die Variable nur einmal initialisiert und die Variable 
behält nach dem Verlassen der Funktion weiterhin ihren Wert.

Ahhhh das erklärt einiges! Danke dafür.