Erstmal Hallo an Alle! :) Zweitens: ICH WEIß, daß die Frage schon zich mal gestellt wurde (habe mir die Threads dazu hier auch schon angeschaut) und eher in die religiöse Richtung geht als in die logische... Trotzdem: Ab wann sollte ich auf C umsteigen? Geschichte dazu: Ich programiere jetzt schon seit Längerem den AVR auf ASM, da ich in der FH da schon einige Kenntnisse gewonnen habe (auf irgendeinem 8051 Derivat) und mir der Umstieg auf AVR ziemlich leicht fiel. Anfangs funzte das Ganze super, kloar. Die ersten Projekte (CLCD, AD, GLCD, 5x7ner LED Display und sonst watt) liefen da auch wunderbar drauf, nur so langsam wirds übelst komplex. Ich versuche eben eine finite state machine mit Menü aufzubauen und außerdem ein kleines Pong-Spiel auf dem Graphikdisplay zu realisieren (ebenfalls mit Menüführung). Und da fangen die Probs in ASM so langsam an, heftig zu werden. Ich habe jetzt schon öfters gehört, das C in vielen Fällen "einfacher" sein soll, nur habe ich mich mit C bisher nur rudimentär auseinander gesetzt. Der Umstieg fällt mir daher echt übelst schwer, ist ja schon ein (fast) komplett anderer Ansatz, den AVR zu programmieren. Interessieren würde es mich schon, OB das einfacher ist, ich möcht halt nur nicht meine Zeit in etwas investieren, das ich in ASM genauso gut hinbekomme. Daher mal meine kleine Fragen-Sammlung: - Ab welchem Level der Programmierung sollte man auf C umsteigen? (Flash & RAM sollte kein Prob sein, verwende meistens den MEGA32) - Wie bekommt man da den besten Einstieg? (Die bisherigen Tutorials, die ich bisher fand, waren alle vom Einstieg her entweder etwas hart oder völlig wech vom Thema) - Bücher Tutorials Beispielprojekte? So genug Text, DANKE fürs Lesen und DANKE für die Antworten! :)
Speziell bei µC ist der Unterschied zwischen Assembler, C und Basic (um nur die gängisten Sprachen zu nennen) vergleichsweise gering, da früher oder später wieder alles auf Register zurückkommt. Ganz grob würde ich sagen: Assembler für zeitkritische Sachen, ansonsten C(gerade bei umfangreichen Sachen, um nicht den Überblick zu verlieren).
Hi, merkwürdig, ich wollte gestern Nacht eigentlich genau die gleiche Frage stellen, war dann aber zu spät (03:00 Uhr) und somit habe ich es auf heute morgen verschoben... =) Allerdings programmiere ich seit langem auf PICs, bin aber genau so angefressen wie Du über die Probleme, die sich bei C schon bei einfachsten Programmen ergeben. Mit anderen Worten gestaltete sich mein Versuch, bei der Programmierung "mal eben" auf C umzusteigen, als ziemlich schwierig. Es scheint laut Dokumentation etliche Besonderheiten im C18 zu geben, so dass ich fast vermute, dass man zunächst wohl klassischess C lernen muss und wenn man dort ein Crack ist, kann man sich an C18 rantrauen. Ich scheitere z.B. schon daran, eine Tabelle im ROM abzulegen und diese wie ein Array vom RAM aus auszulesen (nicht komplett, sondern nur die Bytes, die ich gerade brauche, also eine einfache LookUp-Tabelle, nichts Kompliziertes an sich). Wenn ich daran denke, dass ich das mit Assembler schon dreimal fertig Programmiert hätte, frage ich mich, ob ich irgendwas falsch mache, zu doof bin oder einfach nur den falschen Controller gewählt habe? (PIC 18F2550) Die Probleme sehen dabei z.B. so aus: Wie definiere ich eine Datenstruktur im EPROM? Wie schaffe ich einen genügend großes Array im RAM (da gibts wohl Segmentierung, ab 256 Bytes fangen die Probleme an), um die Bytes vom EEPROM in das RAM zu transferieren? Wie kann ich die Hürde überwinden, dass EEPROM und RAM vom C-Compiler getrennt behandelt werden und man nicht einfach mit einem EEPROM- Pointer vom RAM aus arbeiten kann? Und so weiter und so fort... Wie ist das bei Atmels? Ist es da einfacher, den Umstieg von Assembler auf C zu vollziehen oder ist das mehr ein allgemeines Problem, weil C im Gegensatz zu Assembler gerade zu Beginn mit vielen Spezialfällen im Bereich Befehlssyntax, Variablen und Pointern aufwartet, die die Sprache einerseits sehr mächtig machen, aber andererseits Anfänger schon beim schreiben einfachster Programme in den Wahnsinn treiben, weil man erst mal alle möglichen Befehle, Schreibweisen und Bibliotheken studieren müsste, um einen groben Überblick zu bekommen, was man mit welcher Funktion erledigen kann und welches genaue Format die Befehler oder im Falle von Bibliotheks-Funktionen die übergebenden Funktions-Parameter haben müssen? Ich suche daher auch Lesestoff, wie ich mich möglichst gut auf den Umstieg auf C18 vorbereiten kann. Gerne auch für Atmel, damit ich Dir hier nicht den Topic stehle. So wie ich jetzt vorgehe (immer aus irgendwelchen Foren die fragmentarischen Lösungen anderer studieren, die ähnliche Probleme wie ich hatten, aber sobald man auch nur eine Codezeile ändert spuckt der Compiler wieder hundert Fehlermeldungen aus) sehe ich kein Land, in der Hilfe von C18 stehen auch nur die wichtigsten Unterschiede zu C, aber keine allgemeine Erklärung, welche Befehle wie aufgebaut sind und wo die Fallen lauern (gerade bei den Datentypen habe ich das Gefühl, nichts zu kapieren, obwohl ich im Grunde genommen sehr genau weiß, was INT, UNSIGNED, CHAR und ähnliches bedeutet und wie Pointer vom Aufbau her funktionieren. LG, Kaminsky
Die Diskussion hats in der Tat schon öfter gegeben. Auch Peters Aussage 2K-4K war da schon öfter zu hören. Finde es selbst raus, Ich habe schon häufig ASM Programme jenseits der genannten Grenze geschrieben und verliere nicht den Überblick. C kann übersichtlicher sein, muß es aber nicht. Häufig ist der Kopierschutz im Quellcode enthalten ;-)) Ich kann daher deine Startschwierigkeiten nachvollziehen. Zum Anfang solltest du deine ASM Sourcen die du gut verstehst in C umschreiben, gute Übung. Mach dich mit den Library Funktionen deines C Compilers vertraut. Grundlagen Buch hinzunehmen und dann learning by doing.
Ein grundsätzliches Problem an der Hochsprachenprogrammierung von Mikrocontrollern ist die Tatsache, dass es Compiler von unterschiedlichen Herstellern gibt, die gewisse µC-spezifische Angelegenheiten, die nunmal nicht im ANSI-Standard festgelegt sind, völlig unterschiedlich implementieren (z.B. die oben angesprochenen speicherspezifischen Zugriffe, Arrays im EEPROM oder Flash, die von unterschiedlichen Compilern mit unterschiedlichen Schlüsselwörtern bzw. Bibliotheksfunktionen bearbeitet werden). Der Umstieg von Assembler auf eine noch recht hardwarenahe Hochsprache (C) ist für die meisten Anwender nicht so schwer wie der Umstieg in die andere Richtung. C besitzt nunmal (v.a. gegenüber "hardwareferneren" Sprachen wie Basic) den Vorteil, einerseits eine strukturierte Programmierung zu ermöglichen und dabei die Hardware nicht aus den Augen zu verlieren. Hat man Assembler-Erfahrung, dann kennt man die Hardware und kann eventuell auftretende Probleme an ihrer Basis beheben. Das Initialisieren von Peripheriekomponenten ist z.B. in C nicht so verschieden von Assembler, nur dass man sich in C keine Gedanken über Dinge wie Registerzugriff im extended I/O-Space, Speicherallozierung usw. machen muss, da diese Sachen vom Compiler hingebogen werden, vorausgesetzt, man hat die richtige Device-Headerdatei eingebunden. C-Programme sind aufgrund der Blockstruktur und dem Verzicht auf Sprungbefehle (OK, es gibt zwar einen goto-Befehl, der aber in den meisten Fällen vermieden werden kann und sollte) bei ausreichender Kommentierung wesentlich leichter nachvollziehbar als Assembler-Listings. Es gibt (wie oben schon angesprochen) einige Programmierer, die auch bei größeren und komplexeren Projekten Assembler verwenden, das ist jedoch Einstellungssache und hängt auch davon ab, ob man wirklich zeitkritische Anwendungen programmiert, bei denen man jeden einzelnen Schritt, den der Controller macht, nachvollziehen können muss. Bei der Programmierung in C sollte man sich zunächst die Basics der Sprache (Syntax, Variablen, Strukturen, Operatoren...) aneignen (anhand eines Buches, wobei es im Prinzip kein Problem ist, zunächst mit einem Buch anzufangen, das sich auf ANSI-C für die PC-Programmierung bezieht [z.B. der vielzitierte und durchaus empfehlenswerte Kernighan & Ritchie von den C-Erfindern], da jeder C-Compiler im Prinzip ANSI-C versteht und i.d.R. lediglich bei den µC-spezifischen Dingen vom ANSI-Standard abweicht bzw. Zusatzfunktionen anbietet). Joe hat natürlich auch recht. Auch ein C-Programm ist nicht selbsterklärend und kann beliebig chaotisch und unleserlich sein, wenn auf Kommentierung, "sprechende" Bezeichner für Variablen und Funktionen, Tabstopps usw. verzichtet wird. Alles in Allem eine Frage der "Philosophie" und Einstellung. Ich selber habe meine ersten µC-Gehversuche mit Assembler gemacht und bin vergleichsweise problemlos auf C umgestiegen. Andere haben da vielleicht mehr Schwierigkeiten, allerdings sind Assembler-Kenntnisse nach meiner Erfahrung eine erhebliche Erleichterung beim Einstieg in C. Gruß Johnny
C zu lernen lohnt sich alleine schon aus dem Grunde es eben auch benutzen zu können. Kannst du nur ASM bist du also viel zu unflexibel und wirst niemals in der Lage sein das richtige Werkzeug für eine Problemstellung auswählen zu können. Man kann alles auch nur in ASM machen allerdings ist das eben sehr oft eine sehr machoschistische Wahl, sprich Selbstquälerei. Kannst du C so werden gerade "ich teste mal eben" Projekte viel effizienter. Das Wissen und Können das du mit C arbeiten kannst transportierst du dann später ohne Probleme von Plattform zu Plattform von MCU zu PCs usw. Bei Assembler musst du in gewisser Weise bei einem Plattformwechsel immer wieder von vorne anfangen. Das mag auf MCUs ja eh immer der Fall sein, auf komplexeren Systeme relativiert sich dies aber enorm da dort dann auch C Bibliotheken zum Ansprechen der Hardware vorliegen. Beispiel: Umstieg von AVR auf PICs. Hier musst du egal ob ASM oder C sowieso die Datenblätter der MCUs genau studieren und wirst im Grunde immer sehr Hardwarenah programmieren. Umstieg von PCs auf zb. Handheld Computer. Hier musst die bei ASM wiederum alles ganz genau studieren und wirst auf sehr komplexe und sehr untzerschiedliche Plattformen stoßen. In C benutzt du einfach die vorhandenen Bibliotheken, sprich Betriebssystem funktionen, und kannst dich von vornherein auf das Wesentliche deiner Problemstellung konzentrieren. Ergo: C zu lernen, bzw. sogar gleich 2-3 Hochsprachen lohnt sich in jedem Fall, mal ganz unabhängig von der Plattform betrachtet. Ich benutze zb. ASM + C auf dem AVR. C + Delphi/Kylix + TASM bei der Entwicklung auf PC unter Windows/Linux und C + PASCAL auf Palm Handhelds. Neuerdings noch C# auf .NET Plattformen -> PC und PocketPC. Gruß Hagen
Hallo, Das primäre Kriterium für mich ist die Echtzeitanforderung. Wenn etaws im Sekundenbereich bis millisekundenbereich echtzeitfähig sein muß, dann stellt sich die Frage, warum man sich mit Assembler herumplagen soll. Wenn es aber auf die Mikrosekunden ankommt - dann habe ich lieber alles selbst im Griff als ständig den Compiler zu kontrollieren, ob er brauchbaren Code erzeugt. Ich würde es also eher an den Zeitanforderungen, als an der Größe festmachen. Gruß Wolfgang BDK - Brushless-Development-Kit www.ibweinmann.de
Und dieses Argument halte ich eben mit Blick auf C für irrelevant. Man kann nämlich auch in C seinen zeitkritischen Code, sogar ISRs, in Assembler programmieren. Das hat gleich 3 Vorteile 1.) nur das Wichtigste ist in Assembler zu machen 2.) man lernt auch gleich die "Eigenheiten/Unzulässigkeiten" des C Compilers kennen. Durch Menschen handmade Assembler ist immer noch weitaus besser optimiert als das ein C Compiler kann. Mene Nokia GLCD zeigte dies sehr deutlich (C Bibliothek die aber in ASM codiert wurde, statt 6Kb C Code nur noch 3Kb groß und zusätzlich noch effizientr) 3.) die High-Level Preogrammierung ist dann nur noch in C und somit weitaus besser wartbar, und die LowLevel Geschichten sind austauschbare Bibliotheken. Entscheidend ist aber doch nur das man wenn man verschiedene Sprachen beherrscht selber entscheiden kann mit welchem Werkzeug man die Problemstellung am effizientesten lösen kann. Man muß also nicht mehr jedesmal in einem Forum nachfragen sondern hat selber das Wissen und Können diese Entscheidung nach den eigenen Bedürfnissen einschätzen zu können. Die Frage ist also nicht "was soll ich lernen" sondern ganz einfach "fang einfach an zu lernen". Je mehr Sprachen man kann desto besser und je mehr man kann umso leichter wird es eine weitere Sprache zu lernen. Man sollte eben nicht ständig fragen "was soll ich erlernen" sondern einfach mal anfangen zu lernen. Die Antworten auf diese Frage sind eh immer subjektiv bezogen auf den Antwortenden. Meiner Meinung nach ist die Kombination aus ASM + C eine sehr gute für den Einstieg, sowohl im Hinblick auf das was man erlernt für die Zukunft und auch in der Frage des Preises für diese Tools. Das geht von 0 Euro aufwärts. Im Falle von PASCAL oder BASIC bekommt man keinen so günstigen Einstieg, auch wenn ich PASCAL eventl. C vorziehen würde. Gruß Hagen
Manche Post klingen, als würde man sofort in dem Moment, wo man ein C-Buch in die Hand nimmt sämtliches Wissen über Assembler vergessen. Obwohl ich PICs meide, könnte ich vermutlich trotzdem noch eine entsprechende Asm-Datei lesen und deuten. Was spricht denn dagegen, sich neben Assembler auch noch mit C auseinander zu setzen. Da finde ich es immer sehr praktisch, dass Atmel in den Datenblättern Asm- und C-Beispiele mit der gleichen Wirkungsweise veröffentlicht. Wenn man sowieso schon die Asm-Kenntnisse hat, sollte es relativ einfach sein, sich C anzueignen - da heisst es eigentlich nur "Vokabeln" und "Grammatik" lernen. Eine bestimmte Grenze kann ich übrigens nicht sagen, da ich nur zu Debugging-Zwecken mir Assembler antue... Ich finde C-Programmieren schön, weil ich mich da nicht um Sachen wie den Stack, Push und Pop und son Zeug kümmern muß. (Mich interessiert bspw. einfach nicht, wo eine Variable gespeichert wird [Register oder SRAM?]) Bis jetzt waren meine Anwendungen noch nicht so aufwändig, dass ich darauf achten musste. Man sollte die Funktionsweise des Controllers (wie die Variablen-Handhabung) im Hinterkopf behalten.
eben, ganz meine Meinung. Die Frage nach dem WAS und WIE lernen macht das "Problem" nur noch komplizierter und lösst garnichts. Man muß einfach mal anfangen und im WEB/Datenblätter gibts genügend Hilfe dazu. Gruß Hagen
Sobald man Fließkomma-Arithmetik braucht, würde ich auf C setzen. Wenn es kompakter und optimierter Code sein muss, ist Assembler oft besser. Wenn du z.B. einen Tiny mit einem 2K Programm füllst, wo du schon in Assembler jeden Befehl dreimal überprüfst, weil dir der Platz fehlt. Es gibt Problemlösungen, da fummelt man sehr viel an wenig Code rum, um den zu optimieren. Da kommt man oft gut in Assembler klar. Dann gibt es Anwendungsgebiete, da muss man viel Code schreiben, der an sich nicht sonderlich anspruchsvoll ist. Da ist man oft viel schneller in C. Ein menübasiertes Userinterface zu schreiben, fällt z.B. unter sowas. Ich habe in beidem gearbeitet - erst in Assembler, dann jahrelang in C und im Moment wieder in Assembler. Als ich mit C begann, spürte ich oft eine totale Begeisterung: "Wow, das geht ja hier total einfach, da hätte ich mir voll einen abgebrochen in Assembler." Da wollte ich nie wieder ohne meinen C-Compiler leben. Wenn man genug Ressourcen hat, wäre C immer meine erste Wahl. Im Moment programmiere ich aber wieder mal Tiny's, die sehr effizient programmierten Code brauchen, wo es auf jedes Byte ankommt. Da bin ich wieder bei Assembler gelandet. Wenn man auch nach 10 Jahren noch seinen Code verstehen will, ist man mit C oft im Vorteil. Assemblerprogramme zu begreifen, das ist oft grauenvoll und anstrengend.
Habe auch mal auf dem 8051 mit Assembler angefangen. Beim Umstieg auf die aktuellen Micros habe ich dann auch gleich den Umstieg auf C gemacht, weil ich keine Lust hatte, die ganzen Opcodes etc. zu lernen. War dann einfacher C zu lernen. Heute schreibe ich alles in C, wobei ich bei kritischen Sachen schon mal im Assemblercode nachschaue, was der gemacht hat. Dann passe ich den C-Code entsprechend an. Mag sein, dass ich damit die eine oder andere Optimierung nicht optimal bekommen, aber ich finde, das ist wesentlich besser lesbar und vor allem portierbarer. Und das gilt auch (oder gerade) beim Wechsel innerhalb der Familie also z. B. ATTINY auf MEGA8. Gruss Axel
HAIAIAIAIAIAIAI!!! BOAH, die Antworten kommen hier immer fix wie nix. Na dann erstmal dickes DANKE an alle "Antworter". Ich werde dann schon definitiv mit C anfangen, eins der Argumente dafür ist das von WM-Rahul. Man vergissts ja nich. ;) Wusste nur nicht, das man ASM so einfach implementieren kann, muss ich noch mal gucken, wie das geht. Das Inline-ASM fand ich jetzt nicht sooo super, wenn das anders auch geht, umso besser. ABER: Die (religiöse - Ihr könnt sagen, was Ihr wollt, es bleibt dabei ;) ) Diskussion wird hier schon relativ philosophisch, könnt Ihr mir mal pragmatischerweise einfach ein paar Tips geben, wo & wie man den Ein-/Umstieg am Besten hin bekommt? Tutorials Bücher Projekte - WO? WAS? ... und überhaupt (am besten mit ASM in C integriert - wäre supi, muss ich nicht meine LCD-Routinen erneut schreiben) Also trotzdem noch mal: DANKÖ! Supi community, besser als jeder Mikrocompkurs! :D
Hier auf der Seite gibt es das AVR-gcc-Tutorium (links bei den Links;-). Als C-Buch kann ich eigentlich nur den K&R empfehlen. Ein "Von ASM nach C in 21Tagen" wirst du kaum finden... Und dann solltest du dir vielleicht wirklich die Atmel-Beispiele in Datenblättern angucken. Von der Integration von ASM in C hab ich keine Ahnung.
Nutzt du die kostenlose Toolchain des GCC -> WinAVR GCC genannt und Atmel-AVR-Studio so kannst du - C programmieren lernen - findest viele Beispiele zu eigentlich allen Themen wie Timer, SPI, I2C, UART und ADC - hast eine ausreichend gute Bibliothek inklusive - wirst ein relativ standard konformes C erlernen - bezahlst 0 Euro - hast allerdings am Anfang mit der Installation/Makefiles/Make Scripts zu kämpfen - musst dir einen Editor besorgen da WinAVR GCC nur Komandotools sind (ich nutze den Editor "ConTEXT" der Makros/Syntaxhighlighting/Consolenausgabe unterstützt und auf Windows läuft) - kannst kompatible ELF Dateien erzeugen die dann samt C Source im AVR Studio per JTAG-ICE online debuggung ermöglicht - ASM per inline benutzen - ASM als externe *.S Dateien benutzen (was ich in jedem Falle bevorzuge, da die Syntax fast identisch zu normalem ASM ist, sogar besser da der Preprozessor funktioniert) und am wichtigsten, du erfüllst noch einen guten Zweck weil du die freie Arbeit der Entwickler vom WinAVR GCC damit indirekt unterstützt ;) Gruß Hagen
> ...musst dir einen Editor besorgen... Nicht unbedingt. Wenn er schon AVRs in Assembler benutzt hat, hat er wahrscheinlich eh das AVRStudio, in das sich der WINAVR-Compiler nahtlos einfügt. AVRStudio erstellt auch automatisch die benötigten Makefiles. Ich persönlich habe bisher mit AVRStudio && WINAVR keine Probleme gehabt...
ups, das wusste ich noch nicht. Allerdings hat mir der Editor im AVR Studio noch nie so recht gefallen. Man sollte einfach mal ConTEXT im WEB downloaden, seine Tastenbelegungen einrichten, und dann testen. ConTEXT besitzt halt schon für fast alle Programmiersprachen ein Syntaxhighlighting und man kann das auch noch selber anpassen. Da ich sowas aus professionellen IDEs wie der von Delphi gewohnt bin möchte ich darauf auch nicht mehr verzichten. Gut, AVR Stuido kann das aber auch. Gruß Hagen
> muss ich nicht meine LCD-Routinen erneut schreiben)
Genau hier setzt meine Empfehlung an, übersetze mal dein LCD Programm in
C. So kannst du am besten lernen wie es geht, es sind die gleichen
Gedanken wie beim ASM Programm gefragt und zu beantworten.
Dann kannst du deinen ersten Vergleich durchführen.
Verwende bei dieser Übung keinen fremden Code, mach dir selber die Mühe.
Wenns hängt, dann fragen.
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.