Hi an alle, ich wollte mich mal ein bischen mit AVR´s beschäftigen. Bei der Hardware sehe ich nicht das Problem. (Die Elektronik Gundlagen habe ich soweit drauf ) Jedoch habe ich keinen Plan von diveresen Programiersprachen. Was könnt Ihr mir empfehlen, womit fange ich als "blutiger Amateur" an. Gruß Micha
hi micha man kann das nicht so sagen,welche prog.sprache die bessere ist, bzw.welche man empfehlen kann. ich habe mit dem asm.von atmel angefangen, C ist nicht mein ding,also progr.ich seit einigen jahre mit dem sehr guten basic-compiler bascom avr. pascal(e-lab) ist auch sehr guter compiler,aber schweineteuer am besten du testest mal ein paar compiler ,C,basic oder pascal wenn dir ein compiler zusagt,bleib dabei. demo progr.giebt es ja genug freie c-compiler auch demo vom bascom avr codegrösse auf 2 KB beschränkt demo vom pascal compiler(e-lab) max. 4 KB code. mfg ThomasB
Wenn Du den MC wirklich verstehen willst, dann arbeite dich für den Anfang in ASM ein. Umsteigen kannst Du dann immer noch aber die Grundlagen die Du bei der ASM Programmierung lernst versetzen dich erst in die Lage zu verstehen was der MC wirklich macht und kann. Meine Meinung ist, wer ASM begriffen hat kommt mit jeder höheren Programmiersprache klar. Steffen
Hallo, ich hab keinen Nerv, mich in meiner Freizeit mit trockenem ASM herumzuschlagen, ich nutze FASTAVR (Basic). Da komme ich ruckzuck zu einer Lösung, z.B. Darstellung LCD in 5 Zeilen und gut. Was soll ich Werte in Register schreiben und Verschieben, das soll mir der Compiler abnehmen, ich kümmere mich den Programmablauf und nicht was wo für Werte in Register müssen usw. Wie gesagt, jedem das sein, ich find s so sehr einfach und effektiv, Basic kann jeder leicht lernen, evtl. C64 oder C-Control gehabt, dann ist ganz einfach. Gruss A. Arndt
Damit's wenigstens eine Gegenstimme gibt, von mir keine Zustimmung. :-) Lerne Pascal. Das ist als Lehrsprache konzipiert und erlaubt es, sich einigermaßen schnell in eine Programmierung hineinzuarbeiten. Mit reinrassigem Pascal kann man zwar kaum eine vernünftige Applikation schreiben, aber zum Lernen ist die Sprache wirklich gut. Danach kannst Du relativ einfach C lernen, natürlich auch auf einer Universalmaschine (sprich: PC oder sowas). Eigentlich mußt Du ,,nur'' Pointer und Arrays noch verstehen sowie das andere IO-Konzept (stdio) von C. Dann kannst Du C auf Microcontrollern (MCUs) machen. Das Verständnis des MCU-Assemblers und der Maschine ist zwar zwingende Voraussetzung für eine erfolgreiche Programmierung dieser MCUs, aber es ist deshalb keineswegs notwendig, daß man sich den Masochismus einer Assemblerprogrammierung als solches antun muß. Es genügt vollauf, wenn man den vom Compiler generierten Assemblercode lesen kann. Anfangs liest man sich den etwas häufiger durch, dadurch bekommt man ein Gefühl für den Compiler und den Controller. Später liest man sich dann nur noch kritische Stellen durch, da man gelernt hat, dem Compiler zu vertrauen. Ganz Verwegene können dann auch noch C++ lernen und das auf MCUs machen... Es ist keineswegs so, daß C++ per se größeren Code zwangsläufig erzeugen muß, und von den besseren Abstraktionsmöglichkeiten können teilweise auch MCU-Programme profitieren. Man sollte aber die Feinheiten dieser Programmiersprache schon sehr gut kennen, bevor man sich herantraut, diese auf MCUs zu verwenden. Ein einzelnes vergessenes & kann da heftigen Schaden (in Form von Codegröße und Laufzeitverhalten) verursachen.
@Joerg: Wie soll man denn die Ergebnisse eines C-Compilers auf Assembler-Ebene bewerten können, wenn man nie in Assembler programmiert hat? Zugegeben, auf dem PC arbeite ich mit einer Hochsprache, aber das ist auch eine völlig andere Welt, in der Lösungen auf einer hohen Ebene gefordert sind. Auf Microcontrollern werden eher selten Multiuser-Datenbankanwendungen implementiert, dort schiebt man meist im wahrsten Sinne des Wortes "Bits und Bytes", wozu die Assemblersprache ja entwickelt wurde. Außerdem erscheint mir der Weg über Pascal und C auf dem PC und dann zu C auf dem MC reichlich weit, nur um sich "mal ein bischen mit AVR´s zu beschäftigen". Gruß, Frank
> Wie soll man denn die Ergebnisse eines C-Compilers auf > Assembler-Ebene bewerten können, wenn man nie in Assembler > programmiert hat? Das geht schon. Ich schrob ja, daß die Kenntnis der entsprechenden Assemblersprache und der zugrundeliegenden Maschine (Registersatz etc.) eine unbedingte Voraussetzung für eine erfolgreiche MCU-Programmierung ist. Trotzdem habe ich mir nach einer kurzen PIC-Episode mit Assembler geschworen, mir das nicht wieder freiwillig anzutun, und habe das auch weitgehend durchgehalten. OK, ein paar avr-libc Routinen habe ich auch in Assembler geschrieben oder debuggt :), aber der Compiler nimmt einem eben all die Schusselfehler ab, die man gerade bei heutigen Controllern schnell machen kann. (Muß ich nun den nächsten JMP-Befehl nicht überspringen, wenn das C-Flag jetzt nicht gesetzt ist, oder wie oder was? Achja, wo ist eigentlich der ADCI-Befehl? Braucht man nicht, es ist für einen Compiler kein Thema, statt 33525 zu addieren -33525 zu subtrahieren, und der freiwerdende Opcode wurde für was besseres benutzt.) Außerdem optimieren Compiler mit ihrer stupiden Methode oft mehr, als man sich aus Übersichtlichkeitsgründen in einem Assemblerprogramm zutrauen würde. Von Gleitkomma und Assembler schweigen wir dann lieber gleich... Da artet das Schreiben eines Assemblerprogramms in stures Assemblieren der zugehörigen Unterprogrammaufrufe aus. > Zugegeben, auf dem PC arbeite ich mit einer Hochsprache, aber das > ist auch eine völlig andere Welt, in der Lösungen auf einer hohen > Ebene gefordert sind. Diese Welt ist gar nicht so anders, wie Du denkst. Auch dort werden nicht nur megabyteschwere Datenbanken programmiert, sondern auch simple Tools wie das Kopieren einer Datei oder die Ausgabe der aktuellen Uhrzeit. Würde trotzdem keiner in Assembler machen. Warum bitte soll ich mir den Masochismus der Assemblerprogrammierung dann für die MCU antun? Nein, danke. Es genügt, wenn ich verstehe, was da passiert, aber ich muß es nicht selbst können. (Schlechter Vergleich zum Auto: es genügt, wenn ich verstehe, wie der Verbrennungsmotor funktioniert, ich muß ihn nicht selbst konstruieren können. OK, viele verstehen ihn nichtmal mehr.) > ... dort schiebt man meist im wahrsten Sinne des Wortes "Bits und > Bytes", wozu die Assemblersprache ja entwickelt wurde. Auch C wurde mit diesem Hinblick entwickelt, schließlich wollte man ein Betriebssystem damit schreiben. Was glaubst Du sonst, wofür es Operatoren wie & ^ | << >> gibt? Andere Programmiersprachen hatten diese nicht bzw. nur in ihrem logischen Äquivalent (also && bzw. ||). Vor der Einführung von C hat jeder, der ein Betriebssystem implementieren wollte, genauso argumentiert wie Du heute bei den MCUs: ,,Das kann man ja nur in Assembler tun.'' Heute ist es eine völlige Selbstverständlichkeit, daß man Betriebssysteme zu weit über 90 % nicht mehr in Assembler schreibt. Natürlich ist das auch ein Nachteil von C: man muß sich um alles selbst kümmern, wie beim Assembler. Errorcode bei Funktionsrückkehr ignoriert? Wenn Du Dich nicht selbst kümmerst, bist Du im Fehlerfall erschossen... > Außerdem erscheint mir der Weg über Pascal und C auf dem PC und dann > zu C auf dem MC reichlich weit, nur um sich "mal ein bischen mit > AVR's zu beschäftigen". Entsprechend schlecht sehen viele programmierte Applikationen dann auch aus. Wie wir schon erfahren durften keineswegs nur die eines Hobbyisten, sondern selbst professionelle Baggersteuerungen etc... Wer programmieren will, soll auch programmieren lernen. Wer's nicht will, soll es bleiben lassen. Es gibt genügend, die es gut gelernt haben, so daß es nicht schwer sein sollte, sich einen Freund zu suchen, der einem dabei hilft, sowohl beim Lernen also auch alternativ dabei, sich einfach gegen ein Glas Bier am Abend mal schnell eine kleine Applikation programmieren zu lassen. U. U. kann dabei auch ein `learning by doing' rauskommen, wenn man sich das hinterher von ihm erklären läßt, was er da getan hat, und man die Auffassungsgabe hat, da auch durchzusteigen. Ach so, ich habe sehr viele verschiedene Assembler programmiert, teilweise ausgiebig. Die PDP-11 hatte den schönsten Befehlssatz bislang, völlig orthogonal, jedes Register konnte gleichermaßen benutzt werden für jede Adressierung... Ich weiß schon, worüber ich spreche. Ich habe damals den Leiter unseres Rechenzentrums auch nicht verstanden, als er mir erläutert hat, daß er keinen Assembler mehr anfassen möchte in seinem Leben. Die haben damals das Bibliotheksverwaltungsprogramm der hiesigen TU in Maschinencode programmiert... Das hat ihm fürs Leben gereicht. Inzwischen bin ich selbst seiner Meinung gefolgt, obwohl ich die vor 20 Jahren noch nicht verstehen konnte.
Hi und Danke an alle. Leider habe bei all den Antworten für mich noch nicht die richtige gefunden. Tut mir leid, wenn ich Euch mit meiner Unwissenheit nerve. Ich müsste eigentlich erst mal wissen, was welche Programiersprache kann : Wo liegen die Stärken ? Warum gibt es andere ? Was machen die besser ? ... Ich habe vor in der Holzindustrie einige Anwendungen zu optimieren z.B. Laserscanner, Trocknungstechnik u.s.w. . Mir geht es also hauptsächlich um Steuerungen und Überwachung von Prozessen und/oder Anlagen. Sicher kann man auch gleich eine Siemens "SPS 7" inkl. Software (oder was auch immer) nehmen. Das schöne an eigenen Lösungen ist doch aber das Testen neuer Ideen gepaart mit ein bischen selber gebastelten Systemen. Ich habe früher auch schon ein bischen rumgelötet. Nun, da ich mir vorgenommen habe, mir wieder etwas Zeit für Hobbys zu nehmen, möchte ich gerne "anspruchsvolle" Sachen verwirklichen. Aber so richtig "sinnvolle" sachen gibt es kaum noch für den Home-User. Alle, die mein stuuuuuuuundenlanges Geblubber noch nicht verschreckt hat, kann ich nur bitten, mir mal direkt zu mailen. (wenn Ihr lieber alles im Forum lassen wollt, ist es mir auch recht ) Ich beschäftige mich z.Z. unter anderem mit einer - Mikrowellen-Vakuum-Trockenstrasse für Schnittholz. Es gibt bereits fertige (wohl kaum ausgereifte )Anlagen für die Industrie, aber dieses Kapitel ist noch sehr jungfräulich und gibt allein Stoff genug um einen ganzen Kreis interessierter Bastler Monate zu beschäftigen. Ein weiteres Kapitel ist z.B. eine Fehlererkennung von Holzprodukten. So z.B. folgende Frage: Wie erkenne ich Holzfehler, Äste, faule Stellen oder Risse usw. in einem Sortierband das mit 2m/sec laufen muß ? Also, wie schon gesagt, alle die sich gern mit solchen Problemen rumschlagen möchten, mailt mir. P.S. Ich betreibe diese Sachen als Hobby. Die gesamte "Forschung" hat keinen comerziellen Hintergrund. Mfg. Micha
Wenn man nach oben hin offen sein will, kommt man nicht um C herum. Größere Anwendungen, die einen ATMega32...256 erfordern habe ich bisher immer nur in C gesehen. Aber zum Einstieg empfehle ich auch Assembler. Man muß nämlich erstmal ein Gefühl dafür entwickeln, was der MC mit links macht bzw. was im die Schweißperlen auf die Stirn treibt. Ohne die geringsten Anhaltspunkte über die Laufzeit der verschiedensten Routinen kann man unmöglich Echtzeitanwendungen programmieren. Auch ist Assembler ideal, um die Hardwarezugriffe richtig zu kapieren, angefangen von den Portpins über die Timer, ADC, PWM und sehr wichtig die Interrupts. Sehr schön an C ist, daß man alles was nicht direkt auf Hardware zugreift erstmal am PC, z.B. mit Borland-C austesten kann. Auch ist Borland-C zu empfehlen, um die ersten Schritte in C zu machen. Es läßt sich nunmal am PC einfacher debuggen, als auf dem MC. Und den AVR-Simulatoren ist meistens auch nicht zu trauen. Zumindest werden hier öfters Fehler gemeldet, die gar keine sind. D.h. der MC machts schon richtig, nur der Simulator spinnt. Für Echtzeitanwendungen ist auch besonders wichtig, daß man niemals Bibliotheksfunktionen als Blackbox verwendet, sondern nur solche, die auch als Quelltext vorliegen und somit eine Laufzeitabschätzung erlauben bzw. auch Anpassungen und Debugging fall notwendig. Z.B. die GCC-Bibliotheken (WINAVR) liegen alle auch als Quelltext vor. Anders gesagt, Programmiersprachen, die ihre Bibliotheken geheimhalten sind für zuverlässige und deterministische Echtzeitanwendungen denkbar ungeeignet. Peter
@Micha: Wie Du an der Diskussion siehst, eignen sich im Prinzip alle gängigen Programmiersprachen, aber an der Frage, welche denn nun die beste Sprache ist, scheiden sich die Geister. Darauf wirst Du nie eine eindeutige Antwort bekommen. Ich stimme Joerg aber in mindestens einem Punkt ganz entschieden zu: Professionelle Ergebnisse ohne professionelle Herangehensweise sind so wahrscheinlich, wie 'n Sechser im Lotto. @Joerg: Du betonst, daß man Assembler beherrschen muß, wenn man MCUs programmieren will. Da sind wir uns einig. Und daß eine Hochsprache viele Vorteile hat, bestreite ich auch nicht. Meine Argumentation ist halt nur die, daß man als Einsteiger sinnvollerweise die ersten (wohl meist kleinen und übersichtlichen) Programme auch in Assembler schreibt, weil das Lernen der Assemblerbefehle und der MC-Eigenheiten dann effektiver ist, als wenn man nur Datenblätter büffelt. Der berühmte Unterschied zwischen Theorie und Praxis... Und weil ich glaube, daß Hochsprachen mit ausgefeilten Bibliotheken einen Einsteiger dazu verleiten, mal schnell etwas zusammen zu zimmern, mit den von Dir bereits angesprochenen Auswirkungen. gruß, Frank
@Frank: > Meine Argumentation ist halt nur die, daß man als Einsteiger > sinnvollerweise die ersten (wohl meist kleinen und übersichtlichen) > Programme auch in Assembler schreibt, weil das Lernen der > Assemblerbefehle und der MC-Eigenheiten dann effektiver ist, als > wenn man nur Datenblätter büffelt. Hierin unterscheiden sich eben unsere Ansichten. ;-) Ich denke, daß es vollauf genügt, wenn man den vom Compiler generierten Code anguckt stattdessen, um auf diese Weise mit dem Assemblercode vertraut zu werden. Das ist ein himmelweiter Unterschied zu selbst Assembler programmieren. Klar, rein vom Datenblatt (bzw. Befehllsatz-Doku) lesen kann man das so oder so nicht lernen. Ich halte auch für einen Einsteiger eine ,,höhere'' hüstel Programmiersprache durchaus geeignet. Das primitivste avr-libc Demo ist die per PWM auf- und abschwellende LED und beinhaltet nur paar Zeilen C. Der davon generierte Assemblercode ist auch noch überschaubar... OK, ich habe auch ein Kapitel über Assemblerprogrammierung in der avr-libc Doku geschrieben einschließlich eines Beispiels, für den AT90S1200, da der durch C sowieso nicht unterstützt wird. Ist ein simpler Rechteckgenerator (habe ich mal irgendwann gebraucht), da sieht man aber auch schon, daß das Assembler-Einsteigerprojekt noch eine Stufe tiefer ist als das in C... OK, BASIC würde ich wirklich nur für Dinge empfehlen, bei denen es auf die Laufzeit nicht ankommt, allerdings kann ich auch nicht einschätzen, wie gut Bascom wirklich ist. BASIC hatte allerdings schon immer die Gefahr in sich, daß man damit alles andere als gut programmieren lernt. ;-) @Peter: Warum soll er sich unbedingt Borland C kaufen? Den GCC gibt's auch für den PC, dann hat er sogar gleich dieselbe Umgebung, ziemlich dieselben Compiler-Optionen usw., und er kostet für den PC genauso viel oder wenig wie für den AVR. Du wolltest doch sicher niemanden zum Software-Klau überreden, oder? :-) Zustimmung allerdings, daß man die ersten Programmierschritte besser an einem Universalcomputer macht (das schrieb ich oben schon) und nicht an einer MCU. Läßt sich alles viel besser debuggen. Ach ja, debuggen will ohnehin auch noch gelernt sein...
nur vom asm angucken den ein compiler ausgespuckt hat kann man das ganze sicherlich nicht lernen. andererseits ist es wohl wirklich selten, das ein anfänger sich auf asm stürzt. das ist wohl doch ein wenig zu abstrakt. ich persönlich habe mit Turbopascal angefangen, dann delphi programmiert. zwischendurch auch mal ein wenig asm mit dem 8085) also bin ich wohl vorbelastet... ohne viel text meine meinung: den MC wirklich verstehen lernen: asm anwenden und sich mit den sprungbefehlen ärgern :) aber umso höher ist die freude, wenn das ganze dann doch klappt. das wichtige ist die funktionen die der MC bereithält auch wirklich zu erkennen. ohne dem ist die sache mit der problemlösung tot umgefallen. Man muss jedoch schon das "gefühl" zum programmieren bekommen wie man die sache denn jetz angeht. von daher währe soetwas wie turbopascal wohl das richtige. Wo man jetz wirklich richtig aufgehoben ist ist mir selbst schleierhaft. aber solange ich den asm nicht wirklich kann werde ich nicht auf hochsprachen umsteigen. Ich will wirklich wissen, was in dem ding drin steckt. - Wer das nicht will. könnte ja vieleicht doch auf asm verzichten.
Ich bin wie Peter der Meinung, dass man zuerst mal mit Assembler anfangen sollte um ein "Gefühl" für den Prozessor zu bekommen - was sind Register, wie ist das mit Programm- und Datenspeicher, usw. Sicher kann man auch "auf dem trockenen" lernen wie der Controller von innen aussieht, aber ich bin mir sicher dass sich da Einsteiger deutlich schwerer tun, als wenn sie es anhand von praktischen Beispielen lernen können. Und wenn man mal gesehen hat welcher Aufwand für eine "einfache" Multiplikation nötig ist, dann denkt man vielleicht zweimal darüber nach ob man jetzt wirklich float verwenden muss oder doch lieber eine Lösung mit int sucht. Das (leider immer noch nicht fertige) Tutorial auf dieser Seite kann man in ein paar Tagen durcharbeiten, ich glaube danach hat man einen ganz guten Überblick über die Grundlagen und kann problemlos auf C umsteigen.
Hi, ich denke, dass es für der Anfang ausreicht, mit C anzufangen, da ich denke, dass man es am Anfang leichter hat und schneller zu Erfolgserlebnissen kommt. Ich glaube gerade am Anfang ist es wichtig, dass man sich nicht gleich mit den ganzen Feinheiten eines Controllers herumschlagen muss, da dies gerade für Einsteiger schnell langweilig wird. In C hat man schnell mal was zum laufen gebracht und der Compiler kümmert sich ums Abfragen der Carry-Flags und was es da sonst noch so gibt. Zudem hat man am Anfang auch nicht gleich diese hochkomplexen Echtzeitanwendungen, wo man sich wirklich über jeden Befehl Gedanken machen muß. Das man sich den Controller sehr genau ansehen muß, ist natürlich selbstverständlich, aber ob ich nun in C schreibe Register = Wert oder in Assembler das gleiche mit mov erledige ist doch egal. Letztendlich bringt es das gleiche, nur das es am Anfang im C übersichtlicher erscheint. Das Verstehen von Assembler kommt nachher von alleine, da man sich ja sowieso oft die Listings des Compilers ansehen muß (später zumindest). Andere Sprachen (ausser C und Assembler) spechen mich persönlich nicht so an, da sie meines Erachtens nach vorrangig mehr im Hobbybereich eingesetzt werden, wie z.B. Basic. Wenn es dann doch schon etwas professioneller werden soll, würde ich auch auf die Standards zurückgreifen. Viele Grüße, Ralf
@Joerg > Warum soll er sich unbedingt Borland C kaufen? Den GCC gibt's auch > für den PC, dann hat er sogar gleich dieselbe Umgebung, ziemlich > dieselben Compiler-Optionen usw., und er kostet für den PC genauso > viel oder wenig wie für den AVR. > Du wolltest doch sicher niemanden zum Software-Klau überreden, oder? Der Borland C/C++-Compiler ist 'Free'! MfG Andreas Jäger
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.