Wie viele Interrupts / Impulse/s verkraftet ein Atmega

[WL]

Hi,

wenn ich das Gefühl habe dass es irgendwo knapp werden könnte, messe ich die Ausführungzeiten von den Teilen die "parallel" laufen sollen. Ich setze am Beginn des entpsrechenden Programmteils irgendeinen Pin, den ich dann am Ende wieder lösche. Die high-Phase guck ich mir dann mit dem Oszi an. Auf diese Weise kann man auch die Aufenthaltsdauer in einer ISR in etwa bestimmen. Dabei muss man natürlich noch bedenken, dass da ggf noch Register gesichert werden, bevor der Pin gesetzt, bzw nachdem er wieder gelöscht wird.

Gruß
Malte

Noch komfortabler wird diese Taktik + Logik-Analyser.
Bei mehreren ISR kann sehr schön die Dauer und zeitliche Abfolge verfolgt werden.
Diese Teile sind machmal mehr als Gold wert............

[damfino]

Oszi und Logik Analyzer wären toll, aber nicht vorhanden. Für die 3x im Jahr wo ich diese brauchen würde zahlt sich ein Kauf nicht aus. Ich behelfe mich mit dem Simu indem ich die notwendigen Takte für Funktionen überprüfe und so auf Geschwindigkeit optimiere. Der PI Regler oben benötigt 737 Takte (jetzt gemessen).

Das Projekt und die ISR haben sich laufend weiter entwickelt. Zuerst ein einfacher Zähler, dann ein PI Regler, dann 3 PI Regler, und die Odometriezähler so erweitert dass auf defekte (Wackelkontakt) Hallsensoren reagiert werden kann. Damit kann man schlecht auf Counter wechseln.

LG!

[Besserwessi]

Das sieht noch alles recht harmlos aus. Bei weniger 1 MHz Takt müsste man ggf. nochmal genau nachrechnen. Die Simulation ist schon ganz gut geeignet um die Laufzeiten je ISR raus zu bekommen. Damit kann man dann auch ganz gut ausrechnen wieviel Rechenzeit die ISRs verbrauchen, und wie lang die Reaktionszeit im ungünstigsten Fall wird.

[drew]

Hi,
Laufzeitmessungen mach ich auch so, dass ich im untersten Level eine Schleife mit NOPs durchlaufen lasse.
Dann messe ich die Zeit einmal ohne Interrupts und einmal mit Interrupts. (Die Zeit ohne Interrupts sollte schon mal ein paar Sekunden dauern...)

Die Differenz ist dann die Zeit, die die Interrupts schlucken.
Wenn ich dann die Differenz zur gesamt-Zeit mit Interrupts ins Verhältnis stelle habe ich eine prozentuale Auslastung des System.

Also:
To: Zeit ohne Interrupts
Tm: Zeit mit Interrupts
Td = Tm-To: Zeit der Interrupts
(Td/Tm)*100%: Prozentuale Auslastung des Systems durch die Interrupts.

Gruß,
Drew

[damfino]

Letztes Jahr musste ich wegen diverser Hardwareschäden den Takt von 16Mhz auf 8Mhz reduzieren, da ging dem Kontroller dann die Luft aus, zB funktionierte die Drehzahlregelung obwohl in ISR nicht mehr...
Deswegen gibt es neue Hardware, von 2 Kontrollern zurück auf 1, damit entfällt die langsame Datensynchronisation über TWI, aber gleicht sich aus dass eben alle Aufgaben von einem Kontroller erledigt werden müssen.
Daher wird die Software optimiert, eine Überlegung war eben den USART von Polling und damit verbundenen sinnlosen Wartezeiten auf Interrupt umzustellen, der Hoffnung dass der Interrupt Aufruf kürzer ist als die Wartezeiten zuvor.

Das mit der Laufzeitmessung werde ich mal testen.

LG!

[damfino]

Habe jetzt folgende Laufzeitmessung durchgeführt:
Zähler in der Hauptschleife, alle 0.25s am LCD anzeigen.
1.) normal das Programm mit LCD, nur mit Timer Interrupt.
danach mehr und mehr Code dazugenommen bis:
2.) Programm mit LCD, allen Interrupts und allen regelmäßigen Tasks, TWI das ins leere und damit Timeout geht, als Simulation der 3 Odometrie Zähler haben ich einen zweiten Timer mit 1khz gestartet und in dessen ISR 4 Werte hochgezählt.

Bei 1 gab es max 3580 Durchläufe in 0.25s, bei 2 gab es min 3410 Durchläufe.
Damit komme ich nach obiger Rechnung auf 5% Auslastung durch Interrupts und regelmäßgigen Tasks.
Somit bleibt ja jede Menge Rechenleistung übrig

Eines war schön zu sehen: Habe den Fifo Buffer des USART so programmiert dass er erst Werte aufnimmt wenn der gewünschte Startcode vom GPS NMEA Code zB: "$GPGGA" kommt. Auswertung startet im Hauptprogramm wenn Übertragung komplett ist. Da nur 1x pro Sekunde die Daten übertragen werden konnte man schön sehen das kurz die Durchläufe von 3580 auf 3560 einbrachen. Bei abgestecktem GPS blieb der Wert schön gleichmäßig bei 3579/3580.


LG!