PWM auf der DDS

[dg1vs]

* 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

Anforderung !!

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.

Hi Thoralt,

völlig richtig, die Frage ist doch, was will ich machen. In meinem Hinterkopf gibt es eine "echte" Anforderung, die in Richtung "Stromauflösung" in einer Spule geht. Mehr geht leider nicht an Ausage, aber in dem Umfeld, geht es um den Frequenzbereich von 1-25 kHz PWM.

Auf der anderen Seite, bleibt die Frage, wo brauche ich 160 kHz PWM?

[thoralt]

Hallo mal wieder,

völlig richtig, die Frage ist doch, was will ich machen. In meinem Hinterkopf gibt es eine "echte" Anforderung, die in Richtung "Stromauflösung" in einer Spule geht. Mehr geht leider nicht an Ausage, aber in dem Umfeld, geht es um den Frequenzbereich von 1-25 kHz PWM.

Auf der anderen Seite, bleibt die Frage, wo brauche ich 160 kHz PWM?

Nun, da ist was dran. Ich selbst habe jetzt gerade auch keine Idee, wozu das konkret gut ist. Aber vielleicht findet sich irgendwann mal ein User, dem das was nützt. Was die obere Grenzfrequenz angeht, muss ich mir die Signale erstmal auf dem Oszi ansehen. Wahrscheinlich sind hier eher 100 kHz angebracht, vielleicht auch weniger.

Ich werde zunächst mal folgendes versuchen, was die Einstellung des Tastverhältnisses angeht: Im unteren Frequenzbereich werde ich die Auflösung auf 0.1 % beschränken. Wenn man die Frequenz erhöht, dann wird die Auflösung graduell immer schlechter, was sich dann in größer werdenden Sprüngen bei der Einstellung äußert.

Viele Grüße
Thoralt

[thoralt]

Hallo Leute,

ich wollte nur mal ein kleines Statusupdate geben. Ich bin noch dran am Thema

Ich habe derzeit die Quantisierung der PWM-Frequenz fast fertig implementiert. Mehrere Varianten musste ich schon verwerfen, aber jetzt scheint mir eine einigermaßen elegante Version übriggeblieben zu sein. Das Problem ist immer wieder die Rundung bei der Umrechnung der Frequenz (double) in die Timer-Werte (int16_t). Hier kommt es zu Rundungen, die man vorher meist nicht bedacht hatte... Aber mittlerweile habe ich es (fast) im Griff. Im Flash sind auch noch über 1 kB frei, das reicht noch. Die Timer-Initialisierung ist ebenfalls schon drin, es fehlt noch an der vollautomatischen Vorteiler-Umschaltung, die ist derzeit erst halbfertig.

Worüber wir noch nicht diskutiert haben, ist die Pegeleinstellung. Hier gibt es zwei Varianten: Entweder machen wir die Einstellung symmetrisch wie für die anderen Wellenformen (außer "Logic") mittels Pegel/Offset, oder das PWM-Menü bekommt noch zwei Untermenüeinträge, mit denen man genau wie bei "Logic" getrennt den H- und L-Pegel einstellen kann. Die Einstellung über das Hauptmenü mittels Pegel/Offset bliebe dann natürlich trotzdem erhalten. Gibt es hierzu Meinungen?

Viele Grüße
Thoralt

[dg1vs]

Worüber wir noch nicht diskutiert haben, ist die Pegeleinstellung. Hier gibt es zwei Varianten: Entweder machen wir die Einstellung symmetrisch wie für die anderen Wellenformen (außer "Logic") mittels Pegel/Offset, oder das PWM-Menü bekommt noch zwei Untermenüeinträge, mit denen man genau wie bei "Logic" getrennt den H- und L-Pegel einstellen kann. Die Einstellung über das Hauptmenü mittels Pegel/Offset bliebe dann natürlich trotzdem erhalten. Gibt es hierzu Meinungen?

Hallo,

ich habe auf Arbeit zufällig einen Generator RIGOL DG 2021 "gefunden" und mir die Bedienung angeschaut. Letztlich hilft das auch bei meinem Thema....
http://thoralt.ehecht.com/phpbb/viewtopic.php?f=2&t=439

Das Ding kann umschaltbar beide Varianten darstellen, so ähnlich würde ich es mir auch wünschen (ich könnte dann die Umschaltung auf einen Softkey legen).
Somit könnte man immer beide Werte miteinander vergleichen. Default sollte m.M. nach Logic-Pegel sein.
Wenn ich wählen müsste, würde ich die "Logic" getrennt den H- und L-Pegel bevorzugen.

Karsten

[thoralt]

Hallo Leute,

Update: Derzeit ist Timer-Initialisierung, Frequenzeinstellung, PWM-Tastverhältnis-Einstellung implementiert. Es gibt noch ein paar kleine Ecken und Kanten, aber grundsätzlich ist es schon so, wie ich es mir vorgestellt habe. Gestern hatte ich das erste Mal ein PWM-Signal aufm Oszi

