PWM auf der DDS

[psclab38]

Also, was fehlt zum PWM:

* Eingabe der PWM-Frequenz und des PWM-Verhältnisses
* Umrechnung der Frequenz in Vorteiler/Teiler des Timers im AVR, hier immer Auswahl des optimalen Vorteilers beachten, damit die Auflösung der PWM möglichst groß bleibt
* Zurückrechnen in tatsächliche Frequenz (Rundung wegen der ganzzahligen Teilerverhältnisse im Timer), Anzeige der tatsächlichen Frequenz; Alternative: Einrasten der Frequenzeingabe auf "krummen" Werten, wie sie durch die Timer-Teilung entstehen
* Anlöten des kleinen Drahtes vom Timerausgang an die Verstärkerstufe, damit die ganze Zauberei auch hinten rauskommt


Die Sache mit der vernünftigen Auswahl der Eingabemethode (Frequenz<->Timerwerte) ist das größte Teilproblem. Ich habe das nach wie vor auf dem Schirm, und ehrlich, bisher sind keine privaten Basteleien dazwischengekommen *g*

Wenn aber einer von Euch zu ungeduldig ist, kann er sich gern drum kümmern, wobei ich jederzeit für Fragen zur Verfügung stehe.

Viele Grüße
Thoralt

Ich mach' dann mal ein neues Thema auf, damit die PWM endlich "offiziell" wird.

Thoralt, zu Deinen offenen Punkten": Wenn ich den Sinn und Zweck einer PWM-Anwendung richtig verstanden habe (ich hatte selbst noch keine Anwendung dafür), dann soll doch durch das Puls-Pausen-Verhältnis quasi ein "Analogwert" übertragen werden. Der Tiefpaß im Zielsystem ist aber doch normalerweise so dimensioniert, daß er das PWM-Signal so weit wie möglich glättet. Damit wäre doch eine bestimmte Frequenz relativ unwichtig; eher wäre die Periodendauer und davon prozentual der "Analogwert" von Interesse. Richtig?

Da mit der Methode kaum Präzisionswerte übertragen werden sollen, könnte ich mir vorstellen, daß 0.1% Genauigkeit erstmal genügen sollten. Das dürfte doch bei 16bit (?) Timer-Auflösung locker erreichbar sein.

Viele Grüße
Paul

[Marcel]

Naja, die Frequenz kann durchaus von Bedeutung sein
Je nachdem was mein Endsystem ist. Denkbar wäre z.B. mit dem DDS einen MOSFET anzusteuern, da ist die Frequenz entscheidend. Je höher die Frequenz, desto höher im allgemeinen die Verlustleistung. Das gilt aber eben nicht immer, z.B. können je nach Endsystem Resonanzen auftreten.
Klar kann das DDS mehr als nur die Resonanzfrequenzen austesten, aber das wäre ein Fall wo eine variable Frequenz durchaus sinnvoll wäre. Besonders fein einstellbar muss das System dazu nicht sein, aber was möglich ist sollte man auch umsetzen

[thoralt]

Heyho,

Ich mach' dann mal ein neues Thema auf, damit die PWM endlich "offiziell" wird.

Full Ack.

Zunächst einmal: Ich habe gerade den Sourcecode wieder ins Eclipse geladen und mir den avr-gcc wieder installiert (bin auf einen anderen Rechner umgezogen und hatte bisher noch nicht wieder das Bedürfnis). Ich habe als Fingerübung, um wieder in das Thema reinzukommen, erstmal unter Waveform>PWM> einen Eintrag "PWM Duty" nebst den Management-Funktionen für Encoder/Enter/Display angelegt. Soweit, so gut. Immerhin kann man schon durck Drücken auf den Encoderknopf den Wert auf default 50 % setzen, das ist doch mal was

