Forum: Mikrocontroller und Digitale Elektronik Inkonsistenz gemessener Rechenzeit zu Rechenzeit im Ref. Manual ARM 7TDMI


von Samuel (Gast)


Lesenswert?

Hallo,
ich benutze zu Programmierung den ADuC7020 mit ARM7 TDMI Kern. Da ich 
ziemliche Probleme mit dem Ausreichen der Rechenzeit für meine Anwendung 
hatte und für mich erstaunlich war, wie lange übersetzter c Code 
benötigte, habe ich einen Versuch gemacht, mit inline Assembler Befehlen 
Daten vom SPI Empfangsregister zu lesen, zwischenzuspeichern und wieder 
auf das SPI Senderegister zu legen. Um die Zeit zu messen die das 
benötigt lasse ich einen Portpin toggeln. Folgende (inline) assembler 
Codezeilen machen dies. Hinter die Befehle, also direkt hinter dem 
Kommentarzeichen "//" habe ich die Anzahl der Zyklen, die sich meiner 
Meinung nach nach dem ARM technical reference manual für ARM7 TDMI 
Chapter 6 ergeben geschrieben.


__asm("str r5,[R4,#0x24]"); //2   set port bit P0.4 to high
__asm("ldr r0,[r1,#0x04]");  //3   cycles //store contents of SPIRX
//(contents of datas locted on adress r1+0x04 = 0xFFFF0A04) into r0
__asm("strh r0,[r2,#0x00]");//2
__asm("str r0,[r1,#0x08]"); //2  //store datas in r0 onto SPITX
//(datas on adress r1 +0x08)
__asm("str r5,[R4,#0x28]");  //2/  /set port bit P0.4 to low

der Controller Arbeitet im ARM Mode und die ECLK mit der der Kern 
getaktet wird beträgt 41,78 MHz (höchst mögliche Taktrate)

Rechnerisch ergibt sich, wenn man voraussetzt, dass ECLK und Instruction 
Cycle clk die gleiche Frequenz haben für die Befehle folgende Zeit: 
(2+3+2+2+2)*1/(41,78 MHz) )=263nsec

Am Portpin messe ich allerdings eine Zeit für die Befehle von etwa 
500nsec

Woran liegt der große Unteschied zwischen errechnetem und gemessnen 
Wert??
Habe ich die Angaben zu den instruction cycles im technical reference 
manual für ARM 7 TDMI falsch interpretiert?
Leider finde ich im ARM technical reference manual nirgends die Stelle 
wo steht in welchem Vehältnis ECLK und instruction cycle clock stehen.
Weiss das jemand oder hat jemand eine Idee wo ich das nachlesen kann??
Hat Jemand Erfahrung mit diesem Mikrocontroller oder diesem Kern bzgl. 
Rechnezeitoptimierung gemacht?
Danke für eure Hilfe!
Gruß
Samuel

von ... (Gast)


Lesenswert?

Weil der GPIO Teil im Prozessor nciht mit voller Prozessor Taktfrequenz 
arbeitet?

von Tilo (Gast)


Lesenswert?

Liegt dein Code im Flash oder im Ram?
Im Flash verdoppelt sich die Ausfürhungszeit, da dieses nur mit 16Bit
angebunden ist. Steht aber auch so im Handbuch. Wenn einzelne Funktionen
schnell ausgeführt werden sollen, kann man diese ins Ram kopieren.

Die GPIO-Pins benötigen, wie der Vorposter schon schrieb, immer 2Takte,
egal ob im Ram oder Flash.

Noch ein kleiner Tip zu SPI: 3,5 ist die Maximale Taktrate. Nach der 
Formel,
mit der die Geschwindigkeit berechnet wird, wäre mehr möglich. Die 
Signale
sind dann aber asynchron und die Schnittstelle wird unbrauchbar
(nachgemessen mit Logicanalizer).

Verzweigungn etc machen auch etwas aus, da die Pipeline dann neu befüllt
werden muss.

von Robert T. (robertteufel)


Lesenswert?

Wenn es Dir wirklich auf Rechenzeit ankommt, dann hast Du natuerlich 
einen der langsamsten ARM7 ausgesucht. Ich nehme mal an Du magst einen 
12-bit ADC ;-)

Die Analog Devices Teile haben wohl den besten ADC mit einem ARM7 auf 
demselben Chip, leider wissen die Jungs (oder Maedels) viel weniger 
ueber uCs als sie ueber analog wissen :-)

Angefangen von der Flash Anbindung ueber den nicht vorhandenen Interrupt 
Controller bis hin zur sehr niedrigen max. Frequenz, das Ding ist 
einfach langsam. Im Vergleich zu den schnellsten ARM7 ca. ein Faktor 3 
vom Flash!

Ein kleiner Tip um die Abarbeitung aus dem Flash schneller zu machen, 
bitte im Thumb mode programmieren! Ja, Du liest richtig, Thumb mode KANN 
schneller sein als ARM mode, genau dann, wenn der Programmspeicher nicht 
mit 32-bit Breite (oder mehr) angebunden ist. Deshalb gibt es auch 
einige Bausteine, die sind im Thumb mode schneller und andere, die sind 
im ARM mode schneller. Solange es eine 0WS Abarbeitung aus dem 32-bit 
breiten SRAM ist, ist der ARM mode ca. 20-30% schneller, aus einem 
16-bit breiten Speicher ist es genau anders rum, der Thumb mode ist 
schneller. Die Erklaerung habe ich vor langer Zeit mal ausfuehrlich 
gebracht.
Also in Deinem Fall den kritischen Code wenn moeglich in das sehr kleine 
SRAM laden oder aber vom Flash in Thumb Mode ausfuehren.

Hoffe das hilft ein wenig.
p.s. das mit dem langsamen Zugriff auf Portpins hat in Deinem Fall 
absolut gar nichts zu sagen, denn das mittelt sich aus beim setzen und 
ruecksetzen.

Robert Teufel
Suchen Sie einen Partner in Silicon Valley?
Ich stehe gerne zur Verfuegung.
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Meine ARM/Cortex Webseite: http://www.lpc2000.com

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
Noch kein Account? Hier anmelden.