Ich musste allerdings wirklich lange suchen, warum kein Signal an der BNC-Buchse messbar war. Die Lösung war einfach: Ich hatte damals, weil ich nichts von dem externen Eingang hielt, das Relais zur Umschaltung des Eingangs nicht mit bestückt... Da muss ich mir erstmal eines besorgen, um die Sache mit der korrekten Pegeleinstellung zu testen. Sobald die Sache mit dem Pegel geklärt ist, werde ich eine Version einchecken. Das wird noch ein paar Tage dauern, da ich jeden Tag nur etwa eine Stunde was dran machen kann.

So long
Thoralt

[dg1vs]

Hallo Leute,

Update: Derzeit ist Timer-Initialisierung, Frequenzeinstellung, PWM-Tastverhältnis-Einstellung implementiert. Es gibt noch ein paar kleine Ecken und Kanten, aber grundsätzlich ist es schon so, wie ich es mir vorgestellt habe. Gestern hatte ich das erste Mal ein PWM-Signal aufm Oszi

Cool

D
Ich musste allerdings wirklich lange suchen, warum kein Signal an der BNC-Buchse messbar war. Die Lösung war einfach: Ich hatte damals, weil ich nichts von dem externen Eingang hielt, das Relais zur Umschaltung des Eingangs nicht mit bestückt...

Ich hab immer alles bestückt

Da muss ich mir erstmal eines besorgen, um die Sache mit der korrekten Pegeleinstellung zu testen. Sobald die Sache mit dem Pegel geklärt ist, werde ich eine Version einchecken. Das wird noch ein paar Tage dauern, da ich jeden Tag nur etwa eine Stunde was dran machen kann.

Geht mir auch so

D

So long
Thoralt

Hallo Thoralt

kannst Du vielleicht trotzdem den Code ins CVS stellen. Ich habe aktuell nen größeren Haufen an Änderungen im ldc.* und panel.*. Ich würde mich bereit erklären, die Änderungen zusammenzumergen. Ich glaube, so hält sich der Aufwand auf beiden Seiten begrenzt.

Ws ich gestern noch festgestellt habe ist, dass man mit Festlegung von static für Funktionen ne kleine Menge an Flash sparen kann. Der Compiler hat so mehr an Optimierungsmöglichkeiten.

Grüße Karsten

[thoralt]

Hallo Karsten,

kannst Du vielleicht trotzdem den Code ins CVS stellen. Ich habe aktuell nen größeren Haufen an Änderungen im ldc.* und panel.*. Ich würde mich bereit erklären, die Änderungen zusammenzumergen. Ich glaube, so hält sich der Aufwand auf beiden Seiten begrenzt.

Ich habe soeben eingecheckt. Du kannst ja mal nachsehen, ob es sich von selbst merged

Was ich gestern noch festgestellt habe ist, dass man mit Festlegung von static für Funktionen ne kleine Menge an Flash sparen kann. Der Compiler hat so mehr an Optimierungsmöglichkeiten.

Interessant. Meinst Du damit "static inline"? Das wäre für Funktionen sinnvoll, welche nur einmal aufgerufen werden. Du kannst Dich ja mal auf die Suche begeben und ein paar "static" einstreuen. Wir können jedes gesparte Byte gebrauchen.

Viele Grüße
Thoralt

[thoralt]

... ich hatte noch ein Schnipsel Code zur Initialisierung des Timers vergessen, das habe ich jetzt noch nachgereicht. Außerdem kann man nun *endlich* sowohl Frequenz als auch Tastverhältnis wirklich einstellen (derzeit nur vernünftig am Ausgang des Controllers messbar).

Thoralt

[dg1vs]

Hallo Karsten,

Ich habe soeben eingecheckt. Du kannst ja mal nachsehen, ob es sich von selbst merged

Ich habe es händisch gemacht. Beyond Compare sei Dank. Ich werde heute und morgen noch testen und dann einchecken.

... . Der Compiler hat so mehr an Optimierungsmöglichkeiten.

Interessant. Meinst Du damit "static inline"? Das wäre für Funktionen sinnvoll, welche nur einmal aufgerufen werden. Du kannst Dich ja mal auf die Suche begeben und ein paar "static" einstreuen. Wir können jedes gesparte Byte gebrauchen.

Ich würde nicht "inline" sagen. Static für Funktionen bedeutet, dass diese Funktionen nur in diesem C-Modul genutzt wird. Z.B. PrintLCD. Diese wird oft benutzt, trotzdem bringt es wenig aber immerhin. Der Compiler / Linker kann irgendwie diese Info benutzen. Möglicherweise gibt es auch einen Compiler/Linker Befehl dafür, der dass auch irgendwie dann erkennt. Static bewirkt aber eine gewisse "Kapselung" der Funktionalität.

Ich werde mal durchgehen.

Grüße Karsten

[dg1vs]

Hi Thoralt,

