mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PWM-Ausgabe stimmt nicht bei AVR DDS


Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

habe dieses Projekt hier (AVR DDS Signal Generator V2.0)
https://github.com/dev26th/avr_dds_20/blob/master/README.md
auch nachgebaut.

Mir ist dann aufgefallen, dass etwas mit der PWM-Ausgabe nicht stimmt.

Und zwar ist es so, dass bei besonders kleinen und besonders großen 
Tastverhältnissen die Flanken springen. Man kann es mit dem Oszilloskop 
beobachten und man sieht, dass eine angeschlossene LED parallel dazu 
flackert.

Da ansonsten alles sauber funktioniert, vermute ich, dass es ein 
Software-Bug ist.

Den C-Code habe ich in den Anhang getan (main.c).

Vielleicht kann man der Sache hier gemeinsam auf den Grund gehen.


Es geht in jedem Fall um die PWM-Ausgabe, nicht um die PWM-HS-Ausgabe 
(die liegt an einem anderen Pin).

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier der Code-Bereich, in dem ich den Fehler vermute:
C
void pwm_displayDuty(void) {
  LCDGotoXY(10, 0);
  printf("%5.1f%%", ((double)config.pwmDuty+1) / 256 * 100);
}

void pwm_updateDisplay(void) {
  signal_updateDisplay();
  pwm_displayDuty();
}

void pwn_prepareBuffer(void) {
  for(uint8_t i = 0; ; ++i) {
    signalBuffer[i] = (i <= config.pwmDuty) ? 255 : 0;
    if(i == 255) break;
  }
}

void pwm_run(void) {
  while(running) {
    pwn_prepareBuffer();
    signal_continue(true);
  }
}

void pwm_onStart(void) {
  if(!running) {
    signal_start();
    pwm_run();
    signal_stop();
  }
  else {
    running = false;
  }
}

void pwm_onUp(void) {
  if(!running) {
    menu_onUp();
  }
  else {
    if(config.pwmDuty < 255) ++config.pwmDuty;
    pwm_updateDisplay();
  }
}

void pwm_onDown(void) {
  if(!running) {
    menu_onDown();
  }
  else {
    if(config.pwmDuty > 0) --config.pwmDuty;
    pwm_updateDisplay();
  }
}
Code

Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch ein Screen-Shot vom Oszilloskop-Bild.

PWM-Frequenz: 11kHz

Tastverhältnis 0,4%


Man sieht deutlich die Lücken und die unterschiedlich hohe Amplitude der 
PWM-Pulse.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Man sieht deutlich die Lücken und die unterschiedlich hohe Amplitude der
>PWM-Pulse.

Mach mal ein Foto vom Messaufbau. Welcher Oszi?

Ich sehe nur eine Reihe von Messfehlern.

MfG Spess

Autor: Wolfgang (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Alex schrieb:
> Man sieht deutlich die Lücken und die unterschiedlich hohe Amplitude der
> PWM-Pulse.

Wieso erwartest du bei einer Abtastrate von 1 MSa/s ein vernünftiges 
Bild deines PWM-Signals, wenn der Takt zur Erzeugung eines 0.4% Pulses 
mit 11kHz schon bei deutlich über 2MHz liegen muss?

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rein gefühlsmäßig vermute ich folgendes:

a) Es wurde vergessen, bei der PWM-Ausgabe einen störenden Interrupt zu 
deaktivieren.

b) Das Orginal-Projekt läuft auf einem Atmega16. Der Autor für den oben 
angegebenen Code verwendet einen neueren (oder anderen) Atmega (im 
Schaltplan gibt er Mega16-P an - ich selber benutze einen Mega16-PU).


Könnte eins von beidem zu dem Fehlerbild passen?



--------------------------------------------------------------

spess53 schrieb:
> Ich sehe nur eine Reihe von Messfehlern.

An Messfehler hatte ich auch zuerst gedacht. Dann habe ich eine LED über 
einen Widerstand parallel zum Ausgang angeschlossen und die LED flackert 
nun gut sichtbar im Takt der "Messfehler".

Werde gleich noch mit einem Frequenzmesser gegentesten.

(Oszi ist ein 20MHz-China-USB-Teil - könnte auch noch mal mit einem 
Analogoszi gegenprüfen, aber wegen der ebenfalls flackernden LED tippe 
ich sehr darauf, dass das Problem ein Software-Bug ist)

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> An Messfehler hatte ich auch zuerst gedacht.

