Cortex-M3: Cycles bei HW-Division

[Rene K. (xdraconix)]

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?

[(prx) A. K. (prx)]

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.

[STM-Starter (Gast)]

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.

[Klaus (Gast)]

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

[Karl (Gast)]

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?

[(prx) A. K. (prx)]

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.

[Walter T. (nicolas)]

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.

[Jan K. (jan_k)]

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?

[(prx) A. K. (prx)]

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.