Projekt Simple Chrony

Ä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.

Letzte Fragen noch:

Die Error-States ERROR 1 und ERROR 2 -- werden die für eine feste Zeit gehalten und dann erst zu idle zurückgekehrt? Eine Zeit, in der die Interrupts unterdrückt sind? Oder wird die Meldung nur eingeblendet und dann mit eingeblendeter Meldund ins idle zurückgekehrt?

Warum gibt es keinen eigenen State für eine erfolgreiche Messung und Anzeige der Geschwindigkeit?

Gibt es einen Mechanismus, der dafür sorgt, dass die Meldungen für eine bestimmte Mindestzeit angezeigt werden?

@WhiteSAndS:

Zitat von WhiteSAndS

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.

Ja, auf jeden Fall braucht man gescheite Fehlermeldungen, um überhaupt nachvollziehen zu können, was schiefgegangen sein könnte! Meist wird das, was der Chip wahrnimmt von dem abweichen, was man selbst wahrnimmt. Dafür kann es massig Gründe geben."Senilitätshilfe?"

Was du das über das Jagen nach Einzeltaktcounts schreibst, finde ich schon richtig. Interrupts sind eine aufwändige Operation, kann schon sein, dass die nicht immer die gleicher Anzahl Takte braucht (bin nicht sicher). Wenn nicht und wenn man die vermeiden könnte, könnte das der Genauigkeit natürlich schon helfen. Bei v = 500 m/s, 10 cm Meßstrecke (oder weniger?) und 8 MHz Taktfrequenz entspricht der ganze Durchflug gerade mal 1000 Takten, da ist es schon sinnvoll, dass die Zeitmessung auf möglichst wenige Takte genau stimmt.

OK. Bei näherem Nachdenken finde ich es auch logisch, dass das Auslösen des Interrupts selbst immer gleich viele Taktzyklen braucht, es werden ja jeweils dieselben internen Operationen ausgeführt. Und nur darauf, dass das immer gleich lange dauert, kommt es ja an.

Unterschiede könnten auftreten, je nachdem bei welchen Befehl der Prozessor gerade ist, wenn der Interrupt ausgelöst wird, aber das ist dann sicher immer noch konsistenter als in der Hauptschleife zu pollen.

Zitat von WhiteSAndS

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.

Was genau war denn da jetzt dein Vorschlag? So wie ich es verstehe, willst du keine Interrupts benutzen, oder? Wie würde das Ereignis Lichtschranke in deinem Code detektiert? Durch Pollen in der Hauptschleife?

loop:
      sbis PIND,0
      rjmp weiter
      rjmp loop

Das soll genauer sein sein als ein Interrupt? Wie das denn?

Ich bin eine absolute Eletronik-Fünf und stelle mal jetzt die Frage als Anwender, weil mich das hier interessiert (evtl. ist die Antwort hier schon im Thread und ich verstehe sie nicht)

Es müßte doch einen Error geben, wenn ich schräg durch das Ding schiesse (innerhalb einer gewissen Toleranz). Da wär es schön, wenn man genau das auch anzeigt, anstatt nur Error (Das ist immer ein Rätsel, warum nun Error) Aber wie das bei "Hochschuss" funktionieren soll, wär mir nicht klar. Da bräuchte man ja noch seitliche Lichtschranken

Zitat von Old_Surehand

@WhiteSAndS:

Ja, auf jeden Fall braucht man gescheite Fehlermeldungen, um überhaupt nachvollziehen zu können, was schiefgegangen sein könnte! Meist wird das, was der Chip wahrnimmt von dem abweichen, was man selbst wahrnimmt. Dafür kann es massig Gründe geben."Senilitätshilfe?"
Was du das über das Jagen nach Einzeltaktcounts schreibst, finde ich schon richtig. Interrupts sind eine aufwändige Operation, kann schon sein, dass die nicht immer die gleicher Anzahl Takte braucht (bin nicht sicher). Wenn nicht und wenn man die vermeiden könnte, könnte das der Genauigkeit natürlich schon helfen. Bei v = 500 m/s, 10 cm Meßstrecke (oder weniger?) und 8 MHz Taktfrequenz entspricht der ganze Durchflug gerade mal 1000 Takten, da ist es schon sinnvoll, dass die Zeitmessung auf möglichst wenige Takte genau stimmt.

