"Echter" Digitalservo

[Klebwax]

Hoffe die Erklärung wird Verstanden und sonnst fragt halt wieder, für das habe ich ja diesen Thread eröffnet.......

Ich schon verstanden, was du machst. Nur sollte man Begriffe wie asynchron bei einem Bus der synchron ist vermeiden. Das führt zu Missverständnissen. Außerdem sollte man I2C vermeiden, wenn man nicht I2C macht. Die I2C Spec sieht einen durchlaufenden Takt nicht vor und, was dein Konzept kippt, erlaubt jedem Slave bei jedem Bit SCL auf low zu halten, solange es ihm beliebt (im Hs-Mode nur beim 9. Bit). Dein Bus arbeitet also nur mit deinem Master und deinen Slaves. Ein Master, der kein durchlaufendes SCL erzeugt, der eher I2C Frames als kurze Bursts erzeugt, kann deine Servos nicht betreiben. Ebenso bringt ein beliebiger I2C Slave, der z.B das ACK nach einem Readrequest solange stetched, bis er die die zu lesenden Werte bereitstellen kann (so haben sich die I2C Erfinder das mal gedacht und deswegen ist ja nicht nur SDA ein wired-or sondern auch SCL), deinen Bus komplett aus dem Tritt.

Im Prinzip hast du einen 1-Wire-Bus mit einer zusätzlichen Taktleitung. Man kann aber erkennen, wie flexible das Konzept eines wired-or Busses so ist.

MfG Klebwax

P.S. Die Bezeichnung Königswelle stammt nicht von mir. Ich kenne den Begriff aus dem Maschinenbau, und da es heutzutage meist keinen Zentralen Antrieb mehr gibt (z.B. mehrere Antriebe statt Zug und Leitspindel) ist mir die digitale Königswelle auch schon untergekommen.

- - - Aktualisiert - - -

Habe mir Magnetische Winkelcodierer IC angesehen (Bsw AMS AS5045-ASSU) aber das würde den Preisramen für kleine Servo sprengen, die dinger sind ja schweine teuer......

Ich meine schon Servos gesehen zu haben, die solche Bausteine oder auch einen Resolver einsetzen, hier mal ein Link

MfG Klebwax

[Pali64]

Hallo Klebwax,

Ja was den nu I²C oder nicht??? .... OK ......
bei den von uns Hergestellten Steuerungen, wird der Bus auch "RJC-I²C" genannt aber im Asynchronbetrieb (Nochmals nicht der Bus gemeint sondern die Device) ist der Bus bis auf die 12V Pegel (welcher ja zwar in den NXP Applikationen auch gezeigt wird) 100% I2C Protokoll konform (Wurde Norm-geprüft da es in der Industrie eingesetzt wird).

Ich weiß das es Devices gibt die den SCL Strecken bis sie Ihre Arbeit erledigt haben.... Wird von uns übrigens auch verwendet für gewisse Devices die so ihr Abwarten auf Ende, oder Bereitschaft mitteilen.
Trotzdem ist es ein I²C Protokoll (wäre ja rein theoretisch schon bei nicht TTL Pegel der Fall weil der klar im I2C Protokoll definiert ist).
Ich denke auch nicht das User den Servo I²C Bus rein schon wegen den 12V Pegeln nicht für Standard I2C Bus teile brauchen werden, obwohl wir für unsere RJC I²C Module auch applikationsbeispiele dem Kunden vorschlagen für bsw PCF 8574 parallel als Taster und Anzeigerückmelder im Bussystem zu verwenden......

Also langer Schreiber Kurzer Sinn, Es entspricht dem I²C außer das halt im Device-Synchronbetrieb permanent FF$ eingelesen werden muss bis die Device's (Hier halt Servo) ihre Arbeit erledigt haben.
Im Device-Asynchronbetrieb ist es 100% I2C Protokoll konform.

Gruß Pali64

[Klebwax]

Hallo Klebwax,

Ja was den nu I²C oder nicht??? .... OK ......
bei den von uns Hergestellten Steuerungen, wird der Bus auch "RJC-I²C"

Du kannst den Bus nennen wie du willst. Ich vergebe keine I2C Lizenzen mit der Erlaubniss, das Logo zu führen noch mache ich Konformitätstests.

Aber mein Rat wäre, nenn das anders. Wenn du ein Gerät in die freie Wildbahn entlässt, mußt du damit rechnen, daß die Anwender locker mit der Doku umgehen und insbesondere nur den Anfang lesen. Steht da I2C, würde ich mir vorstellen: ich nehm einen Raspi und steuere das mit dem Kernelmode I2C Treiber und einem Python Script. Wie ich auf die 12V komme, find ich schnell raus, ist ja allgemein bekannt. Und da ich schon mal einen getriebenen Bus habe, klemm ich noch nen SRF08, eine IMU oder sonstwas daran. Jetzt mußt du anfangen zu erklären, daß bestimmte Dinge so nicht funktionieren, daß der Raspi oder der Arduinio so ohne weiteres keine dauerhafte Clock erzeugt, daß mit den üblichen Treibern ein Warten auf 0xFF nicht möglich ist. Du wirst irgendwann die Lust daran verlieren. Ist aber nur ein Rat aus Erfahrung, ich geb ihn für 2¢.

MfG Klebwax