Thoralt, zu Deinen offenen Punkten": Wenn ich den Sinn und Zweck einer PWM-Anwendung richtig verstanden habe (ich hatte selbst noch keine Anwendung dafür), dann soll doch durch das Puls-Pausen-Verhältnis quasi ein "Analogwert" übertragen werden. Der Tiefpaß im Zielsystem ist aber doch normalerweise so dimensioniert, daß er das PWM-Signal so weit wie möglich glättet. Damit wäre doch eine bestimmte Frequenz relativ unwichtig; eher wäre die Periodendauer und davon prozentual der "Analogwert" von Interesse. Richtig?

Da mit der Methode kaum Präzisionswerte übertragen werden sollen, könnte ich mir vorstellen, daß 0.1% Genauigkeit erstmal genügen sollten. Das dürfte doch bei 16bit (?) Timer-Auflösung locker erreichbar sein.

Mein Ziel - und ich halte das für dem Niveau des DDS angemessen - ist es, ein PWM-Verhältnis von 1...99 % (in Schritten von 1 %) erzeugen zu können. Ich stimme Marcel zu, dass man durchaus, um z. B. irgendeine Endstufe oder Leistungstreiber testen zu können, verschiedene PWM-Verhältnisse bei definierten Frequenzen erzeugen will. Die obere Grenzfrequenz wird zwar wegen unserer Endstufe (oder vielmehr wegen des Abschwächers) nicht so dolle, aber ein paar zehn KHz peile ich durchaus an. Mal sehen, wie dass dann auf dem Oszi aussieht.

Du hast recht, das Signal wird sicher irgendwo im Zielsystem glattgebügelt, aber ich hätte schön öfters eine definierte PWM-Quelle mit Rechteck-Ausgang gebraucht (z. B. Tests am Schrittmotor oder halbe Schaltregler im fliegenden Aufbau).

Ich hatte ja schon das Problem der Quantisierung der Frequenz durch die ganzzahligen Timer-Werte erwähnt. Was wäre besser:

• Die Einstellung der Frequenz wie bisher, aber interne "Rundung" auf Timer-gefällige Werte und damit leichte Abweichungen von der eingestellten Frequenz (wäre programmtechnisch wesentlich einfacher umzusetzen) oder
• Einstellung der Frequenz im PWM-Modus nur in quantisierten Werten (wesentlich aufwändiger, dafür _etwas_ präziser in der Ausgabe, wobei die Verbesserung <1 % sein dürfte)

Hat jemand dazu eine Meinung?

Viele Grüße
Thoralt

PS: Da ich den Code nun wieder "geöffnet" habe, bitte ich um Rückmeldung, ob irgendjemand ebenfalls Änderungen an panel.c, panel.h, PARAMS, dds-hw.c vornimmt, um potentielle Konflikte zu reduzieren.

[Roddot]

Bin zwar auch nicht so der PWM/PVM'ler aber für E-Motoren könnte eine variable PWM Grundfrequenz auch Sinn machen. Den Motor über eine der erhältlichen Halbbrücke deren Uref zB bei Ub/2 liegt anschließen. Das DDS übernimmt dann die Ansteuerung mit variabler PWM und dann kann man den besten Wirkungsgrad austesten der wohl von der Ansteuerfrequenz mit bestimmt wird.
Bei Heizfolien (Ätzbad) könnte eine Anpassung an die Zeitkonstanten auch sinnvoll sein.
Soweit ich weiß war PWM mal eine alte Erfindung um AC-Motoren an Gleichspannungen zu betreiben für Servosteuerungen.
Kommt also eine Spule am Aktor zum Einsatz ist die Grundfrequenz der PWM wohl ohnehin wichtig, wie auch immer das sich dann berechnet.

[psclab38]

Da ich den Code nun wieder "geöffnet" habe

Scheint mir, daß ich da wohl den richtigen Knopf gedrückt habe...

Vielleicht habe ich mich oben mißverständlich ausgedrückt. Es ist mir schon klar, daß die Frequenz ein durchaus wichtiger Parameter ist. Aber die Genauigkeit der Frequenz ist doch absolut nebensächlich!? Mit anderen Worten, wenn sich mit dem ATmega32 die PWM-Frequenz (oder eben die Periodendauer) nur in diskreten Schritten einstellen lassen sollte, dann ist das doch vollkommen in Ordnung. Die Genauigkeit würde ich eher einem möglichst exakten Duty-Cycle spendieren.

