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.
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
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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.