Guten Morgen, ich stelle mir die folgende Frage: Wenn ich einen GPIO Interrupt auf beispielsweise eine steigende Flanke setze z.B. bei einem STM32F4, mit wie vielen Takten kann ich rechnen, bis der Sprung in die Interruptroutine erfolgt? Natürlich unter der Annahme, dass dieser Interrupt in dem Augenblick der mit der höchsten Priorität ist. Viele Grüße Marcel
Marcel B. schrieb: > Guten Morgen, > > ich stelle mir die folgende Frage: Wenn ich einen GPIO Interrupt auf > beispielsweise eine steigende Flanke setze z.B. bei einem STM32F4, mit > wie vielen Takten kann ich rechnen, bis der Sprung in die > Interruptroutine erfolgt? Natürlich unter der Annahme, dass dieser > Interrupt in dem Augenblick der mit der höchsten Priorität ist. Du brauchst nicht rechnen. Schau einfach in die Doku, da steht das drin!
John Doe schrieb: > Du brauchst nicht rechnen. Schau einfach in die Doku, da steht das drin! Im Reference Manual habe ich keine Angabe dazu finden können, wie lange es dauert. Dort steht nur irgendwie dabei, dass der eigentliche Interrupt sehr hardwarenah an der CPU stattfindet und dadurch schnell ist. Ich finde die Info nicht, vielleicht übersehe ich sie auch vor lauter Reference Manual, Programming Manual und Datenblatt..
Marcel B. schrieb: > Im Reference Manual habe ich keine Angabe dazu finden können, wie lange > es dauert. Du mußt in den Informationen zum NVIC nachsehen. Ohne selber nachgesehen zu haben: 12++ Takte je nach Aktivität, die gerade auf den internen Bussen abläuft.
m.n. schrieb: > Du mußt in den Informationen zum NVIC nachsehen. Ohne selber nachgesehen > zu haben: 12++ Takte je nach Aktivität, die gerade auf den internen > Bussen abläuft. Danke für den Hinweis, ich habe jetzt nochmal genauer gelesen. Im Programming Manual ab Seite 42 unter Exeption Entry ist erkennbar, dass zunächst 8 Datenworte in den Stack geschoben werden. Das würde ich also als untere Schranke von 8 Takten deuten. Vielen Dank!
Im Cortex-M4 Technical Reference Manual (siehe arm.com) stehen wenn ich mich recht erinnere 12 Takte. Dazu kommt noch eine etwaige Latenz durch die Peripherie von ST.
Ich meine auch 12 Takte + x im Kopf zu haben, wobei ich die genaue Quelle nicht mehr parat habe. Eventuell war das aus dem "Definitive Guide" von Joseph Yiu den ich auch unbedingt empfehlen kann. Marcel B. schrieb: > Danke für den Hinweis, ich habe jetzt nochmal genauer gelesen. Im > Programming Manual ab Seite 42 unter Exeption Entry ist erkennbar, dass > zunächst 8 Datenworte in den Stack geschoben werden. Das würde ich also > als untere Schranke von 8 Takten deuten. Achtung: Bei verwendung der FPU werden einige Register zusätzlich gesichert. Die Latenz erhöht sich dementsprechend.
Christopher J. schrieb: > Eventuell war das aus dem "Definitive > Guide" von Joseph Yiu den ich auch unbedingt empfehlen kann. Und zwar Seite 282, Chapter 8.3.1. Demnach sind es mindestens 12 Takte (inclusive vector fetch und register stacking). Für die FPU kommen weitere 12 Takte dazu, um Speicherplatz für das lazy-stacking der FPU Register zu reservieren. Wirklich gesichert werden sie erst später, falls sie tatsächlich verwendet werden, was innerhalb der ISR weitere Takte in Anspruch nimmt. Häufig ist es aber mehr, wegen diverser Wait States (auch von der vorherigen Operation).
Stefanus F. schrieb: > Häufig ist es aber mehr, wegen diverser Wait States (auch von der > vorherigen Operation). Kann man eine maximale Dauer angeben wenn sich die ISR im schnellen SRAM befindet?
AVR-Umsteiger schrieb im Beitrag #5792252: > Kann man eine maximale Dauer angeben wenn sich die ISR im schnellen SRAM > befindet? Nicht so einfach, weil der Code, der vorher ausgeführt wurde ja eventuell im Flash liegt und auf langsame Hardware zugreift (z.B. die RTC). So aus dem Bauch heraus würde ich sagen, dass du insgesamt mit 12 bis 32 Takten rechnen musst. Warum fragst du eigentlich danach, hast du einen Performance-Engpass?
AVR-Umsteiger schrieb im Beitrag #5792252: > Kann man eine maximale Dauer angeben wenn sich die ISR im schnellen SRAM > befindet? Achtung, Code aus dem RAM auszuführen kann sogar langsamer sein, weil dann sowohl Daten-als auch Code-Zugriffe über den selben Bus gehen. Der STM32F4 hat ja auch den ART als Cache für den Flash, der die Laufzeit aber undeterministisch machen kann. Die F7 haben einen Extra-RAM für Instruktionen, mit eigener Anbindung.
Stefanus F. schrieb: > So aus dem Bauch heraus würde ich sagen, dass du insgesamt mit 12 bis 32 > Takten rechnen musst. Warum fragst du eigentlich danach, hast du einen > Performance-Engpass? Jein, unsicher, es ist tatsächlich eine zeitkritische Stelle, aber bei dieser Abschätzung wohl eher an anderer Stelle zu suchen. Ich kann nur aktuell nicht messen, da ich nicht vor Ort sein kann daher die Frage. Ich kann keine genauen Details nennen, tut mir leid. Viele Grüße Marcel
Marcel B. schrieb: > Ich kann keine genauen Details nennen, tut mir leid. Aber Du könntest dennoch sagen, wieviel Takte Verzögerung die Obergrenze wären. Wenn alles nicht hilft, gehe über F7xx zu H7xx µCs. Letztere laufen mit 400 MHz doch recht flott. Es wäre auch zu prüfen, ob ein ext. Interrupt an einem input-capture Eingang eines Timers nicht schneller behandelt würde. Nur so als Idee.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.