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.
Gast
#5272002
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.
Gast
#5272010
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
Gast
#5272013
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.
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.