www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Ab wann C statt ASM ?


Autor: payce (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! :)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ab 2..4kB Codegröße.


Peter

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Kaminky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: unsichtbarer WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: payce (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: unsichtbarer WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ...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...

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.