Forum: Mikrocontroller und Digitale Elektronik STM32F334: CCM Speedup


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Michael H. (overthere)


Bewertung
1 lesenswert
nicht lesenswert
Hallo,

der STM32F334 hat 64MHz, aber der Flash kommt nicht bei häufigen 
Sprüngen nicht nach und braucht daher 2 Waitstates wenn er springt. Bei 
72MHz zugar 3.

Jetzt habe ich mal nachgemessen wieviel Vorteil es bei einer iterativen 
Routine gibt: 1.09ms mit CCM und 1.57ms ohne CCM für max=10000

Mein persönliches Fazit: Es bringt etwas, häufig genutzen Code dahin zu 
verfrachten.

Edit: Mir ist bewusst, dass die funktion keinen Sinn macht...
uint64_t sumup(int max){
  int a=0;
  while(max>0){
    a=max;
    max=max-1;
   }
  return a;
}

: Bearbeitet durch User
von Samuel C. (dragonsam)


Bewertung
1 lesenswert
nicht lesenswert
Ich würde deinen Post gerne verstehen, weil es an sich ein interessantes 
Thema ist. Leider finde ich deine Sätze ziemlich unverständlich.

> der STM32F334 hat 64MHz, aber der Flash kommt nicht bei häufigen
> Sprüngen nicht nach und braucht daher 2 Waitstates wenn er springt. Bei
> 72MHz zugar 3.
Vor'm abschicken bitte selbst noch durchlesen.
Definiere häufig.

> Jetzt habe ich mal nachgemessen wieviel Vorteil es bei einer iterativen
> Routine gibt: 1.09ms mit CCM und 1.57ms ohne CCM für max=10000
Vorteil gegenüber was?

> Mein persönliches Fazit: Es bringt etwas, häufig genutzen Code dahin zu
> verfrachten.
Wohin zu verfrachten?

von ./. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> Vorteil gegenüber was?
> Wohin zu verfrachten?

Ich hab den Post von Michael verstanden.
Allerdings hatte ich auch schon STM32 die ein CCM hatten in den Fingern.

von Diode (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dann mache doch nicht so spannend: Es geht darum, Code aus dem Flash ins 
interne RAM zu verlagern und den Code-Fetch dadurch zu beschleunigen.

von Uwe Bonnes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
_C_ore _C_oupled _M_emory:
Extra RAM Bereich, der nur von der CPU angesprochen werden kann.

von Stefan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das CCM hängt soweit ich weiß am D-Bus. Wenn da Code liegt ist der 
Zugriff darauf etwas umständlich bzw. der "Havard Vorteil" des 
simultanen Zugriffs auf Code und Daten geht verloren. Die STM32F7 haben 
noch zusätzlich 8kB die am I-Bus hängen. Die STM32F3 haben aber keinen 
Cache Controller. Daher ist der "CCM Code" wohl dennoch schneller.

Ich hatte mal Versuche mit Funktionen im RAM auf einem STM32F405 
gemacht. Da war die Ausführung einer Funktion aus dem Flash bei 168MHz 
etwas schneller als aus dem CCM. Das war übrigens keine Schleife sondern 
eine (Timer) ISR in der am Anfang und am Ende eine LED getoggelt wurde. 
Die CPU hat in der Zwischenzeit anderen Code ausgeführt.

Aber klar, es kommt immer auf die konkrete Anwendung an.

von Michael H. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Samuel C. schrieb:
> Ich würde deinen Post gerne verstehen, weil es an sich ein
> interessantes Thema ist. Leider finde ich deine Sätze ziemlich
> unverständlich.
Ich arbeite gerade am Literaturnobelpreis. :P
>
> der STM32F334 hat 64MHz, aber der Flash kommt nicht bei häufigen
> Sprüngen nicht nach und braucht daher 2 Waitstates wenn er springt. Bei
> 72MHz zugar 3.
>
> Vor'm abschicken bitte selbst noch durchlesen.
> Definiere häufig.
Code schaun? Unten? Im Prinzip bei jeder interation.
>
> Jetzt habe ich mal nachgemessen wieviel Vorteil es bei einer iterativen
> Routine gibt: 1.09ms mit CCM und 1.57ms ohne CCM für max=10000
>
> Vorteil gegenüber was?
Core coupled memory vs. Flash
>
> Mein persönliches Fazit: Es bringt etwas, häufig genutzen Code dahin zu
> verfrachten.
>
> Wohin zu verfrachten?

Ccm. Geht über den Befehl section in dem function prototype. Allerdings 
muss der Startupcode modifiziert werden.

von Michael H. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke  Stefan für die gute Erklärungen!

von Michael H. (overthere)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe gerade nochmal nachrecheriert, daher ein kleine Ergänzung zu 
Stefans Posts:

Stefan schrieb:
> Das CCM hängt soweit ich weiß am D-Bus. Wenn da Code liegt ist der
> Zugriff darauf etwas umständlich bzw. der "Havard Vorteil" des
> simultanen Zugriffs auf Code und Daten geht verloren. Die STM32F7 haben
> noch zusätzlich 8kB die am I-Bus hängen. Die STM32F3 haben aber keinen
> Cache Controller. Daher ist der "CCM Code" wohl dennoch schneller.
Der CCM ist am gleichen Bus wie der Flash. Siehe Anhang. Also dadurch 
entsteht keine Verzögerung.

>
> Ich hatte mal Versuche mit Funktionen im RAM auf einem STM32F405
> gemacht. Da war die Ausführung einer Funktion aus dem Flash bei 168MHz
> etwas schneller als aus dem CCM. Das war übrigens keine Schleife sondern
> eine (Timer) ISR in der am Anfang und am Ende eine LED getoggelt wurde.
> Die CPU hat in der Zwischenzeit anderen Code ausgeführt.

Wenn man nicht springen muss im Flash (ganz böse Zungen sagen 
"Spagetticode"), dann kann der MCU soweit ich weiß ja die Daten 
vorladen. Und da muss er keine Waitstates einlegen. [Bin mir hier aber 
nicht 100% sicher.]

von Irgendwer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> Wenn man nicht springen muss im Flash, dann kann der MCU soweit ich weiß ja die 
Daten vorladen.

Dafür ist ab dem Cortex-M3 sowas hier vorhanden um euch bei Sprüngen die 
Daten vorzuladen:
http://en.wikipedia.org/wiki/Branch_predictor
Nur manchmal wird halt "falsch geraten" und dann dauert es einige Takte 
bis die Pipeline wieder gefüllt ist.

von Stefan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Stefan schrieb:
>> Das CCM hängt soweit ich weiß am D-Bus. Wenn da Code liegt ist der
>> Zugriff darauf etwas umständlich bzw. der "Havard Vorteil" des
>> simultanen Zugriffs auf Code und Daten geht verloren. Die STM32F7 haben
>> noch zusätzlich 8kB die am I-Bus hängen. Die STM32F3 haben aber keinen
>> Cache Controller. Daher ist der "CCM Code" wohl dennoch schneller.
> Der CCM ist am gleichen Bus wie der Flash. Siehe Anhang. Also dadurch
> entsteht keine Verzögerung.

Ist dieses "CCM-SRAM" nicht der neue Block im STM32F7? Im Refman vom 
STM32F40x/41x/42x/43x nennt sich das "CCM data RAM" und hängt laut 
Skizze nur am D-Bus.

von asdf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan schrieb:
> Ist dieses "CCM-SRAM" nicht der neue Block im STM32F7?

Nö, CCM gibts schon länger z.B. im STM32F4 u.a.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.