C-Code für Windmesser

[Peter(TOO)]

Hallo,
[QUOTE=Besserwessi;596939]Damit der der Compiler den zugriff auf Variablen nicht wegoptimieren darf, kann man bei der Variablendeklaration ein volatile davor setzen. Als etwa
volatile long Wind ;QUOTE]

Ein Beispiel:

  while (Wind)
    {
       // mach was
    }

Ein optimierender Compiler findet, dass die Schleife viel schneller ist, wenn Wind nur einmal in ein Register geladen wird und dann vergleicht man immer das Register ...

Wenn Wind jetzt aber ein Port ist oder von einer ISR verändert wird, geht das daneben und die Schleife wird nie beendet!

Mit volatile wird der Compiler gezwungen, bei jeder Verwendung von Wind auch den Code für einen Zugriff auf diese Speicherstelle zu erzeugen.

MfG Peter(TOO)

- - - Aktualisiert - - -

Hallo Daniel

Das hardware-technische Entprellen habe ich bereits mit einem Schmitt-Trigger mittels OP realisiert. Hat jedoch leider keine Verbesserung gebracht...

Ein Schmitt-Trigger kann nicht entprellen, der macht aus dem Rauschpegel nur eine schöne Rechteckspannung

Ein guter mechanischer Schnapp-Kontakt verhält sich beim Schliessen mehr wie ein Ball. Der hüpft auf seinem Gegenkontakt eine weile rum. Bei guten Kontakten dauert die Hüpfzeit so um die 2-10ms. Beim Öffnen sieht es meist etwas besser aus, aber auch da prellt es.
Schlimmer sind Schiebeschalter, bei welchen die Kontakte aufeinander gleiten. Durch die Unebenheiten der der Kontakte tritt dabei prellen währenden des ganzen Verschiebevorgangs auf.

Entprellen ist also ein zeitliches Problem.
Rein per Hardware entlädt man dazu einen Kondensator und zwar so, dass dieser beim ersten Kontaktschluss entladen wird. Die Zeitkonstante muss dann so gewählt werden, dass sich der Kondensator nicht wieder auf den anderen Logikpegel aufladen kann, bevor der nächste Prell-Impuls auftritt.

Nun bekommt man ein neues Problem:
Logik-Eingänge haben zwischen den definierten Pegelbereichen einen undefinierten Bereich. Hier kann es sogar vorkommen, dass bei bestimmten Pegeln der Eingang schwingt.

Hier hilft dann der Schmitt-Trigger, indem er dafür sorgt, dass immer definierte Pegel am Logik-Eingang anliegen.

MfG Peter(TOO)

[daniel031287]

Guten Morgen,

ich habe einige Variablen nun als volatile deklariert. Zustätzlich habe ich mich noch schlau gelesen... wieder was dazu gelernt, danke für den Tipp

Ich hatte noch die Idee, statt einen Schmitt-Trigger einen schnellen Komparator einzusetzen... nur ob das dann wirklich hilft, ist fraglich.

Der Nachteil beim Software-Entprellen ist doch aber der, dass ich Zeit verstreichen lasse, in der schon der nächste Impuls kommen kann? Wenn ich das Programm nun dort "Zwangsanhalte", laufe ich Gefahr, Impulse bei sehr viel Wind nicht mitzubekommen.
Oder sehe ich das nun falsch?

Viele Grüße und ein schönes Wochenende,
Daniel

[Besserwessi]

Die Zeit die der Schalter mechanisch Prellen kann, muss man so oder so Ausklammern. Ob man das analog oder digital macht,macht da keinen Unterschied. Die Softwarelösung ist da eher noch exakter einstellbar. Normal sollte die Zeit vom Prellen auch so kurz sein, das so kurze Pulse auch bei Sturm kaum vorkommen können. Die Vielleicht 2 ms die ein Reed Kontakt prellt, würden immer noch 250 Hz Signal erlauben, was wohl theoretisch 100 m/s entspräche. Da hat man dann andere Probleme, wenn es mehr wird. Zu sehr übertreiben darf an es mit der Zeit zum entprellen aber halt auch nicht.

Bei der analogen Lösung ist ein Schmidt Trigger schon passend - ein Komparator hilft da nicht wirklich weiter. Die Eingänge beim AVR sind bereits Schmidt-trigger Eingänge - im Prinzip würden da passend bemessene Widerstände / Kondensatoren schon reichen. Man darf auch beide Methoden zum Entprellen kombinieren, also trotz analogem Teil noch mal in Software unrealistisch kurze Zeiten zu verwerfen.

[daniel031287]

Okay, dann werde ich mich da die Tage mal "ranwagen" und software-technisch entprellen... werde da aber erst Mitte nächster Woche zu kommen, da ich ein paar Tage im Center Parc bin... also nicht wundern, dass bis dahin nichts von mir kommt.

Sobald ich das Entprellen software-technisch realisiert habe, werde ich den Code hier mal hochladen und eure Meinung abwarten...

Schönes We,

Daniel

[daniel031287]

Moin zusammen,

