Ich habe hier ein STM32F411RE Nucleo Board und bin leider ziemlich überfordert. Das debuggen ging weder mit Eclipse, KEIL, noch mit CooCox. Das flashen ging dann immerhin mit dem ST Utility Programm. Und dann will ich eben mal wissen wie man die Taktrate einstellt und denke WTF. Anscheinend eine Wissenschaft für sich. Ich kann im Eclipse Editor die Taktrate angeben, aber kann nirgendwo im Code die Einstellung nachvollziehen. Überfordere ich mich als Anfänger mit dem STM32F4 oder sind alle ARM's so umständlich, vielfältig und kompliziert? Und ich weiß ja auch nicht mal wie man das vernünftig irgendwie erlernen soll. Man schaut im Internet und findet Code Beispiele die wirklich alle anders aussehen. So kann ich keine einheitliche Logik hinter all dem erkennen. Leider fehlt auch jegliche deutsche Literatur, verwunderlich, wo doch ARM so viel besser sein soll, stattdessen findet man einige Bücher für AVR. Naja nimmts nicht Übel, ich lasse gerade nur etwas Frust ab. Es fehlt für mich einfach der rote Pfaden in der ganzen Sache. Wenn das bald nicht besser wird, lass ich den Scheiß und benutze einfach weiter AVR und höre mir an das ARM die Zukunft sei ^^
Die Nucleo Boards laufen doch mit der Embedd-Online Compilerumgebung und der Embedd-Library. Die ist doch relativ einfach und mit vielen Beispielen. Klappt das nicht?
Also für µC Anfänger würde ich wirklich zur Zeit noch von ARM abraten. Da ARM SoCs in aller Regel aus vielen zugekauften Stücken zusammen gestöpselt werden, sind die hoch komplex. Im Prinzip sind das die gleichen Probleme die auch die 16-Bit Mikrocontrollergeneration hatte. Langfristig schätze ich, dass die STM32-Klasse von unten von den 8-Bit Mikrocontrollern aufgefressen wird, weil die einfacher zu programmieren sind, und von oben von kleinen SoCs auf denen Linux läuft, weil man da saubere herstellerunabhängige Schnittstellen hat, sowie ein Betriebssystem das wirklich sinnvolle Dienste hat. Wobei natürlich Mikrocontroller nicht so einfach aussterben. Selbst 8051er gibts noch in neuen Produkten.
ich habe am STM auch lang herumgebissen. Weil ich kein Windows sondern nur Unix benutze, mußte ich diverse Sachen noch zusammen suchen und rumprokeln. Eclipse lief einmal, dann wieder nicht mehr. Darauf bin ich zu Kommandozeilen-Tools gegangen, die liefen stabiler. Aber so richtig Spass macht es auch nicht, weil auch die Ansteuerung das STM sehr aufwändig ist. Es gibt einfach zu viele Register, bei denen man was einstellen kann. Die müssen alle von Hand bedient werden. Eine Api dafür fehlt irgendwie. Der STM liegt schon länger in der Ecke. Ich spiele dann lieber mit ARM-Boards, die schon ein OS haben, z.B. das Beagle Board oder den Raspi. Über Devices kommt man auch an I2C oder SPI ran. Das Arbeiten ist aber einfacher. Man kann Debuggen, hat Testausgabe. Kompiliert wird auf der Teilchen selber. Und letztendlich ist die Architektur egal. Ich habe embedded Code mit uLinux als Basis. Der läuft auf Intelx86, Mips und Arm.
Die ARMs würde ich gerade zum Einstieg nicht ohne Libraries benutzen. Aber die gibt es integriert in Coocox und es gibt auch viele viele Beispielprojekte (z.B. die hier http://mikrocontroller.bplaced.net/). Das Nucleo ist schon in Ordnung. Ein STM32F4 Discovery tut es auch bzw. ist vielleicht sogar etwas einfacher, da viele Beispielprojekte (s.o.) es zur Grundlagen haben. Man tastet sich langsam an das heran, was man braucht bzw. nutzen möchte. Von daher tut es meiner Meinung nach fast jeder. Beim Nucleo kann es sein, dass du den neuesten Treiber für den ST Link installieren musst. Danach wurde das Board bei mir direkt gefunden. Ich würde definitiv zu Coocox raten, da dabei die Libraries direkt integriert sind und du dich nicht selbst damit rumärgern musst (nur unter Repositories anklicken, welche du für dein Projekt brauchst). Viel Erfolg!
:
Bearbeitet durch User
Was ist mit dem XMC 2go der neulich in den news war? Hat schon jemand damit gearbeitet, ist der Einsteiger freundlich?
Hallo, ich habe damals beim Artikelwettbewerb mit dem XMC2GO das EKG gebaut. Im großen und ganzen programmiert es sich annähernd wie mit einem AVR. Für die doch etwas komplexeren Perepheriemodule muss man halt ins Datenblatt oder in die CMSIS Doku schauen. Man sollte allerdings einigermaßen gut C programmieren können. Enum, Strukturen, Makros sollten auf jeden fall ein Begriff sein.( :D ) Zugegeben, mein Programm für den Artikelwettbewerb ist aufgrund mangelnder Erfahrung sicherlich alles andere als schön, aber es läuft und ich hab in der Zwischenzeit einiges dazugelernt. Also nur Mut zum ARM! Grüße
Der XMC 2Go ist schon relativ Einsteigerfreundlich wenn man die DAVE Apps nutzt. Aber ohne etwas Vorarbeit geht es nicht. Ein ATMEL ist an vielen Stellen schon etwas besser dokumentiert. Hier steht etwas dazu, ist aber noch nicht vollständig http://longrisoft.de/index.php/ucontroller-technik/xmc2go
Tom schrieb im Beitrag #3866412: > Mittlerweile vergleiche ich das so, das XMega sowas iw der Apple der > Computerwelt und ARM die Windowskisten sind... So schauts aus. Architektonische Klar- und Einfachheit bei vielfach ausreichender Leistung hat eben ihren Preis. > Die Arms sind exterm vielseitig Oder sagen wir hochflexibel. Und genau das wird zum Problem des Einsteigers + es treibt den Entwicklungsaufwand (Fehlermöglichkeiten) generell nach oben- ohne das dies von der geplanten Anwendung her gerechtfertigt wäre. Konfiguritis pur. > Obwohl derzeit nervt mich auch die etwas ansteigene Schwemme der neuen > XMega Variationen Für die meisten Anwendungen reicht doch der kleine XmegaE5, mit etwas mehr Pins und Uarts der A4U. Solls was ganz großes werden ggf. der A1. > ok die CAN > Unterstüzung fehlt mir :-( Und da wär zu überlegen, ob solche drahtgebundenen Kommunikationsformen über längere Strecken überhaupt noch zeitgemäß sind- zumindest für Neuentwicklungen.
So sehe ich das auch. Der Voreil von ARM ist eben die Vielfalt der externen Peripherie. Der Kern ist überall (fast) gleich. Es hat schon seine Gründe warum er immer mehr eingesetzt wird. Ich weiß nicht ob das Vergleichen mit Windows und Co. der richtige Weg ist sein eigenes Unvermögen zu kaschieren. µController zu programmieren ist etwas anderes als irgendwelche Klicki-bunti-Anwendungen zu schreiben. Auch einen ARM zu programmieren ist was anderes als ATMEL.
Nico S. schrieb: > µController zu programmieren > ist etwas anderes als irgendwelche Klicki-bunti-Anwendungen zu > schreiben. Auch einen ARM zu programmieren ist was anderes als ATMEL. Was ist an einem einfachen AVR Mikrocontroller Klicki-bunti? Ich glaube instinktiv will niemand mit ARM arbeiten. Man muss sich dazu zwingen oder wird im Beruf gezwungen. Ist wie mit einigen anderen sonderbaren Standards, wo die meisten sich am Anfang fragen wer sich so was hat einfallen, aber dann seufzt man und zwingt sich es zu lernen, dann heißt es, ja hat halt sein Grund wieso es 90% nutzen, muss wohl das beste sein, wenns jeder benutzt, obwohl es scheußlich anzuwenden ist, Standard eben....
Bifffd schrieb: > Ich glaube instinktiv will niemand mit ARM arbeiten. Ich arbeite sehr gerne und freiwillig mit ARM (hier: STM32), aufgrund der Flexibilität und hohen Leistung, freien Linux-Tools, netten Debug-Features, mächtiger Peripherie, vernünftigen Architektur (-> einheitlicher Adressraum, Barrel-Shifter, Offset-Adressierung, verschachtelbare Interrupts mit flexiblen Prioritäten, Multitasking etc. etc.). Ich hätte instinktiv sehr wenig Lust das mit dem AVR irgendwie hinzufrickeln.
Bifffd schrieb im Beitrag #3866522: > aber ich > arbeite doch nicht mal mit Atmel ARM und dann wieder mit STM32. Es Warum nicht? Wenn man sich mit den STM32 auskennt ist es ein Leichtes mal eben schnell zB den LPC11C00 einzusetzen, weil man den aufgrund des integrierten CAN-Transceivers braucht. Wenn ich eine andere Architektur nehmen müsste, fängt es schon bei der Installation der Tools an...
Bifffd schrieb: > Ich glaube instinktiv will niemand mit ARM arbeiten. Man muss sich dazu > zwingen oder wird im Beruf gezwungen. Wie Du meinst. Dann such Dir eben für jede neue Form von Anwendung einen andere Plattform weil deine aktuelle es nicht implementiert hat und lerne sie neu kennen. Klar ist der Einstieg etwas schwieriger, aber man kann sagen: Kennst Du einen, kennst Du alle. Zumal man heutzutage nicht mal mehr die Hardware abtrahieren muss. Meinen ersten ARM konnte ich schon mit meinen damaligen bescheidenden C-Kenntnissen programmieren ohne mich groß zu verbiegen. Was ich damit nicht sagen will ist das ARM das Allheilmittel ist. Jeder µController hat seine Berechtigung, sonst würde er nicht lange auf dem Markt bleiben. Aber nur weil der Einstieg ggf. etwas schwieriger ist ihn zu verdammen ist der falsche Weg.
Moby schrieb im Beitrag #3866551: >> AVR ist eine Einbahnstraße! > > Die auch und meist ... in einer Sackgasse endet. @Moby Deine Ansprüche an µC sind hier bekannt und recht bescheiden. Deine µC Projekte lassen sich auch mit einer handvoll Gatter lösen. ;-) Andere nutzen den µC und nutzen den zeitgemäßen Komfort und die modernen Möglichkeiten, die ein Cortex bietet. Deine aus der Luft gegriffenen Parolen werden den Fortschritt nicht verhindern. Hier im Forum zeigt sich der Trend bereits: Immer mehr - auch Einsteiger - satteln erfolgreich mit Cortex auf. Also beantworte die Frage "Welche ARM Modelle eignen sich für Anfänger?" oder, da du davon keine Ahnung hast, halte die Finger still!
Ich kann stm32 in Kombination mit coocox empfehlen. Also ich kam damit auf Anhieb zurecht (bin von Avr) umgestiegen. Mein Fazit war, dass es genauso leicht ist diese Dinger anzusprechen wie die AVRs. Ich hatte sogar schneller erfolgserlebnisse als damals mit den AVRs (da habe ich mir erstmal alles verfust und der Frust war enorm). Ich habe seit dem Umstieg alle meine Atmegas verschenkt und arbeite auch im Hobby nur noch mit den zeitgemäßen ARMs
genervter Entwickler schrieb: > ... in einer Sackgasse endet. Genau, die endet. Aber in vielen nützlichen, fertig realisierten Projekten- statt eines in der Ecke verstaubenden Preis-Hype Stm-Discovery. > Deine Ansprüche an µC sind hier bekannt und recht bescheiden. Deine µC > Projekte lassen sich auch mit einer handvoll Gatter lösen. ;-) Immer wieder schade, wenn man sich nur noch so zu artikulieren weiß. Aber paßt auch irgendwie zu den anderen abfälligen Äußerungen. > werden den Fortschritt nicht verhindern. Was für ein größenwahnsinniges Ziel ;-) Allerdings ist doch sehr die Frage, von welchem Fortschritt hier die Rede ist wenn sich die überbordende ARM Komplexität immer weiter von reellen Anforderungen konkreter Anwendungen entfernt. > Also beantworte die Frage "Welche ARM Modelle eignen sich für Anfänger?" Keine.
genervter Entwickler schrieb: > Deine Ansprüche an µC sind hier bekannt und recht bescheiden. Moby schrieb: > wenn sich die > überbordende ARM Komplexität immer weiter von reellen Anforderungen > konkreter Anwendungen entfernt Danke für die Bestätigung! Und da du keine Ahnung von ARM Cortex hast, bist du hier überflüssig. Bitte mach einen eigenen Troll- und Jammer-Thread auf!
wuff schrieb: > Ich kann stm32 in Kombination mit coocox empfehlen. Also ich kam damit > auf Anhieb zurecht (bin von Avr) umgestiegen. > > Mein Fazit war, dass es genauso leicht ist diese Dinger anzusprechen wie > die AVRs. Ich hatte sogar schneller erfolgserlebnisse als damals mit den > AVRs (da habe ich mir erstmal alles verfust und der Frust war enorm). > > Ich habe seit dem Umstieg alle meine Atmegas verschenkt und arbeite auch > im Hobby nur noch mit den zeitgemäßen ARMs Klingt geschönt und unglaubwürdig.
>> Wenn du geistig schwerfällig bist, solltest du dich auf einen >> Hersteller beschränken. > > Tut das nicht sowieso schon jeder? Die Auswahl mag da sein, aber ich > arbeite doch nicht mal mit Atmel ARM und dann wieder mit STM32. Es sei > denn ich bin dazu gezwungen weil ich mein Geld damit verdienen muss. Nö, ich springe lustig zwischen ATmega, LPC11/12/13/17 und STM32F2/4 hin und her. Den EFM32 sehe ich mir bei Zeiten auch noch an. Die Toolchain ist ja immer die selbe. Natürlich unterscheidet sich die Peripherie zwischen den einzelnen Typen. Das sehe ich aber als Vorteil. Die AVRs benutze ich allerdings nur noch wenn ich Streifenraster Platinen verwende. Das habe ich in diesem Jahr glaube ich nur einmal gemacht. Die dsPICs finde ich auch recht spannend. Ich habe hier ein Board liegen, finde nur leider keine Zeit mich da mal vernünftig einzuarbeiten. > Ich glaube instinktiv will niemand mit ARM arbeiten. Man muss sich dazu > zwingen oder wird im Beruf gezwungen. Wieder nö. Ich rege mich z.B. jedes mal über die Timer der AVRs auf. Nur 1x 16Bit und allesamt mit seltendämlichen Prescalern. Bei den LPC/STM32 kann ich den Prescaler auf 97 stellen wenn ich so einen Wert brauche. Für den UART brauche ich bei ATmega zudem einen Baudratenquarz. Hoffentlich hat Atmel wenigstens bei den XMegas nachgebessert. Die gibt es aber nicht als DIL, daher nehme ich dann gleich ARM. Des Weiteren habe ich (auch privat) mit Signalverarbeitung zu tun. Da komme ich mit 8Bit nicht weit. Ich brauche 32/64 Bit Festkomma oder Gleitkomma. Deshalb ja auch die Sache mit dem dsPIC. Ist zwar nur 16Bit, die haben aber immerhin einen (zwei?) 40Bit Akku. Und tolle Peripherie. Zum Thema: Für den Einstieg krankt es ein wenig an Enwicklungsumgebungen die aus dem Stand heraus funktionieren. Coocox ist schon nicht schlecht wenn man ein damit erstelltes Programm nicht noch auf den Controller bringen müßte ;). Denn OpenOCD ist für mich eher eine Krankheit als ein Werkzeug. Der GDB Server von Segger für den J-Link übrigens auch. Ich benutze überwiegend Eclipse mit der Linaro Toolchain und die seriellen Bootloader der Controller. Einsteigerfreundlich ist das aber freilich nicht. Atollic ist wie µVision auf 32kB beschränkt (danach wirds teuer), LPCxpresso kann 256kB, geht aber nur mit LPCs. Und es ist ein völlig verbasteltes Eclipse. Dann vielleicht doch etwas Geld in die Hand nehmen und in Crossworks investieren. Die Kosten sind für Privatanwender noch überschaubar (125$ oder €, weiß ich gerade nicht). Und damit kann man dann gut ein STM32 Discovery Board nutzen. Auch zum Programmiereun und Debuggen von anderen Controllern wie die LPCs. Außer den LPC12xx. Die sind am ST-Link etwas bockig.
Zum Thema Anfänger ARM Ich würde die Cortex M0 der LPC Reihe empfehlen. 1. Mit den LPCXPRESSO gibt es spottbillige, breadboard taugliche, Evalboards mit Debugger (!), letzterer auch für beliebige andere LPC Arm uC verwendbar 2. Mit dem LPC1114FN28 und dem Lpc800 gibt es zwei DIP ICs 3. Es gibt zum LPCXPRESSO eine sehr gute, kostenlose (auf 512 Kb Binary beschränkt) und sofort funktionsfähige IDE auf Basis von Eclipse für Windows und Linux. Dazu viele Beispiele für die gesamte Peripherie.
Stefan schrieb: > Ich rege mich z.B. jedes mal über die Timer der AVRs auf. Nur > 1x 16Bit und allesamt mit seltendämlichen Prescalern. Bei den LPC/STM32 > kann ich den Prescaler auf 97 stellen wenn ich so einen Wert brauche. Schau Dir die Xmegas an. Da wurde nachgelegt. > Für den UART brauche ich bei ATmega zudem einen Baudratenquarz. > Hoffentlich hat Atmel wenigstens bei den XMegas nachgebessert. Haben sie. Uart geht quarzfrei.
Es gibt einen ARM, der relativ einfach zum Einstieg ist: http://hobby-roboter.de/forum/viewtopic.php?f=4&t=152
Tom schrieb im Beitrag #3867031: > Vielfalltsproblem! Na ja, such doch einmal hier im Forum nach verfusten AVRs. Nach deiner Meinung sind die AVRs dann totaler Schrott. ;-) @Tom Thema verfehlt! Bitte lies den Titel! Und nur weil du es nicht raffst, heißt das nicht, das die Dinger schlecht sind. Sehr sehr sehr viele haben kein Problem damit. Mach mit Moby den Troll- und Jammer-Thread auf, es wird langsam unerträglich.
Hmmm, irgendwie verstehe ich das Problem nicht. Wenn die Umgebung das nicht unterstützt, ist das doch kein Drama. Man baut sich seine Entwicklungsumgebung doch sowieso nach seinem Gusto zusammen. Mit den entsprechenden ST-Bibliotheken ist das unter Eclipse bspw. kein Problem und selbstverständlich kann man dort alle STM32-Typen verwenden. Eine Umgebung, die mich so einschränkt, wie es Coocox offenbar tut, würde ich hier nicht verwenden - gerade wenn ich damit Geld verdienen möchte. Und was die Komplexität betrifft: niemand wird doch gezwungen, sofort alle Module zu verwenden. Wir haben damals ganz klassisch wie damals beim AVR angefangen: mit einer blinkenden LED :-) Und das war nicht schwieriger als beim AVR. ST liefert mit seinen Quelltexten und Beispielen wirklich sehr gute Kommentare. Und dann macht man weiter und lässt diese vielleicht über einen Timer blinken usw. Für Anfänger würde ich einen kleinen F0 empfehlen - Anleitungen zur erfolgreichen Einrichtung des Compilers und erste Schritte gibt es mittlerweile genug - genauso wie hier im Forum sich immer mehr mit der STM32-Reihe beschäftigen und gerne helfen, wenn es klemmt :-)
Man sollte vielleicht am Anfang auf eine gute und unkomplizierte Entwicklungsumgebung setzen. Keil würd ich mal so empfehlen, das ist auch bis 32kB Code frei. Ist schon eine Menge Holz zum experimentieren. In der IDE gibt's dann auch Demobeispiele, kann man ausprobieren, verändern bis nix mehr geht und dann Fehler suchen. So lernt man das alles recht schnell. Keinen Sinn macht es, das gesamte Manual durchzulesen. Wenn du auf der 500sten Seite bist hast du die 499 Seiten vorher schon wieder vergessen. Dient eigentlich nur mehr für punktuelle Inbetriebnahmen von Peripherie. Grüsse
>Keil würd ich mal so empfehlen, das ist >auch bis 32kB Code frei. 32k ist wenig für einen ARM. Es lohnt sich nicht sich in Keil einzuarbeiten wenn man später mal SD-Karte, RGB Grafikdisplay und Ethernet machen möchte. Eins von den dreien langt meist schon die 32k zu sprengen.
@holger Soo wenig ist das nicht, wenn das alles mal halbwegs läuft, kann er sich ja später einen GNU-Compiler aufsetzen, und ist damit völlig unabhängig. Grüsse
Tom schrieb im Beitrag #3867051: > wir reden hier von ARM und XMEGA Nein, es geht um "Welche ARM Modelle eignen sich für Anfänger?" Zum Glück sind die anderen da wieder gelandet.
Dann frage ich mich was Du von Amtega und verfusen faselst :-) Noch mal zu dem Kommentar von weiter oben... "Und da wär zu überlegen, ob solche drahtgebundenen Kommunikationsformen über längere Strecken überhaupt noch zeitgemäß sind- zumindest für Neuentwicklungen." Was ist denn da eine brauchbare alternative? Und ist es wirklich eine brauchbare? Etwas OT :-)
:
Wiederhergestellt durch Moderator
TomiVoll schrieb: > Naja nimmts nicht Übel, ich lasse gerade nur etwas Frust ab. > Es fehlt für mich einfach der rote Pfaden in der ganzen Sache. Wohl noch nie Artikel zum STM32 gelesen? http://www.mikrocontroller.net/articles/Kategorie:STM32
Kim Schmidt schrieb: > Dann frage ich mich was Du von Amtega und verfusen faselst :-) Er sprach von den AVRs, ist aber egal, da es hier nicht um AVRs oder xmega sondern ausschließlich um die Frage geht, welche ARMs für Einsteiger geeignet sind un dich bitte die Diskutanten, sich daran zu halten. > Noch mal zu dem Kommentar von weiter oben... > "Und da wär zu überlegen, ob solche drahtgebundenen Kommunikationsformen > über längere Strecken überhaupt noch zeitgemäß sind- zumindest für > Neuentwicklungen." > > Was ist denn da eine brauchbare alternative? Und ist es wirklich eine > brauchbare? Der Kommentar zeigt nur, dass sein Schreiber nicht weiss, in welchen Bereichen kabelgebundenes CAN (das es natürlich auch längst kabellos gibt) eingesetzt wird: in sicherheitsrelevanten Bereichen. Dafür wurde das Protokoll entwickelt. Als Hobby kann er gerne drahtlose Kommunikation einsetzen - da spielt es auch keine Rolle, ob etwas auch dann noch funktioniert, wenn daneben ein Lichtbogenofen zündet. In unserem Bereich (chem. Industrie) gibt es aber Tote, wenn Nachrichten nicht ankommen. Da denkt niemand auch nur kurz über drahtlose Kommunikation nach. > Etwas OT :-) Sehr richtig - deswegen bitte für alle: zurück zum Thema!
:
Bearbeitet durch Moderator
Wir haben auch einige neue Projekte mit dem LPC1768 (Cortex M3) von NXP begonnen. Mit den Freeware-Tools sind wir aber nicht froh geworden, kostet zuviel Zeit. Wir haben daher eine professionelle Umgebung gekauft im 4-stelligen €-Bereich. Wichtig ist uns, daß man Support kriegt und nicht selber umständlich rumprobieren muß (passende Libs, Linkerscripte, Debugger usw.). Wir benutzen erstmal das DIP40 Modul. Wenns läuft, kann man dann ne Platine machen.
Nimm doch etwas, das sofort geht. z.B, einen "Arduino Due". Da hast Du eine Menge an funktionierenden Beispielen und auch LIBs.
und welche Software ist das? Es ist traurig,das sowas hier nicht im gleichen Satz erwähnt werden darf, da es dann gleich von irgendwelchen Gerhinakrobaten hier als Schleichwerbung abgetan wird!
Wenn man vom AVR kommt, sollte man auch einen Blick auf die Atmel-SAMs werfen. Die Xplained-Boards kann man direkt mit den Beispielen im Atmel Studio nutzen, Debugger sind auf den Boards mit drauf. Die Peripherie ist natürlich nicht vergleichbar. Ein PWM oder Timer benutzen ist deutlich anders als auf AVRs. Andere Schnittstellen (z.B. UART, I2C) sind schon wieder ähnlicher.
Ich kann ja mal schreiben was mich verwirrt. Ich will also ganz einfach mal eine LED zum blinken bringen, will also lernen wie man einen Pin ansteuert. Ich habe das gefunden: GPIO_InitTypeDef GPIO_InitStruct; RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE); GPIO_InitStruct.GPIO_Pin = GPIO_Pin_15 | GPIO_Pin_14 | GPIO_Pin_13 | GPIO_Pin_12; GPIO_InitStruct.GPIO_Mode = GPIO_Mode_OUT; GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz; GPIO_InitStruct.GPIO_OType = GPIO_OType_PP; GPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_NOPULL; GPIO_Init(GPIOD, &GPIO_InitStruct); Das funktioniert so schon mal nicht. Meine Entwicklungsumgebung mit Eclipse findet im GPIO_InitStruct kein GPIO_Pin oder GPIO_Mode sondern nur Pin und Mode also z.B. GPIO_InitStruct.Pin Auf einer anderen Webseite habe ich dann gesehen das es auch so geht: GPIOD->MODER Und das der GPIO Clock mit RCC->AHB1ENR |= RCC_AHB1ENR_GPIODEN aktiviert wird, statt mit RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE) Bei den Beispielen von ST im STM32Cube Paket findet man dagegen ein GPIO Beispielprojekt wo die Clock mit __PWR_CLK_ENABLE(); aktiviert wird. Ok es gibt also Unterschiede oder verschiedene Wege. Aber wie finde ich jetzt heraus nach welcher Dokumentation/Header mein Compiler geht? Ich benutze diese Toolchain: https://launchpad.net/gcc-arm-embedded Mit diesem Eclipse Plugin: http://gnuarmeclipse.livius.net/blog/ Mein Board: Nucleo STM32F411RE
Korrektur: Ich schrieb __PWR_CLK_ENABLE(). Sollte __GPIOA_CLK_ENABLE() heißen.
naja, mit einem vernünftigen Compiler gehts auch bei arm, aber beim mega und auch xmega geht halt alles einfacher, beim adc mit ext ref wirds beim arm schon haarig..bei xmega ist es genauso einfach wie beim alten Mega Zwei Beispiele für einen STM32
1 | GPIO_Digital_Output(&GPIOA_BASE, _GPIO_PINMASK_ALL); // Set PORTA as digital output |
2 | while(1) {
|
3 | GPIOA_ODR = ~GPIOA_ODR; |
4 | delay_ms(1000); |
5 | } |
ist es in Mikroe C und und hier komplett in Pascal von Mikroe
1 | GPIO_Digital_Output(@GPIOA_BASE, _GPIO_PINMASK_ALL); // Set PORTA as digital output |
2 | while TRUE do |
3 | begin |
4 | GPIOA_ODR := not GPIOA_ODR; // Toggle PORTA |
5 | Delay_ms(1000); |
6 | end; |
Beim Atmega
1 | begin |
2 | DDRA := 0xFF; // set direction to be output |
3 | |
4 | while TRUE do |
5 | begin |
6 | PORTA := not PORTA; // Turn ON diodes on PORTA |
7 | Delay_ms(1000); // 1 second delay |
8 | end; // Endless loop} |
wie man auch sieht, sind C und Pascal komplett andere Welten, daher programmieren echte Vollprofis auch nur in C :-) harhar
:
Wiederhergestellt durch Moderator
Jetzt mal aus dem Blickwinkel des AVR-Hobbybastlers der Lochraster-Kategorie: Was soll mir der Einstieg mit einem "kleinen" ARM bringen? Wenn ich etwas entwickeln will nehme ich doch lieber einen µC, der mir bereits vertraut ist und bin damit schnell fertig. Wenn es ums Lernen geht, dann nehme ich doch besser sowas wie "STM32 F4 Discovery" mit 'nem STM32F429ZIT6U drauf. Da bekommt man für wenig Geld 'ne Menge Zeugs zum Spielen und es ist alles drin, was ein kleiner ARM auch hat. OK, "unverbaute" I/O-Pins bleiben nur 18 Stück übrig und wenn ich noch eine UART-Schnittstelle rauslutschen will, dann wird das eher eine "Schnitz-Stelle", weil eben bei den 18 Pins kein ganzer UART mehr dabei ist. Aber da gibt es zum Glück noch z.B. ein "STM32F401 Nucleo" für I/O-lastige Sachen, auch für kleines Geld.
Konrad S. schrieb: > Jetzt mal aus dem Blickwinkel des AVR-Hobbybastlers der > Lochraster-Kategorie: Es mag sein dass viele Leute hier im Forum mit AVR angefangen haben (warum auch immer). Aber für den Neu-Einsteiger ist ARM als erster uC problemlos möglich, egal ob man mit DIP und Steckbrett, Eval-Board oder eigenere Platine anfangen möchte. Es gibt haufenweise Tutorials, Demos und freie Schaltpläne. Und wenn wirklich Fragen kommen, werden die alle hier im Forum auch von kompetenten Leuten beantwortet. Es gibt nur deswegen weniger Einträge als für AVR, weil es beim ARM-Einstieg eben tatsächlich weniger Probleme gibt :-)
Lothar schrieb: > Es gibt nur deswegen weniger Einträge > als für AVR, weil es beim ARM-Einstieg eben tatsächlich weniger Probleme > gibt :-) Der war gut! ;-)
Lothar schrieb: > Und wenn wirklich Fragen kommen, werden die alle hier im Forum auch von > kompetenten Leuten beantwortet. Es gibt nur deswegen weniger Einträge > als für AVR, weil es beim ARM-Einstieg eben tatsächlich weniger Probleme > gibt :-) Dann muss Arduino ja höllisch schwer sein. Davon gibts gefühlt die meisten Threads.
>> Ich kann ja mal schreiben was mich verwirrt. >> Ich will also ganz einfach mal eine LED zum blinken bringen, will also >> lernen wie man einen Pin ansteuert. Dieses Beispiel zeigt die Verwendung der STM Standard Peripheral Drivers Library für das PIN setzen, löschen, lesen sowie togglen. Taster an Port_A. Hardware: STM32F429 Discovery Board. Damit hast du dann ein einfaches Beispiel. Das Ganze setzt auf CMSIS & CO auf. Hierzu empfehle ich dir folgendes zu lesen: http://www.mikrocontroller.net/articles/STM32_-_Einstieg_mit_Em::Blocks
1 | #include "stm32f4xx.h" |
2 | #include "stm32f4xx_gpio.h" |
3 | #include "stm32f4xx_rcc.h" |
4 | |
5 | #define LED_GREEN GPIO_Pin_13
|
6 | #define LED_RED GPIO_Pin_14
|
7 | #define KEY GPIO_Pin_0
|
8 | |
9 | void gpIO_Init (void); |
10 | void Delay (volatile uint32_t loopCount); |
11 | |
12 | int main (void) |
13 | {
|
14 | SystemInit (); // Sys. Init (Quarz etc.) |
15 | gpIO_Init (); |
16 | |
17 | while (1) { |
18 | GPIO_ToggleBits ( GPIOG, LED_GREEN ); |
19 | Delay ( 2000000 ); |
20 | |
21 | if ( GPIO_ReadInputDataBit ( GPIOA, KEY ) ) // Taster gedrückt ? |
22 | GPIO_SetBits ( GPIOG, LED_RED ); // rote LED an... |
23 | else
|
24 | GPIO_ResetBits ( GPIOG, LED_RED ); // ...oder aus |
25 | }
|
26 | }
|
27 | |
28 | void gpIO_Init (void) |
29 | {
|
30 | RCC_AHB1PeriphClockCmd ( RCC_AHB1Periph_GPIOG, ENABLE ); // Takt für Port_G |
31 | |
32 | GPIO_InitTypeDef GPIOG_InitStructure; |
33 | GPIOG_InitStructure.GPIO_Mode = GPIO_Mode_OUT; // Port_G als Ausgang |
34 | GPIOG_InitStructure.GPIO_Pin = LED_GREEN | LED_RED; // PG 13 (green LED), PG 14 (red LED) PIN 128, 129 STM32F429ZIT6 |
35 | GPIOG_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // Port_G speed (2, 25, 50, 100 MHz) |
36 | GPIOG_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL; // kein Pull Up / Down |
37 | GPIO_Init ( GPIOG, &GPIOG_InitStructure ); |
38 | |
39 | RCC_AHB1PeriphClockCmd ( RCC_AHB1Periph_GPIOA, ENABLE ); // Takt für Port_A |
40 | |
41 | GPIO_InitTypeDef GPIOA_InitStructure; |
42 | GPIOA_InitStructure.GPIO_Mode = GPIO_Mode_IN; // Port_A als Digital-Eingang |
43 | GPIOA_InitStructure.GPIO_Pin = KEY; // PA0 Taster Eingang, PIN 34 STM32F429ZIT6, PA0 ext. Pull Down R |
44 | GPIOA_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL; // kein Pull Up / Down |
45 | GPIO_Init ( GPIOA, &GPIOA_InitStructure ); |
46 | }
|
47 | |
48 | void Delay (volatile uint32_t loopCount) |
49 | {
|
50 | while ( loopCount-- ) { |
51 | }
|
52 | }
|
Einfacher gehts kaum. Ich vermute du hast dir keine Grundlagen erarbeitet. Ich kann mir nicht vorstellen das hieran irgend etwas kompliziert ist, man muß halt die Libraries studieren oder man schreibt selber welche.
>> Das funktioniert so schon mal nicht. Meine Entwicklungsumgebung mit >> Eclipse findet im GPIO_InitStruct kein GPIO_Pin oder GPIO_Mode sondern >> nur Pin und Mode also z.B. GPIO_InitStruct.Pin Die IDE wirst du sicher selbst finden und dein Eclipse geraffel gehört in die Tonne oder vernünftig konfiguriert. http://www.emblocks.org/web/
ist in den standard libs auch was drin, um auf die externe Referenz umzuschalten?
avr schrieb: > Dann muss Arduino ja höllisch schwer sein. Davon gibts gefühlt die > meisten Threads. So viele Arduino Fragen gibt es hier doch gar nicht. Als Arduino Nutzer stellt sich die Lage doch so dar: entweder geht die Library zum Shield, was gibt es dann zu fragen. Oder die geht nicht, oder man möchte was ändern, dann wird es genau so komplex wie ohne Arduino. Eher noch schwieriger, denn seine uC Libraries hat man ja selbst gemacht und findet Fehler einfacher. Bernd N schrieb: > Verwendung der STM Standard Peripheral Drivers > Library für das PIN setzen Ohne diese Library sind es zwei Zeilen (Pin direction, Pin level).
So schwer ist ARM der STM32 nicht. 1. Nimmt man Em:Blocks. Das ist einfacher als das alte AVR-Studio obwohl es moderner und leistungsfähiger ist. 2. Nicht die STM-Libs nehmen. Ein GPIO kriegt man auf Registerebene in drei Zeilen konfiguriert. Für eine UART braucht man 5 Zeilen. Der gesamte Treiber braucht bei mir nicht einmal 50 Zeilen. Mit DMA. Man muss sich nur im Datenblatt zurecht finden, das ist aber wirklich sehr gut. Alles nicht wirklich komplizierter als die Atmegas.
>ist in den standard libs auch was drin, um auf die externe Referenz >umzuschalten? Sagen wirs mal so: Eine interne Referenz ist nicht wirklich vorhanden. Es gibt zwar Refint, aber die hängt an einem ADC Kanal. Ergo es wird immer die externe benutzt. Wenn keine Vref Pins vorhanden sind ist das einer der VCC Pins. Klingt logisch, ist aber so. Um welchen STM geht es da?
na z.B. der STM32F205VB wurde hier vor einigen Tagen angefragt, ich komme damit tatsächlich auch nicht klar.
Antimedial schrieb: > Man muss sich nur im Datenblatt zurecht finden, das ist aber wirklich sehr > gut. Ja ja man muß nur... Man muß sich halt nur auskennen- wielange es aber zum entsprechenden Wissenstand braucht wird an dieser Stelle nicht verraten ;-) Die ARM Datenblätter sind eher dazu geeignet Verwirrung zu stiften- aber vermutlich geht es bei DIESER Architektur auch nicht besser. >Alles nicht wirklich komplizierter als die Atmegas. Scherzkeks. Und an all die großen ARM Experten hier: Nehmt die reale Erfahrungen von überforderten Anwendern mit ARM Controllern ernst, statt sie als Flachschaufel und geistig schwerfällig abzustempeln. Hinsichtlich solcherlei Abfälligkeiten hat mancher ARMer Moderator wohl auch einen blinden Fleck :-(
Moby schrieb: > Die ARM Datenblätter sind eher dazu geeignet Verwirrung zu stiften ARM ist nicht gleich ARM - es hängt vom Hersteller ab ob die Dokumentation übersichtlich, verständlich, beispielhaft ist. Bei NXP waren die 8051 Manuals gut und die ARM Manuals sind so geblieben. Abwechselnder Einsatz von z.B. LPC935 (8051) und LPC1114 (ARM) ist problemlos.
Lothar schrieb: > ARM ist nicht gleich ARM - es hängt vom Hersteller ab ob die > Dokumentation übersichtlich, verständlich, beispielhaft ist. Bei NXP > waren die 8051 Manuals gut und die ARM Manuals sind so geblieben. > Abwechselnder Einsatz von z.B. LPC935 (8051) und LPC1114 (ARM) ist > problemlos. Das kann ich auch bestätigen. Was beim STM32 Mist ist, ist die Lib die einem überall aufgezwungen wird. Die ist für sich nur schlecht dokumentiert und hat auch keinen Bezug zu den Reference Manuals. Die sind für sich allein genommen auch nicht schlechter als die von NXP. Was meines Erachtens nach fast überall fehlt, sind minimalistische Code-Samples. Damit meine ich welche ohne jegliche Libs und ohne SysInit und der gleichen. Also eigentlich nur den Startup-Code mit den Interrupthandlern und ein Linkerscript. Alles weitere kann dann nach und nach dazu kommen. So könnte dann auch ein Neuling wirklich anfangen zu verstehen wie hier der Hase läuft. Statt dessen erhält man aber meistens ein unübersichtliches Projekt. Wenn da noch der komplette Code der stm32-Lib mit drin ist, kann ich jeden Anfänger verstehen den das überfordert. Das sind aber Probleme die nichts mit ARM an sich zu tun haben. Das sieht bei PIC32 auch nicht besser aus. Ich kann nur sagen, der Versuch die komplexere Architektur der Peripherie hinter einer noch komplexeren Lib bzw. Entwicklungsumgebung zu verstecken, geht gründlich in die Hose.
Moby schrieb: > Antimedial schrieb: >> Man muss sich nur im Datenblatt zurecht finden, das ist aber wirklich sehr >> gut. > > Ja ja man muß nur... Man muß sich halt nur auskennen- wielange es aber > zum entsprechenden Wissenstand braucht wird an dieser Stelle nicht > verraten ;-) Nun, das dauerte hier nicht länger als für andere Architekturen auch. > Die ARM Datenblätter sind eher dazu geeignet Verwirrung zu stiften- aber > vermutlich geht es bei DIESER Architektur auch nicht besser. Vermutlich hast Du noch nie welche gelesen. Die sind nämlich sehr gut lesbar und verständlich. > Und an all die großen ARM Experten hier: Nehmt die reale Erfahrungen von > überforderten Anwendern mit ARM Controllern ernst, statt sie als > Flachschaufel und geistig schwerfällig abzustempeln. Das stimmt - aber das gilt wohl für alle Architekturen. > Hinsichtlich > solcherlei Abfälligkeiten hat mancher ARMer Moderator wohl auch einen > blinden Fleck :-( Da sehe ich keinen. Ich sehe nur Moderatoren, die Beiträge, die nichts mit dem Thema zu tun haben und nur dazu dienen, Deine Vorliebe für AVRs (ist ja in Ordnung) in wirklich jedem ARM-Thread anderen mitzuteilen, löschen. Du kannst gerne einen eigenen Thread eröffnen, in dem Du darlegst, warum alle mit AVRs glücklich sein sollen. Hier geht es aber um empfehlenswerte ARMs für Einsteiger. Aber zurück zum Thema: Mich hat bei der ST-Lib gestört, dass sie irgendwie alles in Structs quetschen möchte und es Structs für allgemeine Initialierungen eines Moduls und dann nochmal spezielle gibt. Auch die Abkürzungen sind schon sehr kryptisch. Wenn man sich aber direkt an die Register hält, dann schrumpft das alles schon stark zusammen und man benötigt nur wenige Zeilen. Die Idee von "temp" mit dem minimalistischen Code gefällt mir. Da sollten wir mal ein Besipiel erstellen.
:
Bearbeitet durch Moderator
Tom schrieb im Beitrag #3869195: > interessant das diese Themenfremde löschen besonders gut bei dem Arms > funktioniert.. > Und beleidigende PRO Arm Beiträge nicht gelöscht werden..siehe oben > "Was bist du für ne Flachschaufel? > geistig schwerfällig" Klar, das geht nicht. Ist gelöscht - Ihr müsst so etwas aber auch melden. Auch wir sind nicht überall und auch ich lese nicht jeden Beitrag in jedem Thread. > User Moby nennt sogar Asm Beispiele wo man den Krassen Unterschied > zwischen ARM und AVR sieht, dennoch gelöscht..naja.. Moby nennt diese Beispiele aber immer im falschen Thread. Der Titel hier lautet "Welche ARM Modelle eignen sich für Anfänger?" Was das mit AVRs zu tun haben soll, weiss wohl nur er. Und das nervt dann die Leute weil das Thema komplett abdriftet und sie schreiben uns (reichlich!) und melden seine Beiträge > Leider raffen die wenigsten heir, das andere Leute noch andere Hobbys > haben als nur Mikrocontroller, derren Welt besteht aus mehr als nur > elektronik und frickeln..aber wie sollen die vielen Nerds mit ihrer > Fanatischen sich begreifen, die haben ja nichts anders Genau das ist das Problem. Man kann sich nicht vorstellen, dass es hier Leute gibt, die das Ganze nicht nur als Hobby betreiben, sondern damit auch Geld verdienen müssen. Und da sind die neuen ARMs einfach deutlich interessanter als ältere Architekturen. Wie gesagt: wir haben viele Jahre mit AVRs gearbeitet und sie wirklich gemocht, aber irgendwann merkt man bei anspruchsvollen Projekten einfach, dass man am Ende der Leistungsfähigkeit angekommen ist und man mit bspw. der STM32-Reihe eine deutlich größere Bandbreite abdecken kann. So, das war es jetzt bzgl. AVRs von mir. Ich und die meisten anderen möchten in einem ARM-Thread nicht über AVRs diskutieren.
Chris D. schrieb: > Ich und die meisten anderen möchten in einem ARM-Thread nicht über AVRs > diskutieren. Danke. Löscht bitte alle Beiträge von Moby. Er ist schon seit über 12 Monaten auf ein und der selben Leier und mobbt in allen STM32 Threads rum ohne auch nur einen sinnvollen Beitrag zu leisten die dem Problemhabenden hilft.
Mit den ADuC70xx Typen von Analog Devices bin ich beim "Aufsteigen" und Umsteigen auf ARM(7) sehr gut zurecht gekommen. Sowohl die IDE (von AD) als auch die Programmierung (Bootloader seriell auf allen Chips) sind ohne Verenkungen sofort einsatzbereit. Die Libs sind übersichtlich und gut erklärt. Damit habe ich ohne Hilfe, nur nach Anleitung, alle Projekte hinbekommen. Im Gegensatz zu den XE16xx von Infineon, den SAM7 von Atmel und den EFM32 von Energy Mico, die doch schon mehr Grundwissen verlangen und die ich ohne Hilfe nicht in angemessener Zeit zum Laufen bekommen hätte. Zu den anderen ARM-Typen kann ich nichts sagen. Blackbird
Tom schrieb im Beitrag #3869195: > Asm Beispiele wo man den Krassen Unterschied > zwischen ARM und AVR sieht Da ich selber viele Module in ARM Assembler schreibe (Bit-Banging, Error-Handler, DSP) und ich ARM Assembler für sehr logisch aufgebaut und einfach halte, hätte mich dieser "krasse Unterschied" schon interessiert :-) Habe grade erst einen TFT-Treiber von AVR Assembler nach ARM Assembler portiert, war keine Aktion ...
Chris D. schrieb: > Die Idee von "temp" mit dem minimalistischen Code gefällt mir. Da > sollten wir mal ein Besipiel erstellen. Dafür wäre ich sehr dankbar. Es würde mir den Einstieg sehr erleichtern. Ich würde gerne nur mit gcc, make und Editor bewaffnet den STM32 erobern (oder auch andere ARMs, aber so ein Discovery- und Nucleo-Board hab ich mir nunmal ausgeguckt). Die Datenblätter schrecken mich nicht ab, aber diese Library-Geschichten für die STM32 ... irgendwie erinnert mich das an digitalWrite(). Kann das sein?
@Konrad S. (maybee) >Ich würde gerne nur mit gcc, make und Editor bewaffnet den STM32 erobern >(oder auch andere ARMs, aber so ein Discovery- und Nucleo-Board hab ich >mir nunmal ausgeguckt). So wie in der Steinzeit. Viel Spaß. Andere Leute nutzen sinnvollerweise eine gescheite IDE, die von Profis zusammengebaut wurde.
Falk Brunner schrieb: > So wie in der Steinzeit. Viel Spaß. Andere Leute nutzen sinnvollerweise > eine gescheite IDE, die von Profis zusammengebaut wurde. Und jede dieser tollen IDEs hat ihre eigenen Philosophie für den Startup-Code und das Linkerfile und alle möglichen Libs. Darum ist es ja immer so schön "einfach" Projekte die in einer IDE entwickelt wurden auf eine andere zu portieren. Besonders für Anfänger die erst mal das grundsätzliche Konzept dahinter verstehen wollen. Ich persönlich brauche die IDE (in meinem Fall Crossworks) nur zum Debuggen. Am liebsten wäre mir nur der Debugger ohne den ganzen IDE Kram. Segger baut da gerade was. Aber leider ist es wohl in Zukunft an eine Lizense für den j-link pro gebunden, womit es dann auch wieder ausscheidet. Ich verlange ja nicht von einem Anfänger, dass er den Startup selber schreibt oder komplett durchschaut. Aber sinnvoll ist es nicht in jeder IDE was anders zu haben. Als Editor reicht sowas wie n++. Und für die 3 c(c++) Dateien am Anfang ist auch kein makefile nötig, da reicht ein cmd oder shell-Script völlig aus. Was nützt es einem Anfänger, wenn er wie wild in der IDE rum klickt und am Ende zwar irgendwas geht aber das Verständnis dafür was wirklich dazu gehört fehlt trotzdem?
Entweder überschaubare (und intuitive) Bedienung und schnelle (kleine) Erfolge unter Verzicht einer langen und mühevollen Einarbeitung (mit Rückschlägen) oder genau andersherum: Wofür entscheidet sich ein Anfänger? Der "einfache" Weg, den die vom Hersteller mitgegebenen IDEs und Libs vorgeben, schließt doch nicht automatisch den 2. Weg, die tiefere Einarbeitung aus. Aber wenn man schon mal ein paar Erfolge hat (und damit eine "Rückfallebene", wenn man sich vertan hat), dann geht die tiefere Einarbeitung leichter von der Hand - es sind dann schon (wenn auch einfache) Kenntnisse vorhanden. Wählt man den 2. Weg, so sind fast keine Kenntnisse vorhanden wenn mal was nicht tut. Und dann beginnt das Suchen ... Selbstkasteiung ist nicht jedermans Sache. Warum also nicht mit einfachen weitestgehend vorgefertigen, aufeinander abgestimmten und funktionierenden Tools beginnen und danach in das 'Eingemachte' zu gehen? Blackbird
Ich arbeite seit etwa zwei Jahren mit dem Cortex M3 und hatte zuvor lediglich ein zweiwöchiges Praktikum in der Uni, in dem wir auf einem MSP430 in ASM rumgeeiert haben. Bin dann in einer Firma eingestiegen, die Keil MDK verwendet. C/C++ kannte ich natürlich schon etwas. Habe ein Discovery Board mit stmf103 bekommen und sollte ein paar Wochen rumspielen. Dazu gabs ein paar einfache Programme unseres Software Spezis. Ganz ehrlich - ich war froh, mich erstmal NICHT um linker script, makefile, compiler und flashen zu kümmern, sondern um den Mikrocontroller, es gab schon genug zu lernen. Oben wird was von CAN/Ethernet/LCD etc pp gesprochen. Leute das ist doch noch ewig lange hin. Bis dahin reichen doch die 32 kB locker aus! Ich bin selbst erst bei meinem letzten Projekt auf etwa 40 kB gekommen, da war dabei: 2x UART (relative lange state machine) 2x ADC 1x DAC 1x SPI mit ziemlich umfangreicher digitaler Signalverarbeitung inkl. extended kalman filter. Zugegebenerweise ohne OS, ich weiß nicht genau wie viel z.B. Keil RTX schluckt. Es wird aber als "lightweight" deklariert. Achso, 10 kB oder so schluckt alleine printf, das ich auf Grund der geilen Debugmöglichkeiten über den Stimulus Port benutze (was man natürlich nicht tun muss) Und wenn man das Teil nicht jeden Tag benutzt dauert es vermutlich noch länger, bis man in die Beschränkung kommt. Ich kenne die anderen IDEs leider nicht ausführlich genug, um dazu was sagen, aber: für den Anfang ist eine IDE, die einem das Drumherum abnimmt verdammt hilfreich. Btw, hier wurde aus Kompatibilitätsgründen eine modifizierte Version der STM Std Lib verwendet. Finde die auch nicht so toll, aber man kann relativ schnell durchblicken, was die einzelnen Funktionen so machen, wenn die reference manual pdf gleichzeitig offen ist ;) edit: Die Einarbeitung kommt von alleine, wenn man sich damit beschäftigt. Früher oder später kommt man doch an die Interna der IDE heran, wenn man rumspielt und ein bisschen was liest. Und was bringt es einem Anfänger, sich bestens mit dem Linker auszukennen, aber noch keine Zeile code geschrieben hat? Das kommt von alleine! Schöne Grüße, Jan
:
Bearbeitet durch User
Falk Brunner schrieb: > So wie in der Steinzeit. Viel Spaß. Andere Leute nutzen sinnvollerweise > eine gescheite IDE, die von Profis zusammengebaut wurde. Die Leute haben eben unterschiedliche Voraussetzungen und Anwendungsfälle. Diese ganzen IDEs bringen mich nicht voran, weil sie schnarchlangsam sind und/oder nicht auf allen nötigen Plattformen laufen. In den Jahren, seit ich beruflich mit IT und Softwareentwicklung meine Brötchchen verdiene, habe ich mir ein paar Strategien erarbeitet, die auf allen Plattformen sehr gut funktionieren. Und die beruhen im Wesentlichen auf dem Unix-Kommandozeilenbaukasten. temp schrieb: > Und für die 3 c(c++) Dateien am Anfang > ist auch kein makefile nötig, da reicht ein cmd oder shell-Script völlig > aus. Da verzettelst du dich, wenn du das gegen mögliche Fehler absichern willst. Ein Standard-Makefile für die einfachen Fälle und du hast keine Sorgen damit. Blackbird schrieb: > Entweder überschaubare (und intuitive) Bedienung und schnelle (kleine) > Erfolge unter Verzicht einer langen und mühevollen Einarbeitung (mit > Rückschlägen) oder genau andersherum: Wofür entscheidet sich ein > Anfänger? Anfänger != Anfänger In meinem Fall bezieht es sich auf ARM-µCs. Mit AVR-µCs komme ich ganz gut zurecht, ein paar andere Mikroprozessor-Architekturen habe ich auch schon programmiert, auch im Assembler. Beruflich mache ich viel mit C. Jetzt will ich hobbymäßig mal bei ARM gucken. Aber nicht ARM-Linuxe, denn die kenne ich schon. Ich will mich schon direkt mit dem Controller beschäftigen. Blackbird schrieb: > Selbstkasteiung ist nicht jedermans Sache. Eben deswegen will iche keine IDE! ;-)
Blackbird schrieb: > Der "einfache" Weg, den die vom Hersteller mitgegebenen IDEs und Libs > vorgeben, schließt doch nicht automatisch den 2. Weg, die tiefere > Einarbeitung aus. > Aber wenn man schon mal ein paar Erfolge hat (und damit eine > "Rückfallebene", wenn man sich vertan hat), dann geht die tiefere > Einarbeitung leichter von der Hand - es sind dann schon (wenn auch > einfache) Kenntnisse vorhanden. Diesen Weg bin ich beim Einstieg auch gegangen. LPCXpresso und LPC1769 bzw. Attolic und STM32F103. Das war viel vergebene Zeit. Das LPCXpresso1769 Board ist zwar ganz nett gewesen. Leider ist man damit auf die LPCXpresso-IDE festgenagelt. Wechselt man zu STM32 muss man auch die IDE wechseln. Aus der ursprünglich großzügig bemessenen Atollic IDE wurde irgendwann eine stark eingeschränkte. Spätestens zu diesem Zeitpunkt hatte ich davon und mit allem was auf Eclipse basiert den Kanal voll. Ab da habe ich dann makefiles verwendet und die Projekte selbst gepflegt. Viele Teile meiner Codesammlung sind so zwischen STM32 und LPC1xxx austauschbar. Zum Debuggen habe ich zu dem Zeitpunkt die 32k Version von Keil benutzt. Eine Vollversion von Keil oder IAR kam für mein privates Vergnügen nie in Frage. Dazu sind sie zu teuer. Ausserdem ist der Keil-Compiler und Assembler sicher nicht schlecht, aber leider nur zu sich selbst kompatibel. Aber man kann damit prima extern mit gcc erstellten Code debuggen. Am Ende bin ich bei Crossworks gelandet und damit auch sehr zufrieden. Besonders mit dem Debugger. Aber was soll's, ich will hier keinem meine Meinung aufzwingen. Konrad S. schrieb: >> Und für die 3 c(c++) Dateien am Anfang >> ist auch kein makefile nötig, da reicht ein cmd oder shell-Script völlig >> aus. > > Da verzettelst du dich, wenn du das gegen mögliche Fehler absichern > willst. Ein Standard-Makefile für die einfachen Fälle und du hast keine > Sorgen damit. Da stimme ich dir zu. Trotzdem ist es für einen der sich mit der Syntax in den makefiles noch nie beschäftigt hat eine zusätzliche Hürde, die für "blinky" erst mal nicht nötig ist. Konrad S. schrieb: > In den Jahren, seit ich beruflich mit IT und Softwareentwicklung > meine Brötchchen verdiene, habe ich mir ein paar Strategien erarbeitet, > die auf allen Plattformen sehr gut funktionieren. So ist es. Die IDE's kommen und gehen. Allein für die PC-Entwicklung von C++ Programmen habe ich von Borland, VC, Zortec bis Watcom fast alle Versionen durch. Von anderen Programmiersprachen wollen wir gar nicht erst reden. Was man dabei vor allem lernt ist hassen! Und lieben! Nämlich seinen Editor mit seinen Einstellungen. Da spielt es keine Rolle für was man Code schreibt...
temp schrieb: > So ist es. Die IDE's kommen und gehen. Allein für die PC-Entwicklung von > C++ Programmen habe ich von Borland, VC, Zortec bis Watcom fast alle > Versionen durch. Von anderen Programmiersprachen wollen wir gar nicht > erst reden. Was man dabei vor allem lernt ist hassen! Und lieben! > Nämlich seinen Editor mit seinen Einstellungen. Da spielt es keine Rolle > für was man Code schreibt... Gut auf den Punkt gebracht!
@ Konrad S. (maybee) >> So wie in der Steinzeit. Viel Spaß. Andere Leute nutzen sinnvollerweise >> eine gescheite IDE, die von Profis zusammengebaut wurde. >Die Leute haben eben unterschiedliche Voraussetzungen und >Anwendungsfälle. Nö, es geht um EINEN klar umrissenen Anwendungsfall. "Welche ARM Modelle eignen sich für Anfänger?" Nicht um "Die Lieblingstricks der makefile-Artistik" > Diese ganzen IDEs bringen mich nicht voran, weil sie >schnarchlangsam sind und/oder nicht auf allen nötigen Plattformen >laufen. Bla. Die meisten, incl. mir, sind da eher einfach gestrickt. Bei denn reicht es, wenn die IDE auf EINER Plattform läuft. >In den Jahren, seit ich beruflich mit IT und Softwareentwicklung >meine Brötchchen verdiene, habe ich mir ein paar Strategien erarbeitet, >die auf allen Plattformen sehr gut funktionieren. MÖÖÖP! Thema verfehlt! > Und die beruhen im > Wesentlichen auf dem Unix-Kommandozeilenbaukasten. Jaja, die Neanderthaler sind noch nicht ausgestorben ;-) Es geht aber gar nicht um die Frage IDE oder Kommandozeile, sondern einen SINNVOLLEN, möglichst reibungsarmen EINSTIEGT! Dass man ba einem bestimmten (semi)professionellem Level dann schon ein wenig mehr will und ggf. braucht, aus es die meisten IDEs bieten, ist doch eine ganz andere Frage und eigentlich unstrittig! >Anfänger != Anfänger >In meinem Fall bezieht es sich auf ARM-µCs. Womit wir mal wieder ein Sprach- und Kommunikationsproblem haben. Und selsbt dann würde ICH den Umstiegt nicht über die Kommandozeile machen wollen! Ich behaupte mal, dass 90% aller Programme im Hobby- und semiprofessionellen Bereich NICHT auf die Superpower eines handgestrickten Makefiles angewiesen sind.
Falk Brunner schrieb: > Nö, es geht um EINEN klar umrissenen Anwendungsfall. > > "Welche ARM Modelle eignen sich für Anfänger?" Ah, OK. Und, möchtest du zu diesem Thema etwas beitragen? ;-)
TomiVoll schrieb: > Ich habe hier ein STM32F411RE Nucleo Board und bin leider ziemlich > überfordert. > Das debuggen ging weder mit Eclipse, KEIL, noch mit CooCox. > Das flashen ging dann immerhin mit dem ST Utility Programm. > > Und dann will ich eben mal wissen wie man die Taktrate einstellt und > denke WTF. > Anscheinend eine Wissenschaft für sich. > Ich kann im Eclipse Editor die Taktrate angeben, aber kann nirgendwo im > Code die Einstellung nachvollziehen. Du stellst es grundsätzlich verkehrt an! Also, so einen ARM oder Cortex in C zu programmieren, ist ganz genau so, wie irgend einen anderen µC in C uzu programmieren. Das als Anfang. Versuche mal zu begreifen, daß du dich beim Programmieren nicht zu allererst mit irgend einer IDE und deren Befindlichkeiten befassen mußt, sondern mit der eigentlichen Hardware! Das ist der eigentliche Knackpunkt. Da liest man zu allererst das zuständige Referenzmanual. Normalerweise wird dort schon ganz gut beschrieben, wie man den Systemtakt einstellt, die Funktionalität der Port-Pins so einstellt, wie man das in der onkreten Schaltung benötigt und wie man dann sowas wie main() aufruft. Zum Einstellen der diversen Takte (ja, diese µC Klasse hat deren mehrere) braucht man das Beschreiben von diversen Hardware-Registern.. aber KEINE IDE! Für all so etwas braucht man eigentlich gar keine IDE. Lerne dshalb erst einmal, deine Tools aus eigener Kraft aufzurufen. Wenn du das kannst, dann ist immer noch Zeit, sich ne IDE anzuschauen, sofern diese eine Arbeitserleichterung mit sich bringt. Guck dir mal die Lernbetty hier im Forum an, da kannst du sehen, wie man die Tools von Keil und GCC per simpler Batch-Datei selbst aufruft. Lerne draus! W.S.
Markus Müller schrieb: > auf ein und der selben Leier und mobbt in allen STM32 Threads rum ohne > auch nur einen sinnvollen Beitrag zu leisten Der besteht darin, den Blick auf das Projekt-Ziel zu richten und welcher Aufwand dazu gerechtfertigt ist. Als Anfänger wäre ich vor vielen Jahren für solcherlei Orientierungshilfe auch dankbar gewesen und sie ist in jedem Thread, der die richtigen Mittel zum Ziel thematisiert genau richtig. Wenn sich ein M.M. oder wer auch immer damit "gemobbt" fühlt ist mir das schnuppe. Anders sieht es nur aus wenn vom Projekt her von vornherein klar ist, daß es unbedingt der Leistung eines ARM bedarf, oder weil eben die Firma oder ein Herr Lehrer danach verlangt.
Warum muß eigentlich jeder Thread derart ausarten ? Wer mit ARM anfangen möchte der sollte sich einfach eines der vielen STM, TI oder NXP Boards beschaffen und einen entsprechenden Compiler / IDE + Umgebung dazu installieren. Bei den professionellen Tools wie Keil oder IAR sollte ein Einstieg mittels Beispiele schnell gelingen. Wie weit man abstrahieren möchte (CMSIS etc.) sollte jeder für sich entscheiden. Das bedeutet Libs oder / und Datenblätte studieren und gut ist. Freie Tools sind in der Regel nicht so einfach zu handhaben aber im Bereich ARM sind selbst diese zu haben. Gute Beispiele sind EM Blocks sowie CCS. Mit VI braucht mir allerdings keiner zu kommen :-). Hast du mit den Beispielen was anfangen können ? >> Überfordere ich mich als Anfänger mit dem STM32F4 oder sind alle ARM's >> so umständlich, vielfältig und kompliziert? Was genau überfordert dich denn ?
Moby schrieb: > Der besteht darin, den Blick auf das Projekt-Ziel zu richten und welcher > Aufwand dazu gerechtfertigt ist. Als Anfänger wäre ich vor vielen Jahren > für solcherlei Orientierungshilfe auch dankbar gewesen und sie ist in > jedem Thread, der die richtigen Mittel zum Ziel thematisiert genau > richtig. Das Projektziel besteht hier aber gerade darin sich in einen ARM (STM32) einzuarbeiten. Deine penetranten Auftritte lesen sich in etwa so als wenn jemand im Nespresso Forum ein Problem mit seiner Kaffeemaschine hat und ihm von einem Siggi erklärt wird daß Kamillentee ohnehin viel gesünder ist. Und auch viel einfacher in der Zubereitung da man keine Maschine dafür braucht. Natürlich kennt Siggi sich mit Kaffeemaschinen überhaupt nicht aus. Mit Pfefferminztee auch nicht denn mit Kamille war er bisher immer zufrieden. Klingt albern? Stimmt, ist es auch.
Mit solchen Vergleichen ist das immer so eine Sache. Hast Recht. Sie sind albern.
Also ich sehe als Anfänger ARM eher für embedded Systeme und Mikrocontroller wie z.B. auch von Atmel oder Microchip etc. eher für direktere Steuer bzw. Messfunktionen. Mikrocontroller sind für einen Anfänger natürlich leichter zu bewältigen. Man kann auch gleich miteinem ARM in die vollen gehen. Die Lernkurve steigt dann natürlich erstmal kräftig an, aber auch das kann man mit etwas Geduld schaffen.
Jemand schrieb: > Also ich sehe als Anfänger ARM eher für embedded Systeme Cortex A und R sind für embedded Systeme / Linux gedacht aber Cortex M die es schon ab DIP-8 gibt bestimmt nicht, sind Mikrocontroller.
Was ist mit den Infineon Cortex, sind die nicht einfacher zu programmieren?
TomiVoll schrieb: > Überfordere ich mich als Anfänger mit dem STM32F4 oder sind alle ARM's > so umständlich, vielfältig und kompliziert? Stell Dir einfach mal vor, Du hättest einen AVR vor Dir und es gäbe überhaupt keine Resourcen auf die Du im Internet zu greifen könntest. Du wärst genauso überfordert. Die Cortex-M4, Cortex-M3 usw sind relativ neu und es gibt einfach keine so große Community, wie es bei den PICs und AVRs der Fall ist. Die meisten fühlen sich sicher im Umgang mit diesen uCs haben aber eigentlich gar nichts verstanden, da Copy&Paste meistens die Lösung bringt. Fang am besten ganz, ganz klein an. Setze Dich vor allem mit der Architektur von uC ausseinander und versuche zunächst das startup-Script zu verstehen und zu benutzen. Lass was blinken. TomiVoll schrieb: > Das debuggen ging weder mit Eclipse, KEIL, noch mit CooCox. > Das flashen ging dann immerhin mit dem ST Utility Programm. Versuche auch mal ein Firmware-Update des integrierten Programmers durchzuführen.
@Bernd N Danke, dein Beispiel hat mit Em::Blocks funktioniert. Projektordner und die erzeugten Dateien sehen auch sonst übersichtlich aus, irgendwie besser als in Eclipse mit ARM Plugin und Cortex Template. Schade nur das Em::Blocks nur für Windows verfügbar ist. Was mich verwirrt ist der abweichende Syntax bzw. die abweichenden Befehle die man in Beispielen findet. Wie hier beschrieben: Beitrag "Re: Welche ARM Modelle eignen sich für Anfänger?"
>> Was mich verwirrt ist die abweichende Syntax Ok, deswegen der Hinweis CMSIS. Du kannst auch vollständig darauf verzichten. Du kannst dann eben auch direkt die Register verwenden die im entsprechenden .h File stehen. Die Port initialisierung verwendet derzeit die Lib Funktionen aus der stm32f4xx_gpio.c, schau dir die mal an. Als Einstieg lese mal das hier: http://www.diller-technologies.de/stm32_wide.html
Hier ein Demo-Code für ein Blink-LED für den Anfang: http://www.mikrocontroller.net/articles/STM32_CooCox_Installation Ist zwar mit der CoIDE, sollte auch mit Em::Blocks funktionieren. Die Register werden ohne Lib direkt angesprochen.
Markus Müller schrieb: > Die Register werden ohne Lib direkt angesprochen. Da ich bisher mit LPC gearbeitet habe nicht mit STM32 würde mich interessieren: in dem Beispiel wird keine CLK initialisiert, läuft der STM32 dann ohne eine PLL mit einem internen Oszillator? Was ist dann der Takt? Zudem muss ich sagen, beim LPC haben die Register eingängigere Namen und die Ports sind nummeriert, ich kann also mit einem Register Px.0 bis Px.31 setzen. Wie sieht es beim STM32 mit Bitbanding auf 8/16/32-bit aligned aus?
>> in dem Beispiel wird keine CLK initialisiert Das passiert in der "SystemInit ();". Clock ist 168 MHz. >> Zudem muss ich sagen, beim LPC haben die Register eingängigere >> Namen und die Ports sind nummeriert Namen sind Schall und Rauch :-) Als ich mit dem LPCs gearbeitet habe fand ich die Ports auch nicht gerade übersichtlich. Beim STM ist es erheblich einfacher für einen Anfänger, GPIOA bis ... GPIOG etc. Jeder Port hat seine PINs und eigentlich ist es wie bei jedem anderen Controller. Was verwirrend sein mag ist die Vielfalt der Port Eigenschaften, Pull Up/Down Ja / Nein, eigene Port Clock auch noch mit unterschiedlichen Geschwindigkeiten, Eingang oder Ausgang...
1 | void gpIO_Init (void) |
2 | {
|
3 | RCC_AHB1PeriphClockCmd ( RCC_AHB1Periph_GPIOG, ENABLE ); // Takt für Port_G |
4 | |
5 | GPIO_InitTypeDef GPIOG_InitStructure; |
6 | GPIOG_InitStructure.GPIO_Mode = GPIO_Mode_OUT; // Port_G als Ausgang |
7 | GPIOG_InitStructure.GPIO_Pin = LED_GREEN | LED_RED; // PG 13 (green LED), PG 14 (red LED) PIN 128, 129 STM32F429ZIT6 |
8 | GPIOG_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // Port_G speed (2, 25, 50, 100 MHz) |
9 | GPIOG_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL; // kein Pull Up / Down |
10 | GPIO_Init ( GPIOG, &GPIOG_InitStructure ); |
Das Ganze ist als struct per Port organisiert. Wirklich nicht kompliziert. Man sollte sich einfach mal ein Grundgerüst anschauen und den Code dazu studieren. Das war bei den LPC nicht sehr viel anders, ich habe mit dem 1768 gearbeitet und der ist auch nicht gerade ein einfacher Controller.
Angehängte Dateien:
-
STM.png
400 KB
Im Anhang mal ein Screenshot, mit den Paar Zeilen Beispiel Code steht ja noch kein Projekt. Die Clock Einstellungen passieren im Startup Code. Ich kann auch gerne das Projekt hochladen.
Bernd N schrieb: > Das passiert in der SystemInit() Clock ist 168 MHz Also eine versteckte Funktion, die wahrscheinlich aus dem Startup-Code aufgerufen wird? Kann man auch ganz ohne Library arbeiten? In dem Tutorial steht, dass ohne CLK Initialisierung immer mit 72 MHz gestartet wird, auch wenn der STM32 z.B. nur 48 MHz kann. Das wäre ja wie verfusen beim AVR. Die LPC werden immer mit 12 MHz gestartet. Bernd N schrieb: > ich habe mit dem 1768 > gearbeitet und der ist auch nicht gerade ein einfacher Controller Stimmt, der war noch merkwürdig, musste aber ja abwärtskompatibel zum ARM7 sein. Der einzige der mit 4 MHz gestartet wird. Wenn ich bei einem neueren z.B. dem kleinen LPC810 ohne Library arbeite, definiere ich mir structs und Addressen aus dem Manual. Der hat z.B. 6 GPIO somit: typedef struct { __REG32 P0_0 : 1; __REG32 P0_1 : 1; __REG32 P0_2 : 1; __REG32 P0_3 : 1; __REG32 P0_4 : 1; __REG32 P0_5 : 1; __REG32 :26; } __gpio0_bits; __IO_REG32_BIT(DIR0, 0xA0002000, __READ_WRITE, __gpio0_bits); __IO_REG32_BIT(PIN0, 0xA0002100, __READ_WRITE, __gpio0_bits); DIR0_bit.P0_4 = 1; // output PIN0_bit.P0_4 = 1; // high
Lothar schrieb: > Bernd N schrieb: >> Das passiert in der SystemInit() Clock ist 168 MHz > > Also eine versteckte Funktion, die wahrscheinlich aus dem Startup-Code > aufgerufen wird? Nein, nix wird da versteckt :-) Markus schreibt doch weiter unten auf der Seite mit dem Beispiel: --- Nun da das erste BlinkLED läuft ist der erste Schritt getan und ohne Takt Initialisierung läuft der STM32F4xx mit dem HSI 16MHz (interner RC-Oszillator). Mit Aufruf der Funktion "SystemInit();" aus der ST Library wird: HSE aktivieren (externer Quarz) PLL aktivieren Da ST jedoch nicht weiß welcher Quarz am Borad angeschlossen ist, so ist in der Datei "system_stm32f4xx.c" der Quarz auf 25MHz voreingestellt. Diese Einstellung muss man ändern indem man die Datei "system_stm32f4xx.c" öffnet und das "#define PLL_M" auf die richtige Quarzfrequenz einstellt. Beispiel: PLL_M 25 << Quarz mit 25MHz PLL_M 8 << Quarz mit 8MHz In der Datei "main.c" wird nun noch die h-Datei mit eingebunden: #include "system_stm32f4xx.h" Und zu Anfang in der Routine main() der Aufruf SystemInit(); mit hinzugefügt. Nun sollte das Blink-LED Demo in etwa der 10-Fachen Geschwindigkeit laufen. Damit die anderen ST-Lib Funktionen korrekt funktionieren muss in "stm32f4xx.h" folgenden Wert auf den Quarz geändert werden (Eingabe in Hz): #define HSE_VALUE ((uint32_t)8000000) --- Ganz ohne Quarz und PLL läuft der STM32 also mit 16 MHz. > Kann man auch ganz ohne Library arbeiten? Ja das geht. > Tutorial steht, dass ohne CLK Initialisierung immer mit 72 MHz gestartet > wird, auch wenn der STM32 z.B. nur 48 MHz kann. Das wäre ja wie verfusen > beim AVR. Die LPC werden immer mit 12 MHz gestartet. Das stimmt mWn auch nicht. Wie gesagt: die starten auf jeden Fall immer mit 16 MHz, bevor man irgendwie am Takt rumfummelt. Verfusen geht beim STM32 prinzipiell nicht. In welchem Tutorial steht das? > Stimmt, der war noch merkwürdig, musste aber ja abwärtskompatibel zum > ARM7 sein. Der einzige der mit 4 MHz gestartet wird. Wenn ich bei einem > neueren z.B. dem kleinen LPC810 ohne Library arbeite, definiere ich mir > structs und Addressen aus dem Manual. Der hat z.B. 6 GPIO somit: > > typedef struct { > __REG32 P0_0 : 1; > __REG32 P0_1 : 1; > __REG32 P0_2 : 1; > __REG32 P0_3 : 1; > __REG32 P0_4 : 1; > __REG32 P0_5 : 1; > __REG32 :26; > } __gpio0_bits; > > __IO_REG32_BIT(DIR0, 0xA0002000, __READ_WRITE, __gpio0_bits); > __IO_REG32_BIT(PIN0, 0xA0002100, __READ_WRITE, __gpio0_bits); > > DIR0_bit.P0_4 = 1; // output > PIN0_bit.P0_4 = 1; // high Auch eine schöne Sache - mit den registertypen kenne ich mich nicht so aus, aber das sollte eigentlich auch gehen. Bitbanding gibt es auch beim STM32.
Bernd N schrieb: > Im Anhang mal ein Screenshot, mit den Paar Zeilen Beispiel Code steht ja > noch kein Projekt. Die Clock Einstellungen passieren im Startup Code. > > Ich kann auch gerne das Projekt hochladen. Hallo Bernd, es wäre sehr nett, wenn Du Dein Projekt hochladen könntest. Ich beginne gerade, micht mit dem STM32F2 (F429-Disc.) zu beschäftigen, da wäre dies sehr hilfreich. Danke, Thomas
Chris D. schrieb: > Ganz ohne Quarz und PLL läuft der STM32 also mit 16 MHz. Nicht jeder STM32 läuft zu Anfang mit 16MHz. Die STM32F1xx nur mit 8MHz da der interne RC Oszillator auf 8 MHz kalibriert ist. Der STM32F2xx und STM32F4xx mit 16 MHz. Steht für den jeweiligen Chip im Datasheet unter HSI RC Oszillator.
Markus Müller schrieb: > Nicht jeder STM32 läuft zu Anfang mit 16MHz. Die STM32F1xx nur mit 8MHz > da der interne RC Oszillator auf 8 MHz kalibriert ist. > Der STM32F2xx und STM32F4xx mit 16 MHz. Steht für den jeweiligen Chip im > Datasheet unter HSI RC Oszillator. Danke für den Hinweis :-) Liegt wohl daran, dass ich nur mit den F2-F4 arbeite ;-)
@ Chris D. (myfairtux) (Moderator) Benutzerseite
>Liegt wohl daran, dass ich nur mit den F2-F4 arbeite ;-)
Sind die anderen Funktionstasten auf deiner Tastatur kaputt? ;-)
>> Ich beginne gerade, micht mit dem STM32F2 (F429-Disc.) zu beschäftigen @Thomas http://mikrocontroller.bplaced.net/wordpress/?page_id=2736 Dann ist das die richtige Seite für dich. Dort gibt es reichlich Code Beispiele. Dies sind alles Lauffähige CoCox Projekte und EMBlocks kann diese importieren. Da kannst du von der blinkenden LED bis zum Osci alles ausprobieren und dich langsam einarbeiten.
Chris D. schrieb: > Verfusen geht beim STM32 prinzipiell nicht. In welchem Tutorial steht das? Dieses Tutorial wurde weiter oben mal empfohlen: http://www.diller-technologies.de/stm32_wide.html Das hatte ich aber nicht genau genug gelesen, da steht, "wenn man SystemInit() aufruft" und "Standardmäßig wird der Takt auf 72 MHz eingestellt, unter der Annahme, dass ein 8 MHz Quarz angeschlossen ist. Achtung: Diese hohe Taktfrequenz wird nicht von jedem Chip unterstützt" Das heisst also, wenn man SystemInit() gar nicht aufruft, läuft der interne Oszillator. Und wenn man es auf einem 48 MHz STM32 ohne Änderung aufruft, geht nichts mehr, wohl auch kein Debuggen. Dann kann man vermutlich nur mit dem seriellen Bootloader noch ran (ist beim LPC jedenfalls so).
Lothar schrieb: > Dann kann man > vermutlich nur mit dem seriellen Bootloader noch ran (ist beim LPC > jedenfalls so). da die Cortexe im ResetVector starten und im debugmode auch dort landen kann man auch bei zu hohem takt die dinger neu flashen ich habe so zum spass vereinzelte cortexe übertaktet von max 100MHz bin ich teils bis 160Mhz gekommen eh dann wirklich der kern ausgestiegen ist. wichtig dabei: flashen war immer möglich ... zur not eben erstmal flash löschen.. dann ist das thema eh geklärt
Der Thread ist ja jetzt schon wieder in paar Wochen alt, ich möchte trotzdem noch einen Beitrag zum Thema "STM32 Programmieren mit Registern" in die Runde werfen: http://www.powerloss.de/2014/11/stm32-tutorial-teil1-einstieg-in-die-programmierung-des-stm32-auf-registerebene/
Mitleser schrieb: > Der Thread ist ja jetzt schon wieder in paar Wochen alt, ich möchte > trotzdem noch einen Beitrag zum Thema "STM32 Programmieren mit > Registern" in die Runde werfen: Der Artikel ist ja nagelneu, vielleicht von Deinem guten Bekannten? ;-)
Ich denke Atmel ARM könnte ein bisschen einfacher sein, weil es eine komplette IDE direkt von Atmel gibt. Glaube bei XMC gibt's auch eine. Dafür bezahlt man wahrscheinlich für die Entwicklungsboards und Debugger mehr. major
Heiner schrieb im Beitrag #3895062: > Also fuer einen Anfaenger ist jeder ARM ungeeignet, egal > welche Ausfuehrung. Denk mal drueber nach. Ich halte das für völlig falsch. TomiVoll schrieb: > Überfordere ich mich als Anfänger mit dem STM32F4 oder sind alle ARM's > so umständlich, vielfältig und kompliziert? Nein. Die Controller selbst sind eigentlich recht einfach zu verstehen und zu programmieren. Dein Problem besteht darin, daß du zu allererst angefangen hast, nicht deinen Chip verstehen zu wollen, sondern stattdessen dich mit diversen IDE's herumgeplagt hast. Das ist in fast ALLEN Fällen genau der Grund für Frust. Entweder läuft dann eine Demo glatt durch und die LED blinkt, ohne daß der Benutzer die Funktionalität begriffen hätte, oder es läuft eben nicht durch - und dann ist Frust ohne Verstehen des Warums angesagt. Ich will nicht sagen, daß IDE's an sich schlecht wären, aber sie versuchen vehement, den Abstand zwischen dem Benutzer und seinem eigentlichen Objekt zu maximieren und sich selbst dazwischen zu schieben. Dadurch muß man zweierlei lernen: den eigentlichen Controller UND auch noch die völlig andersartige Sichtweise der Programmierer, die die IDE geschrieben haben. Mein Rat: Erstens konzentriere dich auf die Doku zu deinem µC. Die sind im Prinzip alle schlecht, aber da ist m.E. Philips(NXP) noch deutlich besser als ST und der Rest. Zweitens lerne du, deine Tools selbst und OHNE eine IDE aufzurufen und zu benutzen. Wenn du das kannst, dann wäre die Zeit, sich diverse IDE's anzusehen, weil du dann Ahnung von der eigentlichen Sache hast und die Schlechtigkeiten der IDE's eher erkennen und einschätzen kannst. (gebetsmühle an) Guck dir zumindest informativ mal die Lernbetty hier im Forum an, die ist zum Einstieg in die ARM-Welt gedacht. Manches (wie ARM versus THUMB) ist inzwischen durch die Cortexe überholt, aber nicht die prinzipielle Herangehensweise ans Thema. (gebetsmühle aus) W.S.
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.