Hallole.... Ich weiss nicht ob ich hier an der Stelle richtig bin, aber ich probier es einfach mal. Also ich bin von der Ausbildung her Elektroniker, 60 Jahre alt, verrentet. Habe einige Jahre Design Erfahrung mit Motorola Prozessoren (90er Jahre des letzten Jahrhunderts). Die Zeiten davon sind wohl vorbei. Nach meiner Verrentung versuche ich nun zum 3. Mal mich den modernen Prozessoren und dem ARM-Cortex zu nähern (rein Hobbymässig, damit die Masse zwischen den Ohren nicht schimmelt). Ich finde den richtigen Einstieg nicht. Ich verzettel mich immer dabei den ARM Hardwaremässig zu verstehen, in seiner Funktion und Aufbau. Also quasi von der Assembler Seite. Alle die ich bisher gefragt habe von meinen ehemaligen Kollegen die sich nun mit dem ARM Cortex herumschlagen haben mir gesagt ich soll das lassen und hatten kein Verständnis dafür/winken ab: erledigt alles der Compiler... Meine Frage: gibt es erprobte Vorgehensweise für die Annäherung an ARM-Processoren (Hier LPC2103 bzw. STM32F106 etc.) für unbedarfte wie mich. Mit C kenne ich mich auch nicht aus. Bin Programmiertechnisch wie gesagt nicht über Assembler (DOS-based) hinausgekommen. Hochsprache BASIC only. Also Hoffnungslos? Oder doch Einstiegsmöglichkeiten (ARM und C++ für Dummies in Deutsch....)
Welche Motorolas? 6800er oder 68000er? Wenns 68000er waren, dann schau mal bei den MSP430 vorbei statt bei den ARMen. Eine gewisse Ähnlichkeit dürfte auffallen. Man kann ARMs in Assembler programmieren, aber so viel Freude hat man daran wohl nicht. Die sind für Compiler gebaut, von wenigen handoptimierten Sequenzen abgesehen programmiert die kein Aas in Assembler.
Dieter Machmüller schrieb: > Ich finde den richtigen > Einstieg nicht. Ich verzettel mich immer dabei den ARM Hardwaremässig zu > verstehen, in seiner Funktion und Aufbau. Also quasi von der Assembler > Seite. Alle die ich bisher gefragt habe von meinen ehemaligen Kollegen > die sich nun mit dem ARM Cortex herumschlagen haben mir gesagt ich soll > das lassen und hatten kein Verständnis dafür/winken ab: erledigt alles > der Compiler... Ohne jetzt negativ klingen zu wollen, ich fürchte das wird man dir hier auch raten. Ich selbst sehe das anders, muss allerdings gestehen dass ich mit STM32 erstmals Projekte (in C) aufgezogen habe, ohne zuvor den Controller "zu Fuss" kennen zu lernen. Interesse habe ich daran aber auch. Wär super wenn sich noch Mitstreiter finden. Grüße, Edson
PS: Es ist absolut sinvoll, solche Maschinchen auf Assembler-Ebene zu verstehen. Sehr nützlich beim Debuggen. Aber man sollte sie nicht drin programmieren.
Siehe Artikel STM32. Da gibt es Compiler und Firmen die Demo-Boards liefern und ein paar Tipps für Ein-/Umsteiger. Aber C sollte man schon lernen, sonst sieht es mau aus. (Nicht C++ !)
Also, wie gesagt 3. Anlauf! Ich habe schon diverse Boards mit STMF1** und LPC21** Prozis druff. Ebenfalls JTAG Interface, Debug Hardware etc. Gerade diese Seiten hier und die Leutz hier auf Mikrocontroller.net sind der Grund warum ich noch nicht aufgegeben habe! Habe keine Hemmungen C zu lernen. Aber ich weiss nicht wie anfangen! Wie organisiere ich meinen PC? Müssen bestimmte Strukturen erzeugt werden? Pfade? Inhalte (open ocd etc., JTAG-Interface usw.)? Gibt es nicht irgendwo eine to-do liste die einen aufs Gleis setzt? Laufen will ich gerne selber...
Dieter Machmüller schrieb: > Nach meiner Verrentung versuche ich nun zum 3. Mal mich den modernen > Prozessoren und dem ARM-Cortex zu nähern (rein Hobbymässig, damit die > Masse zwischen den Ohren nicht schimmelt). Ich finde den richtigen > Einstieg nicht. Ich verzettel mich immer dabei den ARM Hardwaremässig zu > verstehen, in seiner Funktion und Aufbau. Also quasi von der Assembler > Seite. Alle die ich bisher gefragt habe von meinen ehemaligen Kollegen > die sich nun mit dem ARM Cortex herumschlagen haben mir gesagt ich soll > das lassen und hatten kein Verständnis dafür/winken ab: erledigt alles > der Compiler... Ich empfehle: http://www.amazon.de/System-Developers-Designing-Optimizing-Software/dp/1558608745 sowie ein beliebiges C Anfängerbuch Deiner Wahl. C solltest Du lernen! Ausrufezeichen! Am Besten zuerst auf dem PC, um es dann auf dem Controller anzuwenden. Wenn Du Dich damit beschäftigen möchtest, empfehle ich Dir jedoch eher, einen Microchip PIC32 (32 Bit MIPS-Kern wie zu Deinen Zeiten die VaxStations und SGI Unix-Kisten) oder dsPIC33 (16 Bit Kern mit Signalprozessor-Erweiterungen - damit kann man auch viele nette Dinge machen). Grund für die Empfehlung: Bei Microchip bekommst Du alles aus einer Quelle: Entwicklungsumgebung, Compiler, Chips, Demoboards, Bibliotheken und Protokollstacks, In-Circuit-Programmer/Debugger (da nimmst Du ein PicKIT3, das langt, damit kannst Du fast alle aktuellen PIC16/18/24/dsPIC30/dsPIC33/PIC32 programmieren und debuggen). Es passt alles zusammen, Du hast Dein System innerhalb einer halben Stunde am Laufen, und Du hast eine Quelle, wo Du fragen kannst. Bei ARM ist das viel unübersichtlicher, weil es nicht DEN ARM gibt. Standardisiert sind nur die CPU-Kerne. Mehr nicht. Bei ARM7/9 sind selbst die Interrupt-Controller von Hersteller zu Hersteller total anders. Bei den Cortex ist wenigstens das noch einigermaßen einheitlich, aber die gesamte restliche Peripherie macht jeder wie er will. Und Dein JTAG-Debugger von Hersteller A sollte den gleichen Anschluss wie das Demoboard von Hersteller B haben und mit der Entwicklungsumgebung von Anbieter C zusammenarbeiten. Das bekommst Du sicher alles hin, aber Microchip macht es Dir als Einsteiger DEUTLICH einfacher. Denk mal darüber nach. fchk
Englisch ist kein Problem? Unter http://Yagarto.de gibt es Eclipse samt HowTo. Oder dieser Artikel STM32 LEDBlinken AtollicTrueStudio. In dem Artikel STM32 Eclipse Installation hab ich auch eine Demo mit der Konfiguration für den Olimex JTAG ARM-USB-OCD drin. Damit sollte es klappen ;-)
Dieter Machmüller schrieb: > Wie organisiere ich meinen > PC? Müssen bestimmte Strukturen erzeugt werden? Pfade? Inhalte (open ocd > etc., JTAG-Interface usw.)? Gibt es nicht irgendwo eine to-do liste die > einen aufs Gleis setzt? Laufen will ich gerne selber... Wenn du schon Hardware hast, würde ich zunächst mal schauen welche IDE das Board oder den Debugger unterstützt. Oder eine IDE deines Geschmacks auswählen und erstmal auf HW-Debugger verzichten. Die STM32 haben einen Bootloader on-chip, d.h. es ist möglich mit einem RS232 zu TTL Umsetzer Programme über die serielle Schnittstelle einzuspielen. Sowohl Keils uVision als auch die Ride7-IDE von Raisonance unterstützen in der freien Version Debugging bis 32kB. Zumindest bei Ride7 bin ich mir auch sicher, dass die Kompilat-Größe nicht beschränkt ist. Mit alternativen Toolchains (Eclipse oder NetBeans mit ARM-GCC) habe ich mich bisher nicht beschäftigt. Grüße, Edson
Hallo Dieter, ich bringe meinem Azubi gerade C für Mikrocontroller bei. Was mir dabei aufgefallen ist: C hat einen Sprachumfang, vom man am Anfang eigentlich nur 20% braucht, jedenfalls für Mikrocontroller. C Bücher/Tutorials wollen einem aber immer gleich Sinn und Zweck von Pointern, Unions, Enums usw. beibringen. Das verwirrt am Anfang sehr. Jetzt bräuchte ich nur noch eine Idee, wie man geschickt erklären kann, welche 20% von den 100 die Wichtigen sind.
Ich empfehle den LPCXpresso mit LPC1769. Mit der CodeRed IDE, ist für die ersten Schritte plug&play. Allerdings hauptsächlich in C, Assembler geht zwar auch aber ich glaube nicht das es mit dem CM3 Spaß macht. Siehe auch http://www.mikrocontroller.net/articles/LPC1xxx
Dieter Machmüller schrieb: > Ich verzettel mich immer dabei den ARM Hardwaremässig zu > verstehen, in seiner Funktion und Aufbau. ARM bezeichnet erst einmal den Kern des Prozessors. Je nach Hersteller sind dann die IO-Gebilde drumherum recht unterschiedlich. Auf mich wirken diese 'ARMs' auch sehr unübersichtlich und inhomogen. Die Datenblätter dazu sind recht dünn und die gesamten Informationen auf mehrere Datenblätter verteilt. Wenn Du mit 68k zu tun hattest, wäre die Renesas-Reihe H8 und H8SX dazu recht ähnlich und für Dich einfacher zu verstehen. Die Nachfolger zu H8SX wären die RX610/RX62. Dies nur, wenn es nicht zwingend ARM zugehen sollte.
Willi schrieb: > sichtlich und inhomogen. Die > Datenblätter dazu sind recht dünn und die gesamten Informationen auf > mehrere Datenblätter verteilt. Das User Manual zum lpc1769 hat 840 Seiten, das ist mir nicht zu dünn. Das sollte für einige lange Winterabende reichen...
JojoS schrieb: > Das User Manual zum lpc1769 hat 840 Seiten, das ist mir nicht zu dünn. > Das sollte für einige lange Winterabende reichen... Ist wohl anders gemeint. Nicht was die Anzahl Seiten angeht. In AVR Datasheets sind viele Codebeispiele drin, auch kurze Anleitungen für die Vorgehensweise. In den References der ARM Controller ist das nicht üblich, würde es zu sehr aufblähen. Sowas findet man ggf. in separaten Appnotes. Zudem sind sie nicht selten unvollständig weil fragmentiert. Da wird in References oder User Manuals der Core mitsamt seiner ihm zugehörigen Peripherie wie NVIC vielleicht nur kursorisch aufgeführt. Für den gibts dann eine separate Referenz, basierend auf der Core-Doku von ARM. Logisch, denn so ist der modellspezifische Kram des Controller-Herstellers in der einen Ref, der allem gemeinsame Kram von ARM in der anderen. Das Kapitel zur Flash-Programmierung ist möglicherweise ebenfalls ausgelagert. Ok, interessiert ja die meisten nicht. Denkste - kann sein, dass die notwendige Flash-Initialisierung mitsamt Waitstates nur dort drinsteht. Ja, dünner wirds dadurch nicht und es reicht für noch mehr Winterabende. In denen man sich vieles zusammenreimen muss, weil nicht systematisch erklärt. Man kriegt die Register und ihre Bits vor die Nase gehalten, aber wie man daraus zu einer Lösung kommt darf man selber rauskriegen. Oder eben in der AN erschnuppern.
Ok, ich habe die ARM Core Doku noch nicht vermisst, aber für Maschinennahe Programmierung (in Assembler) wird man das brauchen. Beim CM3 wurde ja gerade bei Int's und Speicher einiges vereinfacht, das sollte man zum Start schon lesen. PLL und Taktoptionen richtig zu konfigurieren ist für den Anfang sicher keine leichte Aufgabe, bei AVRs hatte man damit wenig am Hut. Aber dazu helfen die Beispiele die mit der CodeRed IDE installiert werden gut weiter. Aber wenn man mehr Leistung haben möchte muss man sich auch durch mehr Doku hangeln, Ethernet und USB sind halt komplexer als ein UART oder SPI. Ich denke daher werden HiLevel Frameworks wie Arduino, .Net oder vielleicht auch Bascom für diese Prozessoren erfolgreich werden.
JojoS schrieb: > Ok, ich habe die ARM Core Doku noch nicht vermisst, aber für > Maschinennahe Programmierung (in Assembler) wird man das brauchen. Bei den Cortex-Mx auch für Interrupts, da anders als bei den ARM7/9 deren NVIC zum Core zählt und folglich dort dokumentiert ist.
Frank K. schrieb: > Bei ARM ist das viel unübersichtlicher, weil es nicht DEN ARM gibt. Ich sehe das ehr als Vorteil - wie beim 8051. Dieter, meiner Meinung nach solltest Du Dich von Deinen Plänen, die Dinger in ASM zu programmieren, abbringen lassen. Ich tu das auch. Der Befehlsumfang der ARMs ist recht einfach zu verstehen. Problem ist, wie hier schon angemerkt, das Drumherum. Dieter Machmüller schrieb: > Gibt es nicht irgendwo eine to-do liste die > einen aufs Gleis setzt? Laufen will ich gerne selber... Würde ich Dir gerne liefern, aber dafür habe ich leider einfach zu wenig Zeit. :-( Ich bin aber davon überzeugt, daß Du Dich da durch beißt. Gruß Jobst
Dieter Machmüller schrieb: > Laufen will ich gerne selber... Ich stell mal die Gretchen Frage: Wohin soll der Weg denn gehen? Wie kommst Du auf einen Cortex-M3? Welches Problem willst Du damit lösen? Ohne Ziel wirst Du nie die Motivation haben, auch steinige Wege zu gehen. Noch etwas zu C: im Grunde kannst Du damit ähnlich programmieren wie in Assembler, ein paar Befehle reichen aus. Das sind Zuweisungen, Grundrechenarten, Vergleiche, Bitverarbeitung und der Zugriff auf absolute Adressen für IO. Es gibt auch einen Befehl 'goto', der zu einer Marke verzweigt. Wenn man alle Variablen global anlegt und Unterprogramme ohne Parameterübergabe aufruft, bleiben die Programme überschaubar :-) Automatisch wird Dir dieser Programmierstil bald auf den Geist gehen und Du wirst Dich um bessere Strukturierung bemühen, und froh sein, dass es auch lokale Variablen gibt, die keine Seiteneffekte erzeugen. Und, und, und ... Aber als erstes brauchst Du eine Aufgabe, die es zu lösen gilt.
Ich kann auch nur den Cortex-M3 empfehlen, besonders die LPC17xx dinger! Ich hab damit ein eigenes Board entworfen was auch auf anhieb funktioniert hat. Mit der CodeRed IDE (auf Eclipse basis, was ich als deutlichen Vorteil sehe) hast du eine voll funktionsfähige IDE und mit einem LPCXpresso board hast du alles was du zum Debuggen brauchst (ich hab leider noch keins) Ich würde dir auch auf jeden Fall empfehlen mit C auf den teilen einzusteigen. Es ist nicht so schwer wie man am Anfang glaubt. Man muss erst mal ein paar Sachen einfach hinnehmen, die man am anfang nicht versteht, aber dann kommt das Verständnis von allein wenn man damit arbeitet. Sich dann noch zusätzlich in den Assembler einzuarbeiten ist sicher nicht verkehrt, kostet aber auf jeden Fall einiges an willensstärke ;) Aber im Prinzip will keiner so einen großen Controller in Assembler programmieren, bis auf ein paar Zeilen startup Code oder hier und da etwas inline assembler. Aber sonst ist es wieder mal nur ein Glaubenskrieg welchen Controller man jetzt wirklich einsetzt. Die meisten haben nur Erfahrung mit einem Hersteller/ einer Familie und halten den für den besten, so wie ich auch ;) Also sind die meißten Empfehlungen subjektive Eindrücke ;)
Wohin soll der Weg gehen... Nunja, zunächst einmal lasse ich die berühmte LED auf dem Testboard blinken (I/O, BITsetzerei, Timer, Schalterbouncing etc.), als nächstes denke ich an die Konstruktion einer Uhr mit LED Sieben-Zement-Anzeigen evt. auch LCD Anzeige auf dem Touchpad-Display des Proto-Boards. Bischen Schnick-Schnack drumherum und dann werde ich mich der Konstruktion eines programmierbaren Niedervolt-Netzteils zuwenden. Und wenn der mit der Ausgabe der schwarzen Essensmarken Beauftragte mir noch Zeit dazu lässt, denke ich daran mir evt. ein progammierbares Hochspannungsnetzteil (0-800V bei 250mA) mit Röhren als Stellgliedern/Längsreglern (primärseitig und sekundärseitig geregelt/überwacht mit STMF irgendwas)anzutun... Wenn dann noch Zeit, vermögen und können ist wird sicher noch das eine oder andere einfallen... Auf ARM-Cortex bin ich gekommen durch Gespräche und nachdenken. Argumentationskette: relativ preiswert auch für Hobbyisten, breite Unterstützung durch Hersteller, viel Platz und Raum für Anwendungen und Code, die BIT-Knipserei aus der beschränkten 8-Bit Zeit ist vorbei, Geschwindigkeit von 40, 72, 150, 200 Megaherz. Und, was mit entscheidend ist: MIKROCONTROLLER.NET! Menschen also die zweckgebunden hilfreich sein können und die gleichen Interessen verfolgen wie man selbst.
Dieter Machmüller schrieb: > Und, was mit entscheidend ist: MIKROCONTROLLER.NET! Dazu mußt Du aber ganz konkrete Fragen stellen. Welches Board, mit welcher Software, wie weit Du selber kommst und wo es hakt. Nur dann kann man sinnvoll antworten. Deine genannten Probleme erledigt ein AVR mit links im Schlafmodus :-) Der M3 stellt Dir zunächst einen Berg in den Weg.
Willi schrieb: > Deine genannten Probleme erledigt ein AVR mit links im Schlafmodus :-) Hast Du wahrscheinlich recht mit! Aber ich glaube halt das die Zukunft jetzt recht schnell die schmalbrüstigen (wenig Platz für CODE und Daten) 8Biter unter sich begraben wird. Es gibt einfach keinen Grund diese Leben zu lassen. Ich kann als Entwickler für das Geld das ein solcher angepasster (an die Aufgabe oder umgekehrt) Kontroller kostet einen universell einsetzbaren Klumpen Elektronik kriegen mit allen Freiheitsgraden (Platz, schnell, individuell usw.). Der Kunde schreit gegen Ende der Entwicklung nach einer umfassenden Erweiterung des Pflichtenheftes: egal, patschen wir hinten dran! Platz hatz! Hat es in der Vergangenheit auch schon gegeben...
So sehe ich das auch. Meine STM32 lasse ich alle mit dem internen RC mit 8Mhz so vor sich her dümpeln. Außer ich brauche USB, dann laufen die mit 48MHz. Und ich habe den Vorteil, dass wenn es klemmt von der Geschwindigkeit, einfach "aufdrehen" und gut ist. Vor allem, der STM32 hat so viel Peripherie drin, SPI, UART, Timer, AD, DA, ... da hat man einfach genug Auswahl.
Dieter Machmüller schrieb: > Aber ich glaube halt das die Zukunft > jetzt recht schnell die schmalbrüstigen (wenig Platz für CODE und Daten) > 8Biter unter sich begraben wird. In Deinem Alter mußt Du doch nicht mehr um die Wette rennen :-) Die Frage für Dich sollte sein: will ich Lust oder Frust? Gerne würde ich auch mit Dir über die Lebenszeit der AVR eine Wette abschließen. Das gibt aber vermutlich nur dann einen Sinn, wenn Du mir den Siegerpreis zügig zukommen läßt :-) Sieh die die 8051 an; die Gurken werden immer noch verwendet. Dieter Machmüller schrieb: > Ich kann als Entwickler für das Geld das ein solcher > angepasster (an die Aufgabe oder umgekehrt) Kontroller kostet einen > universell einsetzbaren Klumpen Elektronik kriegen mit allen > Freiheitsgraden (Platz, schnell, individuell usw.). Wie Du geschrieben hast, hast Du ja schon einige dieser 'Klumpen' auf dem Tisch zu liegen. Und, was kannst DU damit anfangen?
Willi schrieb: Wie Du geschrieben hast, hast Du ja schon einige dieser 'Klumpen' auf dem Tisch zu liegen. Und, was kannst DU damit anfangen? Ist das Dein ernst? Mit der Einstellung würden wir Entwicklungsgeschichtlich immer noch in Ostafrika rumhüppen und Bananen futtern ohne darüber nachzudenken. Mir fehlt doch nur ein gewisses Aha-Erlebnis und ich bin lauffähig. Zwar lauf ich nicht die 100 Meter in 9,8 sec sondern stolpere die ersten Veranstaltunge vor mich hin. Aber wie schon gesagt: ich habe Zeit! Ist blos Hobby, nicht Broterwerb...
Dieter Machmüller schrieb: > Aber wie schon gesagt: ich habe Zeit! Ist > blos Hobby, nicht Broterwerb... Dann mach Dir doch nicht den Streß, hochaktuelle Prozessoren mit Steinzeit Methoden zu programmieren. Nimm den Prozessor, der für die Aufgabe angemessen ist; nicht mehr und nicht weniger.
hallo dieter, deine entscheidung für cortex m3 finde ich gut. der cortex m3 hat eine übersichtliche architektur. allerdings würde ich dir auch empfehlen, ihn in c zu programmieren. die syntax ist nicht so schwer zu lernen und wie schon erwähntr braucht du am anfang vielleicht 20% davon. als entwicklungsumgebung für einen neuling würde ich dir empfehlen eine kickstart version einer kommerziellen lösung (iar oder keil) zu nehmen. grund: keinerlei fragen/probleme mit installation und div. versionen dcer unterschiedlichen tools. die kickstart versionen haben meistens eine codespeicehr-limitierung (bei iar sind das 32kbyte), was aber am fang kein problem sein sollte. wenn du bereits ein jtag interface hast (welches den?) ist das ganze eine sache von einer halben stunden und du kannst die ersten example projekte testen und erweitern. ich persönlich kenne nur die iar workbench. da sind jede menge exmpales enthalten mit denen du am anfang erste erfahrungen sammeln kannst. unter dem link findest kannst du die kickstart vesion: http://supp.iar.com/Download/SW/?item=EWARM-KS32 mfg gerhard
Wieso ist hier noch keiner genervt und sagt " lies doch erst mal das Handbuch Du ...." Das hat nix mit dir zu tun Dieter, aber hier sind oft solche Aussagen alltäglich .
Weil ein STM32 / Cortex M3 nicht mit einem Handbuch zu verstehen ist. Es gibt zu viele unterschiedliche Möglichkeiten den zu Programmieren, angefangen mit Vorlieben, bestehende Hardware, Prozessorhersteller der den Cortex-M3 (oder auch ARM7) in den Chip setzt, JTAG-Interface das bereits gekauft wurde uvm. Bei AVR wäre das einfach, da gibt es fast nur das AVR Studio.
Dieter Machmüller schrieb: > Nach meiner Verrentung versuche ich nun zum 3. Mal mich den modernen > Prozessoren und dem ARM-Cortex zu nähern Hallo Dieter, Ich bin zwar noch nicht verrentet, aber fast genauso alt wie du. Wenn du früher mit Motorola gearbeitet hast, dann wären für dich die Fujitsu FR Controller genau das Richtige. Das sind 32 Bit Controller, die innen ein wenig motorlolalike sind (big endian und so) und sie haben einen ganz angenehmen Assemblercode. Sind bloß in der Bastlerszene kaum angesagt. Der Assemblercode bei den ARM's bzw. Cortexen und auch den MIPS-Teilen wie PIC32 ist hingegen eine ziemliche Krätze. Wobei aus meiner Sicht der MIPS-Code noch viel grauenhafter ist als der ARM-Code. Bei beiden kommt man nicht daran vorbei, den Hauptteil seiner Programme in C zu schreiben - was aber für dich nach sehr kurzer Zeit kein Problem sein dürfte. Man muß C nicht mögen, aber man kann damit auch anständig les- und verstehbare Programme schreiben. Viele selbsternannte "Profis" gefallen sich darin, ein möglichst unverständliches Kauderwelsch in ihren Quellen zu pflegen, aber das ist Mist. Laß dich von sowas nicht abstoßen. Es gibt zwar bei Free Pascal einen Port nach ARM, aber das läuft auf Windows-CE hinaus. Worauf du nach meiner Ansicht viel mehr achten solltest, sind ganz andere Dinge: 1. Such dir zum Basteln Controller aus, die einen eingebauten Bootlader haben. Die meisten Teile von NXP haben einen fest eingebaut und - soweit ich weiß - auch die von ST. Das hat den Vorteil, daß du den Controller über eine schlichte serielle Schnittstelle programmieren kannst und nicht zwingend ein JTAG-Interface brauchst. Ne simple V24 ist einfacher als der ganze JTAG-Kram. Für NXP als Standalone-Programmiersoftware: "Flash Magic". 2. Such dir zum Programme schreiben eine Toolchain aus, die dir keinen zusätzlichen Streß macht. Je aufgeblähter die bei so einer Toolchain enthltene IDE ist, desto schlechter ist es, denn man wird quasi erschlagen mit Problemen der IDE, die mit dem zu programmierenden Chip garnix zu tun haben. Ich selber hab schon einiges durch: GNU, IAR, RIDE(innen auch GNU), irgendwelche kleineren amerikanischen Pakete wo ich den Namen schon wieder vergessen hab und Keil. Bei dem bin ich geblieben, denn dort gibt's die originalen ARM-Tools. Und die kann man auch ganz prächtig ohne IDE benutzen. Wenn du keine großen Sachen programmieren willst, dann reicht dir deren Demo-Version erstmal aus. 3. Mache um die diversen IDE's erst mal nen Bogen. Deine Programme sehen ja im Prinzip so aus: ein kurzer kleiner Kaltstartcode in Assembler, dann der Hauptteil in 1 oder mehreren C-Quellen, alles compiliert bzw. assembliert, dann gelinkt und dann mit 'Fromelf' zur Hexdatei gemacht. Hier ist dann wieder der alte Motorola-S-Code dabei, den du ja kennst. Also rufe erstmal alle beteiligten Tools (den Compiler, den Assembler, den Linker und Fromelf) von der Kommandozeile aus auf und mach dir dann zu deinem ersten Vorhaben eine Batchdatei, so wie früher bei DOS. Auf die Weise wirst du dich erstmal nur mit den Dingen befassen müssen, die wirklich deinen Controller betreffen. W.S.
Dieter Machmüller schrieb: > Wohin soll der Weg gehen... Nunja, zunächst einmal lasse ich die > berühmte LED auf dem Testboard blinken (I/O, BITsetzerei, Timer, > Schalterbouncing etc.), als nächstes denke ich an die Konstruktion einer > Uhr mit LED Sieben-Zement-Anzeigen evt. auch LCD Anzeige auf dem > Touchpad-Display des Proto-Boards. Bischen Schnick-Schnack drumherum und > dann werde ich mich der Konstruktion eines programmierbaren > Niedervolt-Netzteils zuwenden. Und wenn der mit der Ausgabe der > schwarzen Essensmarken Beauftragte mir noch Zeit dazu lässt, denke ich > daran mir evt. ein progammierbares Hochspannungsnetzteil (0-800V bei > 250mA) mit Röhren als Stellgliedern/Längsreglern (primärseitig und > sekundärseitig geregelt/überwacht mit STMF irgendwas)anzutun... Das sind alles Aufgaben, wo Du mit einem 8Bitter (z.B. AVR) deutlich schneller und einfacher zum Ziel kommst. Du mußt da nicht Tod und Teufel konfigurieren, sondern kannst direkt los programmieren. Und gerade, wenn Du andere Hardware ansteuern willst, ist es sehr nützlich, daß Du mit 5V arbeiten kannst oder bei Batteriebetrieb ganz ohne Spannungsregler (AVR: 1,8..5,5V). Für eigene Platinen ist das DIP-Gehäuse ja auch ganz praktisch (AVR: DIP8 .. DIP40, 6 .. 35 IO-Pins). Einen ARM im TQFP kann ich dagegen nicht mehr selber löten. Du kannst sogar in Assembler anfangen. 16, 32 Bit oder float Rechnungen sollte man aber besser dem C-Compiler überlassen. Auch sind die Programiererfahrungen ja nicht verloren, wenn Du mal später auf nen 32Bitter umsteigst, sie gelten dort ganz genau so. Nur ist der Umstieg erheblich leichter, als der totale Neuanfang. Du mußt Dich dann nur mit den Unterschieden bezüglich Toolchain, Konfiguration, Peripherie befassen. Beim ARM ist Assembler nur was für Schreibwütige, da RISC. Ein Setzen eines IO-Registers kostet schon 3 Befehle. Eine C-Zeile ist also mindestens 3 Assemblerzeilen lang. Peter
Dieter Machmüller schrieb: > Aber ich glaube halt das die Zukunft > jetzt recht schnell die schmalbrüstigen (wenig Platz für CODE und Daten) > 8Biter unter sich begraben wird. Da irrst Du Dich gewaltig. Es gibt immer noch viele Aufgaben, die keine Super-Boliden benötigen. Und da macht sich sehr erheblich bemerkbar, daß einfachere CPUs auch robuster und zuverlässiger sind. Jeder Handybenutzer weiß, wie man die Batterien herausnimmt, um die CPU neu zu starten. Es gibt aber Anwendungen, die sich das nicht erlauben können. Solange Du nicht USB, Ethernet, GUI usw. programmieren willst, ist der 32Bitter nur mehr Aufwand ohne jeden Nutzeffekt. Peter
Hallo Dieter Machmüller, hoffe dass Du nach dieser Zeit noch diese Meldung liest. Ich bin der gleichen Meinung wie Du. Assemblerprogrammierung ist einfach schön, sauber und längst nicht so verquirlt wie C. Ich bin beider Sprachen mächtig, aber wenn ich versuche die Beispielprogramme nachzuvollziehen, grauts mir die Haare. Jeder macht sein eigenes Süppchen. Wo ist diese include schon wieder, etc. Und wenn ich in Asm das Gleiche programmiere, wie in C, kann man es lesen, verstehen und muss nicht lange suchen, was machen sie jetzt schon wieder. Schreib mal zurück, wenn Du Infos haben willst.
Hallo Dieter, wenns recht ist gebe ich hier auch mal meinen Senf dazu :-) also zuerst mal: wenn du C lernen möchtest, dann würde ich doch eher empfehlen, das auf dem PC zu tun. Dort hast du funktionierende Hardware, oftmals einen brauchbaren Debugger, was die Sache schon wesentlich vereinfacht. Dann: ich habe Anfangs auch versucht, mich "theoretisch" erstmal in die ARMs einzuarbeiten. Hat bei mir so aber auch nicht funktioniert; ich persönlich konnte das alles erst begreifen, wenn ich wirklich was programmiert habe und mit dem Debugger im Single Step den Code studiert habe. Ich konnte jetzt hier auf dem Smartphone nicht den ganzen Thread lesen. Auf die Gefahr hin dass es schonmal gefragt wurde: welche Prozessoren hast du früher denn programmiert? Gruss und viel Erfolg beim Basteln
Es ist zwar wie gesagt hilfreich die einzelnen Komponenten des Mikrocontrollers zu verstehen (und man kommt auch nicht drum herum), aber wenn du früher auf ner 68k programmiert hast ... Die war halt schon in Assembler fast wie ne Hochsprache, dies hat man jedoch bei den ARMs anders gemacht. Um die Architektur möglichst einfach zu halten hat man sozusagen eine Abstraktionsebene weniger in der Assemblersprache drin (sowas wie die adressierungsart "Doppelt indirekt mit Post-Index"). Auch können um den Opcode klein zu halten keine größeren Konstanten direkt in den Opcode. Man muß dann halt irgendwo im Programspeicher eine Tabelle mit Konstaten haben auf die im Opcode verwiesen wird über ein Register oder einer kleinen 8Bit Konstante. Das macht in Assembler nicht wirklich Spaß. Ich hab auch auf ner 68k angefangen und finde Assembler "gefühlt" schöner als C, aber auf nem ARM ist zumindest ein gemisch aus beidem anzuraten. Spannend sind die bedingte ausführung vom Befehl direkt im Opcode mit gleichzeitigem Shift und auch die Ternären Operatoren mit zwei Sourcen und einer Destination alla "ADDGT y,a,b LSL #1" -> "addiere a und b nach y wenn Größer und schiebe y um 1 nach links".
Also ich denke, mittels Instruction Set Manual und Datenblatt zum Mikrocontroller, solltest du recht einfach zurecht kommen, wenn du kein Neuling in Sachen ASM-Programmierung bist. So hab ich auch meinen Einstieg in die ARM Welt vollzogen. Komplett in Assembler würde ich ein Programm allerdings nicht schreiben wollen. Die Konfiguration der ganzen Peripherie ist bei den Cortex Dingern doch recht mühsam. Ansonsten bin ich nicht der Meinung, dass das ARM Instruction Set schwerer zu beherrschen ist als zb das von den ATmegas oder MIPS. Also C-Kenntnisse würde ich mir an deiner Stelle auf jedenfall aneignen. Soweit von Assembler ist das nun auch nicht entfernt. Würde dir gerne den Link zu dem e-book schicken mit dem ich vor etwa 10 Jahren begonnen habe, finde es aber leider nicht mehr. Name war glaub ich "C in 21 Tagen" und die Webseite hatte ein gelbes Layout. Vielleicht kennt das ja noch jemand. Bis zu dem Pointer-Kapitel bin ich damit sehr schnell voran gekommen.
Hab es doch noch gefunden. War allerdings gleich C++ und das gelbe Layout hatte ich wohl falsch in Erinnerung g. Hier auf jedenfall der Link: http://www.informit.de/books/c++21/data/start.htm Man muss zu Beginn auch nicht gleich alles verstehen. cout, cin zb habe ich lange Zeit einfach angewandt ohne zu wissen was der Shift-Operator hier genau macht. Einfach die Beispiele im Buch ausprobieren und ein wenig experimentieren reicht vollkommen für den Einstieg. Nur nicht gleich jedes Detail analysieren, das gibt sich mit der Zeit von alleine.
>aber wenn du früher auf ner 68k programmiert hast ... >Die war halt schon in Assembler fast wie ne Hochsprache, Dann nimm den R32C, der ist noch mehr wie ne Hochsprache. (Schätze mal, wenn einer früher 68k in ASM progr hat, will er beim R32C auch bei ASM bleiben) >Beim ARM ist Assembler nur was für Schreibwütige, da RISC. Ein Setzen >eines IO-Registers kostet schon 3 Befehle Wäre mit MAKRO auch kein Problem > Aber ich glaube halt das die Zukunft > jetzt recht schnell die schmalbrüstigen (wenig Platz für CODE und Daten) > 8Biter unter sich begraben wird. 8Biter wirds wohl noch ewig geben, weil sehr Vieles damit möglich ist. Es werden ja auch noch 8Biter neu entworfen, und die sind auch günstiger als 32 Biter. >Die Konfiguration der ganzen Peripherie ist bei den Cortex >Dingern doch recht mühsam. Aber die Peripherie muss man sowiso kennen, egal ob in ASM oder in C.
>Wenn du früher mit Motorola gearbeitet hast, dann wären für dich die Fujitsu FR
Controller genau das Richtige....
Nein, das sind RISC, keine CISC.
Also ich habe für meinen Einstieg auch zuerst auf die STM32 mit dem billigen Stm32-Discovery Board gesetzt. Bis ich merkte, dass Attolic Truestudio neben den nervigen Einblendungen auch funktionale Einschränkungen in der freien Version hat. Dann habe ich das Truestudio weg gelassen und nur mit Eclipse und den stlink-gdbserver gedebuggt. Das ist aber schon nicht mehr anfängertauglich beim Einrichten. Da Attolic die aktuelle Version jetzt auf 32k beschränkt hat, kommt es nur noch in Frage wenn man irgendwann mal beabsichtigt das auch zu kaufen. Und 32k mit Debug-Informationen sind schnell erreicht. Da ich später dann Ethernet wollte, habe ich die LPCXpresso-Schiene probiert. Vor allem weil es bei der 1769-Variante reicht eine Ethernetbuchse anzuschließen da der PHY schon auf dem Board ist. Und ich muss sagen: Es ist für den Einstieg das besser abgestimmte System. Die 128k Limitierung reicht für mich aus. Die Beispielprojekte für die Xpresso-Boards werden mitgeliefert und es nervt nirgends ein Popup oder Zwangswartepausen. Natürlich kann man für so eine CPU auch nur in Assembler programmieren. Das hat dann Vorteil, dass man gar nicht erst auf die Idee kommt die Interface-Libs zu benutzen. Die gaukeln einem am Anfang nur vor was zu verstehen ohne das Manual zu lesen. Und wenn dann was nicht geht landet man dann ganz schnell wieder bei den Registern. Und die lassen sich mit Assembler genau so gut befüllen. Wenn man aber so einen M3 wie LPC1769 benutzt, muss es ja einen Grund haben. Sobald dann Ethernet oder ein anderes höheres Protokoll zum Einsatz kommen soll, ist aber mit reinem Assembler nicht mehr viel zu machen. Entweder man startet die Einmannshow komplett und programmiert alles von Grund auf selbst oder man bedient sich an verfügbaren Bibliotheken oder freiem Code. Und der ist in der Regel in C, so dass da kein Weg dran vorbei geht. Deshalb meine Empfehlung: LPCXpresso 11c24 oder 1769 Ausserdem können diese Boards durch die Möglichkeit des "Durchsägens" auch gut in eigenen Projekten als Modul verbaut werden. Noch ein Tip, wenn man sich die Mühe macht, ein makefile zu verstehen und anzupassen, dann kann man seine Projekte prima als batch übersetzen, mit jedem beliebigen Editor den Code schreiben und über den Import als makefile-Projekt in Eclipse (oder einer auf Eclipse beruhenden IDE) damit arbeiten und debuggen.
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.