Versuche meinen Code besser zu modularisiren. Konkret habe ich einen STM32F303 und daran an einem I2C Bus zwei verschiedene Sensoren. (CubeIDE mit HAL) Überlege mir nun wie ich das generell am besten löse wenn ich mehrere Module (je eines für die verschiedenen Sensoren) mache, aber am Schluss immer der gleiche Interupt ausgelöst wird wenn die Übertragung fertig ist. Also wie kann ich nach dem Interrupt bestimmen welche Funktion nun die Daten braucht? Die KI schlägt mir da einen Dispatcher vor der dann die entsprechende Funktion nach einer registrierung aufruft vor. Bin aber noch relativer Anfänger, ist das ein guter Ansatz oder wie macht man das üblicherweise? Danke.
Wenn ich aus mehreren Modulen auf eine Peripherie zugreifen möchte, will ich natürlich auch verhindern, dass ein Modul X auf die Hardware zugreift, da Modul Y z.B. noch keine Antwort erhalten hat. Ich habe mir dazu einen Job-Manager geschrieben. Dieser nimmt Jobs entgegen, reiht diese ein und arbeitet diese ab. Natürlich muss jedes Modul das einen Job übergibt auch eine Callback Funktion mitliefern. Im Endeffekt, ruft die Hardware den Interrupt auf, dieser dann meinen Job-Manager und dort sind ja die jeweiligen Callbacks für den aktuellen und noch offene Jobs bekannt. Ob diese Lösung auch für dich passt, kann ich nicht beurteilen. Aber es gibt da bestimmt 100te Wege die ans Ziel führen. Man könnte dies wohl als "Dispatcher" betrachten, so wie du es erwähnt hast.
:
Bearbeitet durch User
Samuel schrieb: > CubeIDE mit HAL Bei der HAL kannst du doch meistens einen Callback übergeben, was du zuerst in STM32CubeMX im Project Manager aktivieren musst. Dann ruft die HAL automatisch den richtigen Callback des Moduls auf, das eine Aktion angefordert hatte.
Niklas G. schrieb: > Bei der HAL kannst du doch meistens einen Callback übergeben, was du > zuerst in STM32CubeMX im Project Manager aktivieren musst. Dann ruft die > HAL automatisch den richtigen Callback des Moduls auf, das eine Aktion > angefordert hatte. Tja, ist leider ziemlich blöd gelöst, weil das Konzept von Hause aus nur einen Callback-"Konsumenten" erlaubt. Das ist gerade für Sachen wie ISP oder I2C mit vielen verschiedenen, ggf. sogar ziemlich komplexen Clients ziemlich schlecht für die Code-Modularisierung. Und wenn deren Existenz dann auch noch "dynamisch" ist, also erst zur Laufzeit ermittelt werden kann, ob die zugehörige Hardware des Clients überhaupt im System ist, scheitert das Konzept endgültig. Also für alles, was näherungsweise nach einem Bus-System aussieht, taugt der Ansatz von CubeMX leider nix. Läuft i.A. dann darauf hinaus, dass man eine eigene Zwischenschicht mit eigenem Client-API einziehen muss.
Ob S. schrieb: > Tja, ist leider ziemlich blöd gelöst, weil das Konzept von Hause aus nur > einen Callback-"Konsumenten" erlaubt Bei I2C kann sowieso nur eine Kommunikation gleichzeitig statt finden, ich kann mir keinen Anwendungsfall vorstellen wo zwei Module gleichzeitig über I2C kommunizieren müssen - nur abwechselnd. Jedes Modul setzt direkt vor dem Start des Transfers den eigenen Callback via HAL_I2C_RegisterCallback.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.