Ja, das siehst du richtig. Der Servo setzt die Bytes 6 und 7. Der Grund ist die Beschränkung auf nur eine einzige Leitung für Tx und Rx in den Servos. Deshalb werden die Bytes 6 und 7 als 0 gesendet, welche der Open-Collector-Treiber des Servos auf 1 ziehen kann, wenn er möchte. (Im Grunde senden also beide gleichzeitig die Bytes 6 und 7. Nur die 1 Bits vom Servo stechen die vom Controller.) Der Controller empfängt aber alle 7 Bytes, da er den ganzen Datenstrom einliest. Die ersten 5 Bytes kann er gleich wieder vergessen, die hat er ja selber gesendet.
Es gibt inzwischen aktuelle PDFs zum Protokoll. Ich nutze das hier: http://robosavvy.com/site/Builders/l...9-22.pdf<br />
Schau dazu auch mal in diesen Thread:
http://robosavvy.com/forum/viewtopic.php?t=1687
Also ich habe das mal ausprobiert und kann sagen, dass die serielle Ansteuerung prinzipiell funktioniert.
Ich hatte allerdings Probleme mit der Stabilität, d. h. nicht jedes Kommando wurde richtig erkannt. Kann aber auch an meinem improvisierten Schaltungsaufbau gelegen haben.
Daisy Chaining habe ich nicht probiert, weil damals noch nicht bekannt war, wie man die ID eines Servos neu setzen kann und alle meine Servos dieselbe ID hatten.
Aber der Grund, warum ich im Moment den Ansatz nicht weiter verfolge, ist, dass die Abfrage der Position genauso wie beim PWM-Modus dazu führt, dass der Motor kurz stromlos geschaltet wird. Nützt mir nichts.
Ach so, das Killerkriterium: 19200 bps. Nein, ich glaube, es geht tatsächlich nicht schneller.
Fazit für mich: Schöner Ansatz, hätte viel PWM-Gefummel und noch mehr Ports gespart. Aber leider von HiTec suboptimal (freundlich ausgedrückt) umgesetzt.
Probier aber mal selbst ein wenig an der Sache rum. Kann schon nützlich sein und ist eigentlich viel eleganter als die PWM-Geschichte.
Lesezeichen