Au Mann, wieder einer, der alles was es an rechenzeitintensiven
Ausgaberoutinen gibt und noch alles Mögliche andere in einen
Interrupt-Handler schmeißt und sich dann wundert, dass er
Timing-Probleme kriegt. Hat sich das immer noch nicht rumgesprochen,
dass ein Interrupt-Handler so kurz wie möglich zu halten ist?
Mal im Ernst: Schmeiß den ganzen sprintf- und sonstigen Kram aus der ISR
raus und ins Hauptprogramm. Und überlege v.a. mal, wie lange sprintf und
der ganze Rest brauchen und wie viele Interrupts Dir dadurch entgehen.
Bedenke v.a., dass während der Ausgabe, die ja dummerweise in der ISR
stattfindet, alles andere, auch die Frequenzmessung, auf Eis liegt. Mach
die Frequenzmessung mit einem Timer-Interrupt (habs mir nicht so genau
angesehen, musst also selbst entscheiden, obs mit Periodendauermessung
[Capture] oder Periodenzählung [bei höheren Frequenzen] geht). Und die
ganze Ausgabe ins Hauptprogramm. Dann kann der Timer-Interrupt (Compare,
Overflow oder Capture, je nachdem) nämlich den ganzen Mist unterbrechen,
wenn etwas wichtiges passiert. Das ganze Programm ist nicht
durchdacht...
Geil! (SCNR)
Sowas hab ich noch nie gesehen: Eine bedingte USART-Initialisierung in
einer ISR.
Wie mein Held vo KTEL im "Vierten" immer meint "Einfach groossaartig!"
Manchmal glaube ich fast, dass es verboten ist, in der main irgendwas zu
machen.
Die main ist doch dazu da, von Interrupts unterbrochen zu werden, oder?
Ich lege mir immer ein Statusregister an, in dem ich Flags definiere.
Zeitaufwändige Sachen, wie gesagt, ins Hauptprogramm und mi Hilfe der
Flags ausführen lassen. So müssen in den INT-Routinen nur Flags gesetzt
werden.
Ach ja, worüber Du Dir vielleicht zuerst Gedanken machen solltest, sind
die Bearbeitungsprioritäten im Programm. Zeichne Dir am besten einen
Ablaufplan. Denke daran, dass eine Frequenzmessung darauf angewiesen
ist, dass kein Zählereignis verloren geht. Die Ausgabe und die
Berechnung der auszugebenden Werte sind völlig unkritisch, was das
Timing angeht. Die können auch mal warten, wenn grad was wichtiges
ansteht.
Merke:
Sachen wie Fließkommaberechnungen, serielle Ausgaben, Warteschleifen
usw. haben in einem Interrupt-Handler nichts zu suchen. Außerdem
könntest Du überlegen, ob es wirklich unbedingt sprintf sein muss. Da
gibt es wesentlich spezialisiertere Funktionen in der stdlib.h, die
aufgrund ihrer Spezialisierung wesentlich weniger Overhead produzieren
(was auch i.d.R. zu wesentlich kürzeren Bearbeitungszeiten führt).
