Ähem, nettes "State-Machine"-Diagram. Nicht wirklich konsistent aber lassen wir das mal dahingestellt.
Stellen wir uns mal ganz dumm. Was wollen wir messen? Wir wollen die Geschwindigkeit eines Geschosses das den Lauf der Waffe verlassen hat in definierter Entfernung von der Laufmündung messen. Dabei werden folgende Dinge IMMER eintreten:
1. Geschoss verlässt Lauf und begibt sich auf die Reise zur GeschossGeschwindigkeitsMessstelle oder kurz GGM
2. Geschoss durchquert die erste Lichtschranke und löst, hoffentlich, ein Signal aus
3. Geschoss durchquert die zweite Lichtschranke und löst, hoffentlich, ein Signal aus
4. die GGM berechnet ein bisschen und gibt die Werte aus, wie auch immer man das löst und
5. zurück zu 1.
Welche Fehler können auftreten:
1. Geschoss verlässt Lauf und trifft GGM genau zwischen die Augen, keine weiter Aktion erforderlich, GGM abbauen, in einer Tüte verstauen und pfeifend nach Hause gehen
2. Geschoss durchquert erste Lichtschranke löst aber kein Signal aus, keine Aktion erforderlich weil eh keine Messung erfolgen kann
3. Geschoss durchquert erste Lichtschranke löst Signal aus, Messung beginnt scheint aber zwischen den Lichtschranken die Flugrichtung geändert zu haben, tunnelt durch die GGM oder verlässt auf andere Weise die vorgeschriebene Flugbahn, Aktion erforderlich!!!
Die einzige angemessene Reaktion darauf ist es nach angemessener Zeit entweder über einen Watchdog oder auch einfach über den Overflowint des Counters die Messung ergebnislos zu beenden und wieder zum Anfang der Messung zu springen. Um mal das Thema Ausgabe anzusprechen, wenn ich geschossen habe aber keine Messung erfolgen konnte, aus welchem Grund auch immer, braucht ihr da echt eine Senilitätshilfe der Art das euch das Gerät sagt ja, ihr habt geschossen aber ich kann damit nix anfangen? Wenn es soweit ist solltet ihr gar nicht mehr schiessen.
Bei genauerer Betrachtung sieht man das das ein konsequent linearer Ablauf ist. Nix kompliziertes. Latenzen sollten zwar immer gleich sein, besser ausgedrückt, die Latenz der Signalantwort per Lichtschranke sollte so konsistent wie möglich sein sie müssen aber nicht bei beiden Lichtschranken gleich sein. Hauptsache sie sind bekannt. Debugger und auszählen oder, warum habe ich wohl in einem meiner Vorpostings einen Link auf ein Herstellerdokument gepostet wo die Befehle inklusive der Bearbeitungszeiten beschrieben waren, halt in der Tabelle nachgucken und zusammenrechnen.
Den geringsten Bearbeitungsoverhead für eine konsistente Reaktion auf die Signale hätte eine Kombination aus sbis/sbic und relativem Jump nämlich 2-3 Takte weil ja auch noch der Quantisierungsfehler mitspielt. D.h. man hätte eine Gesamtungenauigkeit von +-1Takt wenn man das bei beiden Lichtschrankensignalen machen würde.
Aber das könnte man alles selber wissen wenn man denn mal die wirklich hervorragende Doku von Microchip zum AVR lesen und verstehen würde.
Ich frage mich ja manchmal wie die Leute es geschafft haben ohne Microcontroller und Interrupts auszukommen und trotzdem präzise Messungen hinzulegen nur mit ein paar binär- oder BCD-Countern und ein paar Gattern Logik drum herum.
Also so wie ich das sehe braucht ihr MINDESTENS einen RaspberryPi der 4. Generation mit Counter-Hut damit überhaupt was verlässliches rauskommt.
Ich weiss, ich bin ein Idiot, aber anstatt den Überflieger raushängen zu lassen, eine Wertung zu BASCOM rauszuhauen die ich mir an deiner Stelle echt verkniffen hätte, einen "Hochsprache"-Befehl mies zu machen der in Realität mehr einem Assembler Makro ähnelt als einem "Hochsprache"- Befehl, was man leicht gesehen hätte wenn man denn die Befehlstabelle hätte lesen können und vielleicht mal in einen Debugger guckt, hätte ich mir wirklich mal die Struktur des von mir verlinkten Beispielprogrammes angetan denn da hat jemand gezeigt das er verstanden hat wie so ein AVR tickt und wie man die vorhandene Hardware zu den eigenen Gunsten nutzen kann.
Doch dazu hätte man die Dokus lesen und verstehen müssen...
Ich mach dann mal Urlaub von diesem Selbstbeweihräucherungsthread.