Ok, sagen wir mal du bekommst die Fehlermeldung das Lichtschranke 1 ein Signal gegeben hat, Lichtschranke 2 aber nicht.
Was genau möchtest du mit dieser Information in einem fertigen Gerät anfangen?
Richtig, nichts!
Während der Debugphase KANN es nützlich sein. Wenn die Optik deiner Hardware aber so unzuverlässig ist das das eher Glück als Können ist dann solltest du eh wieder zurück an den Arbeitstisch und ein paar grundlegende Probleme klären.
Das sollte man eh bevor man ein derartiges Projekt anfängt aber dazu später.
Es ist keine Jagd nach Einzeltakten sondern nach Konsistenz. Die Reaktion soll so gut es geht immer die gleiche Reaktionszeit haben. Wie lange genau ist gar nicht sooo wichtig nur eben immer gleich lang.
Man kann das ganze auch mit Interrupts lösen aber eben nicht mit konkurrierenden Interrupts. Wenn du nicht sicher stellen kannst das ein Interrupt während eines zeitkritischen Interruptes ausgelöst wird hast du verloren und zwar massiv an Genauigkeit oder Verlässlichkeit. Wie du willst.
Aber wie gesagt man kann. Bloss verkommt dein schönes Interruptsystem zum blanken Aufruf von Subroutinen wenn du das sauber programmierst und dann kannst du es auch ohne lösen.
Wie ich schon schrieb, wie haben es eigentlich die Altvorderen geschafft genau zu messen ohne CPU und Interrupts nur mit ein bisschen Logik und ein paar Countern?
Gab es dazu nicht einen schlauen Spruch? "Wer die Geschichte ignoriert ist dazu verdammt sie zu wiederholen"
Man muss sich einfach mal angucken aus welcher Zeit das Design der Counter in den AVRs stammt. Das war noch eine Folge der Übertragung digitaler Daten über PWM, PPM bzw dPPM und die Leute die den Befehlssatz konstruiert haben WUSSTEN was sie taten.
Aber mal zurück zu diesem "Projekt".
Was glaubt ihr eigentlich wird das am Ende kosten? Nehmen wir mal an die Hardware, also Platine mit Controller und Lichtschrankenelektronik plus Anzeige, liegt so bei 15-20€. Da habt ihr keine Optik, keine Stromversorgung, geschweige denn ein funktionierendes Gehäuse dazu. Ihr werdet noch unzählige Arbeitsstunden versenken, elendig viel Material verbrauchen bis etwas halbwegs brauchbares rauskommt was hoffentlich zuverlässig ab und zu brauchbare Werte anzeigt. Ohne anständige Optik, und hier reden wir eher von mehr als 30€, ist das dann mehr oder weniger nur für Preller oder PCP einsetzbar. Jedenfalls wenn IR-Lichtschranke und wenn nicht verhindert werden kann das der Schmauch von Feuerwaffen die Optik beeinträchtigt. CO2 geht nur mit genügend Abstand wegen des Absorbtionsverhaltens.
Dann braucht ihr ein Gehäuse. Gibt es ja nicht umsonst und MUSS zuverlässig funktionieren sonst muss man ständig neu bauen.
Lange Rede.... wenn ich nur so ein Ding anwenden wollen würde hätte ich ja als erstes mal in das Pflichtenheft dieses Projektes geschaut, ups, gibt keines, wurde auch nicht diskutiert, nur hingeknallt, ob es denn meine Anforderungen auf welche Weise erfüllen wird. Dann hätte ich mir überlegt ob es nicht sinnvoller ist, finanziell oder zeitökonomisch, eines zu kaufen und, so ich es denn kann, diese meinen Ansprüchen entsprechend zu verbessern. Wobei ich mich da schon frage in welche Richtung das gehen soll denn wie schon geschrieben, die meisten haben ein Interface aus dem man eine Menge holen kann. Wenn ich eine eigene Firmware möchte, gut, aber dann hat man eine funktionierende Optik auf der man aufbauen kann.
Was genau habt ihr? Snakeoil, Unobtanium...ein Versprechen in eine goldene Zukunft.
Selbst wenn ich das aufbaue, so als Fingerübung, würde ich eine preiswerte fertige Platine mit MEGA328, einen preiswerten serial/USB Wandler oder preiswerten serial/Bluetooth Wandler und wäre dann mit vielleicht 12-16€ dabei. Noch etwas Lichtschrankenmagie und fertig wäre der Versuchsaufbau. Doch wofür?
Auf der anderen Seite, wer Spass am basteln hat, nicht unbedingt darauf angewiesen ist und wo Zeit und Geld eher eine untergeordnete Rolle spielen...warum nicht. Dümmer wird man nicht. Und vielleicht lernt ja der eine oder andere sich Informationen an der Stelle zu holen wo deren Ursprung ist denn wie heisst es so schön: "Wissen ist Macht!". Ooh, Tag der Retrosprüche

Zitat von Old_Surehand

Code

