Hallo,
danke fürs Anschauen. Daß sich die Interrupts in die Quere kommen würde ich ausschließen. Ich weiß, daß es verpönt ist, Print-Ausgaben in einer ISR zu machen da eine ISR so schnell wie möglich gemacht werden soll. Bin das Risiko aber kalkuliert eingegangen und kann das später noch korrigieren. Der Tiny hat wenig SRAM und beim Programmieren hatte ich zwischendurch OUT OF SRAM Probleme wegen zu vieler zu großer Variablen beim Print in der Hauptschleife. Ist halt noch ein Testprogramm.
Bei vielen AVR, hier beim ATtiny2313 gibt es ein eigenes 16Bit ICR Register (Input Capture Register). Dort wird bei Auftreten eines Pegelwechsels am ICP Pin der Timerstand des 16Bit TIMER1 hineinkopiert. Gleichzeitig wird ein Interruptflag für den ICP Interrupt gesetzt. Ob die ISR zum ICR Register sichern sofort oder etwas später ausgeführt wird ist egal, da der Timerwert im ICR vorerst sicher ist. Die ISR muß jedoch vor dem nächsten Input Capture Event durchgeführt werden, da das ICR dann überschrieben wird. Bei PICs gibt es vermutlich Ähnliches.
Ich habe gerade nochmal die "Update_display" ISR im Simulator laufen lassen. Braucht 0,18075ms (1446 Zyklen). Die angepeilte, maximal zu messenden Drehzahl von 16-, 17000Upm entspricht einer Capture Frequenz von 17000/60=ca. 284Hz. 284Hz haben eine Periodendauer von 1/284=ca.3,5ms. Bei der höchsten zu messenden Umdrehungszahl bleiben also noch 3,5ms minus 0,18075ms = reichlich Luft. Ich weiß nicht, ob der Simulator das Senden der Zeichen mit dem Print richtig berechnet. Wenn 12 Zeichen (5 Leerzeichen, max. 5 Ziffern des Meßwertes und die beiden CR) mit 57600 Baud gesendet werden dauert das ca. 2ms. Plus der 0,18075ms Rechenzeit bleiben bis zu den 3,5ms immer noch reichlich "Luft". Bei den Messungen im Leerlauf der Motorsäge bei um die 2700Upm (45Hz Capture Frequenz) also noch gar kein Thema falls ich nicht doch etwas übersehen habe. Mit Testfrequenzen über Generator gibt es in der Hinsicht auch kein Problem.
Gruß
Searcher
Lesezeichen