mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32 Header


Autor: M. H. (mh555)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich stehe wie die Kuh vorm Uhrwerk. (Anfängerdepression nach Wechsel auf 
neuen Controller und Toolchain). Habe ein STM32L-Discovery und Atollic 
TrueStudio.

Jetzt wollte ich eine LED blinken lassen. Erstes Tutorial macht nach 
einer Initialisierung über ein Struct und GPIO_Init schließlich 
GPIO_WriteBit(GPIOB, GPIO_Pin_6, Bit_SET); Aber die ganzen Definitionen 
und Funktionen sind dem Compiler unbekannt.

Zweites Tutorial macht u. a. GPIOB->BSRR = GPIO_BSRR_BR_13; Aber auch 
hier steikt der Compiler.

Ich habe #include "stm32l1xx.h" am Anfang stehen.

Warum die unterschiedlichen Ansätze? Sind die Definitionen nicht 
einheitlich? Habe etwas von CMIS und HAL gelesen, aber ich habe keine 
Ahnung, was ich hier habe, bräuchte, haben will.

Hat jemand eine gute Einleitung für mich, welche unterschiedlichen 
Variablen-Definitionen es gibt, wo es Doku gibt und welche das 
TrueStudio verwendet haben will?

Vielen Dank

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. H. schrieb:
> Habe ein STM32L-Discovery
> Ich habe #include "stm32l1xx.h" am Anfang stehen.

Zum Glück gibt es ja nur das eine Discovery...

Autor: M. H. (mh555)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lutz schrieb:
> Zum Glück gibt es ja nur das eine Discovery...

Hmm? Wie man ein GPIO ansteuert und Register benannt sind hängt doch 
nicht vom Board ab.

Das Include kam jedenfalls heraus, als ich im New-Wizard mein Board 
ausgewählt habe.

