einfache Drehzahlmessung mit ATmega88

Geschickterweise hänge ich noch die .hex-Datei an. Und wem dies nicht 
reicht, programmiere ich auch gerne zugeschickte Prozessoren im 
DIL28-Gehäuse.

Hallo,
folgender codeausschnitt verstehe ich nicht ganz:

1

  for(;;) {

2

    if(mess_status==MESSEN  && mess_dauer >= MESSZEIT) {

3

      mess_status=AUSLESEN;      // Auswertung starten

4

      mess_dauer = 0;        // wieder Messzeit abwarten

5

    }

6

    if(mess_status==AUSWERTEN) {

7

      end_zeit = zeit_high*0x10000 + zeit_low;

8

      mess_zeit = end_zeit - start_zeit;        // Zeit-Differenz bilden

9

      start_zeit = end_zeit;    // neue startzeit merken

10

      mess_ereignisse = end_ereignis - start_ereignis;  // Impuls-Differenz

11

    start_ereignis = end_ereignis;// fuers naechste Intervall

12

      mess_status = MESSEN;      // wieder warten

13

      if(messwert_vorhanden) {

14

    led_cnt = LED_EIN;      // LED-Zeit vorgeben

15

    frequenz = ((float)mess_ereignisse * F_CLOCK) / mess_zeit;  // Frequenz berechnen

16

    lcd_cmd(ZEILE1+5);      // 1.Zeile, 5.Spalte

17

    zeige_x(frequenz,0);    // Drehzahl anzeigen

18

    lcd_cmd(ZEILE2+5);      // 2.Zeile, 5.Spalte

19

    zeige_x(frequenz,1);    // Zeit/Umdr. anzeigen

20

      }

21

      else messwert_vorhanden = 1;  // sperre wieder aufheben

22

  }

23

  }

24

  return(815);

25

}

26

27

    lcd_cmd(ZEILE1+5);      // 1.Zeile, 5.Spalte

28

    zeige_x(frequenz,0);    // Drehzahl anzeigen

29

    lcd_cmd(ZEILE2+5);      // 2.Zeile, 5.Spalte

30

    zeige_x(frequenz,1);    // Zeit/Umdr. anzeigen

gibst du damit nicht auf beiden Zeilen das selbe aus?

mfg
Lukas

Lukas schrieb:
> gibst du damit nicht auf beiden Zeilen das selbe aus?

Sieh Dir bitte weiter oben an:
"void zeige_x(float x,char zeige_periode)"

Bei 'zeige_x(frequenz,0)' wird die Drehzahl (ursprünglich die Frequenz) 
und anderfalls die Periodendauer angezeigt.
Das obige Foto entstand bei ca. 1,2kHz Eingangsfrequenz; einmal x*60 
skaliert und in der 2. Zeile mit 1/x.

Vielleicht ist es niemandem aufgefallen und es wird äußerst selten zu 
'unsauberer' Auswertung führen, aber nachfolgender Programmabschnitt 
sollte vor einem T1OV-Interrupt geschützt werden. 'mess_dauer' kann 
sonst falsch gelesen oder gelöscht werden.
Die Sperre für TOIE1 habe ich hier ergänzt:

TIMSK1 &= ~(1<<TOIE1);           // t1OV interrupt sperren
    if(mess_status==MESSEN  && mess_dauer >= MESSZEIT) {
      mess_status=AUSLESEN;      // Auswertung starten
      mess_dauer = 0;            // wieder Messzeit abwarten
    }
TIMSK1 |= (1<<TOIE1);            // t1OV interrupt freigeben

Als Hallsensor sollte ein TLE4905 direkt anschließbar sein. R4 ist der 
Pullup für den OC-Ausgang.

Bei einem Reedkontakt würde ich in Reihe zum Kontakt 1k legen und C3 
soweit vergrößeren, dass bei max. Schaltfolge die Signalamplitude an 
AIN0 maximal 1,5V unter- und minimal 3,5V überschreitet. Als 
experimentellen Startwert würde ich mit 10nF beginnen, was grob einer 
Eingangsfrequenz von 10kHz entsprechen würde. Das Tastverhältnis ist 
aber zu berücksichtigen.
Der 1k Widerstand schützt den Reedkontakt vor zu großen Entladeströmen.