loop:
      sbis PIND,0
      rjmp weiter
      rjmp loop

Das soll genauer sein sein als ein Interrupt? Wie das denn?

Falsch! Nochmal die Befehlsbeschreibung lesen. Alternativ Debugger benutzen und ansehen.

Interrupt, was genau passiert eigentlich bei einem Interrupt und was muss ich tun damit die Reaktionszeit auf eine Interruptauslösung so gut wie möglich gleich bleibt?
Was passiert wenn ich mehrere Interrupts zulasse und während der Ausführung einer Interruptserviceroutine ein weiterer, möglicherweise zeitkritischer, Interrupt ausgelöst wird?
Was unterscheidet einen bedingten Sprungbefehl wie sbis/sbic von der Auslösung einer ISR wenn ich gezwungen bin immer nur einen einzigen Interrupt gleichzeitig zuzulassen?
Oh man, wieso mache ich mir eigentlich euren Kopf?!?

Zitat von Olja

Ich bin eine absolute Eletronik-Fünf und stelle mal jetzt die Frage als Anwender, weil mich das hier interessiert (evtl. ist die Antwort hier schon im Thread und ich verstehe sie nicht)

Es müßte doch einen Error geben, wenn ich schräg durch das Ding schiesse (innerhalb einer gewissen Toleranz). Da wär es schön, wenn man genau das auch anzeigt, anstatt nur Error (Das ist immer ein Rätsel, warum nun Error) Aber wie das bei "Hochschuss" funktionieren soll, wär mir nicht klar. Da bräuchte man ja noch seitliche Lichtschranken

Deswegen arbeiten Profilösungen mit optischen Gittern weil sie dann auch gleich die Fehler durch die Längenänderung kompensieren können.
Das ist ja meine Argumentation, was nutzt mir eine Fehlermeldung die mir nicht hilft ausser das ich jetzt weiss es kommt kein neuer Wert und selbst die GGM hat das bemerkt. Vielleicht ist sie ja klüger als ich...
Irgendwie kommt mir die ganze Diskussion windowsdomestiziert vor.Wollen sie Windows wirklich beenden? Ganz ganz wirklich? Aber es ist doch sooooo toll...

@WhiteSAndS: Als interessierter Mitleser dieses Threads würde ich gerne darauf hinweisen, dass ich deinen Ton als sehr aggressiv und beleidigend empfinde. Wäre es möglich, so sachlich-nüchtern zu schreiben, wie es @Feinmechaniker angesichts seiner Bemühungen verdient?

Zitat von WhiteSAndS

Falsch! Nochmal die Befehlsbeschreibung lesen. Alternativ Debugger benutzen und ansehen.
Interrupt, was genau passiert eigentlich bei einem Interrupt und was muss ich tun damit die Reaktionszeit auf eine Interruptauslösung so gut wie möglich gleich bleibt?
Was passiert wenn ich mehrere Interrupts zulasse und während der Ausführung einer Interruptserviceroutine ein weiterer, möglicherweise zeitkritischer, Interrupt ausgelöst wird?
Was unterscheidet einen bedingten Sprungbefehl wie sbis/sbic von der Auslösung einer ISR wenn ich gezwungen bin immer nur einen einzigen Interrupt gleichzeitig zuzulassen?
Oh man, wieso mache ich mir eigentlich euren Kopf?!?

Oh man, warum antworte ich auch noch auf deinen arroganten Ton? Du hast dich doch hier in die Diskussion eingeschaltet, oder nicht?

Interrupt, was genau passiert eigentlich bei einem Interrupt und was muss ich tun damit die Reaktionszeit auf eine Interruptauslösung so gut wie möglich gleich bleibt?

https://www.mikrocontroller.net/topic/299270

Wenn ich davon ausgehe, dass der Interrupt in einer Idle-Schleife ausgelöst wird, die sonst keine Aufgaben hat, kriege ich eine Reaktionszeit zwischen 4 und 8 Takten, je nachdem, was der Prozessor gerade macht.. Deine Schleife dauert 5 oder 6 Takte, d.h. der Fehler ist etwa gleich.

Was passiert wenn ich mehrere Interrupts zulasse und während der Ausführung einer Interruptserviceroutine ein weiterer, möglicherweise zeitkritischer, Interrupt ausgelöst wird?

Normalerweise deaktiviert man am Anfang der ISR alle Interrupts und lässt sie am Ende wieder zu.

Was unterscheidet einen bedingten Sprungbefehl wie sbis/sbic von der Auslösung einer ISR wenn ich gezwungen bin immer nur einen einzigen Interrupt gleichzeitig zuzulassen?

Ich bin nicht gezwungen.