Autor: Christopher Johnson (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. H. schrieb:
> Erstes Tutorial macht nach
> einer Initialisierung über ein Struct und GPIO_Init schließlich
> GPIO_WriteBit(GPIOB, GPIO_Pin_6, Bit_SET);

Das dürfte HAL sein

M. H. schrieb:
> Zweites Tutorial macht u. a. GPIOB->BSRR = GPIO_BSRR_BR_13; Aber auch
> hier steikt der Compiler.

Das ist mit "CMSIS-Header" direkt die Register beschrieben.

M. H. schrieb:
> Ich habe #include "stm32l1xx.h" am Anfang stehen.

In dem Header gibt es eine Unterscheidung welchen STM32L1 du denn jetzt 
hast, bzw. wofür das xx steht. Das musst du dann irgendwo per #define 
festlegen, sonst bleibt der Header nutzlos. Normalerweise macht man so 
etwas aber im Build-System. Ob TrueStudio das automagisch macht weiß ich 
nicht. Eventuell ist es nicht der Fall. Außerdem sind in dem Header noch 
Verweise auf Funktionen die du implementieren musst bzw. die du aus 
anderen .c-Dateien bekommst. Natürlich musst du die dem Build-System 
irgendwie mitgeben, sonst kann das nichts werden. Fest steht jedenfalls, 
dass "stm32l1xx.h" einen ganzen Rattenschwanz mit sich zieht und es 
meiner Meinung nach wichtig ist, zu wissen was wie wo zusammenhängt.

Hier mal am Beispiel eines STM32F103 wie da was eingebunden wird:

- stm32f1xx.h // bindet stm32f103xb.h ein (je nach definiertem Chip) und 
wenn gewünscht noch stm32f1xx_hal.h, ansonsten nur ein paar Makros
- stm32f103xb.h // der Hauptheader in dem sämtliche Register und 
sämtliche Bitmasken des STM32 definiert sind, bindet außerdem core_cm3.h 
und system_stm32f1xx.h ein
- system_stm32f1xx.h // enthält nur ein paar wenige Verweise auf externe 
Variablen und Funktionen (SystemCoreClock, SystemInit() und 
SystemCoreClockUpdate() )


ARM Cortex-M3 spezifische Header

- core_cm3.h // bindet wiederum core_cmInstr.h und core_cmFunc.h ein
- core_cmInstr.h // Core Instruction Access
- core_cmFunc.h // Core Function Access

Beim L1 hast du dann entsprechend kein core_cm3.h sondern ein 
core_cm0plus.h


Wenn du mal die Fehlermeldung des Compilers verraten würdest könnte man 
dir eventuell genauer sagen woran es scheitert. Meine Glaskugel ist 
leider derzeit nicht im Haus.


M. H. schrieb:
> Warum die unterschiedlichen Ansätze? Sind die Definitionen nicht
> einheitlich?

Nein sind sie nicht. In dem CMSIS-Header/Device-Header hast du für die 
einzelnen Peripherien Strukturen deklariert, die dann alle Register 
enthalten. Der Zugriff erfolgt über Peripherie->Register, wie z.B. 
GPIOB->BSRR auf das "Bit Set Reset Register" von GPIOB zugreift. 
TIM8->CCR3 wäre das "Capture-Compare Register 3" von Timer 8. Die 
Abkürzungen decken sich 1:1 mit denen im Reference Manual. Darüber 
hinaus gibt es noch #defines für die Bitmasken der Register.

Die HAL von ST geht da viel weiter und du hast für alles und jedes 
vorgefertigte Funktionen.

M. H. schrieb:
> Das Include kam jedenfalls heraus, als ich im New-Wizard mein Board
> ausgewählt habe.

Meiner Meinung nach ist es ein Fehler sich auf solche Wizards zu 
verlassen ohne zu verstehen, was da im Hintergrund eigentlicht passiert.

: Bearbeitet durch User
Autor: Stefan Us (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Schau Dir mal meine Notizen an, die werden Dir helfen: 
http://stefanfrings.de/stm32/index.html

Autor: M. H. (mh555)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Fehlermeldungen sind unspektakulär.

GPIOB->MODER &= ~GPIO_MODER_MODE13;
error: 'GPIO_MODER_MODE13' undeclared (first use in this function)

GPIO_InitTypeDef GPIO_LED;
error: unknown type name 'GPIO_InitTypeDef'

(Wenn ich die Includes öffne, sehe ich unter anderem "Could not 
initialize class edu.hawaii.ics.csdl.jupiter.model.review.ReviewModel", 
aber das hat wohl eher was mit TrueStudio zu tun.)

Christopher J. schrieb:
> Meiner Meinung nach ist es ein Fehler sich auf solche Wizards zu
> verlassen ohne zu verstehen, was da im Hintergrund eigentlicht passiert.

Ja aber doch nicht am ersten Tag, an dem ich eine LED blinken lassen 
will, um zu sehen, ob ich vom ATmega auf einen größeren Prozessor 
umsteigen kann/will. (Auch beim ATmega hab ich mich vor einigen Jahren 
nie um die Toolchain kümmern müssen. WinAVR mit dem Standard-Include und 
gut war. Damit hab ich sogar spaßenshalber Multithreading hingekriegt, 
durch Umbiegen von Stackpointer und Instruction-Pointer im Interrupt.)

Autor: Rene K. (xdraconix)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
M. H. schrieb:
> Ja aber doch nicht am ersten Tag, an dem ich eine LED blinken lassen
> will, um zu sehen, ob ich vom ATmega auf einen größeren Prozessor
> umsteigen kann/will.

Dann nutze das von ST empfohlene SW4STM. Da hatte du solche Probleme 
nicht.

Autor: Christopher Johnson (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. H. schrieb:
> Die Fehlermeldungen sind unspektakulär.
>
> GPIOB->MODER &= ~GPIO_MODER_MODE13;
> error: 'GPIO_MODER_MODE13' undeclared (first use in this function)
>
> GPIO_InitTypeDef GPIO_LED;
> error: unknown type name 'GPIO_InitTypeDef'

Vielleicht unspektakulär aber trotzdem nicht unnütz. Wie gesagt: In 
deinem stm32l1xx.h Header hast du so etwas wie
#if defined(STM32L100xB)
  #include "stm32l100xb.h"
#elif defined(STM32L100xBA)
  #include "stm32l100xba.h"
#elif defined(STM32L100xC)
  #include "stm32l100xc.h"
#elif defined(STM32L151xB)
  #include "stm32l151xb.h"
#elif defined(STM32L151xBA)
  #include "stm32l151xba.h"
#elif defined(STM32L151xC)
  #include "stm32l151xc.h"
#elif defined(STM32L151xCA)
  #include "stm32l151xca.h"
#elif defined(STM32L151xD)
  #include "stm32l151xd.h"
#elif defined(STM32L151xDX)
  #include "stm32l151xdx.h"
#elif defined(STM32L151xE)
  #include "stm32l151xe.h"
#elif defined(STM32L152xB)
  #include "stm32l152xb.h"
#elif defined(STM32L152xBA)
  #include "stm32l152xba.h"
#elif defined(STM32L152xC)
  #include "stm32l152xc.h"
// ...

Dann findest du z.B. in stm32l152xb.h
#define GPIO_MODER_MODER13_Pos               (26U)
#define GPIO_MODER_MODER13_Msk               (0x3U << GPIO_MODER_MODER13_Pos)  /*!< 0x0C000000 */
#define GPIO_MODER_MODER13                   GPIO_MODER_MODER13_Msk
#define GPIO_MODER_MODER13_0                 (0x1U << GPIO_MODER_MODER13_Pos)  /*!< 0x04000000 */
#define GPIO_MODER_MODER13_1                 (0x2U << GPIO_MODER_MODER13_Pos)  /*!< 0x08000000 */

https://github.com/modm-io/cmsis-header-stm32/blob...

Also würde ich es mal mit GPIO_MODER_MODER13 probieren, d.h. mit einem 
'R' mehr. Je nachdem wo du den Code her kopiert hast, ist es aber gut 
möglich, dass der trotzdem nicht läuft, weil die Register zwischen 
unterschiedlichen STM32 eben auch unterschiedlich sein können.

Hier findest du ein Tutorial für einfache GPIO-toggelei mit einem 
STM32F0:
http://hertaville.com/stm32f0-gpio-tutorial-part-1.html

Soweit ich das sehe sollte das 1:1 auf einen L1 übertragbar sein, da die 
GPIO-Register identisch sind.

GPIO_InitTypedef ist übrigens ein struct aus der "Standard Peripheral 
Library", was der Vorgänger von STs HAL ist und nicht mehr 
weiterentwickelt wird. Diese StdPeriphLib war im Gegensatz zur HAL 
jedoch direkt an die Registerdefinitionen aus dem CMSIS-Device-Header 
angelehnt, weshalb der ein oder andere Blick in ältere Artikel durchaus 
lohnen kann, z.B. 
https://www.mikrocontroller.net/articles/STM32F10x... 
.

PS:
Die Seite von Stefan Frings kann ich dir übrigens auch wirklich 
empfehlen:
http://stefanfrings.de/stm32/index.html

: Bearbeitet durch User
Autor: dasrotemopped (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>Dann nutze das von ST empfohlene SW4STM.
was ST so empfielt ist Deutungssache (siehe Bild).

Wegen der schwammigen uC Bezeichnung würde ich erst
mal grundsätzliche Fehler bei der Projekterstellung
vermuten und keine Schwäche der verwendeten Tools.

>Die Seite von Stefan Frings kann ich dir übrigens
>auch wirklich empfehlen.
Ich staune immer wieder, wie viel bei den ganzen Tutorials
noch von Hand eingestellt und verändert werden muss.  Ich
klicke mir meine Projekte mit der Maus zusammen und habe
bis jetzt noch nichts vermisst, was ein Mehr an Handarbeit
erfordern würde. Weder bei der Einrichtung der IDE noch der
Projekte muss was von Hand korrigiert werden.
CubeMX erzeugt das Projekt in meinem Projektordner und SW4STM32
importiert es anstandslos (Mausklick auf "ja, Projekt öffnen"
in CubeMX). Bei späteren Änderungen in CubeMX  wird das Projekt
aktualisiert und fertig.

>Hat jemand eine gute Einleitung für mich ?
CubeMX starten, Taste F1 drücken. Dann wird das UM1718 geöffnet.
Funktioniert mit allen IDEs, die im Bild oben zu sehen sind.

Gruß,

dasrotemopped.

Autor: Rene K. (xdraconix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dasrotemopped schrieb:
>> Dann nutze das von ST empfohlene SW4STM.
> was ST so empfielt ist Deutungssache (siehe Bild).

Ich gehe davon aus was ST empfiehlt und mit Sicherheit nicht was CubeMX 
empfiehlt.

Außerdem sind die hinlänglichkeiten von CMX hinreichend bekannt: 
Fehlerhafte Inits der GPIO, die Startroutinen der Timer werden nicht 
integriert, die Interrupts werden nicht gestartet oder sogar fehlerhaft 
integriert. Wenn man bloß eine LED blinken lassen will, Herrgott da ist 
man schneller mit selber schreiben.

Stefan Us hat oben ein Link gepostet. Folge diesen, da sieht man genau 
was ich meine. Und nen Tut für nen einfaches Blinky ist da auch zu 
finden.

: Bearbeitet durch User
Autor: Christopher Johnson (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dasrotemopped schrieb:
>>Die Seite von Stefan Frings kann ich dir übrigens
>>auch wirklich empfehlen.
> Ich staune immer wieder, wie viel bei den ganzen Tutorials
> noch von Hand eingestellt und verändert werden muss.  Ich
> klicke mir meine Projekte mit der Maus zusammen und habe
> bis jetzt noch nichts vermisst, was ein Mehr an Handarbeit
> erfordern würde.

Es gibt halt Leute die aus der AVR-Welt kommen und sich dann (zurecht) 
erstmal fragen warum ein dämliches Blinky 1,5kB RAM benötigt. Solchen 
Leuten ist dann mit einem Hinweis auf die Newlib-Nano schon 
weitergeholfen. Auch wie man sich ein Assemblerlisting ausgeben lassen 
kann oder wie man ITM als schnelle und trotzdem sparsame Debugausgabe 
nutzen kann, gehören meiner Meinung nach zum Handwerkszeug wenn es um 
Cortex-M geht. Das muss man alles nicht wissen, wenn man nur eine LED 
blinken lassen möchte aber nützlich und erwähnenswert finde ich das 
allemal.

Autor: dasrotemopped (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>Es gibt halt Leute die ... sich dann (zurecht) erstmal
>fragen warum ein dämliches Blinky 1,5kB RAM benötigt.
Ob das zurecht ist erschliesst sich mir nicht.
Wenn ich mit CPU Ressourcen nicht geizen muss, weil genug
Flash und RAM da ist und weil das System etwas komplexer ist
und dadurch die Initialisierung etwas aufwändiger wird ist das OK.
Ich sehne mich nicht zu dem ATtiny13A zurück, der 1k Flash
und 64Byte RAM hat.
Jetzt genieße ich den STM32F4/7 mit Megabyte Flash und 100en kByte RAM,
SDKarte als Massenspeicher usw. weil so viel mehr möglich ist. Trotzdem
kann ich für die neuen Verhältnisse sparsam programmieren.
Wenn ich allerdings meinen Programmierstil vom ATtiny13A beibehalte
habe ich nicht viel von der neuen Plattform, weil auch das 
Initialisieren
der Peripherie von der IDE übernommen wird und ich mich direkt der
eigendlichen Aufgabe widmen kann. Beim Atmega musste ich für den UART
die Register von Hand mit selbst ausgerechneten Initialisierungswerten
füttern. Jetzt gebe ich eine Baudrate vor und UART geht wie gewünscht.
Den freiwerdende Hirnschmalz stecke ich dann lieber in das richtige 
Bedienen
der neuen Tools, um schneller voranzukommen.
>ITM als schnelle und trotzdem sparsame Debugausgabe nutzen
Klar, das geht. Ich habe da aber meine Grafiklibs,
schliesse ein Display an den uC und habe sofort eine Textkonsole.
Kostet maximal 64 kB mit Font, aber Speicher ist ja genug da.
Kann mal ein ili9341 über SPI sein, mal auch etwas mehr,
wenn es die CPU hergibt.
Das Terminal im Bild belegt 3,1% der Ressourcen (65044 Byte von 2MB 
Flash).
Das ist doch akzeptabel, oder ? Zugriff auf die SD Karte mit FatFS
inklusive, sonst wäre ja das BMP Bild unkomprimiert in der Auflösung
nicht möglich. Der Text ist ein Overlay über das Hintergrundbild aus den
2 verschiedenen Fontgrößen 12x16 und 20x32.
>sind die hinlänglichkeiten von CMX hinreichend bekannt
Naja, keine Software ist perfekt, aber ich schaffe es trotzdem 
irgendwie,
ganz brauchbare Ergebnisse damit zu erzeugen.
>Wenn man bloß eine LED blinken lassen will,
>Herrgott da ist man schneller mit selber schreiben.
Ich nicht, CubeMX ist beim Erstellen des Projektcodes schneller
als ich tippen kann.

Gruß,

dasrotemopped.

Autor: Stefan Us (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich stehe mit CubeMX auf Kriegsfuß denn schon mein erste Programm mit 
diesem Tool funktionierte nicht.

CubeMX erzeugte eine fehlerhafte Initialisierung des Systemtaktes. Der 
Fehler war allerdings so gut versteckt, daß ich ihn direkt vor meinen 
Augen stehend trotzdem nicht erkannt habe.

Andererseits kommt man als Hobbyprogrammierer wohl kaum um irgendein 
Framework (sei es Cube HAL oder Arduino oder was auch immer), wenn man 
den USB Port nutzen möchte.

Ich hatte mich mal sehr tief in Ethernet reingefuchst, das mache ich 
heute auch nicht mehr. Der Zeitaufwand (von vielen Monaten bis Jahren) 
ist einfach zu hoch. Da wirst du links und rechts von anderen billigeren 
und besseren produkten überholt. Was am Anfang noch innovativ und 
lohnenswert erscheint, ist schon zwei Jahre später für 5 Euro fertig bei 
Ebay zu haben.

Autor: Alex W. (a20q90)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
korrektur

Autor: dasrotemopped (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich stehe mit CubeMX auf Kriegsfuß denn schon
>mein erste Programm mit diesem Tool funktionierte nicht.
Mein erstes Programm auch nicht. Dann bin ich aber besser geworden,
ebenso wie CubeMX. Jetzt sind wir beide unzertrennlich.
Aber wie in jeder Beziehung gibt es Höhen und Tiefen.

>CubeMX erzeugte eine fehlerhafte Initialisierung des Systemtaktes.
Auch mit aktuellen Versionen ? (4.22, Stand heute, nutze CubeMX seit 
2013)
Ist mir noch nie passiert. Der umgekehrte Fall in einem Projekt schon.
Die Kollegen, die alles von Hand machen wollten, da CubeMX ja so buggy
ist hatten den Clock für USART falsch eingestellt und dadurch
Übertragungsfehler. War natürlich ein Hardwarefehler auf meinem 
Boarddesign.
Allerdings waren auch alle Eval Boards davon betroffen, so wurde es zum
Bug im Prozessor, bis eine CubeMX Konfiguration den Fehler im falschen
Multiplikator / Prescaler Zusammenspiel entlarvte. Mit den Settings aus
CubeMX verschwand dann der Hardwarebug magischerweise.

>Da wirst du links und rechts von anderen billigeren und besseren
>Produkten überholt.
Das Rad nicht neu erfinden wollen ist die Devise. IDEs, Libs und 
Frameworks
sollen einen davon abhalten, jedes Mal bei 0 anzufangen. Nur weil man 
etwas
selbst kann, heißt das nicht, das das nicht schon längst von jemand 
anders
erledigt wurde.

Gruß,

dasrotemopped.

Autor: mh555 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite mich (wenn ich Zeit habe) von Vorschlag zu Vorschlag.

Stefan U. schrieb:
> Schau Dir mal meine Notizen an, die werden Dir helfen:
> http://stefanfrings.de/stm32/index.html

Das sieht sehr gut aus!

Ich scheitere – als jemand, der noch die Eclipse verwendet hat – schon 
an diesem Schritt:
1. Lege mit dem Assistenten der IDE das eigentliche Arbeitsprojekt mit 
der Option "No Firmware" an. Unter File > New habe ich "C Project" 
gewählt und dann finde ich nirgends ein "No Firmware".

Autor: Christopher Johnson (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh555 schrieb:
> Ich scheitere – als jemand, der noch die Eclipse verwendet hat – schon
> an diesem Schritt:
> 1. Lege mit dem Assistenten der IDE das eigentliche Arbeitsprojekt mit
> der Option "No Firmware" an. Unter File > New habe ich "C Project"
> gewählt und dann finde ich nirgends ein "No Firmware".

Stefan Us nutzt meines Wissens kein Atollic TrueStudio, sondern 
SW4STM32.
http://www.openstm32.org/HomePage

Da musst du dich allerdings - wie bei Atollic auch - registrieren um die 
IDE herunterladen zu können.

dasrotemopped schrieb:
>>Es gibt halt Leute die ... sich dann (zurecht) erstmal
>>fragen warum ein dämliches Blinky 1,5kB RAM benötigt.
> Ob das zurecht ist erschliesst sich mir nicht.
> Wenn ich mit CPU Ressourcen nicht geizen muss, weil genug
> Flash und RAM da ist und weil das System etwas komplexer ist
> und dadurch die Initialisierung etwas aufwändiger wird ist das OK.
> Ich sehne mich nicht zu dem ATtiny13A zurück, der 1k Flash
> und 64Byte RAM hat.
> Jetzt genieße ich den STM32F4/7 mit Megabyte Flash und 100en kByte RAM,
> SDKarte als Massenspeicher usw. weil so viel mehr möglich ist.

Die Frage die man sich dann zunächst stellt ist doch: "Hier lasse ich 
eine LED blinken und habe einen Verbrauch von 1,5kB RAM. Brauche ich 
dann für ein Programm was den zehnfachen Umfang eines Blinky hat 15kB?" 
Der L152CB hat mitunter nur 16kB von dieser kostbaren Ressource. 
Letztens kam einer mit einem SAMD mit 4kB RAM, der durch das linken 
gegen die Newlib-Nano immerhin 25% seines RAMs wieder zur Verfügung 
hatte. Auch wenn es im Hobbybereich keinen Sinn macht am Controller zu 
sparen finde ich es durchaus angebracht zu Wissen wo die Ressourcen 
hingehen.


dasrotemopped schrieb:
>>ITM als schnelle und trotzdem sparsame Debugausgabe nutzen
> Klar, das geht. Ich habe da aber meine Grafiklibs,

Das mit den Grafiklibs ist ja schön und gut aber nicht immer 
praktikabel. Will man einen Haufen Werte vom AD-Wandler an den PC 
schicken kann man das per ITM schön und komfortabel erledigen. Im 
Gegensatz zum UART können auch immer 32bit Wörter geschrieben werden und 
man kann ITM dazu bewegen ein UART-kompatibles NRZ-Signal auszugeben. 
Dann hängt man noch einen USB-UART-Konverter an den TX-Pin des 
Prozessors und kann mit 2MBaud Daten loggen, ohne dass es den Prozessor 
interessiert. Aber eigentlich ist das hier auch alles komplett OT.

: Bearbeitet durch User
Autor: mh555 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, im letzten Schritt erst.
File > New > C Project > Executable > Ac6 STM32 MCU > ... > No Firmware 
> Finish

Autor: dasrotemopped (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>Aber eigentlich ist das hier auch alles komplett OT.
Erschreckend richtig.

Darum habe ich mal für das STM32L-Discovery ein Projekt aufgesetzt.
PB6 -> LED_Blue
PB7 -> LED_Green
PA0 -> Button_Blue -> EXT-IRQ0
PA13 -> SWDIO
PA14 -> SWCLK
PB3  -> SWO ist leider belegt durch SEG3 LC-Display, darum deaktiviert

Mit der Binary sollten die LEDs blinken,
das Projekt ist für SW4STM32, das CubeMX Projekt ist ebenfalls 
enthalten.
STM32L152RBT_LEDs.ioc mit CubeMX öffnen und auf Atollic umstellen und 
gut ist. Habe das Board nicht selbst, darum alles im Blindflug erstellt.

>Da musst du dich ... registrieren um die IDE herunterladen zu können.
Nein !
http://www.ac6-tools.com/downloads/SW4STM32/

Autor: dasrotemopped (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der STM32L152RBT hat 128kB Flash und 16kB RAM,
das Projekt belegt kompiliert
- auf Größe optimiert 6556 Byte
- auf maximale Geschwindigkeit 6944 Byte
Das Blinky mit aller Initialisiertung des uCs braucht also ca 5%
des Flash. Das wächst jetzt nicht weiter proportional so
mit jedem Pin, den man aktiviert.

Gruß,
dasrotemopped.

Autor: Stefan Us (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> CubeMX erzeugte eine fehlerhafte Initialisierung des Systemtaktes.
> Auch mit aktuellen Versionen ?

Nein, der Fehler wurde wenige Tage danach behoben.

Autor: mh555 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@dasrotemopped

Suuuper! Funktioniert!
Jetzt hab ich endlich eine Basis, um mich langsam voranzutasten.

Die Initialisierung für einen GPIO hatte ich inzwischen auch von Hand 
hingekriegt. (Aber ewig nicht bemerkt, dass man nach dem Flashen noch 
auf Reset drücken muss.)

Und der ganze Initialisierungscode kommt von CubeMX? Was musstest Du 
denn noch von Hand nacharbeiten? Der Interrupthandler? Die 
Initialisierung des Interrupts in GPIO_Init sieht mir auch so auch, als 
könnte Sie von Dir sein :-)

Autor: dasrotemopped (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Suuuper! Funktioniert!
Freut mich zu hören.

Das habe ich in das CubeMX Projekt von Hand eingefügt:
in Datei stm32l1xx_it.c:

uint16_t ticker = 0;

if(ticker == 0){
HAL_GPIO_WritePin(LED_Blue_GPIO_Port,LED_Blue_Pin,GPIO_PIN_SET);
HAL_GPIO_WritePin(LED_Green_GPIO_Port,LED_Green_Pin,GPIO_PIN_RESET);
}
if(ticker == 499){
HAL_GPIO_WritePin(LED_Blue_GPIO_Port,LED_Blue_Pin,GPIO_PIN_RESET);
HAL_GPIO_WritePin(LED_Green_GPIO_Port,LED_Green_Pin,GPIO_PIN_SET);
}

ticker++;
if(ticker>999){ticker=0;}

alle anderen Dateien sind unverändert geblieben und wurden von CubeMX 
erzeugt.

Gruß,

dasrotemopped.

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.

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