PWM?? wie geht das?

hallo.

wie geht das jetzt mit pwm?
gut, das das pulsweitenmodulation ist, weiß ich. und was da passiert auch.
aber wie bekomm ich das aus dem avr?
wie muß so ein timer/counter oder was auch immer geproggt sein?
die hardware geht übrigens schon. und ich kann motoren ein/aus schalten, und richtung ändern.
wo schließt man den pwm kanal an? an welchem port? gibts da einen bestimmten?? und überhaupt.

dank euch schon mal.

Das ist recht einfach erklärt, nicht ganz so einfach programmiert:

Bei einer PWM geht es, wie der Name schon sagt um Puls-Weite,

programmier ein Schema, bei dem auf einem Port in gleichbleibenden Zeitabständen der Pegel auf High geht,
je nach Energieanforderung lässt du ihn mehr oder weniger lange High,
er muß vor erreichen des nächsten Zyklus wieder aus sein.

Beispiel :
Einschaltung alle 100 mS, für 10 mS=10% PWM...........90mS=90%PWM

Das Timing kannst du über einen Timer und Zähler , Interrupt oder Capture/Compare machen.........je nach Controller.
Eine Softwareabhängigkeit ist nicht zu empfehlen da andere Prozesse das Timing stören können.

Da ich nicht mit AVRs arbeite, kann ich dir nur allgemeingültige Hinweise geben, also frag mich nicht....welchen Pin,welchges Register oder so.

Die richtigen Pins findest du im Datenblatt: OC1A, OC1B, OCxx..

Wie man PWM programmiert hängt davon ab welche Sprache du benutzt.
Für Bascom findest du etwas dazu in der Online-Hilfe und in diversen Beispielprogrammen hier im Forum (u.a. in den Anleitungen zu den Roboternetz-Boards)
Für andere Sprachen wird sich über Google sicherlich auch irgendein Beispiel-Code den man kopieren kann finden lassen.

Welchen AVR-Contrloller und welche Sprache willst Du denn genau verwenden?

Es gibt glaub schon Spezialfunktionen, aber ich mach es immer so, dass ich einfach in gewissen Zeitabständen einen Pin auf high und low setze. So kann man den Pin selbst wählen ;)
lg binaer

@binaer Natürlich gibt es Spezialfunktionen, und sogar speziell auf PWM-Ausgabe optimierte AVRs, z. B. die mit "8" als Zusatz in der Bezeichnung z. B. ATmega48 oder ATmega88 oder die mit "PWM" z. B. AT90PWM3. Hier die Übersicht: http://www.atmel.com/dyn/products/pa...&Direction=ASC

Ich finde es überhaupt keine Gute Idee, einen Pin in gewissen Zeitabständen zu setzen, es sei denn der Chip hat keine Hardware-PWM, denn dabei muss man
1. entweder pollen -> performancefressend und einfach unsauber oder
2. bei Timerinterrupt umschalten-> auch performacefressend und man hat nicht so viele zur Verfügung, so dass es schade ist dafür einen zu opfern.

Weitere Nachteile von manueller PWM sind:
1. Die maximale Frequenz ist dann eingeschränkt. Vor allem bei low power-µC, die sagen wir mit 1,6MHz laufen (z. B. ATtiny15L) ist das ein Problem, wenn man die PWM manuell macht. Meist wird bei solchen Controllern für die Hardware-PWM eine größere Frequenz zur Verfügung gestellt. Sehr comfortabel.
2. Eine manuelle PWM hat meistens glitches.
3. Die Präzision ist eingeschränkt. Da für das Erkennen des Zeitpunkts und für die Umschaltung des Portpins an sich Befehle benötigt werden, also Zeit verstreicht, verhält sich eine manuelle PWM vor allem in Grenzbereichen mit einen duty cycle nahe 0% oder 100% sehr sehr unlinear.

Aufgrund dieser Tatsachen rate ich die Hardware-PWM zu benutzen. Dazu müsste man allerdings konkret wissen welcher AVR verwendet wird, um helfen zu können.

Ich habe noch nie einen uC so intensiv benutzt, dass mir die z.B. 8MIPS nicht gereicht hätten. Die Schaltzeiten lassen sich damit auch auf den Takt genau einstellen. Genauer schafft das auch Hardware PWM nicht. Hardware PWM ist wahrscheinlich zum Programmieren einfacher, aber hab es trozdem noch nie gebraucht.
lg binaer

kank euch.
habs jetzt, und die motoren laufen.

@binaer Doch die Hardware PWM ist schon genauer. Eine Umschaltung erfordert inmmer ein paar Befehle und um die Ausführzeit dieser Befehle geht es. Zwischen dem Zeitpunkt, wenn der µC merkt: "Ach ich muss mal wieder Umschalten" und dem wirklichen Zeitpunkt des Umschaltens vergeht bisschen Zeit. Und genau diese Zeit macht die PWM unpäzise, weil der eingestellte duty cycle somit nie mit der ausgegebenen PWM übereinstimmt.

1. Die Zeit die die Befehle brauchen kann man einberechnen, dann geht das auf den Tackt genau.
2. Ist es doch der Elektronik die das PWM Signal empfängt egal, ob 1/10 Mikrosekunden früher oder Später geschalten wird.
3. Die Verzögerung die man laut euch beim setzen auf High hätte, hätte man dann auch beim setzen auf Low. Das hebt sich dann ja wieder auf.
lg binaer

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

Was mich dabei noch interessieren würde, wieviele verschiedene PWM Signale lassen sich von einem AVR generieren? Bzw. wie viele Servos könnte man mit einem uC anstenern?
lg binaer