Wenn kein Schmutz auftreten kann, kann man auch mit Reflexkopplern 
arbeiten. Ein bißchen Alufolie auf dem Drehteil erzeugt kaum Unwucht.

Maximilian A. schrieb:
> Gibt es noch andere Ports woran das ganze geht?

Genausogut kannst Du ICP1 nehmen.
Dazu mußt Du diese Anweisung entfernen:
  ACSR |= 1<<ACIC;

Eine weitere Schaltung findest Du auch hier:
Beitrag "4-Kanal Drehzahlmessung mit ATmega88"
und noch mehr Beschreibungen auch hier:
http://www.mino-elektronik.de/fmeter/neue_versionen.htm

Das Programm zu portieren sollte kein Problem sein. ICP als Eingang ist 
auch in Ordnung.
Was den Webserver angeht: den kenne ich nicht. Dazu muß man wissen, 
welche Timer, I/O und Interrupts dort verwendet werden und ob dies mit 
der Drehzahlmessung kollidiert.

Für ein Einzelstück würde ich der Drehzahlmessung einen eigenen 
Prozessor spendieren und die Meßwerte per UART an den Webserver 
übertragen. Da stören sich die Programme nicht und man ist auf der 
sicheren Seite.

Hallo Leute.
Ich komme hier wirklich nicht weiter und nach langem Überlegen habe mich 
doch entschlossen kein Internet Forschung mehr in diesem Fall zu 
betreiben.
Vielleicht hilft mir hier jemand der "sich besser auskennt".
Ich versuche die möglichst Übersichtig mein Problem zu erklären :

Ich versuche seit tagen die Messung an ein ATmega8 und mein Display 
anzupassen und habe bis jetzt folgendes geändert:

-TMSK1 in TMSK unbenannt - da an ATmega 8- so steht bei Atmel
-lcd_routines.c mit meiner LCD Konfiguration eingebunden - die sind ok.
- im Code folgendes unbenannt:
--int_lcd in lcd_init von lcd_routnes
--lcd_f_str in lcd_string von lcd_routines.

