mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR C "Variablenüberlauf"


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

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend,

ich bastel gerade an nem Frequenzzähler (atmega 8mhz, winavr, t0-pin als 
eingang). Läuft soweit so gut. (Abweichung bei 20khz ungefähr 100hz 
(zuviel) gegenüber einem Orginal Frequenzzähler, evtl leichtes 
Timingproblem der Schleife, ist im moment egal, wird später gemacht)

Das Problem:

Sobald es über 65536Hz geht (freq>65536) ist ja nen u_short am "ende". 
kann aber nicht auf long gehen wegen dem UTOA-befehl fürs Display 
(short>char). Gut dacht ich mir, machste halt in diesem Fall (wenn 
Zähler über 64000): Ergebniss/1000 und Anzeige als kHz. Es will aber 
nicht so richtig, es gibt immer nen Überlauf,d.h. die freq-variable 
fängt wieder bei 0 an. Hab auch schon mal die freq-variable als long 
definiert und das Ergebniss an eine u_short variable übergeben (passt ja 
dann rein), geht auch nicht, sobald die Frequenz über 65536Hz ist gibts 
nen überlauf.

Hier der Codeausschnitt (Completter Code im Anhang):
else //ab 64000hz = anzeige in kHz
    {
    lcd_clear();
    freq = (256*ztmp + count)/1000; // durch 1000 weil freq unsigned short
    utoa( freq, anz, 10 ); // übergabe freq > anz (anz ist char)
    set_cursor (0,1); // cursor pos setzen
    lcd_string( anz ); // anzeige frequenz
    set_cursor (6,1); // cursor pos setzen
    lcd_string( "kHz" ); // anz. in kHz
    }


mfg swen

Autor: swen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ne der läuft mit 16mhz...sorry

Autor: Micha H. (mlh) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
utoa rauswerfen und stattdessen selber was schreiben. Ich hab's mir 
einmal angeschaut und gleich wieder gelöscht, hat für mich nicht 
getaugt.

Mit der Suche findest Du hier auch was brauchbares.

Nur wegen utoa die Variablenbreite zu beschränken und dann mit 
Hilfskonstrukten drumrumlaborieren ist IMHO keine brauchbare Lösung.

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
swen schrieb:
> (Abweichung bei 20khz ungefähr 100hz
> (zuviel) gegenüber einem Orginal Frequenzzähler, evtl leichtes
> Timingproblem der Schleife, ist im moment egal, wird später gemacht)

Wenn du per CTC-Mode durch 125 teilen willst, musst du 124 in das 
OC-Register laden, nicht 125.

> Hab auch schon mal die freq-variable als long definiert
>     freq = (256*ztmp + count)/1000; // durch 1000 weil freq unsigned

Der Überlauf passiert auf der rechten Seite in der Klammer. Die Größe 
von freq spielt für diesen Überlauf (generell für die Berechnung auf der 
rechten Seite) nicht die geringste Rolle. Entweder du machst aus ztmp 
ein long, oder du kannst auch aus der "256" ein "256L" machen.

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha H. schrieb:
> utoa rauswerfen und stattdessen selber was schreiben.

Man könnte auch einfach ltoa nehmen.

Autor: swen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Ernst schrieb:
> swen schrieb:

> Wenn du per CTC-Mode durch 125 teilen willst, musst du 124 in das
> OC-Register laden, nicht 125.

> Der Überlauf passiert auf der rechten Seite in der Klammer. Die Größe
> von freq spielt für diesen Überlauf (generell für die Berechnung auf der
> rechten Seite) nicht die geringste Rolle. Entweder du machst aus ztmp
> ein long, oder du kannst auch aus der "256" ein "256L" machen.
>


Jo danke dir, hat geholfen ztemp als long und schon läufts!
hab auch die schleife auf 124 gesetzt, viel mir dann auch wie schuppen 
von den augen. abweichung nun kleiner aber nicht 0. bei 2000khz zeigt er 
2015khz an. hmm. ne idee?

Autor: swen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hatte noch nen felher gefunden (ein "count = 0;" war zuviel :-))

wenn ich sowohl das comparematch register als auch die schleife auf 124 
setzte komme ich auf 1999khz.. hmm näher aber irgenwie "drüber"

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

Bewertung
0 lesenswert
nicht lesenswert
Du solltest noch 'runden'

19990 / 1000

ergibt nun mal 19kHz und nicht 20kHz, auch wenn 20kHz der Wahrheit viel 
näher kommen würde.

   freq = (256L*ztmp + count + 500)/1000; //weil freq unsigned short

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

