Forum: Mikrocontroller und Digitale Elektronik I2C - Command Queue für verschiedene Slaves


von Felix is the best (Gast)


Lesenswert?

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

von Thomas W. (diddl)


Lesenswert?

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.

von Max G. (l0wside) Benutzerseite


Lesenswert?

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).

von Mick (Gast)


Lesenswert?

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.

von PittyJ (Gast)


Lesenswert?

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?

von Felix is the best (Gast)


Lesenswert?

> 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.

von Peter D. (peda)


Lesenswert?

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.

von Dergute W. (derguteweka)


Lesenswert?

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

von Felix is the best (Gast)


Lesenswert?

> Klingt nach einem schweren Designfehler.

Joa so im nachhinein kann ich dem nur beipflichten.

von Rainer S. (rsonline)


Lesenswert?

I2C überhaupt sehe ich sehr kritisch.

von HyperMario (Gast)


Lesenswert?

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?

von Pat P. (tsag)


Lesenswert?

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
Noch kein Account? Hier anmelden.