Rechteck-Signal pollen (ohne Timer u. Interrupt)

Bronko Pavel schrieb:
> ich habe einen R8C mit dem ich 3 Rechteck-Signale einlesen und deren
> Frequenz bestimmen will. Timer und IntOnChange Interrupts sind keine
> mehr frei.

Das Ding hat 4 Timer und 4 Interrupts. Wenn Du die alle verbraten hast, 
dann ist was grundsätzlich falsch in Deiner Programmplanung.

Man braucht üblicher Weise nur einen Timer für sämtliche zeitabhängigen 
Tasks.

Und daß man externe Interrupts für alles nimmt, außer für Tasten, sollte 
sich auch langsam herumgesprochen haben.


Peter

Heißt das, du weißt es auch nicht?
Da der Code portabel sein soll, z.B. auf einen kleine PIC (12Fxxx) usw. 
muß ich HW unabhängig bleiben. Es gibt noch weitere Gründe... muß man 
sich hier eigentlich immer rechtfertigen
warum eine Aufgabenstellung so ist wie sie ist?
Zu sagen, das "... grundsätzlich falsch in Deiner Programmplanung" ist 
schon ohne jede Grundlage, schließlich habe ich geschrieben 
"Rechteck-Signal pollen (ohne Timer u. Interrupt)" und nicht "wie messe 
ich Perioden/Freuenzen mit einem uC" (denn das weiß ich)
Nicht persöhnlich nehmen, aber die Lösung des Problems ist mir wircklich 
wichtig

Gruß Bronko

Bronko Pavel schrieb:
> Heißt das, du weißt es auch nicht?

doch der Peter weis schon wovon er redet.

Nimm nur einen Timer als Grundtakt (kleinste benötigte Zeiteinheit).
Alle anderen Timer die Du angeblich benötigst, ergeben sich aus dem 1. 
Timer indem zB. Variablen V1 -V3 decrmentiert werden. Oder eben nur eine 
Variable die du auf verschiedene Werte abfragst.
zB. Ggrundtakt 1ms,  für die Tastatur brauchst Du 10 oder 20 und für 
anderes vielleicht 100ms oder 1 Sek. Dann wird im Timerüberlauf 
reagiert, ein Flag gesetzt und V1 -V3 decrementiert. Zurück in der Main 
das Flag abgefragt und die Zählerstände für V1-Vx entsprechend 
verarbeitet.
Is ja nich sooo schwer.

Und Voila, sind die anderen Hardwaretimer übrig....oh Wunder der 
Technik.

Danke Gebhard!
So etwas in der Art habe ich mir vorgestellt. Ist ein langer Tag heute 
gewesen, das ich nicht drauf gekommen bin...
Somit kann ich bis knapp unter 500Hz meine PWM Signal abtasten 
(Abtastheorem). Der gezählte Wert müßte ja absolut korrekt sein, wenn 
ich lange genug zähle, oder irre ich?
 (Werde wohl 256ms nehmen)

Prellen ist kein Problem.

@Die Anderen: Ihr glaubt es nicht, aber der 1ms ist mein Betriebssystem 
Grundtakt. Ja ich habe ein zeitscheibenbasiertes OS mit sehr vielen 
SW-Timern, einen LIN bus welcher z.B TMR RA für die Synchronisierung 
braucht, usw. Nicht falsch verstehen, aber ich schreibe seit ca. 8 
Jahren Automotive ECU Software...

Weil es schon spät ist und ich hauptsächlich Protokollstacks schreibe, 
aber du hast schon recht, das man das wissen sollte....jetzt rechtferige 
ich mich schon wieder, egal HAuptsache ich habe eine Lösung
Kann jemand noch was zum Fehler sagen.
Ich rechtfertige mich auch wieder :-)

Bronko Pavel schrieb:
> Somit kann ich bis knapp unter 500Hz meine PWM Signal abtasten
> (Abtastheorem). Der gezählte Wert müßte ja absolut korrekt sein, wenn
> ich lange genug zähle, oder irre ich?

Wenn Du unendlich lange wartest, dann ist das Ergebnis absolut korrekt.

>  (Werde wohl 256ms nehmen)

Bei 250ms beträgt Deine Auflösung 4Hz.


> @Die Anderen: Ihr glaubt es nicht, aber der 1ms ist mein Betriebssystem
> Grundtakt. Ja ich habe ein zeitscheibenbasiertes OS mit sehr vielen
> SW-Timern

Das ist noch lange kein Hinderungsgrund, einen Timer höher zu takten und 
Interrupts zu verwenden. Damit würdest Du deutlich schneller und genauer 
messen können.
Ich verstehe nicht, warum man sich das Leben immer künstlich schwer 
machen muß und solche Angst vor Interrupts hat.

Die MC-Entwickler bauen schöne Sachen ein und Du willst sie nicht 
nutzen.
Die AVRs haben z.B. Pin-Change-Interrupts auf vielen Ports. Damit 
könntest Du z.B. 8..24 Tachosignale einlesen, auf 0,01Hz genau und 
trotzdem würde sich die CPU nur langweilen.


Eine Frequenz von 0Hz kann aber keiner messen, Du mußt schon einen 
realen Wert angeben. Dieser legt dann die maximal benötigte Meßdauer 
fest.
Wenn Du genau weißt, daß das Tastverhältnis exakt 50% ist, kann man die 
Meßdauer noch halbieren.


Peter

das ist auch das Prob. vieler MCU Frequenzzähler.
Bis wohin messe ich die Dauer und ab wann zähle ich Pegelwechsel..
Da scheiden sich eben die Geister.

@  Stephan Henning (stephan-)

>Bis wohin messe ich die Dauer und ab wann zähle ich Pegelwechsel..
>Da scheiden sich eben die Geister.