Alleine die Tatsache, dass bei einem (digitalen) PWM-Signal negative 
Spitzen auftreten, spricht zumindest für einen falsch abgeglichenen 
Tastkopf. Guck dir mal bei einer angemessenen Abtastrate die Einzelpulse 
an.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
>> Man sieht deutlich die Lücken und die unterschiedlich hohe Amplitude der
>> PWM-Pulse.
>
> Wieso erwartest du bei einer Abtastrate von 1 MSa/s ein vernünftiges
> Bild deines PWM-Signals, wenn der Takt zur Erzeugung eines 0.4% Pulses
> mit 11kHz schon bei deutlich über 2MHz liegen muss?

Da hast du recht, Danke für den Hinweis!

An den Lücken ändert sich aber auch bei höherer Abrastrate nichts (z.B. 
8 MSa/s).
Und wie gesagt "wandern" die Lücken beim Messen über den Bildschirm und 
eine parallel geschaltete LED flackert im Takt der Wanderbewegungen der 
Lücken.

Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der Frequenzzähler (Reziprokzähler bis 80MHz mit 
Schmitt-Trigger-Eingang) zählt ab einem Tastverhältnis von >= 0,8% die 
korrekte Frequenz aus.
Bei einem TV von 0,4% zeigt er genau 2/3 der Frequenz an. Hm.


Im Anhang noch der Messaufbau (Oszi-Anschluss unten mitte/rechts).

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> Und wie gesagt "wandern" die Lücken beim Messen über den Bildschirm und
> eine parallel geschaltete LED flackert im Takt der Wanderbewegungen der
> Lücken.

Zwischenzeitlich hatte ich zwischen Ausgang und LED (mit Rv) ein 
Bustreiber-IC zwischengeschaltet, weil ich dachte, die LED belastet 
vielleicht den Ausgang zu stark. Das Flackern blieb aber nach wie vor 
bestehen.

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> An den Lücken ändert sich aber auch bei höherer Abrastrate nichts (z.B.
> 8 MSa/s).

Bild?

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Alleine die Tatsache, dass bei einem (digitalen) PWM-Signal negative
> Spitzen auftreten, spricht zumindest für einen falsch abgeglichenen
> Tastkopf.

Die Tastköpfe sind perfekt abgeglichen, grade noch mal getestet.

Wenn ich den Tastkopf direkt an Messpunkt 1 anschließe (s. Schaltplan 
oben), bleiben die negativen Überschwinger aus.

Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Walter schrieb:
> Bild?

12kHz direkt an Messpunkt 1 gemessen.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> 12kHz direkt an Messpunkt 1 gemessen.

Eingestelltes Tastverhältnis ist 0,4%

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> 12kHz direkt an Messpunkt 1 gemessen.

Mit PWM hat dieser Puls ja nicht viel zu tun.

Was für ein Signal gibst du da aus?
Guck doch mal, die Signale direkt an den Digitalausgängen vorm DAC z.B. 
mit einem LA an.

Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Mit PWM hat dieser Puls ja nicht viel zu tun.

Ja, merkwürdig, fast so, als wäre irgendwo eine parasitäre Kapazität.


> Guck doch mal, die Signale direkt an den Digitalausgängen vorm DAC z.B.
> mit einem LA an.

Die Sache ist ganz einfach, im PWM-Modus gehen alle Pins (also PA0 bis 
PA7) gleichzeitig auf hi oder lo.

Im Anhang direkt an PA0 gemessen. In der Realität springt der Peak hin 
und her (auf dem Bild natürlich nicht erkennbar).

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> In der Realität springt der Peak hin
> und her (auf dem Bild natürlich nicht erkennbar).

Bezogen auf was spring der hin- und her. Wenn du auf den vorhergehenden 
triggerst, muss er (halbwegs) stehen.

Dann kannst du dir auch den Jitter angucken, indem du den Mittelwert 
über vieles Triggerereignisse anguckst.

Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Bezogen auf was spring der hin- und her.

Das Signal entsteht bei TV von 0,4% immer an einer der drei rot 
markierten Stellen (auf mehr oder weniger chaotische Art und Weise).