Sieh Dir mal AT90PWM3 an der hat 10(!) Hardware-PWM-Kanäle. Also wirklich eine präzise und bequeme Sache.

Naja, wenn man Software-PWM macht, kommt drauf an wie man es macht. Benutzt man Timer, ist man durch deren Anzahl auch wieder beschränkt. Habe Deinen Code noch nicht genau angesehen. Benutzt Du Timer-Interrupts?

Nein, ich lasse den code einfach immer durchlaufen. Für UART anfragen etc benutze ich interrupts, die zeit die das in anspruch nimmt, wird dann aber wieder abgezogen, damit nicht ein zu langer pwm tackt entsteht. Ziemlich mühsam alles manuell gebastelt. ;)
lg binaer

Ach so. Cool. Und wie misst Du die Zeit, die für evtl UART-Bearbeitung verbraucht wurde? Oder ziehst Du einfach einen Erfahrungswert ab?

Das kann man ja genau vorherbestimmen... die Tackte, die die einzelnen Befehle bei der routine brauchen aufsummieren.
lg binaer

Bei den Interrupts gibts immer zwei möglichkeiten, entweder interrupt oder warteschleife, die genau gleich viel zeit verschlingt, so kommt es nicht drauf an. Bei den pwm generatoren wird auch immer x zeit verschlungen, dann wird geschaltet und dann nochmals y - x zeiit verschlungen. y konstant.
lg binaer

Meinst Du mit "PWM Generatoren" Hardware-PWMs? Die laufen ja total außerhalb des eigentlichen CPU-Cores, und verbrauchen somit keine Zeit. Du schreibst einfach x und y an der dafür vorgesehenen Adresse und die CPU bearbeitet sofort den nächsten Befehl. An dem betreffenden Pin wird dann die PWM ausgegeben. Solange Du nicht die Werte in den PWM-Registern überschreibst, bleibt der eingestellte duty cycle erhalten und die CPU kann ganz entpannt was anderes machen. Wie viele PWMs gibst Du im Moment eigentlich aus?

Ich meine damit natürlich meine software "pwm generatoren"...
ich werde beim nächsten projekt wo ich servos brauche (fast jedes projekt) mal diese hardware pwm generatoren ausprobieren.
ich gebe im moment 5 voneinander unabhängige PWM signale aus. für jede achse ein ;)
lg binaer

Dann wirds mit Hardware-PWM von der Anzahl her natürlich knapp, wenn Du 5 Achsen steuern willst. Die meisten gängigen AVRs haben 2 oder 3 Hardware-PWM-Kanäle. Das Problem "zu wenig PWMs" habe ich auch oft. Ich werde im Laufe der nächsten Monate, wenn ich Zeit hab, mal versuchen das ganze mit einem CPLD zu lösen, wo man dann gemütlich 20 richtig schnelle und präzise Hardware-PWMs hat, und der Controller nur noch die Änderungen über SPI oder I²C rausschickt., und das ganze Umschalten und Zählen wird im CPLD erledigt wird. Aber das ist noch Zukunftsmusik. Ich habe gesehen, dass du einen 8515 verwendest, der hat ja immerhin 3 Hardware-PWM-Kanäle.

Ja, aber 3 bringen mir nichts :( wenn ich 2 softwaremässig machen muss, kann ich gleich alle so machen ;)
Ja CPLD ist sicher net übel, aber ich denke das dürfte noch eine Herausforderung werden. Naja mit VHDL geht es noch, aber ich hab solches Zeug mal versucht durch logikschaltpläne zu basteln, das ist das perfekte chaos :(
Haltest mich über das Projekt auf dem laufenden ;)
lg binaer

Ja das stimmt. So ein Mix aus Hardware und Software PWM ist echt unübersichtlich unpraktisch und schlecht zu warten. Man könnte vielleicht auch zwei Controller nehmen und die Sache etwas dezentraler angehen. Es gibt ja kleine Controller, die sehr billig sind.

Über das CPLD-Projekt kann ich Dich auf dem Laufenden halten. Dann bookmarke ich Dich als Freund. Hast Du mit VHDL wohl schon was gemacht? Auch zwecks PWM?

Nein nicht bezüglich PWM, hab noch nichts wirkliches gemacht, halt einfach ein bischen rumprobiert.
lg binaer

Ich habe hier noch mal die beiden Formen von PWM herausgesucht, die ganz unterschiedliche Einsatzfelder und Randbedingungnen haben. Diskutiert wuden sie ja beide schon.
Manfred

http://www.netrino.com/Publications/Glossary/PWM.html

http://www.sprut.de/electronic/modell/allgemein/#3

Bild hier  Bild hier  

Das stimmt die Funktionsweise ist wohlbekannt. Was mich interessieren würde, ob jemand das Problem schon mal von der CPLD-Seite angegangen ist und vielleicht schon fertiger und dokumentierter VHDL-Code vorliegt.

Nein, hab ich noch nie gemacht ;)
Mit prozessbasiertem VHDL dürfte das gut machbar sein, wenn man direkt die Hardware beschreiben will, dürfte das vom Timing her eine ziemliche Herausforderung werden ;)
Aber wir werden da sicher auch Experten im Bereich CPLD/FPGA haben ;)
lg binaer

so und jetzt kannst mir bestimmt sagen wo man einen at90pwm1/2/3 bekommen kann, ich hab nämlich leider keinen händler gefunden der unter 1000 stück verkauft.
gruß werner...