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.
