Hallo, brauche mal wieder eure Hilfe.
Ich habe mir ein ST Nucleo F103RB Board gekauft und habe damit
(erfolglos) experimentiert.
Ich verwende folgenden Code (aus einem Tutorial von Youtube von
UltraFx):
1
#include"stm32f10x.h"
2
3
intmain(void)
4
{
5
RCC->APB2ENR|=0x04;
6
7
GPIOA->CRL=0x200000;
8
9
uint32_tcheck=0;
10
11
while(1)
12
{
13
GPIOA->BSRR=0x20;
14
15
for(check=0;check<20000000;check++){
16
;
17
}
18
19
//GPIOA->BRR = 0x20;
20
21
//for(check = 0; check < 20000000; check++);
22
}
23
}
Nun blinkt die LED nicht (auch wenn ich den auskommentierten Teil wieder
einkommentiere), und so geht sie auch nicht an, wenn man ganz genau
hinsieht, dann leuchtet sie mit vielleicht 1% Helligkeit.
Mit LED meine ich immer die onboard grüne "User- LED".
Was mache ich denn falsch?
Danke für jede Hilfe.
Peter H. schrieb:> Was mache ich denn falsch?
Das du "magic numbers" nutzt. Nutze die defines, statt irgendwelcher
Zahlen, die können schneller falsch sein als man denkt.
Ja hast du vollkommen recht, würde man natürlich machen.
Nun ist es aber so, dass ich den Code kopiert habe, und derjenige der
das Tutorial gemacht hat das selbe Board wie ich benützt.
Da die LED bei ihm blinkt gehe ich davon aus, dass die Zahlen stimmen,
ich habe eigentlich die for Schleife im Verdacht...
Peter H. schrieb:> Da die LED bei ihm blinkt gehe ich davon aus, dass die Zahlen stimmen,> ich habe eigentlich die for Schleife im Verdacht...
Warum? Zumindest sollte die LED an sein, wenn du das Blinken
auskommentiert hast.
Jetzt muss ich doch mal fragen.
Immer wieder tauchen schon beim Blinky diese "geht nicht" Fragen auf.
Was habt ihr eigentlich mit den Dingern vor? Wie soll es weiter gehen?
Die andere Hardware im µC ist ein wenig umfangreicher als ein
Pin-Wackler.
Wollt ihr wirklich jedes Bit zusammen fragen?
Ich denke, wer etwas ernsthaftes mit den µC anstellen will, sollte die
angebotene Hilfestellung in Form von HAL in Anspruch nehmen.
Wer wirklich jedes Bit verstehen will, kann auch später von dort aus
seine Forschungen starten.
Peter H. schrieb:> for(check = 0; check < 20000000; check++) {> ;> }
Willkommen in der Welt der C-Optimierung.
Nachdem check nicht volatile ist, wird ein schlauer Compiler
feststellen, dass die Schleife zu nichts gut ist und sie einfach
wegoptimieren.
Im Resultat glimmt deine LED, weil sie mit "Vollgas" getoggelt wird.
In dem obigen Beispiel wird die LED nicht einmal getoggelt, egal ob die
Schleife noch im Aufgabe-File ist oder nicht.
Hier wird der Ausgang einfach nur auf High gesetzt.
Ich habe den Code wie oben abgeändert.
Nun hätte ich mir erwartet, dass die LED an bleibt.
Wenn ich mit dem Debugger schrittweise gehe, dann geht die LED an, lasse
ich das Programm laufen glimmt sie.
Also muss ich da irgendwo einen gewaltigen Denkfehler haben...
Kann mich vielleicht doch jemand aufklären was ich hier falsch mache?
Steppe ich mit dem Debugger über die Zeile
GPIOA->BSRR = 0x20;
geht die LED an,
lasse ich das Programm laufen glimmt sie....
Ist denn dein Takt schon richtig konfiguriert wenn der da so schnell auf
die Pins losgeht? Ich würde da einfach Mal zwischen jeden Schritt ein
paar Pausen einbauen und gucken ob es dann geht.
Oder vielleicht Steps du Mal nicht komplett durch und machst einen
breakpoint erst in der Schleife und guckst dir dann Mal die Register an.
Peter H. schrieb:> Nun ist es aber so, dass ich den Code kopiert habe, und derjenige der> das Tutorial gemacht hat das selbe Board wie ich benützt.>> Da die LED bei ihm blinkt gehe ich davon aus, dass die Zahlen stimmen,
Dann ist das Turial scheiße. So eine chaotische Schlamperei gewöhnt man
Neulingen gar nicht erst an.
> Warum verwendest Du nicht die SPL von ST?
Vielleicht, weil STM selbst darauf hinweist, dass man sie nicht mehr
verwenden soll? Die ist seit ein paar Jahren deprecated!
Aber die richtige Antwort hatte er ja schon geschrieben:
> Ich verwende folgenden Code (aus einem Tutorial von> Youtube von UltraFx)> Nun ist es aber so, dass ich den Code kopiert habe> Dann ist das Turial scheiße.
Ja.
Habe den Code nochmal geändert, damit die while Schleife was zu tun hat.
Steppe ich durch (also auch x mal über das inkrementieren von check)
bleibt die LED an.
Lasse ich das Programm laufen glimmt sie.
Wenn ich wieder auf Pause gehe, ist das Programm immer irgendwo in der
nähe des Inkrementierers.
Ich bin ratlos ;-)
Peter H. schrieb:> Lasse ich das Programm laufen glimmt sie.>> Wenn ich wieder auf Pause gehe, ist das Programm immer irgendwo in der> nähe des Inkrementierers.
Und dann leuchtet sie wieder?
Setz mal nen Breakpoint an den Anfang der main(), evtl. wird er durch
irgendwas resettet, dann müsste er wieder oben in der main vorbeikommen?
Watchdog vielleicht?
Falsche (zu hohe) Takteinstellungen können ebenfalls zu crash und/oder
Reset oder sonstigem aberwitzigen Verhalten führen, hatte ich selbst
auch mal (F401RE), da wollte er dann bei nem Sprung am Ende der Loop
stattdessen an eine vollkommen absurde nicht-existierende Adresse
springen, hat ne Weile gedauert bis ich ihn im Debugger genau an der
Stelle erwischt habe wo das machen wollte.