Bewertung
0 lesenswert
nicht lesenswert
Stefan Ernst schrieb:

> Der Überlauf passiert auf der rechten Seite in der Klammer. Die Größe
> von freq spielt für diesen Überlauf (generell für die Berechnung auf der
> rechten Seite) nicht die geringste Rolle. Entweder du machst aus ztmp
> ein long, oder du kannst auch aus der "256" ein "256L" machen.

Da diese Thematik im Forum des öfteren vorkommt, habe ich einen FAQ 
dafür begonnen

http://www.mikrocontroller.net/articles/FAQ#Datent...

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

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Du solltest noch 'runden'
>
> 19990 / 1000
>
> ergibt nun mal 19kHz und nicht 20kHz, auch wenn 20kHz der Wahrheit viel
> näher kommen würde.
>
>    freq = (256L*ztmp + count + 500)/1000; //weil freq unsigned short

Wie meinst du das mit runden? also wenn ich 19,99kHz runde dann ergibt 
das bei mir 20Khz, so wars in der Schule...;-)
du meins sicher, das die nachkommastellen rigoros abgeschitten werden, 
wenn sie an "ztmp" übergeben werden, hmm stimmt.

Warum brauche ich 256L (ich denk mal d.h. als Long definiert)? Mit 
"normal" 256 läufts, hab doch ztmp als long definiert (steht weiter 
oben). ->Wenn ich nun aber 256L nehme und ztmp wieder als unsigned 
chart, hab ich trotzdem nen Überlauf, beides zus. geht natürlich auch

Hab die Schleife noch mal angepasst. Nun ist der Fehler: rund 50hz 
zuviel bei 200kHz. Nimmt bei geringeren frequenzen stetig ab (4 Hz zu 
viel bei 20Khz, 2Hz zuviel bei 10Khz, fehlerfrei bis 2Khz). D.h. die 
Schleife ist nenn Tick zu langsam, obwohl mathematisch korrekt

Muss ich da noch ein bissl Handoptimieren, oder sind das 
Unzulänglichkeiten/Toleranzen in der Codeababarbeitung? Ist ja kein 
Assembler

Schleifenausschnitt
while(1)
{
  if (s==125){ //schleife mit 1hz 16mhz/1024/125/125 = 1,0000 hz
  count = TCNT0;
  s=0;
  ztmp = z;
  z= 0;
  TCNT0 = 0;
    if (ztmp<250) //1 -  64000Hz (256*250)
    {
    lcd_clear();
    freq = 256L*ztmp + count;
    utoa( freq, anz, 10 ); // übergabe freq > anz
    set_cursor (0,1); // cursor pos setzen
    lcd_string( anz ); // anzeige frequenz
    set_cursor (6,1); // cursor pos setzen
    lcd_string( "Hz" ); // anz. in Hz
    }
    else //ab 64000hz = anzeige in kHz
    {
    lcd_clear();
    freq = (256*ztmp + count)/1000; //weil freq unsigned short
    utoa( freq, anz, 10 ); // übergabe freq > anz
    set_cursor (0,1); // cursor pos setzen
    lcd_string( anz ); // anzeige frequenz
    set_cursor (6,1); // cursor pos setzen
    lcd_string( "kHz" ); // anz. in kHz
    }
  }
}
return 0;
}

mfg
swen

Autor: Swen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> freq = (256L*ztmp + count + 500)/1000; //weil freq unsigned short

upps, mann sollte auch 256L an die richtige stelle setzen. muss 
natürlich "unten" hin. sorry, dann klappts auch


Swen schrieb:

>     if (ztmp<250) //1 -  64000Hz (256*250)
>     {
>     lcd_clear();
>     freq = 256*ztmp + count;
>     utoa( freq, anz, 10 ); // übergabe freq > anz
>     set_cursor (0,1); // cursor pos setzen
>     lcd_string( anz ); // anzeige frequenz
>     set_cursor (6,1); // cursor pos setzen
>     lcd_string( "Hz" ); // anz. in Hz
>     }
>     else //ab 64000hz = anzeige in kHz
>     {
>     lcd_clear();
>     freq = (256L*ztmp + count)/1000; //weil freq unsigned short
>     utoa( freq, anz, 10 ); // übergabe freq > anz
>     set_cursor (0,1); // cursor pos setzen
>     lcd_string( anz ); // anzeige frequenz
>     set_cursor (6,1); // cursor pos setzen
>     lcd_string( "kHz" ); // anz. in kHz

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

Bewertung
0 lesenswert
nicht lesenswert
Swen schrieb:
> Karl heinz Buchegger schrieb:
>> Du solltest noch 'runden'
>>
>> 19990 / 1000
>>
>> ergibt nun mal 19kHz und nicht 20kHz, auch wenn 20kHz der Wahrheit viel
>> näher kommen würde.
>>
>>    freq = (256L*ztmp + count + 500)/1000; //weil freq unsigned short
>
> Wie meinst du das mit runden? also wenn ich 19,99kHz runde dann ergibt
> das bei mir 20Khz, so wars in der Schule...;-)

