STM32F4-Discovery Keil startup code

mikeR Gast 19.04.2013 23:51 #3134765

Lesenswert?

•

Hi,

ich habe gerade angefangen mich mit dem STM32F4-Discovery Board zu 
beschäftigen und nutze dafür Keil. Nun ist mir aufgefallen das Keil im 
Startup code nur eine Stack-Size von 0x00000400 also knapp 1k angibt und 
der Heap nur halb so groß ist.

Nun hat der Prozessor aber 192k Ram und irgendwie scheinen mir die oben 
genannten Settings komisch.

Frage habe ich was falsch gemacht habe den STM32F407VG gewählt weil es 
keinen STM32F407VGT6 gab aber vermute das T6 steht für das Package...


Oder hat jemand ein vernünftiges Sample für den Startupcode?

Danke schonmal,

lg mike

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Ersi (cell85) 20.04.2013 12:05 #3135034

Lesenswert?

•

▲
▼

Bootloader größe?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

mikeR Gast 20.04.2013 18:21 #3135445

Lesenswert?

•

▲
▼

Wie meinst du sind das nur STACK und HEAP für den Bootloader? ist das 
nicht fix im chip integriert?

lg mikeR

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Daniel F. (daywalker) 20.04.2013 18:46 #3135469

Lesenswert?

•

▲
▼

Hi,

ich arbeite beruflich mit Keil und 0x400 scheint die 
Standard-Stack-Größe zu sein im Startup-Code oder Scatter-File.

Da ich von Hand etwas optimieren muss, habe ich mir einen Teil des SRAMs 
aufgeräumt und gewisse statische/globale Variablen dort feste 
reingelegt.
Mit

1	`U32 fastBuffer[128] __attribute((at(0x00200800))`

 legst du das Array "fastBuffer" feste an die Speicherandresse 0x200800.

So kann man auch einen Teil des SRams nutzen. Wenn du einen 
Stackoverflow hast, solltest du ihn natürlich vergrößern.

Ich bring das Scatter-File zwar eher mit dem SDRam in Verbindung, aber 
du kannst vielleicht auch dort angeben, dass gewisse Routinen im SRam 
landen. Da würde ich natürlich nur etwas reinlegen, was fast immer und 
andauernd benötigt wird.

Schöne Grüße
Daniel

Antwort Zitieren Bearbeiten Löschen Beitrag melden

mikeR Gast 20.04.2013 22:39 #3135759

Lesenswert?

•

▲
▼

Thx für die Erklärung,

Frage was passiert mit dem Restlichen code ich hab schon gesicht was/wo 
der Ausführbare code hingeladen wird müsste ja auch im RAM sein oder? 
Wie funktioniert das beim STM32F407VGT6 oder wird der direkt vom Flash 
ausgeführt?

lg

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Moritz M. (moritz_m35) 21.04.2013 00:06 #3135837

Lesenswert?

•

▲
▼

Hallo,

ist das nicht in Words angegeben? Steht in meinem Startup-Code 
jedenfalls so drin (CoIDE). Also 4kB. Ich verwende immer 0x200 also 2kb.

Außerdem hab ich vor einiger Zeit ein kleines StdFramework zusammen 
gestellt.
Alle Konfigurationen können über eine Config-Header erldigt werden.

Moritz

Angehängte Dateien:

STM32F4xx_StdFramework_V1.0_2013_04_03.zip (365 KB)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

mikeR Gast 22.04.2013 07:13 #3137058

Lesenswert?

•

▲
▼

HI

danke das scheint wirklich hilfreich zu sein aber eine Frage hätte ich. 
Ich habe niergenst einen export von heap lables gesehen werden diese 
nicht benötigt? Brauch kein Teil der Libc diese?


lg

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Steel Gast 22.04.2013 07:57 #3137075

Lesenswert?

•

▲
▼

Man verwendet bei embedded Software normalerweise keinen Heap. Man 
verwendet kaum Stack. Der Code wird direkt aus dem Flash ausgeführt. Das 
sind alles so Sachen die uC Programmierung von PC Programmierung 
unterscheiden.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

mikeR Gast 22.04.2013 10:55 #3137246

Lesenswert?

•

▲
▼

Steel schrieb:
> Man verwendet bei embedded Software normalerweise keinen Heap. Man
> verwendet kaum Stack. Der Code wird direkt aus dem Flash ausgeführt. Das
> sind alles so Sachen die uC Programmierung von PC Programmierung
> unterscheiden.

An der verwendung von Stack kommst du nicht vorbei. (Funktions aufrufen 
dafür ist der ja da)

bei nem 168mhz  uc mit 192kb ram macht für mich der heap schon Sinn is 
ja kein Atmega8

lg

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Choose Gast 22.04.2013 11:03 #3137257

Lesenswert?

•

▲
▼

Beschäftige dich lieber mit Coocox ;-)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Steel Gast 22.04.2013 11:42 #3137303

Lesenswert?

•

▲
▼

mikeR schrieb:
> An der verwendung von Stack kommst du nicht vorbei. (Funktions aufrufen
> dafür ist der ja da)

Darum schrieb ich KAUM.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

mikeR Gast 22.04.2013 14:31 #3137532

Lesenswert?

•

▲
▼

Choose schrieb:
> Beschäftige dich lieber mit Coocox ;-)

Jo klingt interessant habs mal runter geladen.


@ Steel du wirst KAUM ein Programm schreiben das keinen Stack benötigt 
generell ist das ein extrem wichtiges Element.

lg

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Martin T. (mthomas) Moderator 22.04.2013 18:58 #3137850

Lesenswert?

•

▲
▼

mikeR schrieb:
> danke das scheint wirklich hilfreich zu sein aber eine Frage hätte ich.
> Ich habe niergenst einen export von heap lables gesehen werden diese
> nicht benötigt? Brauch kein Teil der Libc diese?

Stack: Die libc eher nicht, da der normalerweise verwendete Stackpointer 
bereits im Startup-Code gesetzt wird (erster Eintrag in der 
Vektortabelle).
Heap: Zur Konfiguration der dynamischen Speicherverwaltung gibt es in 
der libc (eigentlich sind es mehrere) von ARM zwei Ansätze, für 
"normale" libc und die sogen. microlib. Die Dokumentation sollte beide 
beschreiben (Suchbegriffe: __MICROLIB und __user_initial_stackheap). 
Beim letzten Mal schauen, waren auch beide Ansätze in den MDK-ARM 
Beispielen für STM32F4 implementiert. Im Forum bei keil.com wird man 
mehr potentielle Antworter finden.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Matthias Gast 29.04.2013 12:26 #3145918

Lesenswert?

•

▲
▼

Die definierten Grössen fuer Stack und Heap sind relativ klein gewählte 
Defaults. Beide sollten für die eigene Applikation natürlich noch 
angepasst werden.
Der Stack ist natürlich notwendig. Allerdings wird in einem modernen 
Design die Reservierung und Verwaltung der/des Stack(s) einem 
RTOS-Kernel überlassen. Dann sind sogar die 1024 Byte noch viel zu 
grosszügig bemessen.

Heap ist auch auf einem schnelleren Mikrocontroller mit mehr Speicher 
nach Möglichkeit zu vermeiden. Nur weil man mehr Performance hat muss 
man die nicht durch dynamische Speicherverwaltung wieder zum Fenster 
rauswerfen.
Am schnellsten bleiben statisch reservierte Puffer und Variablen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

STM32F4-Discovery Keil startup code

Antwort schreiben