C Schnellster Timer in C?

Kazuya91

Commander
Registriert
Nov. 2007
Beiträge
2.333
Hallo liebes Forum,

Ich brauche die schnellste Methode in C um eine Zeit zu messen.

Hintergrund: Ich empfange ein Manchester-Signal im IEEE-Format auf einem Raspberry-Pi welches ich decodieren muss. Es ist eine Aufgabe für die Uni.

Wir dürfen nur GPIO-Polling (ständige Abfragen des Wertes) benutzen (keine Interrupts). Die Pulsbreite ist variabel. Das erste Bit ist immer eine "0".

Der Ruhepegel ist "0". Alle 10 Sekunden kommt ein Signal (eine Hintereinanderreihung von Pulsen).

Dafür brauche ich einen sehr schnellen Timer, so eine Art Stoppuhr, die misst, wie lange das Signal auf "1" oder "0" bleibt. Das könnte im Millisekunden oder Nanosekunden-Bereich sein.

Was eignet sich da am besten?

Danke schonmal :).
 
Was soll das? Ich hab doch gar nicht nach der Lösung für die Aufgabe gefragt? Ich habe meinen eigenen Lösungsweg. Ich frage nur nach dem schnellsten Timer und nicht nach einer Musterlösung. Was hätte es für einen Unterschied gemacht wenn ich die Angabe "Es ist eine Aufgabe für die Uni" weggelassen hätte?
 
@jurrasstoil Es wird doch gar nicht nach der kompletten Lösung für die Aufagbe gefragt, sondern eine einzelne konkrete Frage gestellt. Das ist wenn ich deinen verlinkten Post richtig verstehe, völlig in Ordnung.
 
und wenn man das Thema Uni nicht nennt sondern das Beispiel anders beschreibt bekommt man eh eine Lösung...
 
Die Herangehensweise ist Käse. Einfach nur massiv und schnell Pins Abfragen bringt nichts. Die Hardware aller PIs hat mehrere limitierende Faktoren, die ein sicheres Auslesen auf eine gewisse maximale Frequenz beschränkt und nach Abtasttheorem damit auch die Frequenz an Signalwechseln die man so auswerten kann. Häufigeres Abfragen es Pins bringt nichts, ein über präziser Timer auch nicht (Nanosekunden... da hat hat entweder der Lehrende verpennt den Studenten einige grundlegende Sachen beizubringen oder der Lernende nicht aufgepasst). Also setzt dich in die Spur, finde raus wie präzise du maximal sein musst / kannst!
 
Zuletzt bearbeitet:
Danke für die Hilfe. Ich lese mich da mal ein.

@Piktogramm
Ja dem Prof. ist das auch bewusst, in der nächsten Aufgabenstellung sollen dann Interrupts verwendet werden. Er weiß, dass es dort einen limitierenden Faktor gibt, das sollen die Studenten dann ja auch sehen um dann beide Methoden miteinander zu vergleichen und eine Erkenntnis ziehen.
 
Das hat mir Interrupts UND Hardwaretimern nichts zu tun. Nochmal, es gibt schlicht "harte" Grenzen der Hardware, die die zeitliche Auflösung von GPIO write/read begrenzen die nicht zu überwinden sind. Du musst, oder solltest in Software keine höhere Präzision vorsehen, als die Hardware hergibt.

Edit: Mit Präzision meine ich hier die mögliche/sinvolle Abtastfrequenz, ohne Betrachtung von Jitter
 
Zuletzt bearbeitet:
Das man das eigentlich nicht mit Polling bzw generell nicht in Software lösen sollte, wurde ja schon oft genug gesagt aber um jetzt doch mal zum Thema zu kommen:
Sofern die Frequenz des Codes niedrig genug ist für Softwarepolling (was sie sein wird, sonst wäre die Aufgabe ja unmöglich zu lösen) kann man das sehr wohl hinkriegen.
Du könntest mittels usleep(1000) einmal pro Millisekunde den aktuellen Wert abfragen. Natürlich wird soetwas in Software ungenau und jittern aber wie gesagt - ist das Signal langsam genug lässt sich das Ursprungs-Signal rekonstruieren.
zB könnte jeder 0 und jeder 1 Pegel für 100ms anstehen. Dann ist es für Software gar kein Problem fest zu stellen, was für 0'en und 1'en angekommen sind. Konstante Werte von 0 (oder 1) die ~100 mal detektiert wurden bedeuten dann eben eine 0 (oder 1). Werte die eher ~200 mal gesehen wurden sind dann halt 2x 0 oder 2x 1.

Dh erstmal musst du überhaupt den Beginn der Sequenz zu erkennen: Mehr als 2 Sekunden konstante Werte und danach eine Änderung.
Anschließen dann in einem vorher allokierten Speicher pro Abfrage jeweils ein bit setzen, wenn der aktuelle Abfragemoment TRUE oder FALSE war. (bool array tuts auch erstmal)
Anschließend lässt du über diese riesen Datenmenge eine Analyse laufen die eben erkennt, dass
97xTRUE, 189xFALSE, 104xTRUE, 99xFALSE 1,0,0,1,0 entspricht.
 
Zuletzt bearbeitet:
usleep und Nyquist-Shannon-Abtasttheorem sind vermutlich nützliche Stichwörter.
 
Digitale Signale haben aufgrund der Signalflanken meist relativ hohe Frequenzanteile. Da es aber nicht darum geht die exakte Signalform wiederzugeben kann die Abtastfrequenz - bezogen auf die Signalbandbreite - deutlich unter der Nyquistrate liegen, ohne dass man sich z.B. um Aliasing Gedanken machen müsste.

Bezogen auf die Datenrate ist die Nyquistrate aber wiederum zu gering um ein Manchester Signal robust ins Software zu decodieren (der Pi ist halt nur bedingt echtzeitfähig).

Wenn ich außerdem die Frage richtig verstanden habe, dann weiß man erst mal aufgrund der wechselnden Pulsbreite noch nicht mal, wo die Nyquistrate liegen würde. Ne simple Schleife, die - so wie Dr. Wiesel es beschrieben hat - so schnell es geht den gpio-pin pollt und die Zeit zwischen den Pegelwechseln z.B. mittels clock_gettime ermittelt scheint mir da die einfachste, robusteste und wohl auch die vom Prof. gewünschte Methode zu sein.
 
Zuletzt bearbeitet:
Zurück
Oben