Wenn die PWM-Routine die eingestellte Frequenz intern auf einfach handelbare Werte anpaßt (auch wenn das nach außen hin nicht sichtbar sein sollte), dann ist das für mich vollkommen ok. Die andere Option wäre dann die Kür. Vielleicht ist es aber gar nicht mehr so schwierig, wenn der erste Schritt erst erledigt ist?

Viele Grüße
Paul

[thoralt]

Da ich den Code nun wieder "geöffnet" habe

Scheint mir, daß ich da wohl den richtigen Knopf gedrückt habe...

Hach, ich bin auch froh, mal wieder was anderes machen zu können

Die Genauigkeit würde ich eher einem möglichst exakten Duty-Cycle spendieren.

Das ist auch mein Ziel.

Wenn die PWM-Routine die eingestellte Frequenz intern auf einfach handelbare Werte anpaßt (auch wenn das nach außen hin nicht sichtbar sein sollte), dann ist das für mich vollkommen ok.

Freut mich zu hören. Das macht die Sache erstmal leichter umsetzbar.

Die andere Option wäre dann die Kür. Vielleicht ist es aber gar nicht mehr so schwierig, wenn der erste Schritt erst erledigt ist?

Naja, ich habe mir das nochmal durch den Kopf gehen lassen. Das zieht eine ganze Menge Arbeit nach sich. Man denke nur z. B. an die Sweeps... Aber Du hast recht, vielleicht ergibt sich dann, dass die quantisierte Frequenz - einmal berechnet und gesetzt - sich vernünftig ins Gesamtkonzept einfügt.

BTW: Nach den ersten Änderungen bin ich jetzt bei einer angezeigten Codegröße von 30353 (0x7777 *g*). Da wären also noch deutlich über 2k Platz. Das sollte reichen. Außerdem ist alles streng mit #ifdef COMPILE_WITH_PWM abgesichert. Wer will, kann also jederzeit auf die Variante mit externer Signalquelle (ohne PWM) umsteigen.

