STM32F767 GPIO Geschwindigkeit hängt an Debug/Release

Bob A. schrieb:
> Was mir jetzt noch unklar ist: wieso ich ziemlich präzise alle ms eine
> Unterbrechung von ca 430ns habe

SysTick Timer Interrupt. Ohne Optimierung übersetzt der Compiler 
ziemlich "dumm", sodass selbst so simple Register-Zugriffe und die 
vermutlich drum herum gebaute Schleife um ein Vielfaches langsamer 
werden.

Bob A. schrieb:
> mal beim kompilieren von
> Debug auf Release umgestellt

Das ist kein Wunder. In Debug-Versionen muss zusätzlicher Code eingefügt 
werden (z.B. zur Anzeige von Zeilennummern im Sourcecode), und der muss 
natürlich auch ausgeführt werden. Und einige Optimierungen werden nicht 
angewendet, sonst erlebt man beim Debuggen komische Sachen wie fehlende 
Codestücke.

Georg

Die Zeilennummern stehen nicht direkt im Code drin. Aber wenn man den 
Optimizer frei arbeiten lässt, strukturiert er das Programm bis zur 
Unkenntlichkeit um, so dass der Debugger Probleme bekommt, den 
zugehörigen C-Quelltext wieder zu finden.

Man kann auch optimierten Code mit Debug-Informationen kompilieren. Der 
Code selbst wird dadurch nicht beeinflusst, der Controller merkt keinen 
Unterschied zwischen "Mit Debug Info" und "Ohne Debug Info". Es wird 
lediglich die ELF Datei größer. Daher kann man das meist auch völlig 
bedenkenlos machen. Die zusätzlichen Debug-Informationen in der ELF 
Datei werden vom Debugger ausgewertet (typischerweise GDB) um z.B. zur 
Adressen Code-Stellen zuzuordnen. Wie schon gesagt ist diese Zuordnung 
bei eingeschalteter Optimierung etwas durcheinander was das Debugging 
erschwert. Es ist aber manchmal unumgänglich, wenn ein Problem nur bei 
eingeschalteter Optimierung auftritt, oder der Controller schlicht nicht 
genug Flash für die unoptimierte Version hat.

Der arm-gcc hat dazu die Kompromiss-Option: -Og

Damit optimiert er so viel wie möglich, ohne den Debugger lahm zu legen.

Wobei "lahm legen" übertrieben ist. Auch bei voller Optimierung 
funktioniert das Debugging an sich; die Abfolge der Anweisungen 
innerhalb von Funktionen gerät durcheinander und lokale Variablen können 
verschwinden/sich anders verhalten. Mit etwas Fummelei kann man dem 
Programmablauf aber schon folgen.

Jim M. schrieb:
> . Das machen einige IDEs als Vorgabe im Release Mode

Bloß warum... Die 1MB hat man auf seiner Festplatte ja noch. Das landet 
ja wie gesagt nicht auf dem Controller...

Jim M. schrieb:
> Weiterhin ist es eine große Hilfe wenn man das Disassembly wenigstens
> lesen kann

Das sowieso ja... Wobei der optimierte Code mMn besser lesbar ist.

TIP: der F7 hat ITCM Speicher
mach dich schlau und lege die ISR und zeitkritische funktionen in diesem 
Bereich ab

zugriffe aus dem flash haben bei den 216Mhz 7 Waitstates.
bei funktionen aus dem ITCM: 0

Bob A. schrieb:
> Wo kommt denn der SysTick her?

Die HAL definiert den und braucht den IIRC auch. Der wird natürlich 
nicht bei -O3 wegoptimiert, denn das ist ja gewünschte Funktionalität! 
Wenn dich diese Unterbrechung stört, solltest du dein Konzept 
überdenken.  Pins mit 108MHz in Software togglen klingt nicht besonders 
sinnvoll.

dann pack den M7 mal richtig voll .. ^^
die Speicherbereiche sind auch sehr witzig.

bei mir sind es
16K ITCM ( für funktionen )
224K SRAM1 ( allgemeinkram )
16K SRAM2 ( für ethernet )
64k DTCM  ( für schnelle sachen , RTOS stack )

problem ist da  das originale linkerfile...

der packt den Stack ans ende vom "RAM ( 320k )"  was am ende des SRAM2 
ist
Der ist langsamer und ist cacheable was irgendwann beim RTOS schonmal 
für verwirrung sorgt ^^

Wenn man  diverse blöcke belegt und er kommt irgendwann über die grenze 
der  ersten 64k( was DTCM ist ) und will in den SRAM1  wirds auch 
witzig.

Die DMA geschichte funktioniert nur zuverlässig aus SRAM1 oder SRAM2

Wenn man dann sich wundert warum das Gerät am anfang bei funktion X so 
schnell war und nun plötzlich langsamer läuft ... hat das 2 ursachen:

RAM bereiche im .map irgendwo anders
Der jump im flash ist größer und er muss den ART komplett umladen


Der M7 hat mich schon so manchen nerv gekostet ^^
Aber er ist gut.

Mw E. schrieb:
> Daher ist das loop unrolling bei dieser Art Cache eigentlich von
> Vorteil?

Na eben nicht! Bei einer normalen Schleife passt vielleicht der ganze 
Code in den Cache, so kann die Schleife im günstigsten Fall ganz ohne 
Flash-Zugriff laufen. Eine ausgerollte Schleife passt ggf. eher nicht 
hinein und erfordert mehr Flash-Zugriffe. Sprünge kosten aber auch Zeit, 
die Prozessoren mit Branch Prediction (Cortex-M7!) reduzieren können. 
Letztlich hängt es vom Einzelfall ab und muss individuell gemessen 
werden.