|
Datum:
|
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).
|
Datum:
|
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 |
|
Datum:
|
Angehängte Dateien:
-
11kHz_TV_0_4_prozent.jpg
48,9 KB, 135 Downloads
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.
|
Datum:
|
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
|
Datum:
|
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?
|
Datum:
|
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)
|
Datum:
|
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.
|
Datum:
|
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.
|
Datum:
|
Angehängte Dateien:
-
circuit_messpunkte.png
22,2 KB, 133 Downloads
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).
|
Datum:
|
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.
|
Datum:
|
> An den Lücken ändert sich aber auch bei höherer Abrastrate nichts (z.B. > 8 MSa/s). Bild?
|
Datum:
|
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.
|
Datum:
|
Angehängte Dateien:
-
12kHz_TV_0_4_prozent.jpg
46 KB, 104 Downloads
Walter schrieb: > Bild? 12kHz direkt an Messpunkt 1 gemessen.
|
Datum:
|
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.
|
Datum:
|
Angehängte Dateien:
-
12kHz_TV_0_4_prozent_direkt_am_ADC.jpg
43,9 KB, 109 Downloads
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).
|
Datum:
|
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.
|
Datum:
|
Angehängte Dateien:
-
Kopie_von_12kHz_TV_0_4_prozent_direkt_am_ADC.jpg
43,7 KB, 92 Downloads
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).
|
Datum:
|
Wird bei der Schaltung die PWM nicht am Anschluss HS ausgegeben?
|
Datum:
|
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)
|
Datum:
|
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 .....
|
Datum:
|
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.
|
Datum:
|
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 ....
|
Datum:
|
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.
|
Datum:
|
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.
|
Datum:
|
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.
|
Datum:
|
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)
|
Datum:
|
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?
|
Datum:
|
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. ;-)
|
Datum:
|
> 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.
|
Datum:
|
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?
|
Datum:
|
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 ....
|
Datum:
|
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€ ;-)
|
Datum:
|
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
Thread beobachten
Seitenaufteilung abschalten