mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Ausgang am ATmega8 schwankt


Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
über den 16-Bit-Timer beim ATmega8 generiere ich am PORTD eine Frequenz 
von ca. 1,15 KHz mit einem externen Quarz. Am Oszilloskop zeigt der 
Ausgang aber extreme Schwankungen, die sich so gut wie gar nicht an die 
einprogrammierten Zeiten halten. Der Nulldurchgang zur 1 kommt zwar zur 
richtigen Zeit, aber danach flattert es nur "irgendwo" rum, mal hier, 
mal da (im Simulator klappt das Programm zumindest). Betrieben wird der 
Mikrocontroller auf dem Pollin Board V2. Ich habe momentan keine Ahnung, 
woran das liegen könnte. Habt ihr eine Idee?

Vielen Dank!
Matthias

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne Code keine Infos! Wie leider so oft, sind unsere Glaskugeln alle 
ausgefallen.

Es gibt eine ganze Reihe Möglichkeiten, mit einem AVR irgendwelche 
Frequenzen zu erzeugen. Und solange Du nichts darüber sagst, welche 
dieser Varianten Du benutzt, kann man nur raten...

Wenn Du tatsächlich am Port D die Signale ausgibst, heißt das zumindest 
schon mal, dass Du nicht die Hardware-Compare-Pinansteuerung verwendest. 
Also vermutlich irgendwas Interrupt-gesteuertes. Und da kann alles 
Mögliche dazwischenkommen, v.a. andere Interrupts.

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt überzeugend :)

Alsdann, hier mein Code (hab das Timer-Interval hochgesetzt; Quarz mit 
3,93126 MHz):

-------------------------------
.include "m8def.inc"
.def temp = r16
.def status = r17

.org 0x000
         rjmp main
.org 0x006
         rjmp timer_event

main:
         ldi temp, LOW(RAMEND)  ; Stack
         out SPL, temp
         ldi temp, HIGH(RAMEND)
         out SPH, temp

         ldi temp, 0b11111111    ; Ausgang
         out DDRD, temp

         ldi temp, 0b00010000
         out TIMSK, temp

         ldi temp, 0xFF
         out OCR1AL, temp
         ldi temp, 0xFF
         out OCR1AH, temp

         ldi temp, 0b00000001    ; Timer start
         out TCCR1B, temp

         sei

loop:    rjmp loop

timer_event:
         tst status
         brne an
         breq aus

an:      ldi status, 0
         sbi PORTD, 0

         ldi temp, 0
         out TCNT1H, temp
         out TCNT1L, temp

         reti

aus:     ldi status, 1
         cbi PORTD, 0

         ldi temp, 0
         out TCNT1H, temp
         out TCNT1L, temp

         reti
-------------------------------

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du solltest den CTC-Mode einschalten. WGM12 (Bit 3) in TCCRB, sonst 
läuft dein Zähler immer bis zum Ende und wird nicht beim Compare-Match 
auf null gesetzt.

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, die Rücksetzung hab ich relativ unelegant gelöst. Hab ich jetzt 
geändert, das Problem besteht allerdings noch immer.

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, solte eigentlich funktionieren! Probier doch mal einen anderen Wert 
für OCR1A, nicht grade den Endwert. Würde zum Testen die Mitte 
vorschlagen.

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

Bewertung
0 lesenswert
nicht lesenswert
Gleiches Problem.
Ich hab euch mal ein Screenshot angehängt

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sieht eher nach einem Problem mit der Messung aus. Sollten 
eigentlich saubere Rechteckimpulse sein. Hast du eine Brummschleife 
drin? Oszi-Schutzleiter liegt auf Masse und evtl. noch der Schutzleiter 
des Netzgerätes?

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cooler Vergleich! Die Burgen haben aber eine deutlich höhere Auflösung, 
grins!

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lol
Messung ist eignetlich korrekt, mit einem anderen, "gekauften" Prüfling, 
kommen saubere Rechtecksignale an.

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Misst du auch am richtigen Pin? Könnte auch ein Übersprechen sein.

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ist der richtige Pin.

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

Bewertung
0 lesenswert
nicht lesenswert
Sorry für den Doppelpost. Im Anhang ein Bild wie es richtig aussehen 
soll (die Zeiten sind unterschiedlich, aber gleicher Versuchsaufbau).

Autor: Henrik J. (henrikj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das jetzt ein anderer Conroller?

Wie wäre es, wenn du den alten dann wegwirfst? Das sieht mir ganz 
strange aus. Der DIO soll doch nur 5V oder 0V schalten. Aber der landet 
ja auch ab und an mal dazwischen. Das geht gar nicht. Ich würd noch nen 
dritten Controller ausprobieren. Falls der auch ok ist, geht der erste 
in die Tonne.

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aaaalso :-)
Ich habe hier ein gekauftes Gerät mit einem einfachen Microcontroller 
drin. Dessen Ausgang (von dem stammt das zweite Bild, das richtig ist), 
möchte ich mit einem ATmega8 simulieren (davon stammt das erste Bild). 
Ich habe inzwischen auch noch einen anderen ATmega8 probiert, aber 
gleiches Symptom.
Muss ich vielleicht an der äußeren Beschaltung irgendwas wichtiges 
beachten?

Autor: Mike R. (thesealion)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwie sieht das ganze immer noch stark nach einem Messfehler aus.
Das Programm ist zwar nicht so geschickt, aber eine Fehelr sehe ich da 
drin bisher nicht.