EDIT: hat sich durch Feinmechanikers Antwort eh erledigt, wenn das so funktioniert.

Zitat von Feinmechaniker

Der Trick liegt darin, nicht den Timer1 selbst auszulesen, sondern das Timer1-Capture Register (siehe ISR2 meiner Beschreibung). Dieses Register sichert den Zählerstand von Timer1 unmittelbar im Moment der H>L Flanke am Portpin. Die Sicherung wird komplett durch die Hardware, quasi nebenbei, erledigt. In der ISR des Timer1 wird dann nur noch das Capture Register in eine Variable übernommen. Die Zeit zwischen dem Auslösen der Hardwareflanke am Pin und dem Schreiben der Speichervariable spielt somit keine Rolle mehr.

Oh, die Funktion der ICU gefunden. Schön.

Zitat von Old_Surehand

Oh man, warum antworte ich auch noch auf deinen arroganten Ton? Du hast dich doch hier in die Diskussion eingeschaltet, oder nicht?

Interrupt, was genau passiert eigentlich bei einem Interrupt und was muss ich tun damit die Reaktionszeit auf eine Interruptauslösung so gut wie möglich gleich bleibt?

https://www.mikrocontroller.net/topic/299270

Wenn ich davon ausgehe, dass der Interrupt in einer Idle-Schleife ausgelöst wird, die sonst keine Aufgaben hat, kriege ich eine Reaktionszeit zwischen 4 und 8 Takten, je nachdem, was der Prozessor gerade macht.. Deine Schleife dauert 5 oder 6 Takte, d.h. der Fehler ist etwa gleich.

Was passiert wenn ich mehrere Interrupts zulasse und während der Ausführung einer Interruptserviceroutine ein weiterer, möglicherweise zeitkritischer, Interrupt ausgelöst wird?

Normalerweise deaktiviert man am Anfang der ISR alle Interrupts und lässt sie am Ende wieder zu.

Was unterscheidet einen bedingten Sprungbefehl wie sbis/sbic von der Auslösung einer ISR wenn ich gezwungen bin immer nur einen einzigen Interrupt gleichzeitig zuzulassen?

Ich bin nicht gezwungen.

EDIT: hat sich durch Feinmechanikers Antwort eh erledigt, wenn das so funktioniert.

Alles anzeigen

Die Konstruktion deiner Loop ist falsch.
Der Ansatz das "meine" Konstruktion 5 oder 6 Takte bzw. die ISR Reaktion 4 bis 8 Takte braucht ist falsch. Aber ich weise gerne noch mal Oberlehrerhaft darauf hin. Es ist fast egal wie lange die Reaktionszeit ist so lange sie immer gleich bleibt. Davon abgesehen braucht "meine" Konstruktion entweder 2 oder 3 Takte. Wie stellst du das sicher wenn du konkurrierende Interrupts hast?
Ja, man kann den Programmablauf fangen damit die ISR immer gleich aufgerufen wird. Das macht die ISR dann irgendwie ... überflüssig.

Zitat von zyx

@WhiteSAndS: Als interessierter Mitleser dieses Threads würde ich gerne darauf hinweisen, dass ich deinen Ton als sehr aggressiv und beleidigend empfinde. Wäre es möglich, so sachlich-nüchtern zu schreiben, wie es @Feinmechaniker angesichts seiner Bemühungen verdient?

Komisch, eigentlich bediene ich mich des nahezu gleichen Tonfalles den er in anderen Threads von sich gegeben hat.
Aber du machst mich neugierig, definierst du für mich zum nachlesen, ausdrucken und an die Wand hängen bitte "seine Bemühungen"?

rjmp braucht 2 Takte, sbis braucht 2-3 Takte. Sind zusammen 4 oder 5. Wenn der Trigger irgendwo innerhalb dieser 5 Takte kommt (du weiß nicht wann, kriegst du eine Ungewissheit von +-- 2 Takten.

Wenn du die Loop besser hinkriegst, her damit, aber ich glaube nicht, dass du sie schneller kriegst.

Das entspricht der Ungewissheit bei den Interrupts, wenn man davon ausgeht, dass der Aufruf zwischen 4 und 8 Takte braucht.

Jetzt verstanden?

Der Vorteil der Interrupts ist natürlich, dass ich potentiell auf verschiedene Ereignisse reagieren kann, ohne dass ich die Loop länger machen muss. Das nennt man technischen Fortschritt, also den von vor 40 Jahren...

Zitat von WhiteSAndS

Aber du machst mich neugierig, definierst du für mich zum nachlesen, ausdrucken und an die Wand hängen bitte "seine Bemühungen"?

Am erstem Post in diesem Thread hängt ein PDF. Druck's dir aus.