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
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...
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.
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
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.)
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.
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
1 | #if defined(STM32L100xB)
|
2 | #include "stm32l100xb.h" |
3 | #elif defined(STM32L100xBA)
|
4 | #include "stm32l100xba.h" |
5 | #elif defined(STM32L100xC)
|
6 | #include "stm32l100xc.h" |
7 | #elif defined(STM32L151xB)
|
8 | #include "stm32l151xb.h" |
9 | #elif defined(STM32L151xBA)
|
10 | #include "stm32l151xba.h" |
11 | #elif defined(STM32L151xC)
|
12 | #include "stm32l151xc.h" |
13 | #elif defined(STM32L151xCA)
|
14 | #include "stm32l151xca.h" |
15 | #elif defined(STM32L151xD)
|
16 | #include "stm32l151xd.h" |
17 | #elif defined(STM32L151xDX)
|
18 | #include "stm32l151xdx.h" |
19 | #elif defined(STM32L151xE)
|
20 | #include "stm32l151xe.h" |
21 | #elif defined(STM32L152xB)
|
22 | #include "stm32l152xb.h" |
23 | #elif defined(STM32L152xBA)
|
24 | #include "stm32l152xba.h" |
25 | #elif defined(STM32L152xC)
|
26 | #include "stm32l152xc.h" |
27 | // ...
|
Dann findest du z.B. in stm32l152xb.h
1 | #define GPIO_MODER_MODER13_Pos (26U)
|
2 | #define GPIO_MODER_MODER13_Msk (0x3U << GPIO_MODER_MODER13_Pos) /*!< 0x0C000000 */ |
3 | #define GPIO_MODER_MODER13 GPIO_MODER_MODER13_Msk
|
4 | #define GPIO_MODER_MODER13_0 (0x1U << GPIO_MODER_MODER13_Pos) /*!< 0x04000000 */ |
5 | #define GPIO_MODER_MODER13_1 (0x2U << GPIO_MODER_MODER13_Pos) /*!< 0x08000000 */ |
https://github.com/modm-io/cmsis-header-stm32/blob/master/stm32l1xx/Include/stm32l152xb.h#L2987 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_Standard_Peripherals_Library . PS: Die Seite von Stefan Frings kann ich dir übrigens auch wirklich empfehlen: http://stefanfrings.de/stm32/index.html
:
Bearbeitet durch User
Angehängte Dateien:
-
STM32L.png
82 KB
>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.
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
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.
Angehängte Dateien:
>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.
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.
>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.
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".
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
Ah, im letzten Schritt erst. File > New > C Project > Executable > Ac6 STM32 MCU > ... > No Firmware > Finish
>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/
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.
>> CubeMX erzeugte eine fehlerhafte Initialisierung des Systemtaktes. > Auch mit aktuellen Versionen ? Nein, der Fehler wurde wenige Tage danach behoben.
@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 :-)
>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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.