Hallo!
@ Besserwessi
Es ist mir klar, aber je mehr Hardware um so weniger Software und umgekehrt, gilt hoffentlich immernoch...
MfG
Beide Versionen haben noch ein Problem mit der Behandung der Überläufe. Problem gibt es wenn Überlauf und ICP bzw. Int0 fast gleichzeitig auftreten. Vermutlich die Ursache für die etwa 2 % Fehlmessungen.
Für die Messung der Periodendauer wird man die gar nicht brauchen, nur für die Rundenzeit selber.
Ps:
Die Programme werden übersichtlicher, wenn man die Zeilenlänge etwas reduziert. Durch den Umbruch einiger Kommentrare wird das wirklich unübersichtlich.
Das kann ich mir eigentlich nicht vorstellen.Problem gibt es wenn Überlauf und ICP bzw. Int0 fast gleichzeitig auftreten.
Auch wenn beide Interrupts wirklich absolut zeitgleich eintreffen wird von jedem ein Flag gesetzt.
Die Routine mit der höheren Priorität wird dann zuerst ausgeführt, die andere später.
Es gilt natürlich auch hier was sonst auch immer gilt - Interruptroutinen sollten möglichst kurz sein.
Ich denke eher, die Fehlmessungen kommen von der Mechanischen Seite her, wenn z.B. die LED nicht genau über die Fotodiode fährt und deshalb kein vernünftiges Signal zustande kommt.
Ich hab ein wenig rumgerechnet, bei 8MHz Controllertakt sollte die Unterscheidung der Frequenzen problemlos möglich sein.
Ich würds mit einer Periodendauermessung mit TCNT1 probieren, weil die am schnellsten ein Ergebnis liefert.
Das selten Problem mit fast gleichzeitigen Interrupts gibt es, auch wenn es selten vorkommt. Wenn gleichzeit die Interruptfalgs für Überlauf und ICP gesetzt sind, wird immer erst die ICP routine aufgerufen, wegen der höheren Priorität. Das passiert auch, wenn zuerst der overflow aufgetreten ist, aber die Auswertung der Interruptflags durch einen längeren Befehl (oder einen CLI-SEI Block) verzögert wurde.
Das ist ein seltener Fall, aber er tritt gelgentlich (etwa 1 mal auf 100000 Fälle) auf.
Zumindest die älteren Versionen des Simulators im AVRstudio haben dabei einen Fehler, so daß der Effekt im Simulator nicht auftrat - das ist (bzw. war) aber ein Fehler der Simulation.
Für die Periodenmessung braucht man den Überlauf aber gar nicht. Ob man die Daten jetzt direkt aus dem Timerregister oder aus dem ICP Register ließt macht kaum einen Unterschied, der Rest des Programms kann gleich sein (Nur der Fall mit der Überschneidung der Interrupts tritt noch etwas häufiger auf).
Es geht positiv voran.
Was hab ich gemacht.
1. Meinem Mega8 ne ordentliche Spannungsversorgung spendiert, war gestern etwas wirr, so an den Schienen wo auch Signale drüber gehen etc, jetzt direkt am Trafo
2. dem Mega nen 16Mhz Quarz spendiert, so das er auch so läuft wie die Codes geschrieben wurden
3. den Sensor ordentlich angeklemmt so mit 1K gegen Masse und 100nF so wie es der Hersteller bei seinen Weichen tut
So bin ganz schön gefahren, einzeln mit versch Autos und 2 Autos Stoßstange an Stoßstange
es gab 4 Fehlmessungen, 2 sind unerklärlich, die anderen beiden passieren wenn 1 Auto kurz vor dem Messpunkt rausfliegt, kann mir vorstellen das die LED im Auto auch bissel Zeit brauch um wieder mit der vorgegeben Frequenz zu leuchten da ja da auch nen Mega8 im Auto steckt und der ja sicher auch "hochfahren" muss......
Bin zufrieden erstmal.
So zum Timerüberlauf, ich glaube, obwohl ich den Code immernochnicht versteh das der Timer nur überläuft wenn die LED im Auto mit einer höheren Frequenz geht als vorgegeben, denn der Überlauf war immer nur nach dem einsetzen. Beim normalen Zählen ist der Timer nie übergelaufen, habs mir anzeigen lassen.
Kann auch wieder sein ich lieg völlig falsch mit meiner Theorie.
Gut, ich werd also Code 1 nutzen, der geht am besten, nun muss ich nur noch verstehen was in diesem Code passiert um unnützes raus zu nehmen und dann weiter am Rundenzähler zu proggen.
So ist erstmal der Stand.
Dank euch kollimann
Berechtigungen
Zitieren
Lesezeichen