Wenn man das Tastverhältnis von 0,4% auf 0,8% hochstellt, ist jeweils 
über jeder roten Markierung ein Signal zu sehen (stabil ohne Springen 
und Wechseln).

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird bei der Schaltung die PWM nicht am Anschluss HS ausgegeben?

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg schrieb:
> Wird bei der Schaltung die PWM nicht am Anschluss HS ausgegeben?

Nein, die HS-Signale werden an Pin 19 ausgegeben. Es gibt auch HS-PWM, 
von dem ist hier aber nicht die Rede. Hier geht es um die normale 
PWM-Ausgabe, die über das R2R-Netzwerk an Port A ausgegeben wird.

Aber auf jeden Fall Danke fürs Mitüberlegen!!!



(HS-PWM kann nur ein paar fest vorgegebene Frequenzen über OC1A 
ausgeben)

Autor: Codelesa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> Da hast du recht, Danke für den Hinweis!
>
> An den Lücken ändert sich aber auch bei höherer Abrastrate nichts (z.B.
> 8 MSa/s).

Wie änderst du denn in dem Programm die Abtastrate?

Ich denke du hast da noch etwas überhaupt nicht
verstanden .....

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PWM Frequenz: 11 KHz
Tastgrad: 1/256 %
PWM-Auflösung: 8 Bit

Updatezeit: ~364 ns entspicht 7 Zyklen, Rest 14 ns

Die Frage ist, ob der µC das auflösen kann? Das Programm habe ich mir 
jetzt nicht näher angesehen, da es einfach nicht gut genug kommentiert 
ist.

Autor: Codelesa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Walter schrieb:
> Die Frage ist, ob der µC das auflösen kann?

Nö, glaube ich nicht .... auch ich hab mir das nicht näher
angeschaut da es aus dem Bauch heraus beurteilt nicht
funktioniert ....

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> Das Signal entsteht bei TV von 0,4% immer an einer der drei rot
> markierten Stellen (auf mehr oder weniger chaotische Art und Weise).

Dann guck doch mal im Simulator, warum das passiert. Der Zyklenzähler 
oder die Stop-Uhr verrät dir, wo du zeitlich liegst.

Autor: Codelesa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Dann guck doch mal im Simulator, warum das passiert.

Wenn er das mit der Abtastrate (noch) nicht verstanden
hat dann ist das hier auch nicht sinnvoll.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Alex schrieb:
>> Das Signal entsteht bei TV von 0,4% immer an einer der drei rot
>> markierten Stellen (auf mehr oder weniger chaotische Art und Weise).
>
> Dann guck doch mal im Simulator, warum das passiert. Der Zyklenzähler
> oder die Stop-Uhr verrät dir, wo du zeitlich liegst.

Mit Simulator meinst du eine Simulation im AVR-Studio? Bin da nicht so 
bewandert, habe es aber immerhin installiert.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Walter schrieb:
> PWM Frequenz: 11 KHz
> Tastgrad: 1/256 %
> PWM-Auflösung: 8 Bit
>
> Updatezeit: ~364 ns entspicht 7 Zyklen, Rest 14 ns
>
> Die Frage ist, ob der µC das auflösen kann? Das Programm habe ich mir
> jetzt nicht näher angesehen, da es einfach nicht gut genug kommentiert
> ist.

Ok, wenn der Atmega das gar nicht schaffen kann, ist die weitere 
Fehlersuche wohl sinnlos.

Aber vielleicht gibt es ja bestimmte Frequenzen, bei denen es exakt 
hinkommt. Das wäre ja schon mal was, wenn man die kennen würde :O)

Autor: Codelesa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> Mir ist dann aufgefallen, dass etwas mit der PWM-Ausgabe nicht stimmt.

Das angegebene Sourcen-Gefüge ist nicht auf Anhieb fehlerfrei
compilierbar.

Wenn man dann die kleinen Ungereimtheiten ausmerzt entsteht
ein Code der nicht in den angegebenen ATMega16 hineinpasst.

---------------------------------------
AVR Memory Usage
----------------
Device: atmega16

Program:   21028 bytes (128.3% Full)
(.text + .data + .bootloader)

Data:        763 bytes (74.5% Full)
(.data + .bss + .noinit)
---------------------------------------

wie funktioniert das bei dir?

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> Mit Simulator meinst du eine Simulation im AVR-Studio? Bin da nicht so
> bewandert, habe es aber immerhin installiert.