An der Schaltung hängt ein Lüfter- das Schwarze Tachokabel an PD6 ( 
(AIN0) .Ich bekomme jetzt nur D: und T: auf dem Display angezeigt. Keine 
000 keine ??? - überhaupt kein Wert,
Ich gehe davon aus dass noch was in der LCD Einbindung verändert werden 
muss.
Das Programm lässt sich fehlerfrei und Warnungsfrei kompilieren.

Kann mir da bitte jemand bei der Einbuindung von lcd_routines ein Tipp 
geben ?

>-lcd_routines.c mit meiner LCD Konfiguration eingebunden - die sind ok.
Beweise? Quellcode?

Du hast lcd_zeichen vergessen.
Wird aber alles nicht ändern.
Wenn ich den Code beim überfliegen richtig verstanden habe
erscheinen erst dann zahlen auf dem display wenn die
Messung erfolgreich war (genauer gesagt nach der 2).
Da aber D: und T: bei dir angezeit wird vermute ich mal
das entweder
- Kein Brauchbares signal ankommt
oder
- Die Ansteuerung des Timers beim M8 nicht komatibel zum m88 ist

> An der Schaltung hängt ein Lüfter- das Schwarze Tachokabel

Ich würd eher sagen Gelb....

Wenn "D: " und "T: " angezeigt werden, funktioniert die LCD-Ansteuerung.
Wenn ein Signal anliegt, muß die LED bei jeder fertigen Messung 0,1s 
aufleuchten. Falls das nicht passiert, ist das Signal nicht erkannt 
worden.

Kontrolliere bitte, ob die T1-Interrupts überhaupt arbeiten. Zunächst 
muß der OVF-Interrupt funktionieren: LED in der Routine blinken lassen.
Als Nächstes die LED in der CAPT-Routine blinken lassen.
Wenn beide Interrupts funktionieren, müßte auch die Anzeige der 
Messwerte klappen.

Noch etwas: ist SEI() wirksam, oder ist irgendwo ein CLI() vorhanden, 
was alle Interrupts wieder sperrt?

Jan schrieb:
> An der Schaltung hängt ein Lüfter- das Schwarze Tachokabel an PD6 (
> (AIN0)

Kontrolliere mit einer LED, ob hier überhaupt Impulse vorhanden sind.

m.n. schrieb:
> Vielleicht ist es niemandem aufgefallen und es wird äußerst selten zu
> 'unsauberer' Auswertung führen, aber nachfolgender Programmabschnitt
> sollte vor einem T1OV-Interrupt geschützt werden. 'mess_dauer' kann
> sonst falsch gelesen oder gelöscht werden.
> Die Sperre für TOIE1 habe ich hier ergänzt:
>
> TIMSK1 &= ~(1<<TOIE1);           // t1OV interrupt sperren
>     if(mess_status==MESSEN  && mess_dauer >= MESSZEIT) {
>       mess_status=AUSLESEN;      // Auswertung starten
>       mess_dauer = 0;            // wieder Messzeit abwarten
>     }
> TIMSK1 |= (1<<TOIE1);            // t1OV interrupt freigeben


Wenn ich das richtig verstanden habe muss es dann so wie angehängt 
aussehen.
Gruß Andreas

Oh, ich sag mal nur, dass ich suchen mußte, um Deine Änderung zu finden.

Damit niemand die schlechte Kopie verwendet, hänge ich die letzte 
Version am besten an.

Wozu ? Das HEX file gibts doch auf der Site zum Download.
Mino Elektronik.

Tommy Tomatronic schrieb:
> kann man die hex file in bascom zurückwandeln?

Und wie soll das gehen? Das scheitert schon alleine an den 
Variablennamen.

Tommy Tomatronic schrieb:
> hätte da einige änderungen. :)

Welche wären das denn?

Eine neue Programmversion mit automatischen Abgleich auf ein 
1Hz-Referenzsignal - am besten von einem GPS-Empfänger - ist fertig.

Damit kann man den oben gezeigten Aufbau von Stephan Henning recht 
einfach abgleichen. Eine kurze Beschreibung dazu sowie .c-Quellcode und 
.hex-Datei sind hier zu finden.
http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp3

Stephan Henning schrieb:
> m.n. schrieb:
>> Eine neue Programmversion mit automatischen Abgleich auf ein
>> 1Hz-Referenzsignal - am besten von einem GPS-Empfänger - ist fertig.
>>
>> Damit kann man den oben gezeigten Aufbau von Stephan Henning recht
>> einfach abgleichen. Eine kurze Beschreibung dazu sowie .c-Quellcode und
>> .hex-Datei sind hier zu finden.
>> http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp3
>
> theoretisch schon. Praktisch schwierig.

Ich weiß jetzt nicht, worauf sich das "schwierig" bezieht.
Den 'Fangbereich' für den auto. Abgleich habe ich von +/-100ppm auf 
+/-1000ppm erweitert, obwohl die nun mögliche Toleranz für mich schon 
grenzwertig ist.
Unter Umständen sollte C3 bei einem GPS-Signal unbestückt sein oder R4 
verkleinert werden, falls der 1pps-Impuls nur 1µs lang ist.

Stephan Henning schrieb:
> Bleib ganz ruhig, alles gut.

Na ja, dass die Istfrequenz von Quarzen in manchen Fällen zu stark 
streut, ist mir schon zu Ohren gekommen. Deshalb wollte ich ein bißchen 
mehr Nachbausicherheit einbringen.

Ferner ist mir bei der Anpassung eines Frequenzzähler-Programms auf 
einen Arduino UNO R3, eine Abweicheng des 16MHz Quarzes von >500ppm 
aufgefallen. Das ist schon heftig und wohl die Folge von "Geiz ist ...".

Laurin E. schrieb:
> Es zeigt mit eine deutlich zu hohe Drehzahl an, wenn ich z.B.
> im Sekundentakt den Hallsensor ansteuere.

Welcher Wert wird angezeigt und ist er stabil?

Das hatte ich schon vermutet. Mit der letzten Version wäre das Problem 
nicht entstanden.

m.n. schrieb:
> Eine neue Programmversion mit automatischen Abgleich auf ein
> 1Hz-Referenzsignal - am besten von einem GPS-Empfänger - ist fertig.
>
> Damit kann man den oben gezeigten Aufbau von Stephan Henning recht
> einfach abgleichen. Eine kurze Beschreibung dazu sowie .c-Quellcode und
> .hex-Datei sind hier zu finden.
> http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp3

In der 1. Zeile von main() steht dort:
  CLKPR = 0x80; CLKPR = 0x0;
Damit wird der interne Vorteiler immer auf 1 gestellt.