Nöö, da rechnet man einfach mal nach. Und kommt am Ende auf das 
Ergebnis, dass

a) Eine Frequenzmessung schneller und höherauflösender ist, wenn das 
Messignal eine höhere Freqeunz als der Referenztakt hat.
b) Eine Peiodendauermessung schneller und höherauflösender ist, wenn das 
Referenzsignal eine höhere Frequenz als das Messignal hat.

Messtechnik, 4. Semester, lange her ;-)

MfG
Falk

Stephan Henning schrieb:
> das ist auch das Prob. vieler MCU Frequenzzähler.
> Bis wohin messe ich die Dauer und ab wann zähle ich Pegelwechsel..
> Da scheiden sich eben die Geister.

Und wo ist das Problem, mach einfach beides:
Zähle die Perioden für eine bestimmte Meßdauer und dann zähle weiter die 
Zeitbasis bis zur nächsten Flanke des Meßsignals.
Damit hast Du immer eine gleich hohe Auflösung.

Beim AVR geht das z.B. so, daß man T1 als Zeitbasis nimmt und den 
T0-Eingang mit dem ICP an das Meßsignal anschließt.


Peter

Danke für eure Beiträge.
Mit 256ms habe ich den Beobachtungszeitraum gemeint. Dadurch das ich 
alle 1ms einlese, steigende Flanke detektiere, um 1 hoch zähle wenn 0->1 
Übergang ist, sollte ich doch (bei 50% dutyCycle) keine Flanke 
verpassen, solange die Frequenz des Tachosignals unter 500Hz bleibt!?
Da diese Umstände gegeben sind, bin ich doch sehr genau?

Einige weitere Überlegungen falls das noch jemand anderes braucht:
1. Wenn man den DutyCyle gegen einen kleinen Wert laufen lassen würde 
("High Zeit"), dann kann es schon sein, dass man einzelne Flanken nicht 
sieht.

2. Wenn man die Frequenz des Tachosignals gegen 0 laufen läßt, dann 
müßte bis a bisserl mehr wie 2Hz alles korrekt erkennen, da ich 
250ms=>4Hz lang "beobachte" und während dieser Zeit >=2 Flanken sehen 
sollte. (shannon)

Kann das jemand besser beschreiben oder in eine Formel packen?

Man braucht also keine CaptureCompare, Interrupt Eingänge usw. wenn es 
sich um die o.g. Umstände handelt.


Peter D.:
"Das ist noch lange kein Hinderungsgrund, einen Timer höher zu takten 
und
Interrupts zu verwenden. Damit würdest Du deutlich schneller und genauer
messen können.
Ich verstehe nicht, warum man sich das Leben immer künstlich schwer
machen muß und solche Angst vor Interrupts hat."

Leider stimmt das nicht, wir in der Automotive Welt sehen das etwas 
differenzierter. Ich weiß sehr wohl wie man Interrupts einsetzt, nur mir 
ist es lieber bei manchen Sachen zu Pollen, denn das ist deterministisch 
und außerdem muß ich den Fall nicht abfangen wenn der Interrupt mich 
zuscheißt, nur weil an der HW was nicht stimmt.

1ms ist der kleinste Takt, damit ich keinen Zeitscheibenüberlauf bekomme 
(incl. Reserve) und für diesen Fall locker ausreichend.

Ich könnte dir noch einige Beispiele nennen, warum wir "defensive 
Programmierung" machen.

Wenn jetzt noch jemand die Muse hat das in der oberen Hälfte zu 
bestätigen bzw. zu beweisen, wäre dies (für mich) ein erfolgreicher 
Thread

Danke+Gruß
Bronko

Es ist schon wieder spät... aber zu 1:
Eigentlich ist nur die "High Zeit" relevant, während dieser Zeit muß ich 
min. 2 mal "High" einlesen haben, außer die "Low Zeit" ist kürzer als 
die "High Zeit", oder?

Bronko Pavel schrieb:
> Danke für eure Beiträge.
> Mit 256ms habe ich den Beobachtungszeitraum gemeint. Dadurch das ich
> alle 1ms einlese, steigende Flanke detektiere, um 1 hoch zähle wenn 0->1
> Übergang ist, sollte ich doch (bei 50% dutyCycle) keine Flanke
> verpassen, solange die Frequenz des Tachosignals unter 500Hz bleibt!?
> Da diese Umstände gegeben sind, bin ich doch sehr genau?

Ich hätte jetzt nicht gedacht, daß ein langjähriger Programmierer so auf 
Kriegsfuß mit der Mathematik steht.

Erzähl dochmal, wir genau ist denn "sehr genau" für Dich?
Welche untere Grenzfrequenz und welche Genauigkeit willst Du konkret?
Reichen Dir 4Hz Genauigkeit, zähle einfach die Flanken innerhalb der 
256ms und fertig.

Je größer die Anforderungen, umso mehr Mathematik muß betrieben werden.

Vom Prinzip her begrenzt die Quantelung auf 256 Schritte Deine maximale 
Genauigkeit, d.h. 1/256 = 0,4%, besser gehts nicht.

Dazu mußt Du dann aber nicht in einem festen Zeitfenster messen, sondern 
auch auf die Flanke des Eingangssignals warten.
D.h. Dein Meßfenster kann 256, 255, 254, ... ms groß sein.
Und dann einfach ausrechnen:

f_x = f_ref * n / m

f_ref = 1kHz
n = Perioden des Signals
m = Anzahl der 1ms Takte

Das Problem dabei ist, daß das Warten auf die Flanke bei kleinen 
Frequenzen das Meßfenster deutlich verlängern kann, da ist dann ne 
Fallunterscheidung nötig.


Peter