Der Cortex M3 hat ja einen Hardware Divisor. Jedoch stellte ich gerade fest das die benötigten Taktzyklen im Instruction-Set mit 2 bis 12 Cycles für UDIV und SDIV angegeben sind. Wie kann ich am besten, für eine Zeitkritische Anwendung, sicherstellen das eine Division eine fest definierten Cycletime nutzt? Mir kommt es nicht auf Geschwindigkeit an, sondern auf gleichmäßige Nutzung. Also kann er sich auch ruhig die vollen 12 Cycles genehmigen, Hauptsache ich kann damit rechnen. Gibt es da einen funktionierenden Workaround für solch einen Fall?
Rene K. schrieb: > Wie kann ich am besten, für eine Zeitkritische Anwendung, sicherstellen > das eine Division eine fest definierten Cycletime nutzt? Klassisch zu Fuss dividieren, also ohne den Befehl zu verwenden.
:
Bearbeitet durch User
Du könntest einen Timer ohne Vorteiler mitlaufen lassen und nach der Division auslesen. Dann weisst du wieviele Cycles es gedauert hat. Hab ich mal bei PIC18 gemacht, um die ISR-Laufzeit zu ermitteln.
Rene K. schrieb: > Wie kann ich am besten, für eine Zeitkritische Anwendung, sicherstellen > das eine Division eine fest definierten Cycletime nutzt? Wie lange so ein Cycle dauert wird doch auch vom aktuellen Zustand des Caches abhängen, ist also nicht vorhersehbar. STM-Starter schrieb: > Dann weisst du wieviele Cycles es gedauert hat. > Hab ich mal bei PIC18 gemacht, um die ISR-Laufzeit zu ermitteln. Der PIC18 wird keinen Cache haben, ein ARM schon. MfG Klaus
Normalerweise finde ich es doof die Anforderung in Frage zu stellen, aber dir ist bewusst dass Controller vom Schlag Cortex m3 noch andere Quellen für variierende Ausführungszeiten haben? Cache, waitstates, konkurrierende Bus Zugriffe etc. Wie genau muss es werden? Muss das durch zyklenzählen passieren?
Klaus schrieb: > Wie lange so ein Cycle dauert wird doch auch vom aktuellen Zustand des > Caches abhängen, ist also nicht vorhersehbar. Viele Mikrocontroller mit Cortex M3 verwenden keinen Cache.
:
Bearbeitet durch User
Rene K. schrieb: > Wie kann ich am besten, für eine Zeitkritische Anwendung, sicherstellen > das eine Division eine fest definierten Cycletime nutzt? Leider gar nicht. Vom Worst case ausgehen, sicherstellen, daß die Division wirklich in Hardware ausgeführt wird und nicht über eine Library-Funktion und wenn es Dir um Jitter geht: Die Pins in der ISR vor der Division setzen.
Klaus schrieb: > Rene K. schrieb: >> Wie kann ich am besten, für eine Zeitkritische Anwendung, sicherstellen >> das eine Division eine fest definierten Cycletime nutzt? > > Wie lange so ein Cycle dauert wird doch auch vom aktuellen Zustand des > Caches abhängen, ist also nicht vorhersehbar. > > STM-Starter schrieb: >> Dann weisst du wieviele Cycles es gedauert hat. >> Hab ich mal bei PIC18 gemacht, um die ISR-Laufzeit zu ermitteln. > > Der PIC18 wird keinen Cache haben, ein ARM schon. > > MfG Klaus Der cortex m3 hat keinen cache. Wenn es eine garantierte Zeit sein muss, kann man ja die maximale Zyklenanzahl annehmen, die Zeit messen (am ehesten mit dem cyccnt, dann braucht man keinen eigenen timer) und dann busy wait bis die Zeit um is. Wofür brauchst du das?
A. K. schrieb: >> Wie lange so ein Cycle dauert wird doch auch vom aktuellen Zustand des >> Caches abhängen, ist also nicht vorhersehbar. > > Viele Mikrocontroller mit Cortex M3 verwenden keinen Cache. Genauer: Der Cortex M3 Core enthält keinen Cache. Wenn ein Cache vorhanden ist, dann als Teil des Flash-Systems. Davon wären ISRs im RAM nicht betroffen.
Bitte 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.