KOntrolliert noch einmal genau, wie du dein Signal mißt, evtl. den 
Controller von der restlichen Beschaltung des Pins trennen um Störungen 
auszuschließen.

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Endeffekt wird an den Ausgang ein Funkmodul angeschlossen. Am 
Empfänger, der sowohl das gekaufte Gerät empfängt als auch mein eigenes, 
erhalte ich bei dem gekauften das richtige Schaubild, während bei meinem 
dieses "verkrüppelte" ankommt, womit der Decoder natürlich nicht 
klarkommt. Da der Anschluss des Oszilloskops ja genau gleich erfolgt 
beim Empfänger für beide Sender, muss mein Sender falsch sein ;-)

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann koppel deinen Sender mal ab und guck wie dann das Signal am Pin 
aussieht.....
Denke so eine Info wäre am Anfang schön ganz sinnvoll gewesen.

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es könnte auch ne fehlerhafte masse am zweiten gnd des avr sein??

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine Vermutung:
ist der Port auf Ausgang geschaltet?

MW

Autor: Martin Kohler (mkohler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andere haben auch schon in diese Richtung gepostet, trotzdem:

Die Periodendauer des überlagerten Signals beträgt etwa 20x Pulsbreite 
des gewünschten Rechtecksignals. Bei einer Umschalt-Rate von ca.1kHz 
würde das für den überlagerten Sinus sehr stark auf die 50Hz 
Netzfrequenz hindeuten.

Vermutung: Du hast die Masseleitung vom Oszi nicht korrekt mit der 
GND-Referenz des Outputs verbunden oder hast eine Masseschleife übers 
Netzteil.

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Sender ist nicht angeschlossen, Masse ist richtig (ist auf dem 
Evaluation-Board von Pollin), Port ist auf Ausgang geschaltet.
Ich hab den AVR jetzt mal an eine Batterie angeschlossen, aber das 
Problem ist dasselbe. Als Oszi benutze ich (schäm) meine Soundblaster, 
was natürlich nicht optimal ist, aber da ja der andere Sender (auch mit 
Batterie) ein sauberes Rechtecksignal liefert, müsste die Soundblaster 
ja richtig angeschlossen sein.
Langsam bin ich am verzeifeln...

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, dass da eine ganze Reihe von AVRs defekt geliefert wurden? 
Das würde das Problem erklären, aber es ist schon unwahrscheinlich.
Ich brauche doch nur dieses gerade Rechtecksignal ;-)
Ich habe die Soundblaster über einen npn-Transistor an den AVR 
angeschlossen, das ist doch korrekt? Wiegesagt, beim anderen Sender 
klappt es ja :-/

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie sieht deine Messschaltung aus?

Ich denke auch, dass in diesem Fall die Messung
falsche Ergebnisse liefert.

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab grad kein Schaltplanprogramm parat:

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

                 ______ Soundkarte Links
 ___        | /
|     |D0     |/
| AVR |-------|\ npn
|     |       | \
|     |GND      |
|     |---------|
|     |         |________ GND
|     |
|_____|


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

Dann halt an XTAL1 und 2 den Quarz mit 22 pF zur Masse, 0,1 µF zwischen 
VCC und GND, da hab ich auch verschiedene Bauteile erprobt.

Autor: Henrik J. (henrikj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nen Vorwiderstand zwischen DO und Transistor hast du auch dran?!

Autor: Sonic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und 'nen Pullup an den Eigang der Soundkarte!

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habs grad mal mit den zwei Widerständen angeschlossen aber immernoch 
gleicher Effekt.

Autor: Janosh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es scheint die Versorgungsspannung sein miss mal da.

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Mittag!
Ich konnte jetzt irgendwie ein sauberes Rechtecksignal erzeugen und nun 
mache ich mich an die korrekten Timings. Der Simulator des AVR Studios 
zeigt die korrekten Timings an, in der Realität weichen sie aber schon 
ein Stück ab. Hat der Simulator beim 16-Bit-Timer irgendwelche Probleme?

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was verstehst du unter 'ein Stück' ?

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In meinem Sendeprotokoll gibt es sozusagen zwei Zeitlängen, ca 300 µs 
und 800 µs. Eine 0 entspricht 800 µs an und 300 µs aus, bei der 1 ist es 
genau andersrum, also 300 µs an und 800 µs aus. Das Verhältnis der 
an-Zeiten untereinander stimmt, die aus-Zeiten sind jedoch stets zu 
lang, obwohl sie im Simulator korrekt sind.

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> die aus-Zeiten sind jedoch stets zu lang

Noch mal.
Über welche Differenzen reden wir? Sind das 10%, 50%, 100%.
Macht der Timer in 1 Sekunde eine Millisekunde zuviel oder eine
Halbe?

Hintergund: Auch dein Quarz ist nicht absolut auf der Frequenz
die draufsteht. Ein bischen Abweichung hast du immer.
Wenn dein Timing also nur im kleinen Bereich abweicht, könnte
es sowas sein. Ist der Fehler aber größer, muss man woanders
suchen.

Autor: matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab jetzt nochmal genau nachgeschaut: Die Pause bei der 0 ist etwa 
3x zu lang, also ca. 900 µs (etwas länger als das Signal). Die Pause bei 
der 1 ist korrekt. Im Programm sind aber die Zeiten des Signals der 1 
genauso groß wie die der Pause der 0.

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.