Dann starte den Simulator doch mal mit deinem DDS-Code. Nur installieren 
alleine bringt nichts. ;-)

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ok, wenn der Atmega das gar nicht schaffen kann, ist die weitere
> Fehlersuche wohl sinnlos.

So schnell sollte man nicht aufgeben.

---

Die schnellste Routine auf dem µCNet stammt von Werner:

Beitrag "Re: DDS Sinus erzeugung"
  add    r28,r24
LOOP1:
  adc    r29,r25    ; 1
  adc    r30,r26    ; 1
  lp                ; 2
  out    PORTB,r0   ; 1    UpDate
  add    r28,r24    ; 1
  adc    r29,r25    ; 1
  adc    r30,r26    ; 1
  add    r28,r24    ; 1
  lp                ; 2
  out    PORTB,r0   ; 1    UpDate
  rjmp   LOOP1      ; 2 => 14/2 = 7 cycles


Wenn du die Ausgabe so machst wie Werner (unbedingt den ganzen Thread 
lese, der sehr interessant ist), dann hast du bei einer Taktfrequenz der 
CPU von 20 MHz und eine PWM-Auflösung von 8 Bit eine max. Frequenz von 
rund 11160,7 Hz. Gehst du mit der Frequenz höher, dann verringert sich 
die Auflösung der PWM.

Autor: Alex (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute, vielen herzlichen Dank für das Interesse und das 
Ausprobieren etc.

Codelesa schrieb:
> Das angegebene Sourcen-Gefüge ist nicht auf Anhieb fehlerfrei
> compilierbar.
>
> Wenn man dann die kleinen Ungereimtheiten ausmerzt entsteht
> ein Code der nicht in den angegebenen ATMega16 hineinpasst.
>
> ---------------------------------------
> AVR Memory Usage
> ----------------
> Device: atmega16
>
> Program:   21028 bytes (128.3% Full)
> (.text + .data + .bootloader)
>
> Data:        763 bytes (74.5% Full)
> (.data + .bss + .noinit)
> ---------------------------------------
>
> wie funktioniert das bei dir?

Ich habe einfach die fertige main.hex von hier
https://github.com/dev26th/avr_dds_20
auf den Atmega16 geflasht (siehe Anhang).

Interessant, dass das Compilieren vom Source-Code ein File erzeugt, das 
nicht mehr auf den M16 geschrieben werden kann. Eventuell wurde vom 
Autor ein M32 verwendet, ohne dass er es im Schaltplan geändert hat?!?
Auch sehr verwunderlich, das es eine deutlich andere Größe hat als die 
mitgelieferte main.hex-Datei.
Könnte das Problem bei einer Compiler-Optimierungseinstellung liegen?

Wolfgang schrieb:
> Dann starte den Simulator doch mal mit deinem DDS-Code. Nur installieren
> alleine bringt nichts. ;-)

Ist auf dem anderen Rechner installiert, morgen kann ich es testen.


Walter schrieb:
> dann hast du bei einer Taktfrequenz der
> CPU von 20 MHz und eine PWM-Auflösung von 8 Bit eine max. Frequenz von
> rund 11160,7 Hz. Gehst du mit der Frequenz höher, dann verringert sich
> die Auflösung der PWM.

Danke für den Beitrag, sehr aufschlussreich!!! Das aktuelle Projekt 
läuft mit 16MHz, liegt dann die max. mögliche 8-Bit-PWM bei 8928 Hz?

Autor: Codelesa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex schrieb:
> Könnte das Problem bei einer Compiler-Optimierungseinstellung liegen?

Nein, ich habe/hatte -0s eingestellt, das ist schon die Optimierung
mit dem kleinsten Code. Mehr geht nicht.

Einzige mögliche Stolperfalle bei mir: ich habe WinAVR-20100110
benutzt, also weit weg von aktuellen Compiler-Versionen.
Aber ich bezweifle dass man noch mehr als 20% mit einer neueren
Version einsparen kann ....

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Codelesa schrieb:
> Wenn man dann die kleinen Ungereimtheiten ausmerzt entsteht
> ein Code der nicht in den angegebenen ATMega16 hineinpasst.

Gräm dich nicht. Ein ATmega328 gibt es fertig auf Platine für unter 2€ 
;-)

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Gräm dich nicht. Ein ATmega328 gibt es fertig auf Platine für unter 2€

Was nutzt ihm das?

ATmega328 -> 28 Pins

ATMega16  -> 40 Pins

MfG Spess

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.