ich habe mir nun ein paar Gedanken gemacht und mich ein wenig eingelesen: Das Software-Entrprellen (scheint) ja am sinnvollsten zu sein, wenn man es über Timer realisiert, um unnötige Warteschleifen zu verhindern und das Programm kurze Zeit zu "blocken".
Jedoch habe ich bereits 2 Timer in Verwendung: Sprich, wenn ich nun so programmieren würde, dass der Reed-Kontakt einen externen Interrupt auslöst, würde meine Int-Routine ausgeführt.
Angenommen, ich würde dann eine Variable hochzählen. Meinetwegen bis 5 Zeiteinheiten. Wenn diese 5 Zeiteinheiten erreicht sind, soll nochmal geschaut werden, ob das Signal (in meinem Fall) immer noch "high" ist. Wenn das der Fall ist, soll die Geschwindigkeit errechnet werden.
ABER: Um diese Zeiteinheiten hochzuzählen, würde die Software aus der Int-Routine rausgehen, um zum Beispiel die Timer0-Overflow-Routine aufrufen, um die Variable hochzuzählen. Wenn dies erledigt ist, springt er wieder in die Int-Routine vom Reed-Kontakt zurück. Oder wird dieser Zähler hardwaremäßig hochgezählt, ohne dass die Int-Routine dafür verlassen werden muss?

ISR(INT0_vect){
volatile unsigned long int us = 0;
volatile unsigned long int millisekunde = 0;

//Entprellzeit
_delay_ms(10);

//Interrupt an INT0 -> PD2
//alter Wert 32
us = (volatile unsigned long int) TCNT1 * 32;
TCNT1 = 0;

millisekunde = us / 1000;

// v = s/t
// Durchmesser Schale Mitte = 92mm
//Umfang = 92mm * pi = 2890mm
//laut Datenblatt Windweg = 0,4m
//Wert 1445

wind = 2890 / millisekunde; //*10 für Kommastelle
GIFR |= (1 << INTF0);
}

Eine einfache Wartezeit von nun beispielsweise 10ms wäre doch auch eine Entprellung? 10ms sind aber sehr wahrscheinlich zu hoch gegriffen...

Ich habe gerad irgendwie einen "Knoten im Kopf"...
Hoffentlich ist das nun auch rübergekommen, wo gerad mein Problem ist.

Gruß

[Besserwessi]

Die ISR von der Flanke muss man schon zu ende kommen lassen, denn sonst geht es auch mit dem Hauptprogramm nicht weiter. Was man machen kann, ist etwa in der ISR vom Int0 erst einmal Int0 zu deaktivieren und dann beim Timer das Compare register so zu programmieren, dass nach etwa 5 ms ein Timer interrupts kommt, denn man dann auch Einschalter. Die ISR für den Start ist dann schon fertig. In der Timer ISR deaktiviert man dann den Timer Interrupt wieder und erlaubt dafür wieder den Int0. Die Flanke auf die er reagiert muss man dabei ggf. je nach Zustand des Eingangs noch anpassen. Das Ende der Messung macht dann wieder die ISR zu Int0. Dabei kann dann ggf. auch gleich die Nächste Messung gestartet werden.

Ein Problem bekommt man ggf. noch bei sehr niedriger Geschwindigkeit: da kann der eine Pulse schon länger als 5 ms sein, und man hat es schwer das Ende des Pulses (mit ggf. Prellen als Störung) vom Anfang des nächsten Pulse zu unterscheiden.

[Peter(TOO)]

Hallo,

Man kann eine ISR aufsetzen, welche z.B. alle 1ms den Eingang abfrägt.

Der aktuelle Wert wird dann in ein Schieberegister eingeschoben.

Wenn man 8 Bit verwendet (8ms) und das Schieberegister den Wert 0xFF hat, stand am Eingang für mindestens 8ms eine 1 an.

Bei 0xFF wird dann der Impuls ausgewertet und ein Flag gesetzt. Ist das Flag schon gesetzt wird nicht ausgewertet.
Das Flag setzt man bei != 0xFF zurück.


Bei Tasten habe ich meistens einfach nur alle 20ms den Eingang abgefragt und dann nur den aktuellen mit dem vorigen Zustand verglichen.
Wenn man die Tasten dann noch in ein Bit-Array packt, kann man alle Tasten gleichzeitig entprellen.

MfG Peter(TOO)

[Klebwax]

Der Nachteil beim Software-Entprellen ist doch aber der, dass ich Zeit verstreichen lasse, in der schon der nächste Impuls kommen kann? Wenn ich das Programm nun dort "Zwangsanhalte", laufe ich Gefahr, Impulse bei sehr viel Wind nicht mitzubekommen.

Das ist prizipiell so. Wenn die "Prellpulse" ähnliche Zeiten haben, wie das Nutzsignal, ist der Sensor ungeeignet. Ob man die Auswertung in Software oder in Hardware

Rein per Hardware entlädt man dazu einen Kondensator und zwar so, dass dieser beim ersten Kontaktschluss entladen wird. Die Zeitkonstante muss dann so gewählt werden, dass sich der Kondensator nicht wieder auf den anderen Logikpegel aufladen kann, bevor der nächste Prell-Impuls auftritt.

macht, ist dabei egal. Der Vorteil der Software ist auf jeden Fall, das man Zeitkonstanten ohne Lötkolben ändern kann.

MfG Klebwax