Druckbare Version
Da es eine günstige Gelegenheit war, habe ich mir, für die noch kommenden langen Winterabende, ein STM32F0-Discopvery erstanden. Hat wer Erfahrungen wo/womit ich mich im Web oder Buchhandel mein Wissen darum erweitern kann. Mir geht es hauptsächlich um Steuerungen...der vielen I/O Pins wegen ;)
Gruss
Gerhard
Hoffentlich kommt (hier bei uns) erstmal der Sommer.Zitat:
... für die noch kommenden langen Winterabende, ein STM32F0-Discopvery erstanden ...
Ich habe seit einiger Zeit ein STM32F4DISCOVERY hier rumliegen. RUMLIEGEN! Es ist ja total schick, schon in der Demo begeistern mich z.B. die Beschleunigungsmesser usf. Soviel Elektronik auf so wenig Platz für sooo wenig Moos. Und diese vielen Anschlüsse, die hohe Taktrate, 32 Bit, 12bittige ADs und DAs, Timer mit 16 und 32 Bit, 3 I²Cs, 4 USARTs - und so weiter. Einfach fast ALLES was das Herz begehrt.
Diese vielen Möglichkeiten und Anschlüsse brauchen auch viel und vielerlei Kenntnisse. Das Datenblatt ist - soweit ich mich erinnere - an die tausend Seiten, ein paar hundert alleine über die Timer. Und die IDE dazu habe ich noch immer nicht installiert. Es fehlte mir der Mut in diese komplexe ARM-Architektur und -Software einzusteigen, trotz "... A large number of free ready-to-run application firmware examples are available ..." . Klar, C ist C, aber Hardwarenähe ist beim ARM etwas komplexer als bei den popeligen 8bittigen Atmels . . .
Ich bin gespannt ob Du das im ersten Winter schaffst - vielleicht hänge ich mich dann dran.
Hallo OAG !
ich glaube da hat uns beiden das selbe bewegt dort zuzugreiffen..viel Anwendungsmöglichkeiten für wenig Moos....Habe auch erst mal die 40 Seiten User-Manual ausgedruckt...
Ja wegen dem Sommer, da ist wohl Petrus seine Klima-HDD fragmentiert und er geht nur Cluster, für Cluster mit dem Wetter der Reihe nach..nicht nach den Fragmenten... ;)
Ich habe erst mal die Entwicklungsumgebung von Keil, nutz ich ja auch für AT89C51 u.ä. in C ..anders herrum, andere Leute lösen Kreutzworträtsel ich C Anwendungen und anstatt für Fussball & Co. Geld auszugeben kaufe ich eben Hardware.. ;)
Ja ich werde sehen was sich da machen lässt, erst mal habe ich noch nicht die Zeit mich da durchzukämpfen bis in die kleinsten Register....
Gruss
Gerhard
Also ich nutze seit einiger Zeit auch STM32. Mit dem DiscoverBoard hatte ich beruflich zu tun. Zuhause spiele ich gerade mit einem NucleoF103RB und FreeRTOS herum.
Als IDE nutze ich Em::Blocks. Kostenlos und fast so umfangreich wie das AtmelStudio. Nur 100x weniger Resourcenverbrauch und 10x so schnell.
STM32s in C programmieren ist echt ein Kinderspiel. ST liefert hierfür die SPL (Standard Periperal Library). Die ist echt ein Traum. Kein lästiges Bitschubsen mehr und trotzdem sehr gute Performance, da alles in C geschrieben ist. Und alles kleines Extra liegen sogar noch haufenweise Beispiel-Codes bei. Warum habe ich das nicht früher entdeckt....?
mfg
Das gleiche Ding hab ich auch noch rumzuliegen. Zusammen mit der edelsten Lochrasterplatine die ich je gesehen habe.Ich kam bisher auch nicht dazu, mich in die ARM-Welt einzuarbeiten. :(
Wenn jemand von euch da weiter ist würde ich mich um Berichterstattung sehr freuen. Um nur Rumzuliegen ist das Teil dann doch zu schade.
Dann hört mal bitte her - oderlachs und White_Fox: mal ein vorsichtiger Vorschlag: Wir arbeiten uns gemeinsam in das Ding ein. Also so ne Art offline-Tutorial als Selbststudien-Vorhaben. Als Leitfaden für uns Anfänger könnte sicher das hier dienen. Wenn man das zeitgleich macht, kann man sich bestimmt auch helfen.Zitat:
Zitat von White_Fox
Anfangstermin ist ja klar, "Winter" - so ungefähr. Zumindest nicht in den nächsten Wochen/Monaten, da habe ich schon zeitliche Planung(en).
Thema001: Eine LED blinken lassen - was sonst.
Viel mehr will ich erstmal nicht vorschlagen. Der Umfang bietet ja schon mal genug Arbeit: Download der IDE - die Wsk8 vorgeschlagen hat, danke schon mal - Einrichten eines Projekts, Einarbeiten in die Chose und los geht der Zug zum Blinken. Das oben verlinkte Tutorial gibt ja schon etliche Hilfen für Anfänger.
Was meint Ihr dazu?
Der Vorschlag hört sich gut an. Also ich wäre dabei. :)
Ich würde zwar lieber Netbeans als IDE vorschlagen, aber da das Tut nunmal mit diesem EM-Dingens arbeitet werde ich mich damit anfreunden. Als Thema002 würde ich, (aufbauend auf 001 natürlich ;)) die Erweiterung der Blink-LED zu einem PWM-Dimmer vorschlagen.
PS: Warum erst auf lange Winterabende warten...graue Herbst-Wochenend-Nachmittage können auch recht öde sein. ;)
Hallo W_F !
Natürlich gibt es auch graue Herbsttage, aber ich persönlcih habe da noch Dinge von der "Sommerpause" aufzuarbeiten, soweit man das Hobby als "Arbeit" bezeichnen darf.. ;)
Hätten wir noch richtigen Winter, ginge es tagsüber hinaus in die Weisse Natur und abends ermüdet ins Bett, aber ein richtiger Winter ist ja auch schon ne Rarität...
Ich habe mich also erst mal mit Keil AVR/ARM/51 ausgestattet, natürlich die Freeware mit ein paar KB für die Code...die kaufversion steht zu keiner Realität der Verwendung bei mir.
Em::Blocks habe ich auch , sehe da nun gar nicht durch...noch nicht...und CoCox weiss ich nicht, muss mich da erst Registrieren...
Mir persönlich wäre KeilARM angenehme, da ich dort schon in der 51er Version (8051) ein bischen gearbeitet habe...
Na ja , die hauptsache ist das man was draus machen kann aus dem Board, wie das ist dann noch offen für mich, nur sollte es "Zeh" sein, ASM habe ich fast seit der C64' er Hoch-Zeit nicht mehr "gehämmert"...
Aber es hat Spass gemacht für Geos-Anwendungen Grafik/Icons Bittweise zu "zeichnen" ...nee tippen. ;)
Gerhard
Ich finde ja, ASM muß jeder mal programmiert haben der programmieren lernen will. Aber für ARMs würde ich mir das auch nicht antun wollen, wenn man das auf einem 8-Bit-Käfer kann reicht das. Ich würde auch C vorschlagen. Muß mich da auch erst wieder etwas reinarbeiten, habe C bisher nur unter Windows angewendet und muß erstmal sehen was bei Mikrocontrollern dann alles anders ist.
Aber noch was zur IDE: Dann würde ich doch lieber vorschlagen, als Konsens dieses EM-Dingens zu verwenden. Keil ist mir aus zwei Gründen unsymphatisch: Einmal entweder Beschränkung oder Kauf, wobei ich das Geld auch nicht ausgeben kann und würde, also bleibt auch mir nur, mit der Beschränkung zu leben. Wobei ich das nicht einsehe, da es wirklich gute Open-Source- bzw. Freeware-IDEs gibt (Netbeans, Eclipse, EM-Dingens).
Zweitens habe ich mir (u.a. von einem Prof an meienr Uni) sagen lassen, das Keil im Vergleich mit anderen IDEs auch nicht so der Bringer ist. Warum also mit Beschränkung leben?
Außerdem habe ich noch die Möglichkeit, Visual Studio vollständig zu nutzen, instaliert habe ich es auch noch. (Student sein hat seine Vorteile. ;)) Eine weitere IDE kann ich von daher auch nicht wirklich gebrauchen.
Da das Tut nunmal mit EM-hastenichjesehn arbeitet wäre es insofern ganz sinnvoll damit anzufangen, da das in dem Tut auch ganz gut erklärt zu sein scheint. Wenn wir sicher genug sind kann ja jeder zu seiner Lieblings-IDE umsteigen.
Nun ja ich will mich an Keil nicht festhalten, aber für meine kleinen AT89x5x Versuche war das bestens, zumal es da kaum auf Codegrösse ankam zum lernen und Verstehen, ich hatte/Habe da ein MCU-8051 zu liegen und 2..3 Chips die ich mal testen wollte, das ging für mich da mit Keil am besten...
Ich denk aber wenn mein "Brett vorm Kopp" bei EM::Blocks entfernt ist komme ich damit auch klar und man kann /möchte ja lernen....Nein es ist heute als Hobbyprogger nicht mehr nötig sonst was für Software auszugeben, weil es genügend FreeCode gibt.
Wenn ich da noch an meine Taschengeldverlust zu Zeiten von Delphi1,2,3 usw.. denke , so schnell konnte keiner Sparen..
Gerhard
Hallo!
Ich bin gleicher Meinung ! :)Zitat:
Zitat von White_Fox
Aber nur solche davon, für die "Hex" schon wie "Dec" ist. Ich habe früher PC CPU's (von 80186 bis Pentium) umfangreich in ASM programmiert. Deshalb denke ich, dass "Umstieg" von 8-bittigen µC's auf z.B. 32-bittige CPU's etwas schweriger wäre. :confused:
Gewiss , gewiss..schon alleine der ASM Befehlsvorrat dürfte schon "etwas" umfangreicher sein...
Ich bin gerade dabei meinem Board ein wenig Linux , oder besser Linux die Verbindung mit dem STM32 beizubringen. da muss ich erst mal im Web recherchieren..
Na vielleicht hat wer ' ne Hilfestellung für mich in Sachen Linux? Da bin ich ja nun schon zig Jahre so "aktiv" raus...
Gerhard
Ist bei den ARMs eigentlich schon Division und Fließkomma-Arythmetik-Unterstützung mit eingebaut, oder erwarte ich da zuviel von den Prozessörchen?
Div/Mult ist normal hardwareseitig unterstützt. FPU gibts nur ab Cortex M4.Zitat:
Zitat von White_Fox
mfg
- - - Aktualisiert - - -
Zur Vorgehensweise:
- Ihr braucht Emblocks.
- STLink Utility
- Standard Peripheral Library für eure Prozessorserie für die Beispiel. (F0, F1, ...)
Beide Programme installieren.
In Emblocks dann hier noch ein Tool zum flashen der Hex einrichten. (Debuggen funktioniert auch ohne, aber man will ja irgendwann mal ohne Debugger starten :p)
http://www.emblocks.org/wiki/tutorials/f401_f429_disco/release_target#add_load_hex_tool
Hier müsst ihr normal nur diesen 1 Schritt machen.
Das Tutorial auf Microcontroller.net find ich jetzt teils nicht ganz so toll, da ziemlich viel unnötiges aufgeführt ist.
Im Prinzip müsst ihr bei dem Project Wizard nur euren Prozessor einstellen (in dem Tut gut erklärt) und den Hacken bei "Enable Semihosting" setzen. Sonst würde ich da gar nichts ändern.
Schon könnt ihr euer erstes Programm schreiben und den Debugger starten. Da ist wirklich nichts dabei.
mfg
Musik in meinen Ohren. Denn bei mir liegt ist das STM32F4DISCOVERY Board, da steht in der Kurzbeschreibung "... STM32F407VGT6 microcontroller featuring 32-bit ARM Cortex-M4F core, 1 MB Flash, 192 KB RAM in an LQFP100 package ...". Und ich hoffe, dass das "F" im M4F kein Downsizing-Zusatz ist. Da sehe ich fast schon, dass ich (wieder mal) Rechenzeiten von transzendenten Funktionen messen werde.Zitat:
Div/Mult ist normal hardwareseitig unterstützt. FPU gibts nur ab Cortex M4 ...
Das Board hatte ich ja zur Seite gelegt . . . weil . . . aber Deine Rede macht ja wirklich Mut. Ich hoffe nur, dass ich nicht übermütig werde und mich überstürzt da reinhänge. Denn - erst ist noch mein Archie dran, der soll auf einen halbwegs passablen Zustand gebracht werden. Übrigens hatte ich genau dieses Disco-Board eigentlich für das Projekt Archie gekauft und bin dann eben auf die mir halbwegs bekannten 8Bitter von Atmel als I²C-UART-Teamworker ausgewichen. Vor allem - weil ich von mehreren Seiten vor der Komplexität der ARMs gewarnt wurde.
Alles nur Nullen und Einsen...kein Hexenwerk. ;)Zitat:
Vor allem - weil ich von mehreren Seiten vor der Komplexität der ARMs gewarnt wurde.
So habe ich mir komplexe Thematiken in Informatik-Kursen bisher immer kleingeredet um nicht an der Komplexität der Dinge zu verzweifeln. Ich hoffe, das klappt bei dir auch.
Aber die arythmetischen Fähigkeiten der ARMs klingen auch zu gut...was man damit alles anstellen kann...*lechz*...vielen Dank für die Infos Wsk8. :)
Bringst mich auf eine Idee, ich hab ja auch noch so eine Taschenuhr förmige, echt russische Stoppuhr zu liegen... ;) Nein mit sowas befasse ich mich nicht....Zitat:
Zitat von oberallgeier
Die Tools sind schon Installiert...bis auf das Flashen, gleich via EM::Blocks..danke für den Tipp Wsk8 !!
Das ist ja schon fast ein Tutorial, danke. Nun habe ich mal eine Frage/Bitte: Üblicherweise sichere ich bei Platinen mit aufgespielten Demos die Firmware (hex, EEPROM, Fuses, etc) - damit ich mal später, wenn mal wieder etwas nicht läuft, nachsehen kann ob wenigstens die Demo unverändert läuft. Deswegen würde ich die Demo erstmal sichern - und das ohne jegliche Ahnung wie ich das machen soll.Zitat:
Zitat von Wsk8
Daher meine Bitte um eine Liste der Arbeiten - wirklich für Dummies - mit denen ALLE Modifikationen auf meinem STM32F4DISCOVERY Board gesichert werden (können). Danke im Voraus.
Zitat:
Zitat von oderlachs
Wie stehts bei Euch um dieses Projekt? Seid ihr vorbereitet?Zitat:
Zitat von White_Fox
Ich habe bisher nix dazu vorbereitet (ausser dem STM32F4 discovery board das hier schon über ein Jahr liegt) - aber vielleicht könnten wir gemeinsam drangehen? Jeder an seine Sache natürlich, aber der Einstieg ist sicher prinzipiell ähnlich - ich denke da an das Posting oben von Wsk8. Und wenn wir jetzt so langsam die Rechner einrichten, sind wir nach dem GEschenke auspacken und der Silvesterparty bereit für neue Horizonte!
Hallo Oberall... !
Leider habe ich wegen zZt. häuslicher Verpflichtungen kaum gross Zeit für solche Sachen...bin noch nebenbei dabei von Win auf Linux umzusteigen, da muss man sich erst einfuchsen..es ist eigendlich nur die Arduino-Programmierung was ich bislang 100%ig da vollbracht habe. Alles Andere kann ich zwar unter Linux Code schreiben..compilieren, muß aber unter Win dann, den Code in den Chip flashen....
Ich habe da Code:Blocks und Geany..aber so recht will es mir nicht gelingen...schliesslich muss der "Professor" ja auch noch mitbekommen was ich ihm befehlen möcht.
nach dem HDD Crash sind auch meine vorherigen Linux-Anleitungen mit ins Nirvada verschwunden...also es braucht noch seine Zeit.
Gruss der Oderlachs ;)
Vorbereitet habe ich auch noch nix, aber ich habe es zumindest nicht vergessen.
Meine "langen Winterabende" bestehen zur Zeit vor allem darin, lange in der Uni beschäftigt zu sein. :(
Ich werde in den nächsten Tagen aber mal besagte Codeschreibumgebung bei mir installieren. Außerdem hat ein Kommilitone von mir mit den Dingern viel zu tun, die programmieren den Käfer bei sich auf Arbeit, sodass er notfalls auch andere fragen kann. Der hat (so wie ich) vorher auch 8-Bit-Käfer in ASM programmiert, aber nun nimmt er auch nur noch STM32....
Also zumindest scheitert es nicht daran, jemanden fragen zu können. Und hier im Forum gibt es ja auch noch Leute.:)
Hallo,
bin vor einigen Tagen zufällig über diesen Thread gestolpert und dachte mir, ich frage mal nach, ob ihr was macht oder nicht? Hab selbst mein STM32F4Discovery Board gestern bekommen und bin schon fleißig am experimentieren. Da wärs natürlich toll, wenn man sich mit anderen Leuten austauschen könnte, ist eben doch was anderes als die kleinen 8bit Avrs.
Ich arbeite mit EM:Blocks, hab mir aber auch CoIDE runtergeladen, das gefällt mir aber nicht so gut (bzw. stürzt auch öfters mal ab).
Gruß
Chris
Ich bin leider auch in den Wintertagen im "Haushalt" eingespannt...sitze wegen dem Umzug auch schon so wie auf gepakten Koffern.
Des Weiteren habe ich noch arge Probleme unter Linux, bin umgestiegen, meine Seriellen Ports nutzbar zu machen.., d.h. ich konnte plötzlich nicht mehr auf einen ser.Port zugtreifen...
Werde warscheinlich ne komplette neue Installation machen müssen, das Rumexperimentieren hängt mir klangsam zum Halse raus...
EM::Block kenne ich so nicht aus der Praxis, vom Namen her ja...
Ich nutze Keil Vision mit 30KB begrenzung, da es ja ich ja nur hobbymässig programmiere..so ist die Vollversion zu teuer, wird aber sein Geld wert sein.
Gruss
Gerhard
Die nächste Saison der "langen Winterabende" steht ja nun an. Wollen wir es nochmal anpacken? Ich jedenfalls habe jetzt definitiv ein Projekt für einen derartigen Rechenknecht.
Ich studiere grad das Datenblatt des STM32. Man, das Teil ist ja wirklich komplizierter als die 8-Bit-Tröten...aber ich bin gespannt was das Teil kann. Das Teil verfügt intern über zwei getrennte unterschiedliche Bussysteme, die auch noch unterscheidlich schnell takten (ich rede vom STM32-F446) und eine interne Echtzeituhr, die Sekunde, Minute, Stunde, usw direkt als Dezimalwerte speichert und sogar Schaltjahre selbstständig berechnet. Mal sehen, vielleicht wird das recht nützlich um Vorgänge zu parallelisieren.
Hallo W-F !
Ich muss erst mnal ganz ganz kurz treten in Sachen Hobby. Habe einen Wohnungsumzug hinter mir...Das Hobby ist zZt. noch verpackt und lagert in Garage/Keller. Leider habe ich nicht mehr so viel Stauraum in meinem Hobbyzimmer wie vorher. Da muss ich langsam harrausfinden was wichtig ist und was wo hinkommt....
Auch muss ich mich mal vom Überflüssigem trennen, aber es will nicht so recht duch das "Sieb laufen" was vielleicht überflüssig ist.. ;)
Na ja vieleicht schaffe ich es ja das ST32 weiter zu erforschen...habe aber zur Zeit nicht mal dafür einen Anschluss am PC...noch Platz auf dem Tisch, bin auch noch beim Verkabeln.
Beste Grüsse
aus dem nasskalten Oderlande
Gerhard
Meine Güte, dein Umzug dauert dann ja jetzt schon reichlich ein Jahr...dann wünsche ich dir mal hurtiges Gelingen deiner Umzugsanstrengungen.
Ich werde meine Fortschritte dann aber trotzdem hier reinstellen...vielleicht nutzt es dir oder jemand anderem ja später.
Behörden, Ämter und sonstige Bremsen...im Sept. 14 die Zusage und ab Sept. 15 konnten wir in die Wohnung, eben der Osten, da braucht keiner Miete da stehen die Wohnungen leer... Na ja nun füllt man sie mit Asylanten auf...
Gerhard
Da ich grad Ernst mache...ist es normal, das Em::Blocks jetzt EmBitz heißt?
Mal noch was anderes...hat jemand ne Ahnung, wie ich die Bibliotheken von ST für den F446 in EmBitz einbinden kann? Nicht nur in einem einzelnen Projekt, sondern so daß ich die gleich in einem neun Projekt zur Verfügung habe?
Also das weiss ich nicht , vielleicht mal Tante Google befragen. Ich arbeite fast nur noch unter Linux und Geany, macht sich einigermaßen gut, solange man keine eigenen Libraries mit einbinden möchte, ins projekt. Das habe ich noch nicht geschnallt wie es geht...
Nun ist bald wieder gartenarbeit, dann ist der Spass bald zu ende mit dem Basteln Programmieren, jedenfalls im grossen Umfange...
Frohe Ostern und einen fleissigen Osterhasen wünsche
Gerhard
Danke, dir auch ein schönes Osterfest. :)
Google hat mir noch nichts brauchbares ausgespuckt. Ich hab jetzt ein Nucleo mit nem STM32-F446 mit diversen Zusatzboards. Es gibt unzählige Möglichkeiten den STM32 zu programmieren. Die meisten beruhen auf irgendeinem Eclipse-Verschnitt mit irgend einem Plug-In und allerhand Konfigurationsarbeit. Mit ebenso viel negativen Kommentaren mit diesen Eclipse-Verschnitten. Wenn ich daran denke daß ich schon einen halben Nachmittag gebraucht habe um bloß die Firmware vom ST-Link zu aktualisieren halte ich mich davon lieber fern. Ich will programmieren, nicht konfigurieren.
Die Cube von ST wollte ich auch vermeiden...zuviel Klickibunti, ich will auch etwas davon verstehen wie der STM32 arbeitet.
Ich kann die EDU-Version vom J-Link (und damit das Embedded Studio von Segger) nutzen, aber ich kann keine Schnittstelle für einen externen Debugger am Nucleo finden. :(
Ich hab jetzt EmBlitz installiert, das scheint mir recht ordentlich zu sein. Die Oberfläche erinnert ich an die vom Visual Studio, aber wie gesagt, obige Frage steht immer noch im Raum...
Also...ich hab meinen ersten STM32-Erfolg eingefahren. Die grüne LED auf dem Nucleo-Board leuchtet. :)
Als IDE hab ich das Embedded Studio von Segger verwendet, ich programmiere mit dem J-Link- Für den nucleo-eigenen STLink gibts was zum draufflashen, damit der auch als J-Link dient. Die Hardware besteht aus einem Nucleo-64-Board mit einem STM32-F446RE.
Zuerst hab ich das entsprechende Package (STM32-F4xx) installiert. Embedded Studio hat einen sog. Package-Manager, der das bewerkstelligt. Im Package sind die notwendigen Bibliotheken enthalten. Danach war erstmal Datenblattlesen dran. Wichtig ist die "STM32F446 Reference". Dort werden fast alle notwendigen Register erklärt die benötigt werden, um die Ports zu konfigurieren. Hier lauern auch schon die ersten Fallen. Die Peripherie (dazu zählen auch die Ports) müssen noch an die Taktversorgung angeschlossen werden, sonst tut sich nix. Dies muß übrigens auch noch VOR der eigentlichen Registerkonfiguration geschehen. Die zweite Falle ist: Das Bit für die LED soll, wie ich von einem freundlichen USer erfahren habe, besser NICHT über das output-Data-Register (ODR) geschehen, sondern über BSRR.
Der entsprechende Thread ist hier:
https://www.roboternetz.de/community...e-zur-C-Syntax
Noch ein Tip zur Entwirrung:
Embedded Studio erstellt sofort ein kleines "Hello-World-Projekt zum Einstieg für euch. Im Prinzip ist das eine Schleife, in der eine Variable n 100-mal hochgezählt und zusammen mit einem "Hello World" ausgegeben wird. Die Ausgabe geschieht mit einer Funktion printf();
Nun ist das Nucleo-Board ja nur mit ner lumpigen LED und nem Taster ausgerüstet und nicht mit einem LCD oder so. Die printf()-Funktion sendet die Daten über den J-Link an den Debugger. Der gesendete Inhalt wird in einem kleinen Fenster unten in der Mitte angezeigt. Zum Fehlersuchen wird das später bestimmt sehr nützlich.
Das ist der Code von meinem ersten Programm:
Code:#include <stdio.h>
#include <stdlib.h>
#include <stm32f446xx.h>
void main(void) {
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN; //Taktversorgung Port A
GPIOA->MODER |= (GPIO_MODER_MODER5_0); //A5 => Ausgang
GPIOA->OTYPER &= ~(GPIO_OTYPER_OT_5); //A5 0> Push-Pull
GPIOA->PUPDR &= ~(GPIO_PUPDR_PUPDR5); //A5 ohne Pullup-Pulldown
printf("Einstellung fertig\n");
GPIOA->BSRR |= GPIO_BSRR_BS_5; //Ausgang A5 setzen
printf("LED gesetzt\n");
while(1){
}
}
Mein zweites Programm. Dieses Mal wird noch der Button mit einbezogen.
Die LED wid eingeschaltet, solange der Knopf gedrückt ist.
Code:#include <stdio.h>
#include <stdlib.h>
#include <stm32f446xx.h>
void configLed(){
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN; //Taktversorgung Port A
GPIOA->MODER |= (GPIO_MODER_MODER5_0); //A5 => Ausgang
GPIOA->OTYPER &= ~(GPIO_OTYPER_OT_5); //A5 0> Push-Pull
GPIOA->PUPDR &= ~(GPIO_PUPDR_PUPDR5); //A5 ohne Pullup-Pulldown
}
void configButton(){
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOCEN; //Taktversorgung Port C
GPIOC->MODER |= GPIO_MODER_MODER0_0; //C13 => Eingang
GPIOC->PUPDR |= GPIO_PUPDR_PUPDR13_1; //C13 => Pulldown einschalten
}
void main(void) {
configLed();
configButton();
printf("Einstellung fertig\n");
while(1){
if(!(GPIOC->IDR & GPIO_IDR_IDR_13)){
GPIOA->BSRR |= GPIO_BSRR_BS_5; //Ausgang A5 setzen
printf("Knopf gedrückt\n");
}
else{
GPIOA->BSRR |= (GPIO_BSRR_BR_5); //Ausgang A5 zurücksetzen
printf("Knopf nicht gedrückt\n");
}
}
}
Edit:
Noch eine Frage...gibt es in C eigentlich die Möglichkeit, ein Bit direkt zu kopieren? In Pseudocode ausgedrückt:
Sodaß ich mir das If-Statement sparen könnte.Code:PA5 == PC13;
Hallo,
Müsste lauten:Code:GPIOA->BSRR |= (GPIO_BSRR_BR_5); //Ausgang A5 zurücksetzen
Code:GPIOA->BSRR &= ~(GPIO_BSRR_BR_5); //Ausgang A5 zurücksetzen
Nur wenn du die Ports als Bitfelder definierst.Zitat:
Noch eine Frage...gibt es in C eigentlich die Möglichkeit, ein Bit direkt zu kopieren?
Allerdings spielen dann noch einige compilerspezifische Dinge mit rein.
MfG Peter(TOO)
Sicher? Immerhin funktioniert der Code klaglos.
Code:GPIOA->BSRR |= GPIO_BSRR_BS_5; //Ausgang A5 setzen
Ich hatte das jetzt als "Bit rücksetzen" interpretiert. Ob das auch funktioniert wenn ich eine 0 ins BS-Register schreibe probiere ich gleich mal aus...Code:GPIOA->BSRR |= (GPIO_BSRR_BR_5); //Ausgang A5 zurücksetzen
Edit:
Nein, das funktioniert nicht. Das wird zwar ohne Klagen kompiliert, die LED geht dann aber nicht mehr aus.