Guten Tag, ich bin mir nicht ganz sicher wie ich meine Frage am Besten formulieren soll, daher Beschreibe ich lieber mein Problem. Aktuell habe ich einen I2C Master, der verschiedene Slaves kontrolliert. Die Aktionen, die der I2C Master ausführen soll, gebe ich über eine Oberfläche vor. Manche Aktionen dauern jetzt aber etwas länger als andere. Beispielsweiße habe ich Treiber-ICs für Motoren und Servos aber auch einen LED Treiber und ADC. Wenn ich nun die Position des Motors verändern will, was vielleicht ein paar Sekunden dauert, dann ist solange auch der Bus belegt; sprich: eine LED ließe sich in der Zwischenzeit nicht dimmen. Die einzige Möglichkeit die ich jetzt sehe wäre die Befehle der Motor-Ansteurung in kleine Häppchen aufzuteilen, damit zwischendurch auch andere Sachen gemacht werden können. Ich bin mir noch nicht ganz klar darüber ob das eine gute Idee ist und wie ich das machen könnte. Beste Grüße Felix
Du könntest für jeden Slave ein "Objekt" halten. Jedes Objekt hat einen Soll Zustand und andere "Eigenschaften". Dazu eine Queue für I2C Telegramme. ======== Deine Applikation spricht nur mit den Objekten. Jedes Objekt kümmert sich um "seinen" Slave. Wenn du eine LED dimmen willst, änderst du einfach diese Eigenschaft des LED Objekt. Das LED Objekt erzeugt ein Telegramm für den Slave und legt es in die Queue. Und es setzt den Status auf "in Arbeit". Im Status "in Arbeit" prüft das Objekt die Queue regelmäßig auf Rückmeldungen.
Du könntest dich mal mit den kleinen RTOS wie Nut/OS, FreeRTOS usw. beschäftigen. Dort können mehrere Tasks parallel laufen. Ansonsten eben die harte Tour mit State Machines, Queueing, Interrupts und Callbacks. Ist auch machbar, erfordert aber einiges an Denkarbeit (und erfahrungsgemäß Debugging).
Wir hatten ein ähnliches Problem. Die Lösung war ein zusätzlicher Mikrocontroller, der die Steuerbefehle/Logik für den Motor übernimmt. Der Hauptmikrocontroller sendet dann nur noch die gewünschten Motorpositionen als einzelne I2C Nachrichten.
Felix is the best schrieb: > > Wenn ich nun die Position des Motors verändern will, was vielleicht ein > paar Sekunden dauert, dann ist solange auch der Bus belegt; sprich: eine > LED ließe sich in der Zwischenzeit nicht dimmen. > Das verstehe ich nicht. Normalerweise sind I2C Kommandos recht kurz. Nehmen wir 100KHz Frequenz und ein Kommando mit 10 Bytes. Dann ist das in 1 Millisekunde verschickt, und der Bus ist frei für etwas anderes. Wieso ist der Bus ein paar Sekunden belegt? Werden Megabytes über den Bus verschickt?
> Wieso ist der Bus ein paar Sekunden belegt? Werden Megabytes über den
Bus verschickt?
Weil ich z.B. bei Schrittmotoren eine bestimmte Abfolge an Befehlen
absenden muss, damit er sich bewegt, sonst würde nur ein Schritt
ausgeführt werden.
Da ich die Hardware nicht mehr ändern kann (einen Mikrocontroller
spendieren um den Motor zu treiben), bieten sich nur die vorgeschlagenen
Softwarelösungen an.
Felix is the best schrieb: > Weil ich z.B. bei Schrittmotoren eine bestimmte Abfolge an Befehlen > absenden muss, damit er sich bewegt, sonst würde nur ein Schritt > ausgeführt werden. Klingt nach einem schweren Designfehler. Wenn man die Motortransistoren zu Fuß ansteuert, sollte man wenigstens IO-Pins dafür benutzen und nicht erst durch einen PCF8574 tunneln. Noch besser ist es, wenn man 4 PWM-Ausgänge dazu benutzt.
Moin, Peter D. schrieb: > Klingt nach einem schweren Designfehler. Seh' ich auch so. Wenns das so ist und da nix mehr geaendert werden kann/will/soll - dann muss man halt schmerzhaft aussenrumprogrammieren. Also wenn z.b. die Motor-I2C Kommandos zeitkritisch sind, dann z.B. immer direkt nach so einem zeitkritischen Kommando, wenn man weiss, dass jetzt sich der Spulenstrom ein paar msec aufbauen kann, gleich mal die Zeit nutzen und eines der nicht so zeitkritischen I2C Kommandos abarbeiten, so denn eines ansteht... Gruss WK
> Klingt nach einem schweren Designfehler.
Joa so im nachhinein kann ich dem nur beipflichten.
Felix is the best schrieb: > Die einzige Möglichkeit die ich jetzt sehe wäre die Befehle der > Motor-Ansteurung in kleine Häppchen aufzuteilen, damit zwischendurch > auch andere Sachen gemacht werden können. Hast du schon das Timing berechnet?
Nur meines Verständnisses halber. Wie sieht denn solch ein "Motor slave" aus? Hast Du dort wirklich nur ein I2C to GPIO chip dran? Oder hast Du einen Mikrocontroller, der einen Motortreiber über die GPIO Pins angeschlossen hast (nicht über I2C) und würdest gerne, während der Motor läuft, noch über I2C Daten an den LED Controller senden?
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.