habe meine Änderungen auch eingepflegt. Es tut bei mir im Arbeitszimmer auf dem CAN128 und compiliert auch für die Atmega32 Version. Meine nächsten Schritte sind:

* Anpassungen an das 204 Display (aktuell nur 082)
* Noch mehr Trennung des Inhalts von der Darstellung
* Speicher sparen (static)
* Blockierung zwischen "Burst" und "Sweep" (Diskussion mit Paul)
* ...

Grüße Karsten

PS: Die Idee meiner Änderungen ist folgende:
Ich möchte Inhalt von der Darstellung trennen (ähnlich PrintLCD, eine Funktion, häufig benutzt, ich muss die Postion nur einmal ändern). Deswegen die Macros am Anfang von panel.c und die neuen Funktionen am Ende von panel.c. Ich hoffe, dass ich keinen Fehler eingebaut habe.

Grüße und bis denne

Karsten

[dg1vs]

..Interessant. Meinst Du damit "static inline"? Das wäre für Funktionen sinnvoll, welche nur einmal aufgerufen werden. Du kannst Dich ja mal auf die Suche begeben und ein paar "static" einstreuen. Wir können jedes gesparte Byte gebrauchen.

Viele Grüße
Thoralt

Hi Thoralt,

ich habe es gerade nochmal versucht nachzuvollziehen. Bei
neu Panel_OutputValue
alt PrintLCD
beträgt der Unterschied ob static oder nicht 6 byte. Nicht viel, aber immerhin.

Funktionen, die nur einmal benutzt werden, erkennt der Compiler (vielleicht Linker) selbständig, sobald aber mehrmals gerufen wird, kann static dem Compiler bei der Optimierung helfen.

Grüße Karsten

[dg1vs]

Hallo Thoralt,

ich bin heute zum Abgleich der zweiten DDS-Platine gekommen. Funktioniert auch mit dem großem µC (1284). Ich warte jetzt auch die Frontplatten und die neuen Leiterplatten für das „große“ Display.

Beim Probieren der PWM-Software ist mit aufgefallen, dass es nur möglich ist die Pulsweite zu ändern. Wenn man die Frequenz ändern möchte muss man erst wieder im Menu nach oben. Wäre es nicht von der Bedienung her einfacher, auch die Frequenzverstellung als extra Menüpunkt unter PWM mit einzubauen. Eine weitere Frage: Die Verstellung über Bus kommt sicher noch mit rein.

Grüße Karsten

[thoralt]

Hallo Karsten,

Beim Probieren der PWM-Software ist mit aufgefallen, dass es nur möglich ist die Pulsweite zu ändern. Wenn man die Frequenz ändern möchte muss man erst wieder im Menu nach oben. Wäre es nicht von der Bedienung her einfacher, auch die Frequenzverstellung als extra Menüpunkt unter PWM mit einzubauen.

Da hast Du recht, mir kam das auch schon etwas umständlich vor. Die Frequenzeinstellung ist dann zwar redundant, aber die Implementierung ist sehr einfach: Es muss lediglich der Menüeintrag für die Frequenz im Untermenü PWM angelegt werden, die Funktionen dafür sind ja bereits vorhanden. Ich werde das mal schnell einbauen - zum Glück haben wir ein flexibles Menü-Monster

Eine weitere Frage: Die Verstellung über Bus kommt sicher noch mit rein.

Ja, das muss der Parser erledigen. Ich habe das im Changelog als ToDo vermerkt, aber werde es wahrscheinlich nicht selber machen. Bisher hatte den Parser immer jemand anders betreut, vielleicht findet sich jemand? Es wäre jedenfalls sinnvoll, in den PWM-Modus wechseln zu können, das Tastverhältnis ändern zu können sowie H- und L-Pegel (analog zur Logik-Funktion) über den Bus einstellen zu können.

Viele Grüße
Thoralt

[thoralt]

Update: Die Änderung des PWM-Untermenüs ist eingecheckt: Jetzt kann man die PWM-Frequenz direkt neben der Pulsbreite einstellen. Weiterhin habe ich PWM-Hi- und PWM-Lo-Pegel ins Menü sowie in die Initialisierung und Range-Checks integriert. Das alles ist noch nicht getestet. Bitte vor weiteren Arbeiten am Code neu auschecken.

Thoralt

[psclab38]

Ja, das muss der Parser erledigen. Ich habe das im Changelog als ToDo vermerkt, aber werde es wahrscheinlich nicht selber machen. Bisher hatte den Parser immer jemand anders betreut, vielleicht findet sich jemand?

Also ehrlich! Der erste Parameter kostet Dich sicher nicht länger als 20 Minuten und den Rest hast Du eingebaut und getestet, bevor die Stunde voll ist. Ich war selbst immer erstaunt, wie schnell das geht.

Poste doch mal bitte für die anderen Interessierten, welchen Draht man genau fädeln muß, damit die PWM auch am Ausgang erscheint. Bevor jetzt alle raten müssen...

Grüße
Paul