Hallo, ich habe einen R8C mit dem ich 3 Rechteck-Signale einlesen und deren Frequenz bestimmen will. Timer und IntOnChange Interrupts sind keine mehr frei. Dabei ist das DutyCycle immer 50% und die Frequenz ist 0-260Hz, ich bekomme somit 130 5V Pulse. Wenn ich jetzt jede Millisekunde alle 3 Signale "abtaste" habe ich sozusagen 1kHz Abtastfrequenz, was laut Theorie ausreichen sollte. Bloß leider habe ich keinen Schimmer wie ich möglichst genau die Anzahl der Pulse/s auswerten/ausrechnen kann? Das ganze ist für das Einlesen von Tachosignalen gedacht. Danke+Gruß Bronko
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
Sollte eigentlich einfach sein. Nimm 4 Zähler (3 für die Signale, einer für das 1s Fenster) und polle mit 1ms die Leitungen. Immer wenn das Signal z.b. von 0 auf 1 wechselt,zähle den entsprechenden Signalzähler hoch. Nach 1s hast du dann die jeweiligen Impulse/s. Voraussetzung: Signale prellen nicht. Grüße Gebhard
>Da der Code portabel sein soll, z.B. auf einen kleine PIC (12Fxxx) usw. >muß ich HW unabhängig bleiben. Ich schreibe gerade an eine TCP/IP-Stack für einen ATTiny13, da es sowas ja auch für einen ATMega32 gibt. Um es ohne Ironie zu sagen: Irgendwo sind Grenzen. Wenn du jede Millisekunde einen Wert einlesen willst, brauchst du schon wieder eine feste Zeitbasis. Beim Pollen ohne die, braucht dir nur ein Interrupt dazwischenfunken, und deine Messung ist im Eimer.
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...
>Nicht falsch verstehen, aber ich schreibe seit ca. 8 Jahren Automotive ECU >Software... Und warum stellst du dann eine solche Anfängerfrage?
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 Fehler-Problem fängt bei recht niedrigen Frequenzen an. Da kann man entweder auf Perioden-Dauer Messung gehen oder das Beobachtungsfenster länger machen. 1s= 1Hz Auflösung, 2s= 0,5Hz Auflösung. Letztendlich bestimmt die Applikation was sinnvoller ist. Grüße
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
@ Falk Ziemlich blöd, wenn man das Messsignal nicht kennt, oder es in weitem Bereich die Frequenz ändert. Rechne mal schnell nach!
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.