Eins noch: Ich habe, weil es sich so ergab, in DDS.h zwei Konstanten für die Definition der Menüeinträge hinzugefügt (#define SUBMENU_PWM_DUTY 49, #define SUBMENU_PWM_BACK 50). Diese Konstanten stehen jetzt auch in den zugehörigen Menü-Definitionen. Welche Konsequenzen ergeben sich daraus? Wo muss evtl. noch angepasst werden, damit die Geschichte "Menu identifier for DSP command" auch weiterhin komplett funktioniert? Ich vermute, dass hier nur noch der Rest der Welt, also jeder, der das Kommando benutzt, Änderungen vornehmen muss.

Viele Grüße
Thoralt

[Roddot]

Aber die Genauigkeit der Frequenz ist doch absolut nebensächlich!? .... Die Genauigkeit würde ich eher einem möglichst exakten Duty-Cycle spendieren.

Gute Frage! Nächste Frage?

Ich denke du hast recht, nur die Reproduzierbarkeit der Grundfrequenz ist hier wichtig.
Je nach Implementierung kommt das leidige IRQ Thema zum tragen.

[dg1vs]

Hi,

wenn Interesse besteht, würde ich gerne den Code für das große Display einchecken. Es wird dann alles über Compiler-Schalter abgesichert, bzw. wie von Paul schon vorgeschlagen über ein eignes panel204.c file. Könnte man einen CVS-Zugang bekommen?

Karsten

PS:
Das Größenproblem kann man ja mit einem 1284 Atmel lösen. Ich hab ne Leiterplatte mit dem Chip schon daheim zu liegen.

[thoralt]

Hallo,

wenn Interesse besteht, würde ich gerne den Code für das große Display einchecken. Es wird dann alles über Compiler-Schalter abgesichert, bzw. wie von Paul schon vorgeschlagen über ein eignes panel204.c file. Könnte man einen CVS-Zugang bekommen?

Natürlich besteht Interesse

Den CVS-Zugang musst Du bei amd-65 beantragen, er nimmt Dich in die Gruppe der Entwickler des Projektes auf Sourceforge auf. Voraussetzung ist natürlich, dass Du bei Sourceforge angemeldet bist.

Das Größenproblem kann man ja mit einem 1284 Atmel lösen. Ich hab ne Leiterplatte mit dem Chip schon daheim zu liegen.

Das stimmt. Allerdings, ich scheue den Aufwand und das Restrisiko, den IC zu tauschen. Das wird vielen, die ein DDS besitzen, ähnlich gehen. Deshalb versuchen wir alles, den Code irgendwie passend in 32k zu bekommen, damit wir niemanden von der Nutzung der Firmware ausschließen müssen.

Viele Grüße
Thoralt

[Marcel]

also ich finde folgendes erstrebenswert:

- Einstellung des Tastverhältnisses von 0-100% in 1% schritten
- Einstellen der Grundfrequenz (welcher Bereich wäre wohl drin?)

Wichtig bei der Grundfrequenz fände ich, dass die genaue Frequenz de ausgegeben wird angezeigt wird.
Ich fände es bei der Einstellung okay, wenn man nicht grade Werte einstellt, sondern sich direkt durch die Möglichkeiten des Timers wählt. Also statt 1000 Hz, 1100, 1200 Hz... z.B. 1024 Hz, 1642 Hz, 1896 Hz ...
Wenn die Frequenz sowieso durch den Timer (und die genauigkeit des Tastverhältnisses) eingeschränkt ist, macht es meiner Meinung nach kaum Sinn vorzugaukeln man könnte exakt 1536,754 Hz Einstellen. Dann lieber direkt die realisierbaren Werte anzeigen, dann wissen alle User woran sie sind

[psclab38]

Das Größenproblem kann man ja mit einem 1284 Atmel lösen. Ich hab ne Leiterplatte mit dem Chip schon daheim zu liegen.

Das stimmt. Allerdings, ich scheue den Aufwand und das Restrisiko, den IC zu tauschen. Das wird vielen, die ein DDS besitzen, ähnlich gehen. Deshalb versuchen wir alles, den Code irgendwie passend in 32k zu bekommen, damit wir niemanden von der Nutzung der Firmware ausschließen müssen.

Im c't-lab-Projekt sind bislang ATmega32 und ATmega644(P) verwendet worden. Für letzteren gibt es per Default auch schon fast überall eine Compileroption für den UART und der Rest ist (für unsere Zwecke) sowieso identisch. Bei der EDL (mit Arbitrary) wird es schon recht eng. Der Umstieg von ATmega32 auf 644P hat mich gerademal 15 Minuten gekostet, für Code- und Chipwechsel. Nur ist der dort gesockelt als DIL-40.

Mit dem richtigen Werkzeug ist der Wechsel eines TQFP-44 kein echtes Problem, ohne Werkzeug aber auch nicht wirklich: Beine abzwicken/abfräsen, Gehäuse entnehmen, Beine einzeln ablöten, saubermachen, neuen Chip drauflöten, fertig. Aber die meisten werden sowas aber trotzdem nicht wagen. Wie Thoralt meine ich, es wäre von Vorteil, wenn der Code noch in 32k reinpaßt.

Viele Grüße
Paul

[dg1vs]

Hallo,

ich hatte und habe beruflich den Luxus zwar embedded, aber mit einem TriCore zu arbeiten, der genügend Flash und halbwegs RAM hat. Und die Optimierungen, die wir machen müssen, gehen fast immer in Richtung Laufzeit. Deswegen der aktuelle Versuch, ein DDS mit dem 1284 und 20 MHz Takt aufzubauen. Und nen TQFP-44 traue ich mir mit meinen über 40 auch noch zu, aber beim eigentlichen DDS-Chip funktioniert die biologische Optik nicht mehr. Richtig ist, dass es dann immer noch eine Codevariante für den ATmega32 geben muss, die die Speichergrenze nicht sprengt. Möglicherweise muss man sich beim Bauen dann entscheiden.

Zum Thema Anforderungen PWM.
* Für den eigentlichen Frequenzwert ist es m.M. nach ausreichend wenn er in per Timer erreichbaren Schritten einstellbar ist. Siehe

sondern sich direkt durch die Möglichkeiten des Timers wählt. Also statt 1000 Hz, 1100, 1200 Hz... z.B. 1024 Hz, 1642 Hz, 1896 Hz ...

* Einstellung des Tastverhältnisses von 0-100% in min. 1 Promille-Schritten

Grüße Karsten

[psclab38]

... Und nen TQFP-44 traue ich mir mit meinen über 40 auch noch zu, aber beim eigentlichen DDS-Chip funktioniert die biologische Optik nicht mehr. ...

Hi Karsten, geht mir genauso. Aber dafür gibt es Leuchtlupen und Stereomikroskope...

Grüße
Paul

[thoralt]

* Einstellung des Tastverhältnisses von 0-100% in min. 1 Promille-Schritten

Ich habe das mal ausgerechnet. Zur Theorie: Wir haben den freien Pin am Controller PD4 (OC1B). Das legt uns auf Timer1 (16 Bit) fest, welcher zum Glück auch in der Firmware noch nicht benutzt wird. Vernünftigerweise wird der im Fast-PWM-Modus betrieben, dabei zählt er von 0x0000 bis zum frei wählbaren Endwert, welcher sich in OCR1A befindet. Wenn der Wert OCR1B erreicht wird, dann wird der Ausgang PD4 (OC1B) zurückgesetzt, bei Erreichen des Endwertes (OCR1A) wird er wieder gesetzt.

Nehmen wir einmal an, der Timer wird ohne Vorteiler mit dem Takt 16 MHz gefüttert. Unsere kleinste PWM-Frequenz wäre also 16 MHz / 65535 (wegen des 16-Bit-Timers) = ca. 244 Hz. Wir müssten also, um kleinere Zykluszeiten zu erreichen, einen Vorteiler (/8, /64 oder /256) vor den Timer schalten, was kein Problem ist, damit kommen wir auf 30.5, 3.8 und 0.95 Hz. Untere Grenze wird also 1 Hz sein. Das ist zwar nicht ganz so langsam, wie wir es vom AD9833 gewohnt sind, aber ich denke, das wird schon reichen.

Die obere PWM-Frequenz ist zunächst einmal etwas enttäuschend. Wenn wir von einem PWM-Teiler = 1000 ausgehen (Endwert = 1000), was nach Karstens Forderung von mindestens 1-Promille-Schritten nötig ist, dann kommen wir nur auf bescheidene 16 MHz / 1000 = 16 kHz. Das stellt mich ehrlich gesagt nicht zufrieden, hier hätte ich gern mehr. Wenn man stattdessen mit 1-Prozent-Schritten zufrieden wäre, kann man bis zu 160 kHz hochgehen. Möglich, aber sicher aufwändig, wäre hier ein Kompromiss, welcher bis 16 kHz mit 0.1 % Auflösung arbeitet und darüber automatisch auf 1 % Auflösung umschaltet. Oder man ignoriert das Problem, erlaubt die Einstellung im 0.1-%-Raster, aber ab 16 kHz wird der Teilerwert halt so klein, dass die tatsächlichen PWM-Werte nicht mehr genau den gewählten Werten entsprechen (die werden dann genauso wie die Frequenz quantisiert).

Soweit die Theorie. Ich bin momentan dabei, die o. g. Fakten in der Firmware auszuprobieren.

Viele Grüße
Thoralt

[Marcel]

wie wärs mit auto-umschaltung von 0,1% auf 1% sobald man höher geht mit der frequenz?