I2C - Command Queue für verschiedene Slaves

Felix is the best Gast 10.01.2019 09:36 #5689613

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

Beitrag melden Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Markierten Text zitieren Antwort Antwort mit Zitat

Thomas W. (diddl) 10.01.2019 09:49 #5689630

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.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Max G. (l0wside) 10.01.2019 09:58 #5689644

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

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Mick Gast 10.01.2019 10:05 #5689653

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.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

PittyJ Gast 10.01.2019 10:08 #5689657

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?

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Felix is the best Gast 10.01.2019 11:19 #5689774

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.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Peter D. (peda) 10.01.2019 13:03 #5689961

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.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Dergute W. (derguteweka) 10.01.2019 13:37 #5690031

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

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Felix is the best Gast 10.01.2019 13:41 #5690033

Lesenswert?

•

▲
▼

> Klingt nach einem schweren Designfehler.

Joa so im nachhinein kann ich dem nur beipflichten.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Rainer S. (rsonline) 11.01.2019 10:09 #5691050

Lesenswert?

•

▲
▼

I2C überhaupt sehe ich sehr kritisch.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

HyperMario Gast 11.01.2019 11:40 #5691207

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?

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Pat P. (tsag) 11.01.2019 13:07 #5691346

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?

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

I2C - Command Queue für verschiedene Slaves

Antwort schreiben