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!
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
Gast
#1983513
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.
Gast
#1983531
Sorry falscher Lnk!! http://www.hitex.com/index.php?id=850 Anmelden und guide herunterladen. Fand ich nich schlecht! MfG
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!
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:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
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
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).
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.