I2C-zugriff während in ISR?

Timo K. Gast #1868558
Lesenswert?
• ▲
▼ 
Hallo zusammen.
Ich bin gerade dabei eine Projektarbeit zu starten. Da ich diesmal etwas 
strukturiert an die Sache herangehen will, hätte ich da eine Frage 
bezüglich der ‚allgemeinen‘ Software-Struktur. Und zwar sollte ich 
mittels I2C einen Baustein ansteuern. Dieser Baustein löst immer dann 
einen Interrupt aus, wenn allgemeine Ereignisse eintretten. Die Art des 
Ereignisses lässt sich dann über I2C aus dem  Register 0h auslesen. 
Danach müssen  weitere Register ausgelesen werden,  um weitere 
Informationen zu erhalten. Meine Frage bezüglich der SW-Struktur 
betrifft nun konkret die Interruptverarbeitung.
Ich sehe folgende Möglichkeiten:
a.) Ich lese direkt im Interrupt über I2C die entsprechenden Register 
aus und starte die Abarbeitung. Vorteil: Ich kann direkt auf das 
entsprechende Ereignis reagieren. Nachteil: Ich habe eine relativ lange 
ISR (Auslesen der Register über I2C, Algorithmus…)
b.) Ich setze in der ISR nur ein Flag. In einer nebenläufigen Schleife 
lese ich dann die Register über I2C aus und starte eine entsprechende 
Abarbeitung.  Vorteil: Kurze ISR, Nachteil: Ich reagiere ziemlich spät 
auf das Ereignis. Im Grunde genommen könnte ich dann ich der Schleife 
gleich den entsprechenden Pin pollen…

Wie würde man in der Praxis dies implementieren? Danke für eure Tipps 
und Anregungen.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Alfred Gast #1868565
Lesenswert?
• ▲
▼ 
Guten Morgen Timo,

ich würde Deine Variante b) in Betracht ziehen. Die "nebenläufige 
Schleife" wäre ja in Deinem Fall eine Endlosschleife in main(), die das 
Flag überprüft und dann die Verarbeitung anstößt.

Das heißt, Du hast in der Hauptschleife noch die Möglichkeit, andere 
Sachen zu erledigen, was bei der Polling-Variante ausfällt, weil Du ja 
den Pin pollst :-)

Die Variante b) entkoppelt Dir Dein System zeitlich und wenn Du 
irgendwann noch was anderes machst, als einen einzelnen I2C Slave zu 
steuern, wird Dir das zugute kommen.

Variante a) geht eigentlich nur, wenn die lange ISR keinen stört, also 
sonst nix passiert. In dem Fall würde ich dann das Flag pollen, weil das 
einen einfacheren Code gibt.

Beste Grüße

Alfred
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Olaf D. (Firma: O.D.I.S.) #1868567
Lesenswert?
• ▲
▼ 
Hallo Timo K.

die Variante a) wird nicht funktionieren, da der I²C auch wieder 
Interrupts auslöst. In den Projekten meiner Kunden sehe ich immer wieder 
solche Ansätze und große Augen, wenn es schiefgeht. Schreibe Dir einen 
Treiber Task der die Logik der Hardware-Ansteuerung implementiert. 
Getriggert wird er über Events die aus den Interrupts gesendet werden, 
wenn etwas zu eempfangen ist, bzw. über Nachrichten der 
Applikations-Tasks, wenn was zu senden ist.

Der Vorteil: mehrere Applikationen können senden, der Treiber-Task 
serialisiert das.

Gruß

Olaf
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Timo K. Gast #1868589
Lesenswert?
• ▲
▼ 
Hallo Alfred, hallo Olaf.
Vielen Dank für den Hinweis auf I2C und Interrupts. An das hätte ich 
jetzt wahrscheinlich auch nicht gedacht.

Ich werde mich dann also an Variante b. orientieren.

Gruß
Timo
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren