Was ist Synchron? DER SERVO!
Hallo Klebwax,
Das Synchron bzw Asynchron, beziht sich auch nicht auf den Bus selbst, sondern auf das die Servo Synchron oder Asynchron zu einander verhalten.
Das I²C Bussprotokol ist so vom Hersteller (Vormals Phillips nacher NXP) spezifisziert, das wenn KEIN Startbit erkannt wurde das Klocksignal machen darf was es will das heist es wird von den I²C standarddevices Ignoriert. Nun habe ich mir dies zu Nutze gemacht, (Wird übrigens vom MSP430 I²C UART Unterstützt) das der Clock so lange stabile pulse ausgibt, bis das Stopbit erkannt wird.
So fährt der Servo Los und Synchronisiert seine Fahrt mit dem SCL bis er seine Endposition erreicht hat. Hat er sie erreich senddet er ein Bitmuster das seine Adresse als Bit wiederspiegelt
Als Beispiel:
[Start Bit][Adress][Command][SCL]----------[SCL][Bitmuster auf SDA 10111111 11111111] für servo No 1
So quitiert der Servo 1 dass er sein "Ziel" erreicht hat
{wie oben}----[SCL][Bitmuster auf SDA 11011111 11111111] für servo No 2
{wie oben}----[SCL][Bitmuster auf SDA 11100111 11111111] für servo No 3 und 4 Zeitgleich angekommen
Das heißt der Controller liest so lange "FF" vom I2C Bus bis alle Servos sich gemeldet haben und ihre Fahrt Quitiert haben
Es gibt auch die Möglichkeit dass sich die Servos Sequenziell mit Ihrem Stromverbrauch melden bis die Fahrt beendet ist, dies ist aber der Geschwindigkeit wegen nur im 400kHz Modus möglich.
Auf diese weise fahren die Servos, absolut Synchron und der MC ist permanent auf dem Stand des Stromverbrauchs und über die Situation der Servos.
Dies verhindert auch das ev. bereits ein Neuer Fahrbefehl gesendet werden kann bevor alle Servo ihr Ziel erreicht haben.
Dadurch lassen sich aufwendige Fahrkontrollen mit Zusatzkabel o.ä. aufwand vermeiden.
Ich arbeite mit diesem Prinzip schon Jahre für Chemiewerke um so Schlauchpumpen per I²C Bus zu Kontrollieren und exakt Chemie zu mischen.
Es hat sich bewährt und ist auch keineswegs Fehleranfällig. Aber ein Problem mit verklemmten Servos(Hier halt Pumpen) wird vom System sofort erkannt.
Hoffe die Erklärung wird Verstanden und sonnst fragt halt wieder, für das habe ich ja diesen Thread eröffnet.......
Gruß Pali64
Liste der Anhänge anzeigen (Anzahl: 3)
Hallo oberallgeier,
Ja und ich versteh wie du das Löst :)......
Aber du kontrollierst nicht die Stromaufnahme der Servos?, und hast somit auch keine Rückmeldung was der Servo gerade macht?. sondern du schickst einfach Timergenau neue PWM Längen und gibst damit auch die Fahrgeschwindigkeit vor hmmmm.... Ja das geht sicher aber was passiert wenn ein servo plötzlich "Hängt"? dan hast du keine Rückmeldung, oder prüfst du das woanders im Programm?
Na ja auch egal es funst ja bei dir ;)
I²C vs I2C: Hmm ah ja dann verstehe ich natürlich dein Timingproblem, da kommt dein Prozi ja ganz schön ins Schwitzen :D
Ich arbeite eben mit dem MSP430 von TI und bin in der Beziehung Steuerung-seitig, klar im Vorteil. ;)
Anhang 31359
Der hat interne DMA Logic,
Anhang 31360Anhang 31361
Womit ich grad für das Fahren über den I²C Bus klar im Vorteil bin. Ich lege eine Tabelle mit den Koordinaten und Fahrgeschwindigkeiten an, setze den DMA Tackt für das I²C-UART die Start und Endadresse der Tabelle im DMA des MSP430.... und schick theoretisch die eigentliche CPU Schlafen (oder lass sie was anderes machen) bis die Servos ihre Arbeiten erledigt haben.
Ich habe so natürlich den Vorteil durch die Bidirektionale Kommunikation, zwischen der I²C-UART und den I²C-Device das dies völlig selbstständig abläuft (na ja zumindest fast) und die CPU immer erst wenn Alle ihre Fahrt abgeschlossen haben von der DMA wieder geweckt wird.
Gruß Pali64
