STM32 Anfänger

[Matze T. (gruetzwurschd)]

Hallo Leute,

Ich muss/will mich in die Materie der ARM Cortex M3 prozessoren von ST 
einarbeiten.

Ich hab mir schon die Hilfe-Artikel hier auf der Webseite durchgelesen. 
Und auch die Foren habe ich durchforstet. Aber ich habe zum Thema STM32 
noch ein paar fragen.

Ich habe hier auf meinen Tisch folgendes liegen:
-Segger J-Link
-PC mit einer kommerziellen Lizenz vom Rowley Cross Studio
-Ein Evaluationboard vom Typ STM3210E-Eval

Ich hab jetzt auch die Demo-Progrämmchen von ST auf das Board 
draufgebrannt und geschafft das die LED's blinken.

Jetzt geht es daran, die ersten kleinen Programme selber zu schreiben.

Ich habe mir Über den Package-Manager das Package für den STM32 
installiert.

Meine fragen sind:
-Was hat es mir gebracht das Package zu installieren?

-Für die STM32 bietet ST eine stdperiph lib und eine USB-FS... lib. Muss 
ich nun die darin enthaltenen dateien in irgendeinen library ordner vom 
Rowley kopieren, oder muss ich, sobald ich beispielsweise den ADC 
verwenden will die entsprechenden Dateien in den Projektordner Kopieren 
und sozusagen "vor ort" einbinden mittels #include"..."

-Wie sieht das "minimalprogramm" aus um eine LED zum leuchten zu 
bringen, bzw. einen Pin auf high, bzw auf low zu setzen.

Bitte habt bisschen Nachsicht mit meinen evtl. "dummen" fragen. Ich 
komme aus der 8 und 16 bit ecke von atmel und microchip. ARM's sind für 
mich absolutes Neuland.

Danke für eure Hilfe im Voraus

Grüße Tarkan

PS: Ich habe die anderen Controller in ANSI C programmiert. Ein Umstieg 
von C auf C++ scheint mir in diesem Kontext Ratsam. Daher beim Helfen 
bitte von einem C++ "nicht-profi" ausgehen :) Danke!

[Matze T. (gruetzwurschd)]

Hallo Leute,

trotz intensiver beschäftigung mit dem Thema komme ich auf keinen grünen 
Zweig.

Weiß jemand wo man sich vielleicht ein kleines Tutorial dafür ansehen 
kann? Ich bin echt am verzewifeln!!

Grüße Tarkan

[R. A. (Gast)]

http://www.mikrocontroller.net/articles/STM32

[Matthias K. (matthiask)]

In der Stdperiph Lib sind viele Beispiele drin und auch Projektvorlagen 
(Templates) für unterschiedliche IDE/Systeme. Da kannst Du Dir den 
Grund-Aufbau eines Projektes rausnehmen.

Ansonsten hier:
http://www.mikrocontroller.net/articles/Kategorie:STM32
Beitrag "STM32 und Rowley CrossStudio"

>Ich habe die anderen Controller in ANSI C programmiert.
Das ist gut und sollte auch bei den STM32 so bleiben.

> Ein Umstieg >von C auf C++ scheint mir in diesem Kontext Ratsam.
Nicht zu empfehlen, die M3 werden fast ausschließlich in ANSI C 
programmiert, C++ ist erst ab ARM9 zu empfehlen.

[R. A. (Gast)]

Sorry falscher Lnk!!

http://www.hitex.com/index.php?id=850

Anmelden und guide herunterladen. Fand ich nich schlecht!

MfG

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Wichtig:

Wenn man mit gcc eine C-Datei mit dem Dateiname "MeinCode.C" kompilliert 
wird diese als C++ erkannt. Wenn der Dateiname "MeinCode.c" ist, so wird 
diese als C Datei kompilliert.

Merke: Endungen von Dateinamen immer klein schreiben!

[Matze T. (gruetzwurschd)]

Hallo Leute,

danke für die Antworten. Ich habe mich jetzt noch intensiver mit der 
Library auseinandergesetzt.

Ich hab es auch zum kompilieren bekommen, indem ich alles in einen 
Ordner reinkopert habe und den Preprozessor angeweisen habe dort 
ebenfalls nach headerdateien zu suchen. Außerdem habe ich alle C-dateien 
in mein Projekt eingebunden.
desweiteren war es nötig die datei stm32f10x_conf.h sobald ich die datei 
zusätlich einbinde lässt es sich kompilieren.

was mich interessieren würde wäre, was hat der folgende code zu 
bedeuten:

/* Exported types ------------------------------------------------------------*/
/* Exported constants --------------------------------------------------------*/
/* Uncomment the line below to expanse the "assert_param" macro in the 
   Standard Peripheral Library drivers code */
// #define USE_FULL_ASSERT    1 

/* Exported macro ------------------------------------------------------------*/
#ifdef  USE_FULL_ASSERT

/**
  * @brief  The assert_param macro is used for function's parameters check.
  * @param  expr: If expr is false, it calls assert_failed function
  *   which reports the name of the source file and the source
  *   line number of the call that failed. 
  *   If expr is true, it returns no value.
  * @retval None
  */
  #define assert_param(expr) ((expr) ? (void)0 : assert_failed((uint8_t *)__FILE__, __LINE__))
/* Exported functions ------------------------------------------------------- */
  void assert_failed(uint8_t* file, uint32_t line);
#else
  #define assert_param(expr) ((void)0)
#endif /* USE_FULL_ASSERT */

#endif /* __STM32F10x_CONF_H */

sobald ich die zeile

// #define USE_FULL_ASSERT    1

auskommentiere funktioniert alles. Wenn ich die zeile im code habe lässt 
es sich nihct kompilieren.

Danke für eure antworten
gruß Tarkan

[Simon H. (simi)]

Matthias K. schrieb:
>> Ein Umstieg >von C auf C++ scheint mir in diesem Kontext Ratsam.
> Nicht zu empfehlen, die M3 werden fast ausschließlich in ANSI C
> programmiert, C++ ist erst ab ARM9 zu empfehlen.


Warum denn das? Was spricht gegen C++? Der Overhead kann's schon mal 
nicht sein, der ist nämlich marginal (vorausgesetzt, man wird nicht 
übermütig).

[Simon H. (simi)]

Wegen dem // #define USE_FULL_ASSERT    1 :

Wenn Du das definierst, dann definierst Du ein Makro:

  #define assert_param(expr) ((expr) ? (void)0 : assert_failed((uint8_t 
*)__FILE__, _LINE_))

Also: Jedesmal, wenn Du im Code

assert_param(x>0)

schreibst, ersetzt der Compiler (nö, der Preprozessor) Dir das in einen 
Aufruf von

assert_failed()


In dieser Routine kannst Du nun irgendwas programmieren, das z.B. eine 
Fehlermeldung auf Deinem Supidupi-OLED-Bildschirm (den Du mal an Deinem 
Gerät dran haben wirst :-) ausgibt:
"Fehler auf Zeile 4523 von main.c! Eine Assertion ist nicht 
eingetreten!"
(obiges Beispiel assert_param(x>0) würde z.B. in einer sqrt-Funktion 
Sinn machen).

Natürlich musst Du die Methode aber noch schreiben! Ist dann praktisch 
für Debugging, und beim Release kannst Du USE_FULL_ASSERT dann wieder 
wegnehmen, um Overhead zu reduzieren.