www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Rechteck-Signal pollen (ohne Timer u. Interrupt)


Autor: Bronko Pavel (bronko99)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bronko Pavel (bronko99)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: geb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Stephan Henning (stephan-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bronko Pavel (bronko99)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nicht falsch verstehen, aber ich schreibe seit ca. 8 Jahren Automotive ECU 
>Software...
Und warum stellst du dann eine solche Anfängerfrage?

Autor: Bronko Pavel (bronko99)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: geb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan Henning (stephan-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: geb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Falk

Ziemlich blöd, wenn man das Messsignal nicht kennt, oder es in weitem 
Bereich die Frequenz ändert. Rechne mal schnell nach!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bronko Pavel (bronko99)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bronko Pavel (bronko99)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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.