Ich hab jatzt die ersten Schritte mit meinem STM32F4 Discovery gemacht. Also IDE einrichten und GPIO. Womit würdet ihr mir empfehlen, weiter zu machen? Also zum Beispiel Timer oder UART. Es söllte möglichste noch einfach sein, bei der Hitze... Es wäre nett, wenn ihr zu denn vorgeschlagenen Themengebiet noch einen Link zu einer guten Anleitung hinzupackt. Danke im voraus.
Hast du denn nicht IRGENDEIN Ziel? Hast du wenigstens eine Idee? Also irgend etwas, das du damit bauen willst? Irgend ein Gerät mit einem Nutzwert? Oder zu welchem Zwecke befaßt du dich mit dem Discovery? Irgendeinen Sinn sollte das ganze "sich beschäftigen" doch haben - und den kannst nur DU uns hier benennen. Erwarte doch bitte nicht, daß andere dir deine Ideen einflößen, das kann keiner. Also frag ich erstmal: Was kannst du? Und wo willst du hin? W.S.
W.S. schrieb: > IRGENDEIN Ziel? Eben das sorgt auch für die Langzeit-Motivation. Aber ohne Ziel, ohne konkrete Anwendung kann auf den Hype nur Frust folgen, insbesondere nachdem dem ARM-Einstieg eine steile Lernkurve folgt.
OK, dann setz ich mir als Ziel: Einen MAX 168 per SPI auslesen und das Ausgelesene Zeug per UART an PC weitergeben, villeicht spendier ich ihm auch ein nettes LabView-Interface. Dann such ich nur noch das Tutorial für UART bzw. SPI. Mit Demos ist bei mir nichts, da komm ich nicht wirklich dahinter.
Peter K. schrieb: > Mit Demos ist bei mir nichts, da komm ich nicht > wirklich dahinter. Welche IDE verwendest du? Das Discovery hat nen eigenen Debugger (ST-Link) drauf, du kannst dir mal von www.keil.com die MDK-ARM Demo runterladen, da hast du schöne einfache Beispiele für dein Board, und mit den 32kB solltest du ne ganze Weile hinkommen. Arbeitet man ohne Driver Library, werden die Programme auch deutlich kleiner.
Random ... schrieb: > Peter K. schrieb: >> Mit Demos ist bei mir nichts, da komm ich nicht >> wirklich dahinter. > Welche IDE verwendest du? Das Discovery hat nen eigenen Debugger > (ST-Link) drauf, du kannst dir mal von www.keil.com die MDK-ARM Demo > runterladen, da hast du schöne einfache Beispiele für dein Board, und > mit den 32kB solltest du ne ganze Weile hinkommen. > Arbeitet man ohne Driver Library, werden die Programme auch deutlich > kleiner. CooCox CoIDE. Ich hab schon selber was gefunden: http://eliaselectronics.com/
So, ich hab das ganze für den UART jetzt ein wenig schön gemacht und abgeschrieben. Am Terminal kommt aber immer "ðHALLO WELT! Es funktioniert!!!". Dieses komische ö am Anfang stört mich. Der Code ist im Anhang.
Mir ist gerade aufgefallen, das dieses ö bei jedem Reset kommt. Also wenn ich nichts sende und den USART nur Intialisiere kommt das ö bei jedem Reset.
Hi Peter, falls du noch Anregungen und Beispiele für das STM32F4 Discovery-Board unter CoCoox suchst... ...ich habe genauso wie du Schritt für Schritt "alle" Funktionen der CPU in Betrieb genommen (na gut, ein paar fehlen noch :-) schau es dir mal an vlt. reicht das ja als "anstupser" um eigene Funktionen zu schreiben http://mikrocontroller.bplaced.net/wordpress/ Gruss Uwe
Ja, deine Libs kenn ich, Problem ist nur, das diese ganzen typedefs mich verwirren - das ist zwar ein schöner Code-Stil und macht das ganze ein wenig dynamischer, aber mir bringt es nicht wirklich was. Noch mal zu den UART-Problem: Kann das an Luft-Pegeln liegen? Also an keine Pulldown? Die internen werden aber eigentlich gleich am Anfang definiert, und auserdem wäre das ja nicht immer ein ö - oder?
Dieses komische ö hat übrigens den Hex-Wert F0. Am Ende des Strings kommt jetzt noch ein FF. Denkt ihr dass es sinnvol ist, das ganze mal mit den Oszi anzusehen?
erst den uart initialiesieren und dann den pin konfigurieren, dann ist das ö weg
Also ich hab jetzt: Pins - UART - Interrupt. Soll das zu UART - Pins - Interrupt werden? Dann muss ich dich enttäuschen: Es geht weder mit UART - Pins - Interrupt noch mit UART - Interrupt - Pins
ließ dir mal in der "stm32f4xx_usart.c" ganz oben bei "How to use this driver" die Reihenfolge der Init-Sequenz durch und probier ob es damit funktioniert oder (was ich noch gesehen habe) warte mal beim senden nicht auf das Flag "TC" = 0x0040 sondern auf das Flag "TXE" = 0x0080 ob das was bringt Gruss Uwe
DANKE. Ich wusste nicht, das die Reihenfolge so wichtig ist. Im Anhang ist noch mal der funktionierende Code. Das
1 | while( !(USART1->SR & 0x00000040)); |
hab ich gleich zu
1 | while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); |
geändert. Sieht einfach besser aus. Was jetzt noch nicht funktioniert ist das \n\r. Das empfängts einfach nicht.
Der scheint mit den \n und \r nicht klar zu kommen. Ich sende jetzt einfach 0x0A und 0x0D. Bis zur nächsten Frage beim SPI.
Peter K. schrieb: > Der scheint mit den \n und \r nicht klar zu kommen. Ich sende jetzt > einfach 0x0A und 0x0D. Bis zur nächsten Frage beim SPI. dreh's mal um ^^
Random ... schrieb: > Peter K. schrieb: >> Der scheint mit den \n und \r nicht klar zu kommen. Ich sende jetzt >> einfach 0x0A und 0x0D. Bis zur nächsten Frage beim SPI. > > dreh's mal um ^^ Was?
Kann ich eigentlich für einen GPIO-Port verschiedene Funktionen verwenden? Wie mach ich das?
1 | GPIO_InitStruct.GPIO_Pin = GPIO_Pin_7 | GPIO_Pin_6 | GPIO_Pin_5; |
2 | GPIO_InitStruct.GPIO_Mode = GPIO_Mode_AF; |
3 | GPIO_InitStruct.GPIO_OType = GPIO_OType_PP; |
4 | GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz; |
5 | GPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_NOPULL; |
6 | GPIO_Init(GPIOA, &GPIO_InitStruct); |
Wie kann ich jetzt PA8 anders konfigurieren? Kann man danach einfach
1 | GPIO_InitStruct.GPIO_Pin = GPIO_Pin_8; |
2 | GPIO_InitStruct.GPIO_Mode = GPIO_Mode_OUT; |
3 | GPIO_InitStruct.GPIO_OType = GPIO_OType_PP; |
4 | GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz; |
5 | GPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_NOPULL; |
6 | GPIO_Init(GPIOA, &GPIO_InitStruct); |
machen, oder überschreibt der das wieder?
Bitte 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.