Das interessiert aber deine Berechnung nicht.
Eine Integer Division liefert keine Kommastellen.

Wenn du keine Vorkehrungen triffst, um bei einer Integer Division ein 
gerundetes Ergebnis zu erhalten, dann wird auch nichts gerundet.

> Hab die Schleife noch mal angepasst. Nun ist der Fehler: rund 50hz
> zuviel bei 200kHz. Nimmt bei geringeren frequenzen stetig ab (4 Hz zu
> viel bei 20Khz, 2Hz zuviel bei 10Khz, fehlerfrei bis 2Khz). D.h. die
> Schleife ist nenn Tick zu langsam, obwohl mathematisch korrekt

Das ist jetz durch deine Messmethode zu erklären.
Für das was du machst, gibt es einen eigenen Timermodus: Input Capture. 
Damit kannst du Zyklengenau messen unabhängig davon, wie lange dein 
Programm zur Auswertung braucht.

Die nächste Annahme, die du triffst:
Dein Quarz hat exakt 16000000 Hz. Die hat er aber nicht!

Autor: Swen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, aufm quarz steht 16,000 Mhz, da ist natürlich mit Abweichungen 
unterhalb 1Khz anzunehmen, wenn man das so deutet, wie es draufsteht. da 
muss wohl ein genauers (16,000000 Mhz :) )Quarz her, wenn es denn sowas 
gibt.

also mit input capture könnte man es ja mal probieren., was dann aber 
die unzulänglicheiten des quartzes aber nicht ausgleichen kann?!

Autor: Swen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Das ist jetz durch deine Messmethode zu erklären.
> Für das was du machst, gibt es einen eigenen Timermodus: Input Capture.
> Damit kannst du Zyklengenau messen unabhängig davon, wie lange dein
> Programm zur Auswertung braucht.

ich hab da mal nen thread ausgegraben, da gehts genau darum (input 
capture)

Beitrag "Input Capture Pin (ICP) auslesen ( Frequenz messen)"

da hast du freundlicherweise mal den code optimiert. nun lese ich aber 
was von max 75khz. weil das capture interrupt permanent reinschiesst. 
das wäre natürlich blöde.. ich brauch noch bissl cputime für weitere 
aufgaben.

mein plan: nen frequenzgenerator (max038 oder sowas) mit dem avr 
koppeln, d.h. ich stelle die frequenz mittels tasten am display ein, der 
misst dann die permanet die frequenz (darum der freqcounter) und regelt 
dann darauf ein und nach. da brauch ich ja noch kapazitäten.

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

Bewertung
0 lesenswert
nicht lesenswert
Swen schrieb:

>
> Beitrag "Input Capture Pin (ICP) auslesen ( Frequenz messen)"
>
> da hast du freundlicherweise mal den code optimiert. nun lese ich aber
> was von max 75khz. weil das capture interrupt permanent reinschiesst.
> das wäre natürlich blöde.. ich brauch noch bissl cputime für weitere
> aufgaben.

Grundsätzlich gibt es 2 verschiedene Messmethoden

a) Man baut ein 'Tor'
   Dieses Tor lässt man zb 1 Sekunde offen stehen, und zählt wieviele
   Pulse in dieser Zeit am Tor sichtbar sind.

b) man misst die Zeit von einer steigenden Flanke des Signals bis
   zur nächsten steigenden Flanke

Geht man nun davon aus, dass man Zeiten nicht beliebig genau messen 
kann, dann kann man sich mal fragen, wie sich eigentlich der Messfehler 
in den beiden Methoden verhält.
Und da sieht man etwas Interessantes: In Methode a) wird der Messfehler 
mit steigender Frequenz kleiner. Bei Methode b) hingegen wird der 
Messfehler mit fallender Frequenz kleiner.

Es gibt daher einen Punkt, über dem man mit Methode a) besser bedient 
ist und darunter mit Methode b)

Zudem ist man in beiden Fällen extrem gut beraten, wenn man die Messung 
erst dann starten lässt, wenn das Signal gerade eine Flanke macht.

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.