-
Ja. Bei einem duty cycle von 50% hebt sich alles genau auf. Aber pass mal bei einem duty cycle von sagen wir mal 0,001% auf. Jeder der beiden Zustände low und hi wird quasi künstlich um eine, wie Du richtig sagst, kostante Dauer verzögert. Aber wenn Du zu 0,001% von der cycle zeit diese konstante Dauer dazuaddierst und zum den 99,999% auch diese konstante Dauer, dann pass das Verhältnis am Ende nicht mehr. Beispiel mit extemen Werten.:
cycle Periode 1 s
Befehhlsausführung der Abfrage und des Schaltens: 5s
duty cycle: 90%
also ist die Wunschzeit hi 900ms und die Wunschzeit lo 100ms.
Wenn Du zu jeder Zeit jetzt aber die hier (extrem lange) Befehlsausführungszeit von 5s dazuaddierst, in der der Zustand ja nicht geändert wird kommt eine hi-Zeit von 5,9s und eine low-Zeit von 5,1s raus. Und das sind nicht die gewünschten 90%.
-
Das stimmt, sobald die Verzögerung länger ist, alls der Impuls selbst, dann geht es nicht mehr, aber sag mir ein Gerät, das einen Impuls von weniger als 1/10 Mikrosekunden braucht. Und wenn, dann würde ich eh einen schnelleren Controller empfehlen.
Das es einfacher ist, das PWM Signal hardwaremässig generieren zu lassen, da bin ich absolut einverstanden, aber es geht auch softwaremässig (von mir aus gesehen) genauso genau. Der Code verschlingt einfach enorm Speicherplatz denn um diese Genauigkeit zu erreichen, braucht man viele NOP's, da man mit schleifen alleine dies nicht erreicht.
lg binaer
-
Du hast absolut recht mit nops kann man das auch erreichen.
Übrigens ist es nicht nur dann, wenn die Verzögerung länger ist, als der Impuls selbst. Nur dann ist der Fehler nicht mehr sichtbar, wohl aber messbar.
Wenn die cycle length genau so groß ist wie die Verzögerung, sagen wir mal beides 1s. ist der Fehler bei 90% trotzdem noch riesig. Aber auch bei einer Verzögerung von sagen wir mal 1/1000 der Impulsdauer ist der Fehler, der bei duty cycles, die sich um die 1% oder 99% bewegen noch echt groß. Ich habe letztens einen ATtiny 15L, der eine Hardware-PWM hat noch eine zweite dazuprogrammiert. Der Chip läft mit 1,6MHz. Man kann die Software-PWM gerade noch mit 1% genauigkeit steuern. Um die 50% ist der Fehler kaum messbar. Allerdings macht er bei 1% eigentlich 2% draus. Die Null habe ich manuell abgefragt.
Programmierst Du Deine Software-PWM eigentlich in Assembler? Welchen Chip benutzt Du?
-
Ich benütze diverse Atmel uCs. Je nachdem, was ich gerade brauche (Ports, Speicher,...) und der der da halt am günstigsten ist nehm ich.
Ich programmiere uCs prinzipiell nur in Assembler. So hat man seine Maschine wenigstens unter kontrolle. Je hardwarenäher die Programmiersprache, desto lieber ist sie mir ;)
Deshalb mag ich auch nichts besonders, wo "visual" davorsteht ;)
lg binaer
-
Cool. Könnte mir mal so nen Software-PWM Code von Dir ansehen, denn meine Software-PWM hatte das Problem, dass sie bei 0% eben den Fehler hatte, weil einfach getoggelt wurde und die Dauer des nächsten Zustandes in einen Timer geschrieben wurde. Bei 0% eben die Null. Gut der Timer läuft dann "sofort" über und und es wird quasi "sofort" wieder getoggelt. Problem: der Pin ist bei 0% um die Dauer der Ausführung dieser Befehle in einem Zustand, den er eigentlich nicht haben sollte (0% wird zu 0,5%). Später habe ich dann auf die Null explizit geprüft, was zwar das 0%- und 100%-Problem beseitigt, aber eben die Befehlssequenz und Ausführungszeit des Umschaltens wieder verlängert, und somit die Einstellung 1% wie gesagt 2% liefert.
-
Kann dir ja mal den Quellcode meines Roboterarms geben... ist zwar noch testweise und noch ziemlich verbuggt, aber das Prinzip sollte ja klar werden. Steuert 5 Achsen, die PWM Zeiten sind verkrüppelt, da Conrad 5€ Servos verkrüppelte Zeiten fordern ;)
Muss das dann für Zwei achsen noch änern, da dort vernünftige Servos rein müssen... hoffentlich kommen die morgen an :)
lg binaer
-
Ja. Das würde ich mir sehr gerne ansehen. Danke Dir! :) Wie funktioniert hier eigentlich die Dateiübertragung (Bin erst seit nem Tag hier)? Was meinst Du eigentlich mit verkrüppelt!?
-
Naja, ein PWM Signal dauert 20ms. Bei einem normalen Servo ist 1ms high ganz auf der einen seite, 1.5ms gerade, 2ms ganz auf die andere seite. Bei den Conrad servos sind diese zeiten eben ganz anders... was sie im modellbau sogut wie unbrauchbar macht, weil die Fernsteuerungen ja nicht darauf ausgelegt sind.
-
Aha. Ich habe noch nie ein Servo angesteuert, habe aber eines rumliegen (altes robbe). Freue mich deshalb um so mehr auf deinen Code. Was braucht man da eigentlich für ne Schaltung um den µC herum?? Würde wirklich gerne mal eines ansteuern.
-
Nicht viel, alles damit der uC läuft. Dann einfach plus und minus pol beim servo strom drauf und das datenkabel (meistens gelb, oder sonst weiss) am avr einstecken.
btw: schick mal email addy per pn, weiss nicht, wie ich dir sonst den code schicken soll.
lg binaer