Liebe ARM-Experten, ich möchte in die ARM-Prozessortechnik einsteigen und finde 1 Mio. Seiten dazu im Internet. Leider weiß ich, daß man viel Zeit verlieren kann, wenn man den falschen Einstieg wählt, daher interessiert mich Eure persönliche Einschätzung bzw. Euer Rat. Ich habe hier 3 Einstiegsboards herumliegen und frage mich, mit welchem Board/ARM-Prozessor ich optimalerweise beginnen sollte: - TI: Stellaris Launchpad LM4F120 - NXP: LPC812 mbed/Xpressoo (Arduino compatible) - ST: STM32F4 Discovery (habe eine leichte Präferenz hierzu) Insbesondere folgende Kriterien sind mir wichtig: - Für welches Board/Prozessor gibt's die besten Tutorials? (Ich bin Euch für jeden guten Link dankbar!) - Gibt's empfehlenswerte Bücher? - Welches Board wird von der Community am besten supported? - Für welches Board gibt's die beste kostenlose IDE (ohne Code-Limit!!)? Mein Vorwissen: - C-Kenntnisse & Passable C++ - Kenntnisse - AVR-8-Bitter-Kenntnisse (Assembler + C) - Elektronik-Kenntnisse - Bin vor 2-3 Jahren mal bis zum "Blinky" auf STM32F4 Discovery gekommen - Kann Doku in Englischer & Deutscher Sprache lesen - Logic-Analyzer + Oszi vorhanden Mein Ziel: - Die Grundtechniken beherrschen (I/O, UART, I2C, PWM, DMA, ggf. USB) - Fernziel: OV7670-Kameramodul auslesen und auf LCD-Display ausgeben Es wäre supernett, wenn Ihr mir ein paar Tipps gebt und mich auf die "richtige Schiene" setzen könntet. Gerne könnt Ihr mir auch schildern, wie Ihr Euch in Euren jeweiligen ARM-Prozessor eingearbeitet habt und wie Ihr heute vorgehen würdet, wenn Ihr heute nochmals am Beginn stehen würdet. Insbesondere interessieren mich Links auf Einstiegstutorials und gute Doku. Bitte hier aber keine Glaubenskriege vom Zaun brechen - es führen sicherlich mehrere Wege nach Rom ... Viele Grüße Igel1
Andreas S. schrieb: > - TI: Stellaris Launchpad LM4F120 Hierzu gibt es Bücher in English, ("Introduction to ARM Cortex-M Microcontrollers", "Real-Time Interfacing to ARM-Cortex-M Microcontrollers", usw.) meines Wissens relativ aktives Forum bei TI. > - NXP: LPC812 mbed/Xpressoo (Arduino compatible) Sehr große und aktive community bei mbed > - ST: STM32F4 Discovery (habe eine leichte Präferenz hierzu) hier im Forum gut vertreten Hardware: mit allen Dreien kannst Du sofort anfangen. Software: für alle drei frei verfügbar, egal, ob Kommandozeilenfreak oder IDE-Anhänger tutorials: kenn ich nur für STM32 (subjektiv gefärbt ohne irgendeinen Anspruch auf Vollständigkeit), siehe Artikel hier im Forum
Also ich empfehle den STM. Da gibt es mehrere kostenlose IDEs, sehr viele Tutorials und wie du siehst sogar im Wiki ein Subwiki. Dazu gibt es z.B. den CubeMX, der mittlerweile einen viel Arbeit abnimmt. Auch wenn manchmal noch ein paar Fehler in der HAL sind, ist es immer noch besser, als wenn ich alles selbst baue.
Dein Grundlagen Ziel bezieht sich nicht auf den ARM core, sondern auf die Peripherals. Und die sind herstellerspezifisch. ;-)
Andreas S. schrieb: > ich möchte in die ARM-Prozessortechnik einsteigen und finde 1 Mio. > Seiten dazu im Internet. Leider weiß ich, daß man viel Zeit verlieren > kann, wenn man den falschen Einstieg wählt, daher interessiert mich Eure > persönliche Einschätzung bzw. Euer Rat. Ich verstehe deine Startposition nicht: Du willst "einsteigen", aber was meinst du konkret damit? Willst du bloß ein wenig herumprogrammieren? Das klingt bei "Die Grundtechniken beherrschen (I/O, UART, I2C, PWM, DMA, ggf. USB)" nämlich so. Willst du bloß in irgend einer IDE herumgucken, was es da alles an Whistles&Bells gibt? Oder verfolgst du ein konkretes Ziel - mal abgesehen von deinem Fernziel? Also, wenn du schon drei Marketing/Eval-Boards auf der letzten Embedded abgestaubt hast, dann würde ich dir - die Bastelhardware betreffend - am ehesten zu dem NXP-Board raten. Das scheint mir noch am ehesten überschaubar zu sein. Andreas S. schrieb: > Mein Vorwissen: > > - C-Kenntnisse & Passable C++ - Kenntnisse > - AVR-8-Bitter-Kenntnisse (Assembler + C) > - Elektronik-Kenntnisse Das scheint mir völlig ausreichend. Aber C++ kannst du hier steckenlassen. Arbeite dich eher in die Anfangsgründe der ARM-Assemblerprogrammierung ein. Nee, nicht daß du jetzt anfängst, Epen in Assembler zu schreiben, sondern nur, daß du dir ein Bild machen kannst über die Struktur der CPU, die Register und deren Verwendung, die Flags und Bedingungen, das Aufrufen und wieder Verlassen von Unterprogrammen und die Interrupt-Mechanismen. Lies dazu einfach das Referenzmanual zum Cortex M0 (für dein Board) von arm.com - die haben reichhaltige Dokus zum Herunterladen. Als nächstes wäre die Lektüre des Referenzmanuals zu deinem Chip von NXP dran. Wenn du dir dort einen Überblick verschafft hast, wäre damit eigentlich der wesentliche Grundstein gelegt. Wovon ich dir abrate, ist alles Draufgesetzte, weil das einem nur die Augen verkleistert mit unsäglich vielem Krempel, der sich zwischen dich und der zu verstehenden Hardware schiebt. Also kein Arduino, keine Eclipse, keine sonstige IDE, keine wohlgemeinten "Systembibliotheken", die das Ganze nur aufbauschen. Das Einzige, was du zu allererst brauchst, ist eine echte Toolchain, also vom Compiler bis hin zum Hexfile und dann eine Programmiermöglichkeit, die du bezahlen kannst (und willst). Die Chips von NXP haben m.W. eigentlich alle einen residenten Bootlader an Bord, so daß du fast kostenlos mit FlashMagic und einem billigen Usb->Serial Adapter (FTDI, Prolific, etc.) auskommst. Wenn du Geld ausgeben willst, dann kauf dir einen Seggerschen J-Link-Edu. So. Wie man sinnvoll programmiert, setze ich hier mal voraus, das solltest du ja bereits können. W.S.
W.S. schrieb: > zu dem NXP-Board raten. Das scheint mir W.S. schrieb: > Die Chips > von NXP haben m.W. eigentlich Tipps für Anfänger sollten auf fundierten Kenntnissen und eigenen Erfahrungen beruhen. "Hörensagen" nachbrabbeln ist hier nicht dienlich.
Andreas S. schrieb: > Ich habe hier 3 Einstiegsboards herumliegen und frage mich, mit welchem > Board/ARM-Prozessor ich optimalerweise beginnen sollte: Nur mal zum Verständnis: Du HAST 3 Boards besorgt und fragst nun, welches Du nehmen sollst? Hmm... Nimm das welches Deinen Anforderungen entspricht. Mich beschleicht aber immer wieder das Gefühl, dass die Leute diese Billigboards nehmen, die ab und zu als Marketing-Gag von Firmen herausgebracht werden. Und dann bleiben die Leute daran kleben, weil man sich die Einarbeitung in eine Kontrollerfamilie nur einmal antun will. Wäre es nicht besser, sich zunächst zu überlegen, WAS man machen will? Also ob es in Richtung Kommunikation, Steuerung, Regelung, Audio, Signalverarbeitung oder was auch immer geht. Und DANACH schaut, welcher Hersteller das passende Konzept anbietet. Und sich DAVON dann ein Board besorgt. Die Funktionalität der einzelnen Herstellervarianten unterschiedet sich in der Peripherie. Daher sollte man die Peripheriefunktionen unterschieden. Mal ehrlich, gemessen an der Einarbeitungszeit in einen neuen Kontroller spielt es kaum eine Rolle, ob ein Entwicklungsboard 15,- Euro oder 300,- Euro kostet. Wenn man aber merkt, dass der Kontroller von dem 15,- Euro Board eben doch nicht der richtige war, hat man am falschen Ende gespart. Gruß Joachim
Joachim schrieb: > Wenn man aber merkt, dass der Kontroller von dem 15,- Euro Board eben > doch nicht der richtige war, hat man am falschen Ende gespart. Und wenn man merkt, dass der Controller vom 300€ Board der falsche war, hat man richtig ins ... gegriffen. Die kleinen EVALs a la Discovery & Co. sind schon eine tolle Sache. Du kannst hier im Forum viele Projekte nachlesen oder dir die Wettbewerbsergebnisse vom XMC Contest anschauen.
@google: Danke für Deine Tipps. Hast Du die Bücher ergooglet oder tatsächlich gelesen und kannst sie aus eigener Erfahrung empfehlen? Mit welchem Board und welcher IDE arbeitest Du? Und welche Tutorial würdest Du lesen, wenn du nochmals mit ARM anfangen würdest? CAN-Fan schrieb: > Also ich empfehle den STM. Da gibt es mehrere kostenlose IDEs, sehr > viele Tutorials und wie du siehst sogar im Wiki ein Subwiki. Ja, momentan tendiere ich ebenfalls dahin - allerdings nur deshalb, weil ich die anderen Board/Prozessoren noch nicht kenne. Welche IDE'en empfiehlst Du mir? (sollte kostenlos und ohne Code-Limit sein) > Dazu gibt es z.B. den CubeMX, der mittlerweile einen viel Arbeit > abnimmt. Auch wenn manchmal noch ein paar Fehler in der HAL sind, ist es > immer noch besser, als wenn ich alles selbst baue. Danke für diesen Tipp. Vor 3 Jahren, als ich erstmals mit dem STM32F4 herumspielte, gab's dieses CubeMX noch nicht (oder ich hab's nicht gefunden). Kann mir gut vorstellen, dass einem dieses Tool das Leben deutlich erleichtert. Long long schrieb: > Dein Grundlagen Ziel bezieht sich nicht auf den ARM core, > sondern auf die Peripherals. Und die sind herstellerspezifisch. ;-) Hmmm - trotzdem muß ich diese Dinge erst einmal beherrschen, damit ich mit einem ARM überhaupt so weit komme, wie mit meinen heutigen ATmegas. Und weil die Frage zu meinen Anwendungsgebieten mehrmals kam, so muß ich Euch leider antworten, daß ich es heute noch nicht so genau weiß. Ich weiß nur, daß ich Hobby-Elektroniker bin und meine Projekte somit vom Umfang her beschränkt sind - genau wie meine Einarbeitungskapazitäten. Das Einzige, was unbeschränkt ist, sind meine Ideen :-) Hier ein paar davon (most important first): - Bildsensoren OV7660 auslesen und ggf. jpeg's daraus generieren (siehe auch mein Beitrag Beitrag "Re: Projekt Maus") - Anwendungen auf dem ARM per USB steuern - Daten vom ARM per USB in den PC einlesen (und umgekehrt) - Sensoren auslesen, Daten zwischenspeichern - Meine Roboter steuern (z.B. meinen RP6) - SD-Karten lesen und schreiben - Audiodaten aufnehmen, filtern, ausgeben W.S. schrieb: > Willst du bloß ein wenig herumprogrammieren? > Das klingt bei "Die Grundtechniken beherrschen > (I/O, UART, I2C, PWM, DMA, ggf. USB)" nämlich so. Das klingt jetzt aber ein bißchen abwertend ... Aber egal: ja,ich will zunächst einfach nur ein bißchen herumprogrammieren. Ich gehe anfangs oft wenig zielstrebig vor und spiele zunächst mit den Möglichkeiten der Prozessoren. Wenn ich die raushabe, gehe ich Konkreteres an. > Also, wenn du schon drei Marketing/Eval-Boards auf der letzten > Embedded abgestaubt hast, Muß Dich enttäuschen: ich habe alle drei gekauft - zwei davon gebraucht hier im Forum. > dann würde ich dir - die Bastelhardware betreffend - am > ehesten zu dem NXP-Board raten. Das scheint mir noch am ehesten > überschaubar zu sein. Kennst Du den Prozessor und hast Du bereits Erfahrungen mit einem ARM von NXP gemacht? Entspricht die aufgezeigte Vorgehensweise Deiner Vorgehensweise, die Du am NXP - ARM praktiziert hast? Welche Tutorials von arm.com meinst Du genau? Sicherlich ersaufe ich da wieder in Material. Welche davon hast Du gelesen und kannst sie aus eigener Erfahrung empfehlen? Du hast Dir sehr viel Mühe mit Deiner langen Antwort gemacht (Danke dafür) - basiert alles auf eigenen ARM-Erfahrungen? Joachim schrieb: > Nur mal zum Verständnis: Du HAST 3 Boards besorgt und fragst nun, > welches Du nehmen sollst? Hmm... Ja, das zeigt meine Unsicherheit ... > Nimm das welches Deinen Anforderungen entspricht. Die hatte ich hinter dem Satz "Insbesondere folgende Kriterien sind mir wichtig:" versteckt. Als Hobby-Elektroniker erbeitet man sich in einen MC ein und versucht dann später möglichst viele Probleme mit genau diesem Teil zu erschlagen - da gebe ich Dir recht. @All: Vielen Dank für die Mühen Eurer Antworten. Habe alles fein säuberlich gelesen und werde es beherzigen. Allerdings fehlen mir noch ein bißchen konkretere Ansagen a la: Wenn Du Board X nimmst, dann lese Artikel Y und nutze Toolchain Z - hat mich auch gehilft. Auch wenn's sicherlich sehr subjektiv wäre - so würde ich mich über solche Tipps (basierend auf Euren eigenen Erfahrungen) sehr freuen ... Viele Grüße Igel1
Also ich habe das Init-Zeugs per Cube erstellt und dann mit Eclipse die Makefile. Dann einfach unter Linux + Texteditor + JLinkCommander alles gemacht. Bei größeren Sachen nutze ich Eclipse + Plugins oder das neue SW4STM32. Das ist nichts anderes als ein Eclipse mit Plugins. Muss man nicht alles einzeln installieren. Was mich überrascht hat: Ich habe ein Board mit STM32F446RE designed. In Cube die IPs eingestellt und das mit SW4STM32 geöffnet, kompiliert und dann (von Hand, später das JLink Plugin installiert) auf die MCU geladen. Und ich konnte auf Anhieb Daten an den PC per USB versenden. (USB-Middleware kannst per Cube einstellen) Die Ernüchterung: Beim CDC-Empfangen gabs massive Probleme und ich hab Teile der Middleware ändern müssen. Auch bei dem STM32F302 hatte ich mit der HAL und dem DMA ein Problem. Also es ist nicht zu 100% fehlerfrei, aber wenn man das darunter einschätzen kann, spricht m.M.n. nichts dagegen. Was ich aber empfehle, und wie ich es gelernt habe: - Das Cortex-M3/M4 Buch (definitive guide for the ...) - Sich erstmal nur auf die CPU konzentrieren, Clock tree und Speicheranbindung etc. - Hab mit Assembler da einfache Sachen gemacht um die CPU zu verstehen etc. - Simples Linkerskript erstellt - Datenblätter zum ARM gelesen und dann eigentlich schon Datenblätter zur MCU und wie die Speicherbusse etc verlaufen. Und mit C angefangen.
Andreas S. schrieb: > Wenn Du Board X nimmst, dann lese Artikel Y und nutze Toolchain Z - hat > mich auch gehilft. Wenn du Board "STM32F4 Discovery" nimmst, dann nutze Toolchain "Atollic TrueStudio Lite" und lese da die Beispiele. Klar, TrueStudio ist beschränkt, hat aber den vorteil, dass es auf anhieb funktioniert. Die IDE kannst du dann ja immer noch wechseln. Im TrueStudio sind alle ST-Beispiele für das Discovery dabei und lassen sich problemlos kompilieren. Hier siehst du, wie die HAL benutzt wird. Ein einfach gehaltenes Linker Skript zeigt dir, wie der Speicher genutzt wird. Meine Vorgehensweise (eigentlich bei jedem Controller gleich): - Blinky LED in Main Loop - Blinky LED mit Timer - UART - UART mit DMA und dann speziel für den Einsatz weiter arbeiten
long long schrieb: > Und wenn man merkt, dass der Controller vom 300€ Board der falsche war, > hat man richtig ins ... gegriffen. Wenn ich den gewissenhaft ausgewählt habe, dann ist es nicht der falsche. Du hast leider NICHTS von dem kapiert, was ich geschrieben habe. Mich erinnern die Auswahlkriterien von Kontrollern an den "Eagle"-Hype: Eagle war (zumindedst in den 90ern) das gräuseligste Layoutptogramm, was man sich vorstellen konnte. Aber jeder hats benutzt, weil billig oder für lau. Der Gedanke der Hersteller ist der: Streue das Zeug billig oder umsonst unter die Schüler und Studenten und hoffe dann, dass es ein Großteil zu seinem künftigen Arbeitgeber mitnimmt. Es kann natürlich sein, dass ich das von einer für Euch unverständlichen Seite sehe. Ihr habt viel Zeit, Euch in Dinge einzuarbeiten, auch wenn Ihr es nachher verwerft. Als Gewerbetreibender steht bei mir die Zeit an erster Stelle. Nach 2 Arbeitstagen eines Angestellten sind die Kosten für ein Entwicklungsboard eh verbraten. Und nach 1 Monat Arbeit an dem Projekt sind ein paar Tausender verbraten. Wen kümmern da 300,- Euro für das Board? Gruß Joachim
Andreas S. schrieb: > Kennst Du den Prozessor und hast Du bereits Erfahrungen mit einem ARM > von NXP gemacht? Entspricht die aufgezeigte Vorgehensweise Deiner > Vorgehensweise, die Du am NXP - ARM praktiziert hast? > > Welche Tutorials von arm.com meinst Du genau? Sicherlich ersaufe ich da > wieder in Material. Welche davon hast Du gelesen und kannst sie aus > eigener Erfahrung empfehlen? > > Du hast Dir sehr viel Mühe mit Deiner langen Antwort gemacht (Danke > dafür) - basiert alles auf eigenen ARM-Erfahrungen? Also, mein Lieber, Ich bin jemand, der Geräte entwickelt - und davon sind eine ganze Reihe davon mit ARM-Controllern von NXP ausgestattet. Ich hab allerdings auch Nuvoton, ST und neuerdings Freescale im Portfolio. So, reicht dir das? Ich hab vor geraumer Zeit die Lernbetty hier im Forum geschrieben, damit Neulinge wie du eine saubillige und dabei recht gut ausgestattete Hardware haben zum Erlernen des Umgangs mit ARM-Prozessoren. Ist bei Pollin leider ausverkauft. Die Betty war zwar ein ARM7TDMI, aber dennoch ist das Anschauen und Lesen der Lernbetty auch heutzutage noch für die meisten Anfänger sowohl lehrreich als auch eine Fundgrube für Softwaredetails und zum Verstehen der prinzipiellen Herangehensweise. Viele Dinge sind soweit plattformunabhängig, daß man sie auch auf anderen Chips benutzen kann. Soweit dazu. Zu arm.com: Da meine ich keine Tutorials, sondern Dokumentationen. Hänge dich nicht an Tutorials, das sind ganz häufig Trittbrettfahrer-Produkte, wo Leute gegen Geld über irgendwas schwätzen. Bei ARM findest du hingegen Dokumentationen - und zwar aus allererster Hand. Ich kann dir auch bedingt zu Appnotes der jeweiligen Chiphersteller raten, aber lies das mit Vorsicht: Häufig genug will dir der Hersteller damit was unterjubeln -selbstverständlich in lauterster und bester Absicht. So z.B. Setzen eines Portpins mittels CMSIS oder Toggeln eines anderen Portpins mittels ST-Lib oder so ähnlich.. ;-) W.S.
Joachim schrieb: > long long schrieb: > Und wenn man merkt, dass der Controller vom 300€ Board der falsche war, > hat man richtig ins ... gegriffen. > > Wenn ich den gewissenhaft ausgewählt habe, dann ist es nicht der > falsche. Und ist der Richtige auf dem EVAL Board nicht OK? Nur weil er günstig ist, taugt er nicht? Man schreibst du einen B..s... :-( Bei den EVAL Board sind die Pins auf Stiftleiste geführt. Eigene HW kann einfach angeschlossen und genutzt werden. Bei den teuren Boards sind Display in Co. direkt darauf. Zeugs, das ich nicht kenne, und nicht brauche. Alle namhaften Hersteller haben die günstigen und komfortablen Boards. Du bekommst also auch eins mit dem Richtigen! ;-) Lies den ersten Post und du wirst verstehen, warum ein günstiges Board mit allem drum und dran für den TO das Richtige ist. ;-)
Joachim schrieb: > Mich beschleicht aber immer wieder das Gefühl, dass die Leute diese > Billigboards nehmen, die ab und zu als Marketing-Gag von Firmen > herausgebracht werden. Und dann bleiben die Leute daran kleben, weil man > sich die Einarbeitung in eine Kontrollerfamilie nur einmal antun will. Nimm's leicht und betrachte mal die Zielgruppen. Da haben wir die eigentlichen Entwickler, die sich sowas lediglich mal ansehen und lediglich wissen wollen, ob der Chip darauf ihnen gefällt. Als nächstes haben wir die Bastler und Wurschtler unter den Entwicklern, die zu klein sind, um in der Firma was Eigenständiges auf die Beine zu stellen und die deshalb solche Eval-Boards tatsächlich in Produkte verbauen. Dann haben wir die eigentlichen Bastler. Das sins Privatleute, die zwar ein Faible dafür haben, aber nicht die Potenz einer Firma, weswegen sie keine eigene Entwicklung auf die Beine stellen können und deshalb ihre Basteleien auf so einem Eval-Board aufsetzen. Das elende Problem mit den Distries hierzulande, die zum großen Teil jegliche Privatleute ausschließen, ist ja seit Jahren bekannt. Entsprechend beschränkt ist die Zugriffsmöglichkeit von Bastlern auf Bauelemente. Als nächstes haben wir die Schüler und Studenten, die eigentlich garnichts bauen oder basteln wollen, sondern sich eben nur damit beschäftigen, also drin herum daddeln, ein wenig programmieren (soll aber keinen Nervenschmalz kosten) oder in einer IDE erumklicken, kurzum zum Zeitvertreib ohne Entwicklungsziel. Ich sehe natürlich durchaus die schlimmen Langzeiteffekte, die auf die Allgemeinheit mit Leuten aus der letzten Gruppe zukommen. Die kleben dann an irgendwas fest, können eigentlich garnichts und verstehen auch fast garnichts - aber sie sind stolz auf sich und ihr Blinky und voll erfüllt von ihrer Selbsteinschätzung als großartige Mikrocontroller-Spezialisten - und sie sind dann in einigen Jahren das Einzige, was am Arbeitsmarkt für Elektronik-Ingenieure überhaupt zur Verfügung stehen wird. Tja.. W.S.
Ah, immer gut, wenn sich die Welt einfach und pauschal erklären lässt.
Tja, es gibt immer so ein paar Labersäcke, die nmach dem Motto leben: Was nichts kostet, taugt nicht!
@CAN-Fan: So ein langer Beitrag - das ist aber nett. Dabei hast Du genau meine Frage getroffen und mir konkrete "Handlungsanweisungen" zur Einarbeitung gegeben - super. "The definitive guide" hatte ich damals bereits angelesen und fand ihn gut - danke, daß Du mir diese Lektüre bestätigst, dann werde ich dort wieder die verlorene Spur aufnehmen. Sollte ich unbedingt die aktuellste Version des Buches für meinen STM32F4 lesen, oder tun es auch die älteren M0 und M3- Auflagen des Buches? Auch die Hinweise auf CDC waren für mich interessant - ich hatte das vor 3 Jahren bereits probiert, war aber damals noch an fehlenden Kenntnissen plus fehlender Doku bzw. fertigen Codeschnippseln/Libraries und dem Code-Limit der Atolic-IDE gescheitert. @Little Basdart: Auch Dir ein Dank für die Hinweise - jawohl, ich werde die ersten Schritte wohl wieder (wie vor 3 Jahren) mit Atollic machen, dann aber auf etwas ohne Code-Limitations umsteigen. @Joachim: Im beruflichen Umfeld gebe ich Dir 100% Recht: an Tools oder Werkzeugen zu sparen macht bei den hiesigen Stundensätzen absolut keinen Sinn. Im privaten Hobby-Bereich sehe ich es etwas differenzierter: letztendlich ist das Hobby-Budget halt doch beschränkt - genau wie die zur Verfügung stehende Zeit. Hätte ich vor 3 Jahren ein 300,- EUR Board gekauft, so hätte es nun 3 Jahre ungeplant im Schrank gelegen und ich hätte mich geärgert. Mit meinen 10,- Euro-Boards sehe ich das viel entspannter. Außerdem gilt hier im Hobby-Bereich viel eher: der Weg ist das Ziel. Und selbst wenn er ein wenig länger ist - solange ich ihn genieße ist ja alles im Lot, oder?! @W.S.: > Also, mein Lieber, > Ich bin jemand, der Geräte entwickelt Nett, daß Du mich offenbar in Dein Herz geschlossen hast - bei der Anrede ... :-) Sorry, wenn ich kurz an Deiner Qualifikation gezweifelt habe - ich kann bei meinem Wissensstand nicht entscheiden, ob mir hier jemand vom Fach Tipps gibt, oder ob mir Google-Anhänger Tipps geben - daher meine Nachfrage. Nun, da Deine Quali über jeden Zweifel erhaben ist, sind Deine Tipps natürlich noch viel wertvoller - daher auch Dir: 1000 Dank dafür! Danke auch für den Betty-Tipp (habe schon immer mal damit kokettiert) und Deine Erläuterungen zu arm.com @long long: > Man schreibst du einen B..s... :-( > Tja, es gibt immer so ein paar Labersäcke ... Eifer und Leidenschaft sind ja gut und davon lebt unser Hobby, aber laßt uns bitte über die Sache diskutieren und uns nicht gegenseitig persönlich angehen. Zwischenfazit: Die Tipps von CAN-Fan und Little Basdart haben mich bislang am meisten angesprochen. Allerdings hatte der Tipp von W.S. mit seinem Hinweis auf die Übersichtlichkeit der NXP-Prozessoren auch Potential, mich umzustimmen. Mal sehen, ob hier noch weitere Stimmen eingehen werden. Immerhin werde ich erst einmal die Lektüre des Definitive Guide's wieder aufnehmen - die Zeit scheint gut investiert zu sein. Viele Grüße Igel1
@Igel1: Zum LPCXpresso gibt es hier das Tutorial: https://www.lpcware.com/system/files/LPCXpresso_User_Guide_0.pdf Bzw. wird das aktuelle mit der Installation der IDE mitgeliefert. LPCXpresso hat zwar ein Codelimit in der freien Version, ist aber für den LPC812 nicht relevant weil der gar nicht soviel Speicher hat (Limit 256k). Selbst für die grösseren LPCs kommt man da nicht so leicht ran, auch nicht mit Webserver, Dateisystem und RTOS. Die IDE ist sehr umfangreich, deshalb ist es ratsam sich das Tutrial gut anzusehen. Wenn man mit IDEs gerne arbeitet ist die aber sehr komfortabel. Von NXP gibt es eine Lib names LPCOpen, damit bekommt man die jeweiligen Peripherieteile schnell ans Laufen. Die Lib mag ich nicht so, aber man kann hier immerhin abgucken welche Register/Bits wie konfiguriert werden müssen. Wenn du mit den Atmel Datenblättern klar gekommen bist dann ist die LPC Doku auch kein Problem, die ist sehr gut. Oft wird das hier als kompliziert dargestellt weil das bei einigen Prozessoren mehr als Tausend Seiten sind, die liest man aber nicht von A-Z als Lehrbuch. Es gibt ein Datasheet das die Features beschreibt und ein User Manual das in die bitweisen Details geht. Für den Anfang sollte man Wissen das fast alle Pins mehrfach belegt sind man erstmal die gewünschte Funktion aktivieren muss. Dann lassen sich viele Peripherieteile zum Strom sparen abschalten und nach dem Reset müssen die erst eingeschaltet werden, das findet man aber auch schnell in der Doku. Ähnliches gibt es natürlich auch für die anderen Kandidaten, hier im Forum ist ST weiter verbreitet. Den LPC1769 gibt es aber schon seit Jahren als günstiges Einsteiger Angebot und deshalb hatte ich damit angefangen. ST hat eine wahnsinnig grosse Palette, aber das ist wohl eher für kommerzielle Anwendungen wichtig. Die LPC8xx sind die neueren 'kleinen', besonderes Merkmal ist die IO Switch Matrix und ein sehr komplexer Timer (SCT). Ich benutze gerne den LPC1347 wg. eingebautem USB und weil ich das LQFP SMD Zeug gerade noch verarbeiten kann. Der nächstgrössere ist der LPC1769, dann auf dem LPCXpresso Board. Da muss nur eine MagJack Buchse dran und die Hardware ist Ethernetfähig. Noch eine Stufe drüber ist der LPC4088 mit FPU und Display Controller. Ich denke damit bekomme ich alles rund um den heimischen Herd gesteuert :-)
@Jojo S.: Interessantes Plädoyer für NXP - insbesondere den Verweis auf die professionelle IDE und das eingebaute USB fand ich gut. Die verlinkte Doku macht ebenfalls einen guten Eindruck. Ob ich doch schwach werde und auf NXP umsattle? Danke in jedem Fall für Deine Einschätzung/Tipps! Viele Grüße Igel1
Little B. schrieb: > Klar, TrueStudio ist beschränkt, hat aber den vorteil, dass es auf Ist es seit kurzem nicht mehr, die Codesize Limitierung is weggefallen. Allerdings ist es natürlich ein ziemlich lames teil.
CAN-Fan schrieb: > , als wenn ich alles selbst baue. Wenn Du es selbst baust, verstehts Du wenigstens was Du tust. Ich halte von dem CubMx garnix. Ich hatte mir vor Jahren eine der ersten Versionen reingezogen, einfach gruselig. Nix hat gescheit funktioniert. Vor kurzen habe ich mir noch einmal die neueste Version installiert. Das da zum Teil an Code rauskommt ist schon genial: if (ptr != NULL) { ptr = NULL; } Das zeigt schon wie effizient das ist und von welchen Leuten das gemacht wurde.....
Ich finde die Teensies einfach genial. Die sind zwar für Arduiono gemacht, aber das braucht man nicht, so man nicht will. arm-none-eabi Toolchain installieren, Makefile, eine IDE der Wahl, das Ding auf ein Steckbrett gesteckt, USB-Kabel dran, den UART dazu und man hat eine brauchbare Entwicklungsumgebung für die ersten ARM-Schritte (20 €). Dazu das Kinetis-Manual auswendig lernen und es kann losgehen. Einziges Manko ist die nicht zugängliche SWD-Debuggerschnittstelle. Das läßt sich aber mit einem scharfen Messer und Lötkolben beheben. Macht man so ein Ding auf dem Steckbrett mal kaputt (hab' ich noch nicht hingekriegt), holt man sich einfach ein neues aus der Schachtel ;) Ob die allerdings für dein "Fernziel" ausreichend sind?
Andreas S. schrieb: > Interessantes Plädoyer für NXP - insbesondere den Verweis auf die > professionelle IDE und das eingebaute USB fand ich gut. Da möchte ich nur noch anmerken das ich nicht mit NXP oder Philips verwandt bin und auch nix dafür kriege. Ich habe halt auch mit den Atmel AVR den Einstig in die µC Welt angefangen und fand die ARM dann wegen gleicher Grösse und mehr Power interessanter. Mit den ARM7TDMI war das aber ein Krampf, nicht wegen der ARM sondern OpenOCD und irgendwie eine lauffähige Umgebung hinzubekommen. Da ist heute deutlich einfacher, nur hat man jetzt die Qual der Wahl... USB können andere selbstverständlich auch, ich wollte damit nur sagen das ich mit den genannten Familien meine Hobbyprojekte wie zB LED Schnickschnack, FS20->UDP Gateway, Blumenbewässerung oder Motorsteuerungen realisieren kann. Der 'Nachteil' am LPCXpresso ist ja das es leider auf die NXP beschränkt ist. Es kam von CodeRed und da sollte es (zumindest gegen Cash) auch für andere Hersteller offen sein, aber in diese Richtung geht es ja nicht mehr weiter. Für mich ist hier weniger mehr und selbst wenn es mal was mit ST sein soll gibts ja immer noch CooCox und andere. So kleine Breakoutboards wie Teensy finde ich auch gut, gibt es ja auch für LPC, ST und andere. Dazu etwas eigene HW auf ein Steckbrett und man kann schnell alles mögliche ausprobieren. Die kleinen Boards kriegt man auch noch gut auf eine eigene Platine und man umgeht das SMD verarbeiten wenn man das nicht mag.
@Jojo S. Ich bin mit dir einverstanden. Ich hatte das mbed LPC1768 modul frei bekommen. Habe Angefangen mit mbed. Ist einfach zu benutzen, aber für mich ist das Problem C++ kenntniss. Das ist noch ein bisschen schweriger als reines C. Ich fand die Docu von NXP sehr gut. Habe mir auf Youtube demo von LPCXpressoIDE angesehen, aber dass sieht sehr Komplex aus... Ich habe es schon lange auf PC, und mehrfach updates installiert. Das ging alles ohne probleme. (Vergleiche mit Atmel Studio, der braucht immer etwas anderes/neues, der ist nie erwachsen). An sich sieht LPCXpressoIDE besonders stabil aus. Ich habe auch KeilMDK angesehen, macht einen einfacheren Eindruck. Alles zusammen finde ich dass LPC1768 eine Art Standardmodul ist. Sehr weitverbreitet und "alles" ist drin. Alles was mann dazu braucht an software ist da, und von bester Qualität. Ich habe mich konzentriert auf Bascom-AVR, aber wenn ich weiter gehe mit ARM denke ich dass das Studium mit die NXP der beste Investition ist. Ein Anfangerkurs auf Mikrocontroller.net mit LPCxpressoIDE möchte ich gerne mitmachen.
:
Bearbeitet durch User
Andreas S. schrieb: > Danke für Deine Tipps. > > Hast Du die Bücher ergooglet oder tatsächlich gelesen und kannst sie aus > eigener Erfahrung empfehlen? > > Mit welchem Board und welcher IDE arbeitest Du? Und welche Tutorial > würdest Du lesen, wenn du nochmals mit ARM anfangen würdest? Ich habe die Bücher, habe mit dem Code Composer und den launchpads seinerzeit angefangen, bin aber mittlerweile auf eigene STM32-Boards bzw. bei Ebay gekaufte Minimalboards und Coocox bzw. IAR (codebeschränkt) umgestiegen. Aber ich bin fachfremder Bastler mit wenig Zeit, kein Profi.
W.S. schrieb: > Ich sehe natürlich durchaus die schlimmen Langzeiteffekte, die auf die > Allgemeinheit mit Leuten aus der letzten Gruppe zukommen. Ich muss Dir da leider recht geben. Aus eigener Erfahrung kann ich bestätigen, dass 90% der Leute am liebsten mit 3 oder 4 monströsen Tools gleichzeitig arbeiten und jede kleinste Funktion ihrer Monster-IDE auswendig können, aber nicht im geringsten ein Problem lösen können. Natürlich verstehe ich das mit dem Bastlergedanken. Ich wollte auch nur den Hinweis geben, sich nicht an 3 zufällig vorhandene Boards zu binden, sondern vielleicht mal herumzuschauen. Gerade weil die Einarbeitung nicht ganz ohne ist, sollte es das wert sein. Ein Arduion Due Clone kostet auch nur um 20,- Euro. Und wenn man das Arduino-Geraffel weglässt (sprich: per JTAG und einem richtigen Compiler drangeht), dann hat man ein sehr leistungsfähiges Board. Jojo S. schrieb: > Mit den ARM7TDMI war das > aber ein Krampf, nicht wegen der ARM sondern OpenOCD und irgendwie eine > lauffähige Umgebung hinzubekommen. Ich habe für meine älteren ARM7-Projekte immer noch die Kombination WinArm und OpenOCD drauf. Macht überhaupt keine Probleme. Da kann man sogar noch das Makefile von Hand editieren und es funktioniert so wie man will. Ein Krampf ist eher das ATMEL Studio. Ich habe es bis heute nicht geschafft, dem Ding mal beizubringen, dass es mir nicht den Stackbereich mit Daten überschreibt, wenn mal ein paar KB RAM mehr benutzt werden :-( Compiler bzw. Linker-Warnung in dem Fall Fehlanzeige! Sowas ist doch Mist! Leider war es schon in der Vergangenheit oft so, dass man sich zwischen einem guten Kontroller mit mäßiger Entwicklungsumgebung und einem schlechteren Kontroller mit super Entwicklungsumgebung entscheiden musste. Beides zusammen ist mir bislang noch nie begegnet ;-) Gruß Joachim
iwoasesned schrieb: > CAN-Fan schrieb: >> , als wenn ich alles selbst baue. > > Wenn Du es selbst baust, verstehts Du wenigstens was Du tust. > > Ich halte von dem CubMx garnix. Ich hatte mir vor Jahren eine der > ersten Versionen reingezogen, einfach gruselig. Nix hat gescheit > funktioniert. Habe ich auch früher gemacht. Hab dann z.B. für einen Freescale (die IPs sind ganz ok, aber die Doku und Support finde ich einfach schlecht) eine SPI-Lib geschrieben. Zuerst für eine Cortex-M4, dann sollte es eine kleinere Version vom Produkt mit einer M0+ geben. Da durfte ich wieder alle Register raussuchen, die defines schreiben etc. Mir ist bewusst, dass jede Schicht ein Performanceverlust ist, nur habe ich keine Lust einen USB-Stack in Assembler zu schreiben. Dank CubeMX suche ich mir einfach genau die MCU, die alles hat, was ich brauche und dabei am "kleinsten" ist. Ob das jetzt eine M0+, M3, M4 ist, ist egal, davon bin ich unabhängig. Und 4 kB mehr Flash für die Lib ist bei den Produkten auch egal. Klar wenn es z.B. Multimedia-Massen-Markt ist, da rechnet man anders. Auch wenn eine Firma die Ressourcen hat um eine eigene Hardware-Lib zu pflegen ist das ok. Die ersten Versionen von Cube habe ich auch nicht verwendet (hab noch die alte HAL benutzt). Zeitkritische Sachen schreibe ich auch direkt selbst. Aber beim Startup um die Register für die GPIOs zu beschreiben habe ich mit der HAL kein Problem. Wichtig ist, dass man weiß, was dahinter passiert und ob es für die Anwendung passt. @Andreas S. danke für das Lob :) Damals gab es leider noch nicht so viel, als ich angefangen habe. Für die Grundzüge ist es egal, ob es das M3 oder M4 Buch ist. Im wesentlichen ist da nur die FPU dazu gekommen. Von NXP habe ich selbst nichts schlechtes gehört, habe mich dann einfach wegen den support und den tools für St entschieden. Der ganz große Nachteil ist, St bietet keine STM32 bis 125°C an. Daher werde ich mich auch wegen anderen Herstellern umsehen müssen. Und da ist ein Board mit Power Supply und einem Chip genau das richtige. Warum 300€ für ein Board ausgeben, wenn ich nur die CPU testen will, bzw. das Toolchain. Was ich da dran hänge, teste ich separat. Die billigen Boards bringen auch nicht unbedingt dummen Nachwuchs, sondern ist eher eine Chance. Aber da stimme ich @W.S. zu: Wer einfach in einer IDE rum klickt und ein Beispiel ladet und sich als Experte fühlt, der soll mal wieder auf den Boden kommen.
Hi Ein Kollege hat versucht mit CubMX den USB von einem STM32F103 zum laufeb zu bringen. Der hat irgendwann entnervt aufgegeben. Wir haben zum Glück in der Firma die SW von Segger. Die läuft Prima.
iwoasesned schrieb: > Hi > > Ein Kollege hat versucht mit CubMX den USB von einem STM32F103 > zum laufeb zu bringen. Der hat irgendwann entnervt aufgegeben. > Wir haben zum Glück in der Firma die SW von Segger. Die läuft > Prima. ... Ihr solltet Euch CAN-Fan aus diesem Forum einkaufen - er hat genau dieses Problem gelöst. Siehe sein Posting etwas weiter oben in diesem Thread: Beitrag "Re: Einstieg ARM: Tutorials, Toolchain, DevBoard" Viele Grüße Igel1 PS: @CAN-Fan: 10% Vermittlungsgebühr gehen an mich :-)
iwoasesned schrieb: > Little B. schrieb: >> Klar, TrueStudio ist beschränkt, hat aber den vorteil, dass es auf > > Ist es seit kurzem nicht mehr, die Codesize Limitierung is weggefallen. > Allerdings ist es natürlich ein ziemlich lames teil. Super Info!! Damit hatte ich vor 3 Jahren angefangen und bin dann bei meinen USB-Experimenten (die definitiv 'ne Nummer zu hoch für mich waren) schon ganz schnell an die Codesize-Limitierung gestoßen. Einfach klasse, was man hier für Infos bekommt - Danke nach Bayern an iwoasesned. Markus F. schrieb: > Ich finde die Teensies einfach genial. Macht ebenfalls einen interessanten Eindruck, aber habe ich dort eine genauso große Community-Unterstützung wie bei ST, NXP oder TI? Jojo S. schrieb: > Da möchte ich nur noch anmerken das ich nicht mit NXP oder Philips > verwandt bin Ja, ja - schon gut: ich bin auch nicht mit Mikrocontrollern verwandt, obwohl meine Frau ab und an meint, ich sei mit denen und nicht mit ihr verheiratet ... Aber mal 'ne Frage: Wenn ich tatsächlich auf NXP umsteigen sollte, welches Einsteigerboard sollte ich dann nehmen? Für welches gibt's die größte Community, die beste Doku und die meisten Code-Beispiele? Etwa das mbed LPC1768 modul von Geerd H.? Schlägt immerhin mit 60,- EUR zu Buche ... @google: Danke für die Erläuterung - sehr eindrucksvoll, wie weit Du offenbar gekommen bist, während ich direkt zu Anfang aus der Kurve geflogen bin. @CAN-Fan: Danke nochmals für Deine Hinweise. > Der ganz große Nachteil ist, St bietet keine STM32 bis 125°C an. Au, das ist jetzt ganz schlecht für mich, denn ich wollte den STM32 nicht nur zum Programmieren, sondern auch als Lötkolbenablage benutzen ;-) @All: Ich werde mich dann jetzt mal ans Werk machen und das von CAN-Fan empfohlene Buch lesen, bevor ich vor lauter Recherche den eigentlichen Forscher-, Entdecker- und Programmier-Spaß verpasse. Aktuell präferiere ich noch immer ganz leicht den STM32, aber die NXP-Fraktion hier hat mich mit den Hinweisen auf die gute Doku und die gute CodeRed IDE mächtig verunsichert. Danke für Euren vielen Tipps. Ihr wart mal wieder super hilfsbereit. Viele Grüße Igel1
Andreas S. schrieb: > PS: @CAN-Fan: 10% Vermittlungsgebühr gehen an mich :-) Da ich nicht billig bin, kannst dir schon mal ne schöne Reise buchen. Also ich schreib durchaus positiv, aber ich nutze auch nicht alles mit CubeMX. Eigentlich nur für die HW-Init und dass es mir die Middleware für z.B. Rtos rein kopiert. Hab das früher mit der Hand gemacht, jetzt kopiert er das rein, und passt paar Configs an, was ich sonst auch per Define und Hand gemacht hab. Wer da etwas voll automatisches erwartet (und ohne Grundlagenwissen), ist da auch falsch. Es hilft, wenn man weiß, was Cube macht und was man eigentlich machen will. Wegen USB: Ich hab die STM32F446RE genutzt und das senden (!) per VCP hat auf Anhieb funktioniert. Beim empfangen ruft er ca. 10 Unterfunktionen auf, bei einer steht einfach: return HAL_OK; drinnen. Da die Empfangsfunktion nicht blockierend war und immer HAL_OK zurückgegeben hat, musste ich mir den kompletten USB-Stack ansehen und das dann direkt vom Endpoint auswerten und weiter geben. Aber das Problem ist eigentlich von der Middleware, Cube kopiert nur. Die Doku zu der St USB Middleware ist zwar (vermutlich) besser als jede Freescale Doku scnr, aber die Segger doku zu emWin ist da deutlich besser. Auch hatte ich das Problem bei dem STM32F302, dass der DMA für UART nicht funktioniert hat. Die HAL hat (warum auch immer) das DMA-Start bit nicht gesetzt. Habe dann einfach das Register direkt beschrieben und dann ging es. Aber z.B. bei der Lib von Freescale habe ich ewig einen CMSIS-Befehl wie __SET_MSP gesucht, welcher nicht dabei war. Und wenn es z.B. die Anforderung ist, dass die Software auf nem AtMega8 (abgespeckt), Kinetis M0+ und STM32F4 läuft, dann bin ich ehrlich gesagt froh, wenn es solche libs gibt und ich meine Software leicht für einen Hersteller portieren kann. Überzeugen oder Missionieren will ich keinen, da ich eigentlich hauptsächlich einen Texteditor nutze und am liebsten alles selbst schreibe.
Andreas S. schrieb: > @CAN-Fan: > > Danke nochmals für Deine Hinweise. > >> Der ganz große Nachteil ist, St bietet keine STM32 bis 125°C an. > > Au, das ist jetzt ganz schlecht für mich, denn ich wollte den STM32 > nicht nur zum Programmieren, sondern auch als Lötkolbenablage benutzen > ;-) Als Bastler baust du eh (hoffentlich) nichts in ein KFZ ein ;) Noch ein letzer Tipp, lies das Buch und leihe/nutze das Board, das du hast und gehe einfach auf die nächste Messe. Z.b. embedded world in Nürnberg (Februar 2016) oder die electronica in München (Nov. 2016), da bekommst du kostenlos sämtliche Boards und kannst dich damit austoben und selbst entscheiden. Letztendlich ist es (für den "Allgemeinen Bastler" sowieso) egal, ob NXP oder St, außer du brauchst eine ganz spezielle IP. Und wie ich praktisch mit der Cortex angefangen habe. Datenblatt + Altium. Wenn du die Hardware selbst baust, lernst du direkt einiges über die IPs.
Andreas S. schrieb: > Hätte ich vor 3 Jahren ein 300,- EUR Board gekauft, so hätte es nun 3 > Jahre ungeplant im Schrank gelegen und ich hätte mich geärgert. > Mit meinen 10,- Euro-Boards sehe ich das viel entspannter. > > Außerdem gilt hier im Hobby-Bereich viel eher: der Weg ist das Ziel. > Und selbst wenn er ein wenig länger ist - solange ich ihn genieße ist ja > alles im Lot, oder?! Das sehe ich auch so. Habe auch ein paar Discovery Boards hier liegen, auch MSP430 (sogar das 432) und nur eines der Discovery habe ich mal blinken lassen. Habe mir gerade einen Segger EDU bestellt. Selbst wenn alles liegen bleibt, so kann ich sie mir ab und zu ansehen.
Andreas S. schrieb: > Aktuell präferiere ich noch immer ganz leicht den STM32, aber die > NXP-Fraktion hier hat mich mit den Hinweisen auf die gute Doku und die > gute CodeRed IDE mächtig verunsichert. Sachlich gesehen, liegen beide mittlerweile fast gleichauf. NXP war seit Jahren führend bei größeren Chips, wo man externen SDRAM und TFT-Interface erwartet. Das kam von der Übernahme der BlueStreak's her. Bei ST gab es in dieser Richtung lange Zeit nichts und die ersten STM32F mit SDRAM und TFT hatten vorigen Herbst noch Hardware-Bugs im externen Businterface. Bei der Programmierung der Chips hat NXP immer noch die Nase vorn, denn wenn man mal von JTAG und SWD absieht, ist mit FlashMagic das Programmieren per Bootlader immer noch besser als bei ST mit dem "..Demonstrator" - der nach meinem Gefühl von ST zu sehr vernachlässigt wird. Bei NXP gibt es bei einigen Chips inzwischen auch die Programmierung mit Bootlader per USB, wo der Chip sich am PC einfach als Massenspeicher anmeldet. Da braucht man die Firmware einfach nur draufzukopieren und fertig. Ob es sowas pfiffig-elegantes mittlerweile auch bei ST gibt, müßte ich mal nachgucken. Aber eines ist ganz klar: Sinn macht das Ganze nur dann, wenn am Ende etwas wirklich Benutzbares bei herauskommt - und das ist eben nicht nur ein irgendwie programmierter Controller, sondern ein Gerät, also Kistchen zum Anfassen mit Knöpfen und so. Vorschlag: Bau deiner Liebsten ein Küchen-Thermometer mit PT100 und monochromem Grafikdisplay und mit eingebautem Kurzzeitwecker, womit sie das Roastbeef rosé und die weichen Eier und die Weihnachtsstolle gut hinkriegt. W.S.
Vergess den Cypress PSOC5 nicht CY8CKIT-059 >> $10 incl programmer Mit diesen preis also einfach in Produkten Einzubauen
Andreas S. schrieb: > Etwa das mbed LPC1768 modul > von Geerd H.? Schlägt immerhin mit 60,- EUR zu Buche ... Das Modul ist nicht schlecht, aber der Preis nicht mehr ganz zeitgemäss... Für ein paar Euro mehr gibt den LPC4088 von EA, der hat viel Ram/Flash, Displaycontroller, USB/Ethernet, FPU usw. Das mbed1768 Modul war das Ur-Modul für die mbed Umgebung und im Preis sind vielleicht noch Entwicklungs- und Lizenzkosten mit drin, mbed konnte nur mit ausgewählter HW genutzt werden. Heute ist mbed komplett offen und kann für eine grosse Palette an Hardware verwendet werden. mbed ist eine Online IDE mit Versionsverwaltung, einer Basislibrary die für alle Kontroller einigermassen gleich ist sowie viel Code für Komponenten wie Aktoren, Sensoren, Display uvm. Das ganze in C++ und recht effizient. Bei C++ melden sich aber gleich wieder die Puristen und es kommt schnell zu Glaubenskriegen... Ich bin faul und nutze mbed gerne, aber um für den Anfang mit dem Controller auf du zu kommen sind erste Experimente mit zB den LPCXpresso Beispielen sinnvoller. Und mbed hat keinen Debugger, dazu kann man Projekte aber aus der OnlineIDE in eine lokal installierte exportieren.
@W.S.: Danke für Deine interessanten NXP-Infos - das war mir alles neu, erweitert meinen Horizont und es spricht natürlich für NXP. > Aber eines ist ganz klar: Sinn macht das Ganze nur dann, wenn am Ende > etwas wirklich Benutzbares bei herauskommt - und das ist eben nicht > nur ein irgendwie programmierter Controller, sondern ein Gerät, also > Kistchen zum Anfassen mit Knöpfen und so. Das mit dem "Sinn machen" ist immer so eine Sache: Du brauchst eine Kiste mit Knöpfen zum Anfassen - mir reicht ein windiger Drahtverhau, der irgendwelche (für mich) interessanten Dinge tut. Jeder von uns findet also auf seine ganz persönliche Weise Sinn. Off-off-topic: "Sinn machen" ist übrigens ein Anglizismus, den es im Deutschen eigentlich gar nicht gibt - es "macht" also so oder so keinen Sinn :-) > Vorschlag: Bau deiner Liebsten ein Küchen-Thermometer mit PT100 und > monochromem Grafikdisplay und mit eingebautem Kurzzeitwecker, womit sie > das Roastbeef rosé und die weichen Eier und die Weihnachtsstolle gut > hinkriegt. Weil's mein Thread ist, möchte ich der Form halber zu Protokoll geben, daß ich von meiner Frau, oder genauer: von keiner Frau (Ausnahme: Köchin im Restaurant) erwarte, daß sie mir das Roastbeef rosé, die Eier weich und den Weihnachtsstollen zart aufbackt. Ich nehme an, unsere Frauen(bilder) unterscheiden sich in diesem Punkt etwas (... au weia - hoffentlich spricht W.S. jetzt noch mit mir ...) @foldi: Ich dachte, daß der ST-Link/V2 auf den Discovery-Boards zur Programmierung genügt. Jedenfalls konnte ich den STM32F407VGT6 vor 3 Jahren ohne Zusatzhardware quasi "mit bloßen Händen" programmieren. Wofür benötigst Du zusätzlich einen Segger EDU prommer? @Patrick C.: > Vergess den Cypress PSOC5 nicht > CY8CKIT-059 >> $10 incl programmer > Mit diesen preis also einfach in Produkten Einzubauen Hammer - was es alles gibt! Und zu welchem Preis ... Aber wie gut ist die Doku und wie groß ist die Community dahinter? Könntest Du dazu noch netterweise ein paar Worte schreiben? Jedenfalls ist das ein interessanter Hinweis - Danke dafür. @Jojo S.: Hochinteressant, was Du da schreibst. Das mit der Online IDE habe ich leider noch nicht so ganz verstanden. Heißt "Online IDE" wirklich, daß ich den Code irgendwo im Internet eintippe und mir das Kompilat dann nach Hause geschickt wird? Das LPC4088 von EA habe ich mir ebenfalls kurz angeguckt: schmuckes Teil, was ich als Hobby-Elektroniker natürlich nur so richtig verwenden kann, wenn ich direkt das LPC4088 Experiment Bundle für 99 EUR kaufe: http://www.embeddedartists.com/products/boards/lpc4088_qsb.php Oder liege ich da falsch? Und noch eine Frage: wenn ich dann irgendwann einmal mit diesem LPC4088 Prozessor "Laufen gelernt" habe, gibt es dann auch günstige Boards mit diesem Prozessor, die ich in meine Schaltungen einbauen könnte? Das finde ich am STM32F4 Discovery-Board so interessant. Oder kann ich meinen Code dann auch fix auf kleinere LPC'en portieren, für die es solche günstigen Boards gibt? Nur wenige meiner Projekte benötigen so einen Düsenjäger. Viele Grüße Igel1
Andreas S. schrieb: > Wofür benötigst Du zusätzlich einen Segger EDU prommer? Hallo Andreas, ganz ehrlich? Ich musste einfach mal wieder was kaufen. :-) Eins dieser Dinger blinkte auch schon bei mir und über USB.
Andreas S. schrieb: > Weil's mein Thread ist, möchte ich der Form halber zu Protokoll geben, > daß ich von meiner Frau, oder genauer: von keiner Frau (Ausnahme: Köchin > im Restaurant) erwarte, daß sie mir das Roastbeef rosé, die Eier weich > und den Weihnachtsstollen zart aufbackt. Frauen(zerr)bilder? Ach nö. Ich hoffe, du hast den Sinn des Vorschlags verstanden. Natürlich weiß ich nichts über deine familiären Verhältnisse, aber das selbstgebastelte Kistchen mit nützlichem Funktionsumfang wird zweifelsohne durchaus geschätzt - egal ob von Ehefrau oder anderweitigem Lebens(abschnitts)gefährten oder der eigenen Oma etc... - und du willst beim Eierkochen in der Küche gewiß auch nicht mit einem Drahtverhau zu tun haben. W.S.
Ich finde das Timerprojekt nicht schlecht. Habe mal an einen zyklischen Timer gedacht für Sport (Zirkeltraining). Aber für die Küche bzw. den Grill ist ein Steaktimer der zB 4 x 90 s bimmelt noch besser. Geht natürlich nur mit 32 Bittern :-)
Jojo S. schrieb: > Aber für die Küche bzw. den Grill ist ein Steaktimer der zB 4 x 90 s > bimmelt noch besser. Geht natürlich nur mit 32 Bittern :-) Zum Steak Braten braucht es nur eine Gabel.
F. F. schrieb: > Zum Steak Braten braucht es nur eine Gabel. zum Steak Essen braucht es nur eine Gabel (wenn's gut gemacht ist).
Zwar kein schönes Steak, aber ohne Messer: http://download.e-bookshelf.de/download/0003/0344/47/L-X-0003034447- 0009138671.XHTML/image/ART_04_steak_eggs.jpg
Leute, Leute,
bevor Ihr hier nun ganz in Richtung Barbecue abdriftet, erlaubt mir
bitte noch eine Frage:
Gibt es eigentlich auch weniger "trockene" Einstiegsmöglichkeiten als
den "Definitive_Guide_To_The_ARM_Cortex_M3"?
Mir schweben da so Bücher/Tutorials wie das von Günter Schmitt vor
("Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie").
Dort bekam man zu jedem Thema ein bißchen Code, das man selbst
studieren, verstehen und ausprobieren konnte.
Schritt für Schritt hat man sich so durch den ganzen Prozessor
gearbeitet und man hatte am Ende nicht nur ein fundiertes AVR-Wissen
erlangt, sondern man hatte sich auch eine passable Auswahl an
Beispielcode für alle Basis-Fragestellungen erschlossen.
Ich muß gestehen, dass mir so etwas deutlich mehr Spaß macht, als wenn
ich mir erst einmal 400 Seiten durchlesen muß, bevor ich die erste Zeile
programmieren kann.
Das heißt nicht, daß ich ohne Grundlangen losprogrammieren will - ich
weiß, daß dies nur im "Herumwurschteln" endet - aber ich möchte mir die
Grundlagen gerne direkt von Anfang an mit kleinen Beispielen erarbeiten.
Habt Ihr so etwas ebenfalls "im Angebot"?
Viele Grüße
Igel1
Andreas S. schrieb: > Gibt es eigentlich auch weniger "trockene" Einstiegsmöglichkeiten als > den "Definitive_Guide_To_The_ARM_Cortex_M3"? http://users.ece.utexas.edu/~valvano/arm/outline1.htm http://users.ece.utexas.edu/~valvano/arm/outline.htm Für TI-launchpad gut geeignet
Andreas S. schrieb: > Mir schweben da so Bücher/Tutorials wie das von Günter Schmitt vor > ("Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie"). > Dort bekam man zu jedem Thema ein bißchen Code, das man selbst > studieren, verstehen und ausprobieren konnte. Oh man, vielleicht habe ich den ja zu früh in die Ecke gestellt? Ich fand den fürchterlich und habe das Buch schon nach ein paar Seiten ins Regal gestellt.
STM schrieb: > http://users.ece.utexas.edu/~valvano/arm/outline1.htm > > http://users.ece.utexas.edu/~valvano/arm/outline.htm Vor allem auf Seite 3, das mit dem Widerstand und dem Wassertank. Auf 508 Seiten wird das was erklärt und davon werden Seiten für so was verschwendet. Wo es von den Herstellern doch Dokumente mit über 1000 Seiten gibt. Lernt man da noch genug?
F. F. schrieb: > Vor allem auf Seite 3, das mit dem Widerstand und dem Wassertank. Ist halt idiotensicher. Niemand zwingt Dich, alles zu lesen. Du kannst ins Inhaltsverzeichnis schauen und auf Deine Kenntnisstufe vorblättern. Geht auch bei Büchern im reallife. ;-)
Bei Segger gibt es eine Seite auf der alle möglichen IDE's mit "Full J-Link Support" aufgeführt sind. https://www.segger.com/jlink-ide-integration.html Hier noch ein kleines und günstiges M3 Board. http://www.ebay.de/itm/ARM-Cortex-M3-STM32F103C8T6-STM32-Kern-board-Mini-System-Entwickeln-USB-DE-TE177-/261884357762?hash=item3cf9862c82:g:Y8wAAOSwv0tVUNWk
:
Bearbeitet durch User
Habe gerade mal das LaunchPad MSP432 rausgehohlt (schon ganz vergessen, dass ich das mal bestellt hatte) und werfe das mal in die Runde. @Andreas Da du ja viele Software Beispiele haben willst, hier sind sie: http://dev.ti.com/tirex/#/Device/MSP432P401R?link=MSPWare%2FDevices%2FMSP432P401R%2FExamples%2FC%2Fmsp432p401_1%2Fmsp432_startup_ccs.c Du kannst die IDE im iNet öffnen und dann dir schon mal alles ansehen, was du willst.
Andreas S. schrieb: > Ich muß gestehen, dass mir so etwas deutlich mehr Spaß macht, als wenn > ich mir erst einmal 400 Seiten durchlesen muß, bevor ich die erste Zeile > programmieren kann. Nur im Schlaraffenland fliegen einem die gebratenen Tauben freiwillig in den Mund. Wenn du nicht auf der mentalen Stufe von Leuten kleben bleiben willst, die in ihrer IDE ein Blinky-Projekt laden und dann auf den Knopf drücken, bis daß die LED auf dem dazu passenden Evalboard blinkt, dann bleibt dir nichts anderes übrig, als dich in die Materie einzulesen - und zwar selbst und trotz der fast immer relativ trockenen Schreibweise. Spaß ist was anderes. W.S.
Andreas S. schrieb: > Gibt es eigentlich auch weniger "trockene" Einstiegsmöglichkeiten als > den "Definitive_Guide_To_The_ARM_Cortex_M3"? Das kommt auf deine Vorkenntnisse an. Wenn du Microcontroller an sich kennst und Programmierung in C an sich kannst. Und vielleicht auch noch den Unterschied zwischen Compiler, Linker und make kennst, dann brauchst du für den Einstieg in die ARM Welt wirklich nur ein Buch über die Architektur. Und dafür ist dieses Buch sehr gut. Es liegt hier auf meinem Nachttisch :) Für konkrete Cortex-M Implementierungen brauchst du natürlich immer noch das Datenblatt des Herstellers, weil sich Peripherie, Flash, Debuginterfaces etc. dann halt doch unterscheiden. Das Buch mag "trocken" rüberkommen. Aber ich bin ehrlich gesagt ganz froh, daß mir keiner mehr glaubt erklären zu müssen was Strom ist und wie man einen Taster anschließt und ausliest. > Schritt für Schritt hat man sich so durch den ganzen Prozessor > gearbeitet und man hatte am Ende nicht nur ein fundiertes AVR-Wissen > erlangt, sondern man hatte sich auch eine passable Auswahl an > Beispielcode für alle Basis-Fragestellungen erschlossen. Und dafür braucht man eine Anleitung? Ich bin da mehr für Learning by Doing. Deswegen steckt bei mir ein STM32F030F4 auf dem Steckbrett (Methode wie hier: Beitrag "~1€ ARM-Cortex-M0 (STM32)-Bord selbstgestrickt") und ich programmier(t)e ausgehend vom Standard "Blinken mit for()-Schleife" diverse Varianten mit Timern bis hin zur PWM. Und das gleich noch auf verschiedenen Ebenen: komplett zu Fuß a'la http://eleceng.dit.ie/frank/arm/STM32F030ISP/index.html, mit CMSIS von ST, mit (lib)opencm3. Und mit verschiedenen Adaptern. Angefangen vom USB-seriell Adapter mit stm32flash und dem STM32 Bootloader über einen STLINK/V2 vom Chinamann mit Texane st-util hin zum Segger J-Link (China-Clon). Toolchain ist ARM-gcc aus meiner Linux-Distribution. Und make und vim brauche ich ja sowieso immer. Das STM32F4 Discovery liegt derweil in der Ecke und verstaubt. "Einsteigen" kann man damit nicht sinnvoll. Da steckt viel zu viel Hardware drauf, um die in Betrieb zu nehmen und gleichzeitig verstehen(!) zu können. Und auf Abstraktionsschichten a'la CubeMX habe ich keinen Bock. Ich will verstehen was da passiert. Demnächst werde ich wahrscheinlich mein Moodlight auf den STM32 portieren. Und dann vielleicht einen Reziprokzähler. Oh und das STM32F103 Board das demnächst aus China kommt will ich zum Blackmagic-Probe verwursten. Da lerne ich sicher auch noch was dabei.
Axel S. schrieb: > Das kommt auf deine Vorkenntnisse an. Wenn du Microcontroller an sich > kennst und Programmierung in C an sich kannst. Und vielleicht auch noch > den Unterschied zwischen Compiler, Linker und make kennst, dann brauchst > du für den Einstieg in die ARM Welt wirklich nur ein Buch über die > Architektur. Er kennt sich mit Sicherheit aus und sicher ist es nur seine Bescheidenheit, dass er sich hier so zurück hält. Mal ein Projekt von ihm: Beitrag "Projekt Maus" Ihr habt es nicht mit einem Nerd zu tun. Aber wenn er das will, wird er schon was dazu sagen.
@W.S. schrieb: > Spaß ist was anderes. Na dann bin ich hier doch wohl falsch ... Aber immerhin: die ersten Seiten des Buches habe ich schon hinter mich gebracht. Vielleicht sollte ich mir ein paar Durchhalteparolen über Schreibtisch, Bett und sonstige Orte hängen? @Axel Schwenke: Vielen Dank für Deine ausführliche Schilderung! Du hast einen Weg gewählt, der mir ebenfalls gut gefällt und an dessen Ende man sicherlich zu 100% verstanden hat, wie so ein 1000-Füßler funktioniert. Sehr interessant fand ich auch Deine Links sowie die vielen kurzen Tipps im Posting. Und ein STM32F103 Board für 3,68 EUR beim Ali habe ich mir kurzerhand ebenfalls bestellt: http://de.aliexpress.com/item/stm32f103c8t6-stm32-stm32f103-stm32f103c8-minimum-system-board-stm32-development-board-learning-board-CortexM-Evaluation-Board/1986886246.html Mal sehen, ob's jemals ankommt. @Foldi > Beitrag Beitrag "Projekt Maus" > Ihr habt es nicht mit einem Nerd zu tun. Ach - da mußte ich fast lachen. Wenigstens einer, der mich noch für "normal" hält. Für das Maus-Projekt erhielt ich bislang überall 10-Nerd-Points extra - jedenfalls bei meiner Frau und allen, denen ich bisher mit leuchtenden Augen davon erzählt habe ... Viele Grüße Igel1
Kenne die beiden anderen von dir im Ausgangsposting gelisteten Boards nicht, aber das Stellaris Launchpad LM4F120 von TI hat Floating Point und DSP ähnliche Funktionen. Je nachdem, was du vorhast kann das einen deutlichen Unterschied machen. Entwickle mit ihm unter Linux Audio-Algorithmen und bin sehr zufrieden (sowohl mit Editor und make als auch mit Eclipse) und froh, dass ich mich nicht mit Fixed-Point Skalierung rumschlagen muss. Gerhard
Andreas, das "Maus Projekt" war seit langem der friedlichste und schönste "Neuthread" hier. Ich muss mich mal mit deiner Frau unterhalten. ... und du weißt ja, gegen mich hat die keine Chance. ;-)
Vielleicht ist das was? http://www.myavr.info/download/software/pjb_leseprobe-mySTM32-Lehrbuch_de.pdf Koste aber 49 Euro.
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.