ARM Laufzeit eines Programms abschätzen

[Fragr (Gast)]

Guten Tag,

ich würde gerne auf einem STM32 etwas Signalverarbeitung machen.
Dabei habe ich hier im Forum den Tipp gelesen, zuerst ungefähr die 
Laufzeit abzuschätzen und zu schauen, ob ich die Verarbeitung überhaupt 
innerhalb eines Zyklus schaffen kann.

Kann mir jemand in etwa erklären wie ich dabei vorgehe?
Irgendwie ist mir das nicht ganz klar. Theoretisch müsste ich mir doch 
meine C Funktionen in Assembler ansehen, mir die Befehle irgendwo 
raussuchen, gucken wie viele Prozessorzyklen dafür gebraucht werden und 
diese addieren?
Das klingt irgendwie nach seehr viel Arbeit.

Vor allem passieren dann zwischendurch noch Speicherzugriffe von dem 
DMA. Wie ich gelesen habe sollen diese vergleichsweise langsam sein und 
deswegen soweit wie es geht vermieden werden, aber wie schätze ich so 
etwas ab?

Beste Grüße
Felix R.

[Stefan F. (Gast)]

Fragr schrieb:
> Das klingt irgendwie nach seehr viel Arbeit.

Ja.

Du könntest die Zeit auch messen. Dafür haben die ARM Kerne extra einen 
Zyklen-Zähler. Andere rufen die Funktion n mal auf und messen die zeit 
mit einer Stoppuhr, einem Oszilloskop oder einem Logic-Analyzer.

Bei deinen Bedenken hast du noch den Prefetch Buffer und eventuell 
vorhandenen Cache vergessen, sowie Interrupts. Messen ist definitiv 
einfacher.

[Jim M. (turboj)]

Zuallererst: Hirn einschalten!

Der einfache Weg: Testdaten generieren, durch die Signalverarbeitung 
jagen und messen wie lange es dauert.

STM32 haben reichlich Timer, bessere Kerne (Cortex-M3 und aufwärts) 
haben sogar einen Zyklenzähler (IIRC in der Debug Einheit).

Dickere Varianten haben unabhängige Speicherbereiche, d.h. DMA und CPU 
Kern können gleichzeitig auf verschiedenen Speichern arbeiten. Sowas 
könnte man bei der Auswahl des konkrenten µC dann berücksichtigen.


DMA Zugriffe stören IMHO eher selten, Interrupts stören viel mehr da 
während deren Ausführung das Hauptprogramm ja "steht".

[Random .. (thorstendb)]

Hast du eine IDE mit grafischer Analyse für Variablen und einen halbwegs 
schnellen Debugger, kannst du das auch über das Setzen von Variablen 
lösen (der Cortex-M kann bis zu 4 per SWO rausschreiben).
Besser noch, wenn dir die IDE gleich die Interrupt und RTOS Timings mit 
dazupinselt.

So habe ich für eine Echtzeitanwendung während die Anwendung auf PC und 
µC lief die Ethernet Antworten, Buffering sowie Fehlerzustände 
untersucht :-)

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Fragr schrieb:
> Vor allem passieren dann zwischendurch noch Speicherzugriffe von dem
> DMA. Wie ich gelesen habe sollen diese vergleichsweise langsam sein und
> deswegen soweit wie es geht vermieden werden, aber wie schätze ich so
> etwas ab?

Es gab früher sehr viele DMA-Implementierungen, bei denen sich die 
Entwickler viel zu wenig über die damit einhergehende Busbelastung und 
Latenzen beschäftigt haben. Damals(tm) konnte man den Z80 DMA so 
programmieren, dass er die CPU komplett abklemmte und dauerhaft 
Speicherinhalte umkopierte. Mangels Reset-Eingang konnte man ihn nur per 
Stromreset stoppen.

Einen Atmel AT91RM9200 konnte man komplett aus dem Tritt bringen, indem 
man ihn mit Ethernetpaketen überflutete und der DMA-Controller mehr 
Speicherbandbreite benötigte als an irgendeinem Nadelöhr verfügbar war. 
Den Vogel schoss jedoch der Sharp LH79402 ab, dessen DMA-Controller sich 
überhaupt nicht um gerade laufende DRAM-Speicherzugriffe der CPU scherte 
und einfach "dazwischenfunkte".

Solche Fälle sehr schlecht konstruierter DMA-Controller werfen natürlich 
ein schlechtes Licht auf DMA, aber vielfach liegt es einfach auch nur an 
den Programmierern, die durch eine vergurkte Konfiguration des 
DMA-Controllers zu solchen Problemen beitragen. Es ist eben so wie mit 
anderen gefährlichen Werkzeugen: richtig eingesetzt sind sie sehr 
wirkungsvoll, falsch eingesetzt können sie großen Schaden anrichten. DMA 
zu verbieten wäre so, als würde man ausgebildeten Chirurgen den Einsatz 
des Skalpells verbieten, nur weil irgendjemand mal mit dem Skalpell in 
seiner Nase gepopelt hat und daran verblutet ist.

Zur Laufzeitmessung:
Gerade bei Microcontrollern hat man doch paradiesische Zustände, d.h. 
man kann - neben den schon genannten Methoden - doch munter mittels 
Portpin und Oszilloskop Laufzeitmessungen durchführen.