Mit dem Zeitstempel zum Interrupthandler meinte ich im Prinzip den Inhalt eines Hardwaretimers.
Das Ganze ziehlt darauf hinaus einen Hardware Timer per Api zur Verfügung zu stellen. Den Ablauf könnte ich mir folgender Weise vorstellen:
1. Ereignismessung wird mit einem Aufruf aktiviert. Hierbei wird die Auflösung bzw. der Teiler des Timers zur Taktfrequenz des Bricks bestimmt. Zusätzlich definiert der Aufrug noch ein Ereignis. Z.B. eine steigende oder fallende Flanke eines IO4/16 Pins.
2. Tritt dieses Ereignis nun ein, wird der aktuelle Wert des Timers an die nächste Stelle eines Arrays mit fest definierter Größe angelegt. Vielleicht reicht hier bereits der Platz für 10 Timerwerte aus. Diese Pufferung dient nur dazu evtl. auftretende Verzögerungen in der Übertragung zum PC zu Puffern. D.h. es ist eher als eine Sende Queue anzusehen in dem die ältesten Werte wieder überschrieben werden sobald kein Platz mehr frei ist. Tritt dieser Fall ein, wird in der Answendung die Callbackroutine mit gesetzen Flag (TIMER_BUFFER_OVERRUN) angestoßen. Die signalisiert dem Anwender, dass die Ereignisse zu häufig auftreten. Das System kommt mit der Übertragung nicht nach.
3. Sind Werte im Array vorhanden, werden Sie per Callback in die Anwendung geliefert.
4. Der Anwender deaktiviert den Timer sobald er mit der Messung fertig ist.
Damit erschlägt man meiner Meinung nach eine ganze Reihe an Anwendungsfälle, ist nah an der Interruptverarbeitung der Hardware, garantiert aber eine gleichbleibendes Timing in der Messung.
Für die jenigen, die eine Kopplung an den Hardwaretakt zu technisch ist, könnte man auch Zeitscheiben in natürlichen Größen, sprich glatten Frequenzen anbieten.