mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welche Programmiersprache ?


Autor: Werner Bilkenbrihl aka Bilko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi erfahrene Programmierer,

ich würde gerne wissen, welche Programmiersprache für Mikrocontroller 
ihr am ehesten gelernt hättet, wenn ihr euch nochmal entscheiden könntet 
? Wie ist es euch ergangen ?

Einsatzgebiet für mich wären verschiedenste eingebettete Systeme im 
eigenen zu Hause. Vielleicht am Anfang was mit einfachen Befehlen 
erreichen können, aber später auch ausbaufähig. Welche hat denn die 
besten Zukunftsaussichten ?

Aber wie gesagt - ich habe noch nicht so viel Ahnung und möchte nicht 
erst eine Sprache lernen, nur um festzustellen, dass das nix ist. Ich 
stehe nämlich vor der Entscheidung und jede Programmier-Website 
favorisiert natürlich ihre eigene Sprache. Also die Einführung auf 
dieser Website habe ich natürlich schon gelesen, gelle ;)

Danke !
Bilko

Autor: Helge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Werner

Ich stand damals vor dem selben Problem.Hatte davor viel mit dem 
CControl gebastelt.Aber Basic war extrem langsam.Wollte ein 
Grafikdisplay mit bewegte Bilder zum laufen bringen.Man konnte jeden 
einzelnen Pixel beobachten wie er sich aufbaute.
Hab dann zum Atmel gewechselt und mit Assembler angefangen.Ging auch 
ganz gut. Bin aber jetzt bei C gelandet und muß sagen,daß es sich recht 
gut lernt.
Also ich würde dir C empfehlen.
Gruß Helge

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C C C C C

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber ASM ist wichtig für das Basiswissen über die Controller

Autor: Werner Bilkenbrihl aka Bilko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke schonmal !

Kann man denn Grundkenntnisse aus Assembler auch bei C verwenden oder 
gibt es wieder gemeine kleine Unterschiede (zB gleichlautender Befehl, 
aber verschiedene Auswirkungen) ?

Gibts irgendwo weitere Internetquellen, die ihr empfehlen könntet zum 
Einstieg ?

Bilko

Autor: Eckhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also ich würde sagen asm oder C. Bei einem Microcontroller mußt DuDich 
sowieso mit den Hardwareinternas auseinandersetzen. Wenn Du die kennst 
ist das in asm auch nicht mehr so ein Problem. Die meiste zeit bist Du 
eh damit beschäftigt irendwelche MCU internas zu bedienen und das ist in 
Assembler nicht wirklch komplizierter als in C. Es gibt natürlich manche 
sachen, für die sich die Hochsprache lohnt. Portabel wird der ganze kram 
aber eh nicht, weil man sich immer mit den speziellen Eigenschaften des 
Controllers bzw der Controllerfamilie herumschlagen muß.


Eckhard

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dafür kann man ja die Spezialitäten kapseln, damit nur diese Angepasst 
werden müssen.

@ Werner
ASM ist in sofern wichtig, das Du das Bitgemarmel aus dem FF beherrscht. 
All die Oder/UND/XOR-Verknüfungen oder Speichermanipulationen sind in 
Beiden wunderbar möglich.

Die bereits erwähnte Motorsteuerung z.B. ist komplett in C 
geschrieben(mehrere Tausend Zeilen Source 63% Belegung). Seit ich mit 
den Atmels angefangen habe, das war im Herbst letzten Jahres, hatte ich 
mir noch nicht einmal die Mühe gemacht irgend eine Codezeile in ASM zu 
schreiben. Aber zu wissen wie's geht hilft auch in C.

Reiner

Autor: thomas b (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Werner,

ich sage wiedermal BASCOM.
Einfaches BASIC, wenn Du bei einen Befehl nicht weiterkommst hilft F1 
mit passender Erklärung und Quelltextbeispielen. Der integrierte 
Emulator ist ebenfalls nur schwer zu toppen.
Bei Bedarf kann mann auch einfach ASM zwischen seine BASICZeilen werfen.
Für den Umstieg von BASIC auf ASM würde ich dann FastAVR empfehlen, das 
produziert aus Deinem Basic sehr gut lesbaren und kommentierten ASM 
Quelltext.

Gegenargumente zu BASCOM wie zu langsam oder zu langer Code sind 
Ansichtsache. Ich hab mal Bascom mit 8535 voll ausgereizt (Basic > 8kB 
ASM). FastAVR machte daraus knapp 9kB (lief also nicht) und eine 
komplette Umsetzung in ASM von Hand war immernoch etwas über 6kB. So 
gross ist der Unterschied nicht.

cu tb

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du am Rest der Welt teilhaben willst, vergiß BASIC.
Reiner

Autor: BernhardT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Basic ist gut für den schnellen Einstieg. Wenn man da mit ernst heran 
geht, sich auch mal den Hex.code anguckt etc. kann man einiges lernen 
und machen. Wenn du aber bereit bist erst mal den etwas unbequemeren Weg 
zu gehen und gleich mit C anfängst machst du dir unter dem Strich das 
leben leichter. Du wirst etwas länger brauchen für die ersten 
Erfolgserlebnisse. Dann hast du aber ein mächtiges Werkzeug an der Hand. 
Die alten Dos Rechner hatten selbstverständlich Basic on board. Ich hab 
daher mit Basic angefangen . C und Pascal wurde erst später bezahlbar. 
Wenn ich heute noch mal anfangen würde (hab ich ja eigentlich auch 
letztes Jahr) dann mit C besonders für uC's. Heute ärgere ich mich , das 
ich für die  PIC's nicht auch schon mit  C programmiert habe, statt mit 
ASM.
Gruß Bernhard

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man in den Bereich der grösseren Controller kommt (16-32Bit) und 
komplexere Anwendungen hat (Implementation von kompletten Protokollen 
z.B.), dann wird C++ sehr interessant und ist im Endeffekt auch am 
sinnvollsten, da z.B. Erweiterungen viel leichter sind.

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BASIC ist prima, wenn man sich den Programmierstil versauen will. 
Solange man ASM programmiert merkt man die Schwächen von BASIC nicht, 
wechselst Du aber zu einer Hochsprache kriegst Du einen Knoten im Hirn.

Klar C ist hammerhart zu lernen, irgend jemand sagte mal der C-Code 
sieht aus als wenn sich ein Gürteltier über die Tastatur gewälzt hat - 
und irgendwie hatte der Mensch recht.

Ich bin froh viele Jahre mit Assembler meine Erfahrungen gemacht zu 
haben (was für'n deutsch), aber dumm von mir nicht schon viel früher mit 
C zu starten.


Reiner

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C sieht nur zu Anfang chaotisch aus.

Die Entwickler waren eben nur etwas schreibfaul. Aber die 
Klammerschreibweise {} ist schon wahnsinnig effektiv.
Und mit Einrückung auch gut lesbar.

Ist alles nur eine Gewöhnungssache.


Ich empfehle zum C Lernen ein altes Borland-C in der DOS-Box mit 
deutscher Hilfe.


Basic ist nur das Spielen mit lauter Blackboxes, d.h. man versteht 
nicht, was dahinter vorgeht.


Ich habe auch 10 Jahre lang nur Assembler gemacht. Aber nachdem ich ein 
C-Projekt eines ehemaligen Kollegen fortführen mußte, mache ich zu 99.9% 
alles in C.



Peter

Autor: Oryx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Etwas anderes als C bleibt ja kaum

Kleine Fragestunde

1. Auf wievielen Controllerfamilien läuft Basic?
- Mhh AVR und dann wirds dünne

2. Auf welchen Controllern läuft kein C?
- Ausser den ganz kleinen ohne Ram auf allen, da die Controller sonst 
kaum zu verkaufen wären

3. Wie ist es mit Büchern?
- Im Buchladen gibt es die "Internetsprachen" und
Delphi, Visual Basic und C,C++
und dann wird es schon wieder dünne

Für alles anderen Sprachen wie Pascal, Eifel, Smaltalk, Ada, Fortran, 
Cobol usw. gilt das gleiche wie für Basic. Der Compilerhersteller deckt 
immer nur eine Controllerfamilie ab.

Assembler stellt eine Ausnahme dar. Für das Verständnis der Maschine ist 
es sehr hilfreich, wenn man sich den Assemblercode, den der Compiler 
erzeugt hat, immer wieder einmal ansieht. Und natürlich auch versucht zu 
verstehen.

Dann noch eine Antwort zur Zukunftssicherheit. Das sagt mir meine 
Glaskugel, das sich eine Programiersprache, die von div. Herstellern 
halbwegs Standartkonform unterstützt wird, noch eine Weile am Markt 
halten sollte.

Lange Rede wenig Sinn: Es bleibt nur C und wenn es Dir dann mal zu 
langweilig werden sollte, nimmst Du einfach C++. Hat nur ein ganz paar 
Befehle mehr, aber wahnsinnige Möglichkeiten in der 
Programmorganisation.

Zum Start ist der von Peter vorgeschlagene Weg der DOS-Box sinnvoll, da 
Du dich nicht mit ganz so vielen Hardwaretücken rumschlagen mußt.
Bevor Du auf einen Controller losgehst, sollten die Grundlagen schon 
einigemassen sitzen.


Und noch eine Anwort zu Eckhard:
Der Code ist sehr wohl portabel, das Programm braucht nur eine 
Anwendungs- und eine Hardwareschicht. Damit ist es sehr leicht auf 
andere Controller zu portieren. In Assembler geht bei einer anderen 
Controllerfamilie garnichts. Basic gibt es da wahrscheinlich garnicht.

Grüsse Oryx,
der nun C++ macht und die Leidensgeschichte der Vorschreiber aus eigener 
Erfahrung kennt.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Ich würde zum C-lernen keinen Borland-Compiler nehmen sondern gleich 
irgendeinen gcc+make. Ist zwar doppelt schlimm zu C auch gleich noch den 
gcc und vor allem make zu lernen aber auf die Dauer kommt man eh nicht 
an GNU-tools vorbei.

Matthias

Autor: Oryx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mathias,
auf die Dauer gebe ich Dir recht, aber gleich mit gcc+make und dann auch 
wohl noch mit einem Linkerscript auszufangen, das haut einen Anfänger 
doch aus den Socken.
Ich hatte schon Praxissemesterstudenten, die völlig schwindelig wurden, 
weil sie die Probleme garnicht einkreisen konnten.

Oryx

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch ich bin der Meinung ein altes Borland C auf DOS bringt den 
Lerneffekt.
Zum Jahreswechsel hatte ich einen Praktikanten im Labor. Dem hatte ich 
die Grundbegriffe genau damit vermittelt, als er das dann einigermaßen 
verstanden hatte sind wir auf avrgcc übergegangen.
Mit dem Borland läßt sich sehr einfach Lernen, da man ja einen ganzen 
Bildschirm für Kontrollausgaben zur Verfügung hat.

Und was da portieren betrifft: Letztes Jahr hatte ich den M16C am 
Wickel. Da ich immer irgend welche Verzögerungen brauche (in Borland C 
delay(wert in ms); ) programmierte ich mir die auf dem Controller. Dazu 
kam noch eine Frequenzausgabe (in Borland C sound(frequenz); ). Nun 
hatte ich vor vielen Jahren, als ich mit C das erste mal anfing mir ein 
paar Sounds kreiert. Solche kennt man noch aus den alten DOS-Games. Nun 
ja, ich brauche nur diese uralten Routinen ohne eine Änderung einbinden 
und es klang exakt wie auf dem PC. Aus Faulheit mich umzugewöhnen hatte 
ich für delay() und sound() die gleichen Namen wie Borland benutzt...und 
schon lief es.


Reiner

Autor: Holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
zum Thema Programmiersprache muß ich nach dem Lesen der Kommentare auch 
etwas loswerden.
Also programmieren kann jeder.
Der Eine macht es professionell und der Andere eben nicht.
Und das ist genau der Unterschied.
Egal mit welcher Sprache Du beginnst; Du wirst nach einiger Zeit "Lust" 
auf andere Sprachen bekommen und merken, daß die Unterschiede nicht 
gross sind.

Du entwickelst Dich - denk dran!

Holger

Autor: A. Arndt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich nutze FASTavr, der macht einen wesentlich kleineren Source-Code als 
BASCOM, bin auch noch nie mit etwas grösseren Programmen unter 65% 
Source gekommen, es sind viele Assistenten schon mit drin und einfach 
anzuwenden (I2C, RC-5,Dallas 1-Wire LCDs uvm.) Wenns auf Geschwindigkeit 
ankommt, kann ich keine Aussagen treffen. Als C-Controller ein leichter 
Umstieg, ich bin sehr zufrieden. Wenn ich einen Text auf einem Display 
an bestimmter Stelle anzeigen möchte mache ich das mit 3 Programmzeilen 
und I2C-Schreiben auch mit nur 3 Zeilen, fertig.

Gruss
Alex
www.AR-Online.de

Autor: Reiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Professionell, ja ein wenig schon. Aber da wären all die Cer nicht 
hingekommen, wenn die sich gesagt hätten: "Basic ist okay, das versteh 
ich, es reicht mir" -> Sackgasse
Reiner

Autor: task (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Zusammen,

mit dem freien LCC32 kann man super das programmieren für den m16c
lernen. Ich entwickle seit 1998 firmware auf dem m16c und teste meine
software teilweise mit dem LCC32 aus.

Vorteil:  Der C-Code mit dem Tasking Compiler (v2.3) erstellt läuft
          problemlos bzw. ohne zu portieren auf dem LCC32.


          Der LCC32 besteht aus einer completten Entwicklungsumgebung
          und ist streng ANSI C conform.

          Einfach C-Programm vom m16c laden zum debuggen einiges
          printf-mässig umleiten und fertig.

cu.

Autor: harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nu gibts hier einen haufen lobgesang über c und asm, okay.
aber wo um gottes willen liegt denn nun das problem mit
basic-dialekten?
sie haben doch folgende vorteile:

1. der code ist enorm übersichtlich und fast schon 'selbsterklärend'
2. wenn's um tempo geht, hat jemand einen direkten vergleich zu c oder
asm? bedenkt, dass heutzutage basic-code kompiliert wird, also
maschinencode erzeugt wird. damals lief basic ausschliesslich unter
interpretern, die waren natürlich grottenlahm.
3. definitionen für display's und rs232 oder oder... sind eben
bestechend einfach.
4. zugriffe auf register sind auch in basic möglich, der compiler
'blickt' auch anweisungen wie 'ocr1 = 255' und setzt sie direkt um,
ohne eine latte umständlichen code zu generieren.

fazit: wer in basic anfängt liegt nicht falsch. mit der zeit kommt dann
der feinkram und die interna von avr's fast zwangsläufig dazu.

gruss, harry

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Harry,

ich möchte jetzt mit AVR anfangen, aber für die Zukunft liebäugele ich
auch etwas mit den ARMs von Philips, die haben einfach massig mehr
Ressourcen. Kannst Du mir einen Basic-Compiler empfehlen, mit dem ich
später auf den ARM aufrüsten kann, oder muss ich dann wieder komplett
neu anfangen?

Stefan

Autor: harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
keinen plan von ARM's, ich mach alles mit avr's, hab noch nie die
mega32-grenze geknackt. z.b. für 'ne steuerung mega16 im einsatz, ca.
1700 zeilen code (ist schon richtig viel für basic) klappt aber
hevorragend. die steuerung hat allen zirkus mit display, menue's,
sensorik und weiss der geier was noch alles, was habel denn die arm's
für vorteile???

Autor: harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ooohps, bascom für's tägliche, fastavr wenn du 'ne perfekt
kommentierte übersetzung nach asm benötigst.
in beide kannste asm-code mit reinpacken.

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Harry,

sorry, die Frage war vielleicht etwas unfair. Ich wollte Dir eigendlich
zeigen, wo (für mich) das eigendliche Problem an Basic liegt: es gibt
es für fast keine Microcontroller, AVR ist die grosse Ausnahme. Ob
jetzt einer C oder Basic programmiert, ist wohl relativ schnuppe, in
beiden Sprachen kann man gut oder schlecht programmieren. Wenn man aber
fürs nächste Projekt die Sprache wechseln muss, dann ist das schon
recht ärgerlich. Und Microcontroller wechselt man öfters als die
PC-Architektur, glaub mir!

Die ARMs haben (für mich) den grossen Vorteil, dass sie massig RAM und
Flash und alle nötige Peripherie in einem winzigen Gehäuse (48pin)
vereinigen. Natürlich nur dann interessant, wenn man es auch wirklich
braucht ;-)

Stefan

Autor: Wolf-Ruediger Juergens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als ich vor fast 20 Jahren mit Mikrokontrollern angefangen habe war das
nur mit Assembler, C gabs defakto noch nicht. Dann kamen die ersten
Basicinterpreter und machten vieles leichter. Kennt jemand noch das 12k
große RDK Basic? Wurde damals auf dem berühmten Rolf-Dieter Klein
NDR-Kleincomputer eingesetzt und es war für 90% der Aufgaben
aussreichend schnell. Die wirklich zeitkritischen Sachen wurden dann in
Assembler gemacht. Später als die Aufgaben immer größer wurden bin ich
zu C gekommen (C51 Keil). Die Einarbeitung war nicht ohne, vor allem
das Banking raubt einem schon mal die Nerven ;-)
Heute würde ich jedem raten C zu erlernen und zu benutzen, der
unbezahlbare Vorteil ist der dass man das Gelernte und den Code auf
fast jedem Prozessor wieder einsetzen kann. Natürlich muß man immer ein
Auge auf den Assemblercode haben, kein Compiler ist perfekt und wenn
nicht versteht was der Compiler da erzeugt hat ist man im Ernstfall
schnell aufgeschmissen.

Wolf

Autor: Matthias Friedrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke auch dass es sinnvoll ist Assembler zu können, aber nicht
zwingend notwendig. Die aktuellen Compiler erzeugen so guten Code, ich
möchte behaupten, dass es aber einer bestimmten Codegröße nicht mehr
möglich ist, effizienteren Code in vertretbarer Zeit per Hand in ASM zu
schreiben.
C ist mit Sicherheit die erste Wahl. Ich arbeite in einer Firma an
einer Software zur Regelung von Kälteanlagen. Der Code besteht aus fast
100K Zeilen C-Code und läuft auf AVR, 8051, ARM und Win32. Das ist nur
mit C möglich.
Die heutigen Controller werden immer leistungsfähiger und besitzen mehr
Speicher. Deswegen ist die Portierbarkeit und Wartbarkeit des Codes
vorrangig der Möglichkeit ein paar Bytes oder µS zu sparen, ganz
abgesehen davon, dass das kein Kunde bezahlt.
Basic und sonstige Dialekte haben keine Zukunft. Es wird sie zwar immer
geben, aber als Randerscheinungen ohne breite Unterstützung.
Also: Lerne gleich eine brauchbare Programmierspache, nämlich C.

Autor: maxigs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
auch wenn mich jetzt alle schlagen fang mit php an ;-)

damit kann zwar kein controller was anfangen, aber zum lernen der aller
ersten codezeilen ist es veradammt einfach.
und der umstieg auf c ist auch kein problem, weil dort fast alles
genauso geht (zumindest das grundlegende). ok pointer kommen dann noch
aber dann ist schon mal ein großer teil geschaft.
c++ ruft ;-)

Autor: A. Arndt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die beste Programmiersprache wird es wohl nie geben, jedem das seine.
Ich finde FASTAVR (Basic) klasse und mir reichts und ich habe auch
keinen Bock mich mit trockenem ASM oder C rumschlagen zu müssen, für
mein Hobby reicht Basic dicke und mir vergeht daran nicht die Freude,
der Kaufpreis schmerzte etwas, aber gut.

A. Arndt

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe diese Diskussion läuft wie jede andere Diskussion wenn es um
die "richtige" Programmiersprache geht.

Aber, zu diskutieren welche Sprahce besser ist ist eiegtnlich falsch.
Viel wichtiger sind andere Punkte:

1.) Um die Hardwarearchitektur zu erlernen sind manche Sprachen
wesentlich besser als andere. In Assembler wird man am schnellsten die
Architektur erlennen, allerdings aber auch am qualvollsten. Dieser
Schritt ist Grundvorraussetzung um auch in den anderen Sprachen zu
wissen was ein Timer ist, ein ADC, Flashspeicherbedeutet usw. usw.

2.) Am schwierigsten ist der Erst-Einstieg in eine beliebige
Programmiersprache. Es ist im Grunde UNWICHTIG welche Sprache du
nimmst. Allerdings, am Anfang sollte man den zusätzlichen Overhead zur
Installation und Konfiguration der Programmiersprache so gering wie
möglich halten. Die Einstiegs-Sprache sollte möglichst ein Lineares
Denken unterstützen, anders ausgedrückt: Spaghetticode + Integrierte
IDE und Debugger ist für den Einstieg am besten geeignet, Dies ist auch
der Grund warum BASIC die meisten Dialekte und die größte Verbreitung
besitzt. Denn viele C/C++ Enthustisten meinen immer noch das ihre
Sprache am weitesten verbreitet ist, dies ist definitiv falsch, es ist
BASIC und Assembler.

3.) nachdem man also mit einem einfachen Tool sofort einteigen kann
wird man sehr schnell ein Fealing für die Programmierung bekommen.
Dieses "Fealing" ist für ALLE Programmiersprachen gleich, findet man
es NICHT wird man nie die Programmierung erlernen.

4.) nachdem man sehr schnell an die Grenzen von BASIC stösst, und
natürlich auch an dessen "Schwachstellen" in der Programmierungs-Art,
wird es Zeit OHNE Umschweife und Ängste NEUE Sprachen hinzuzulernen.
Nun wäre im speziellen für AVR's der richtige Zeitpunkt für Assembler.
Denn für AVR's gibt es eine gute IDE + Sourcen für Assembler. Nach
diesem Schritt wird man erkennen wie schnell man in BASIC einfache
Sachen machen kann, wie lange manchmal das Gleiche in Assembler dauern
wird, obwohl Assembler die meiste Freiheit bietet. Denoch wird sich
durch diesen Schritt dein "Blick" auf die Architektur ändern. Dann
wird es Zeit in C einzusteigen. Man benötigt nur wenige "Syntax"
Grundlagen um die Parallelitäten zu BASIC's und Assembler zu erkennen.
Ich rede also von Vergleichen, Berechnungen, Konstanten, Funktionen
usw. Wichtiger beim Erlernen von C ist ein Fealing für die nötigen
Tools zu bekommen, die meistens aus dem UNIX Lager stammen.
Dementsprechend unterscheiden sie sich in der Logik gravierend. C
ansich ist nicht schwierig, sondern es ordentlich zum Laufen zu
bekommen. Die Fehlersuche kann in C genauso schwierig sein wie in
Assembler.


Exakt in diesem Moment manchen die "Sackgassen"-Programmierer ihren
entscheidenden Fehler ! Die meisten die mit C anfangen zu lernen,
können zu einem späteren Zeitpunkt nur extrem schwer neue,
andersgeartete Programmiersprachen erlernen. Allerdings, man sollte
immer mehrere Sprachen erlernt haben. Ein guter Mix ist BASIC, PASCAL,
C, Assembler, und die ganzen Scriptsprachen wie Perl, HTML.

Jede weitere Sprache wird man dann innerhalb von Tagen erlernen können.
Denn im Grunde ob BASIC, Assembler, PASCAL, C, mit jeder Sprache kann
man fast immer das gleiche Resultat programmieren. D.h. ein gesetztes
ZIEL kann man mit allen Sprachen ereichen. Nur, der WEG dahin
unterscheidet sich, auf grund von fertigen Bibliotheken, vorhandenem
Demo-Source, fertigen IDEs, Debuggern usw. usw.
Ein guter Programmierer wird aber immer programmieren können, egal mit
welchen Tools.

Ich stimme also meinen Vor"postern" zu, nimm am Anfang BASIC, wenn es
schon für AVR's vorhanden ist.

Im deutschen Bildungssystem wird auf Schulebene meistens BASIC oder
PASCAL gelernt. Erst an Universitäten wird C/C++ vorausgesetzt. Dies
hat auch seine Gründe.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich denke auch dass es sinnvoll ist Assembler zu können, aber nicht
>zwingend notwendig. Die aktuellen Compiler erzeugen so guten Code,
>ich möchte behaupten, dass es aber einer bestimmten Codegröße nicht
> mehr möglich ist, effizienteren Code in vertretbarer Zeit per Hand
> in ASM zu schreiben.

Dies ist ein absoluter Trugschluß. Meine GLCD Library für das Nokia6100
Display hatte ich am Anfang mi WinAVR gcc C gecodet. Ich musste sehr
schnell enttäuscht feststellen das dieser Compiler und Linker enorm
schlecht optimieren. Gerade bei größeren Projekten viel ein enormer
Unterschied zu Assembler auf.

Leider sind heutige Compiler eben noch lange nicht schlauer und
intelligernter als der Mensch. Demzufolge ist es IMMER so das ein
handmade Assembler weit effizienter als jeder Compiler sein wird.
Dies liegt eben auch daran das die meisten Compiler doch ziemlich
einfach gestrickt sind, es sind eben nur State-Machines, mehr NICHT.

Im Falle meiner GLCD Library, die ich inerhalb von 3 Tagen nach
Assembler portiert hatte, hies das das der Assembler Source fast nur
noch die Hälfte an Coderesourcen benötigte. D.h. statt 4600 Bytes
compiliertem C entstand 2800 Bytes Assembler !! Dies ist ein gewaltiger
Unterschied und zeigt auch wie die "State-Machne" Mechanismen eines
Compilers durch menschliche Intelligenz weit übertroffen werden kann.

Alledings! eine PC Anwendung mit 500.000 Zeile C/Pascal Source in
Assembler schreiben zu wollen wäre Idiotie. D.h. Assembler wird IMMER
wesentlich höheren Zeit-/Arbeits-/Wissensaufwand benötigen.

Im Bereich der AVR's mit ihren doch enorm beschränkten Resourcen, ist
Assembler eine Alternative zu Hochsprachen. Denn ein 8Kb
Assemblersource ist noch relativ überschaubar und schnell erzeugt.

Eine 100Mb PC Anwendung wird aber OHNE Hochsprache nicht mehr
produzier- und wartbar sein.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man sieht also das es wichtig ist IMMER den inneren Schweinehund zu
besiegen, und möglichst mehrere Sprachen zu erlernen.

Gerade solche Aussagen wie "BASIC reicht mir völlig aus", "mit C
kann man alles machen, ich brauche keine andere Sprache" sind
tödlich.

Es wird immer wieder neue, verbeserte Sprachen geben, die auf neue
Technische Anforderungen in der Programmierung zugeschnitten werden. Es
ist also wichtig, eben nicht nur an einer Sprache hängen zu bleiben.

Kannst du dann eines Tages von dir sagen "ich kann BASIC, Assembler,
PASCAL, C, JAVA und Perl", dann kannst du dich beruhigt zurücklehnen
und den vielen Diskussionen welche Sprache denn nun besser sei,
zuhöhren :)

Du wirst dann wissen das es NICHT die ultimative Sprache geben kann,
und es demzufolge am sichersten ist ein breites Spektrum der
verbreitesten Sprachen zu beherrschen.


Gruß Hagen

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da kann ich nur zustimmen.
Solange es bei funktionaler Programmierung bleibt, ist es relativ egal
womit man anfängt.
Man wird irgendwann feststellen, dass manche Sachen in der einen
Sprache einfach von der Hand gehen als in einer anderen.
Wichtig ist eigentlich nur, dass man sich mit der Sprache wohlfühlt. Es
bringt nichts, wenn man beim x-ten Programm immer noch irgendwelche
Standard-Funktionen nachgucken muss, weil sie so kryptisch sind ( die
benutzt man eigentlich auch nicht).

Eigentlich geht es doch nicht darum, nur eine Sprache zu lernen. Im
Umgang mit Mikrocontrollern ist es doch grundsätzlich nötig, Assembler
zu verstehen (meist haben sich die Entwickler eine recht verständliche
Mnemonic ausgedacht, die man quasi so lesen kann).
Ob man als Hochsprache dann Basic oder C wählt, ist relativ egal, da
man sich mit der Zeit sowie in die jeweilige Sprache einarbeitet.
Und wenn man mit Basic beginnt, und damit zufrieden ist, dann ist das
halt so. Wer auch mal über den "Tellerrand" hinausschaut, wird dann
vielleicht feststellen, dass es zwar in Basic auf den ersten einfacher
ist, in C aber schneller und effizienter.
Für mich ist C im Bereich der Mikrocontroller schon die bessere Wahl,
da es für fast jeden Controller einen entsprechenden Compiler gibt.
Basic-Compiler gibt es für Controller wohl nur 2, so wie ich das
mitbekommen habe...
Steigt man beispielsweise vom AVR zum ARM oder irgendwelchen ganz
anderen (verbreiteten) Controllern um, so steht man mit reinen
ASM-Kenntnissen ziemlich dumm dar, weil man da meist umlernen muss.
Das haben die Entwickler von Compilern meist schon gemacht...

Es ist immer die Mischung, die es ausmacht:
Für das Architekturverständnis Assembler und fürs Programmieren eine
dem Zweck entsprechende Hochsprache.
Mit tiefgehenden ASM-Kenntnissen eines Controllers kann man meist auch
Compilate noch optimieren. Denn Compiler sind meist auf ein breites
Anwendungssprektrum ausgelegt.

@Hagen:
Hast Du deine GLCD komplett neu in Assembler geschrieben, oder das
C-Compilat optimiert?

Es hilft meist, Sachen in einer Hochsprache zu schreiben und die
Übersetzung dann zu optimieren, da man in der Hochsprache vielleicht
eher Fehler vermeiden bzw. entdecken kann. Meine Meinung halt.

Gruß Rahul

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:

> 1.) Um die Hardwarearchitektur zu erlernen sind manche Sprachen
> wesentlich besser als andere. In Assembler wird man am schnellsten
> die Architektur erlennen, allerdings aber auch am
> qualvollsten. Dieser Schritt ist Grundvorraussetzung um auch in den
> anderen Sprachen zu wissen was ein Timer ist, ein ADC,
> Flashspeicherbedeutet usw. usw.

Warum sollte man die Architektur in Assembler schneller lernen können
als in einer höheren Sprache?  Das ist so schlicht Unsinn, beides hat
miteinander nichts zu tun.  Im Gegenteil, man könnte genauso gut
argumentieren, daß man sich beim Assembler erstmal in nebensächlichen
Dingen verzetteln muß, während man sich in der Hochsprache sofort auf
die Hardwareeigenheiten des Controllers stürzen kann.

Ich habe noch nie einen MSP430 gesehen, erst recht mich noch nicht mit
seiner Assemblersprache befaßt.  Trotzdem brauche ich zum Verstehen
eines in C geschriebenen Schnipsels für diesen Controller nur noch das
Datenblatt + andere Doku.  So gut, wie das ,trocken' ohne Hardware
überhaupt machbar ist, kann ich damit anderen u. U. sogar noch die
Fehler in deren Code suchen.

Klar kann man den Output eines Compilers aus Sport noch in irgendeiner
Richtung optimieren (schneller heißt ja nicht immer auch kleiner).
Andererseits, wie schrieb doch neulich jemand: Du hast einen ganzen
ROM mit Deinem Controller gekauft, was für einen Sinn hat es dann,
Deinen Code so zu optimieren, daß er nur noch den halben ROM braucht?
Wenn Du Nokia-Mobiltelefone in Serie bauen willst, ist es sicher ein
Thema, 50 Cent am Controller zu sparen, aber für eine Hobbyanwendung
mit 2 oder 3 Exemplaren, warum soll ich das mühevoll in einen
ATtiny2313 pressen, wenn der ATmega8 nur einen Euro mehr kostet?  Den
Prototypen entwickelt man am bequemsten (und schnellsten) ohnehin auf
einem ATmega128, ``downsizen'' kann man danach allemal.

Schlechten Code kann man übrigens in jeder Programmiersprache
schreiben.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg:

>Warum sollte man die Architektur in Assembler schneller lernen können
>als in einer höheren Sprache?  Das ist so schlicht Unsinn, beides hat
>miteinander nichts zu tun.  Im Gegenteil, man könnte genauso gut
>argumentieren, daß man sich beim Assembler erstmal in nebensächlichen
>Dingen verzetteln muß, während man sich in der Hochsprache sofort auf
>die Hardwareeigenheiten des Controllers stürzen kann.

Ei, da habe ich mich nicht ganz klar ausgedrückt. Um zu verstehen wie
man ein Auto fährt muß man nicht KFZ Techniker sein. Allerdings wenn
man KFZ Techniker IST versteht man was passiert wenn man am Lenkrad
dreht. Eher in diesem Zusammenhang war meine Aussage gemeint.
Ich gebe dir Recht, meinte aber das wenn man Assembler verstanden hat
es automatisch eine Grundbedingung ist das man die Hardware verstehen
wird. Noch näher an die Hardware käme man nur mit der eigenen
Programmierung von Chips heran. Diese Aussage ist auch definitiv
logisch, denn bei einer High Level Language wie C macht gerade die
vorhandene Abstraktion zur Hardware das "High Level" aus. Durch diese
Abkapselung zur spezifischen Hardware wird auch die Portabilität der
Hochsprache erreicht. Portabilität und Hardwareabstraktion sind also
sich zwei bedingende Grundsätze. Das heist logischerweise auch das man
die Hardware auch OHNE Assembler verstehen kann, aber auch, das man in
Assembler nur effektiv arbeiten kann wenn man die Hardware verstanden
hat. Eher aus diesem Blickwinkel war mein Kommentar gemeint. Es ist
also auch gut zu wissen, wenn mann zB. in C programmiert, WIE C ansich
funktioniert. Wenn man schon einen Compiler als Mittel zum Zweck
benutzt, dann sollte man sich über die Arbeitsweise dieses Mittels
informiert haben. Zwangsläufig kommt man dann zu Assembler. Für meine
Begiffe ist diese Ansicht absolut logisch.


@Hagen:
>Hast Du deine GLCD komplett neu in Assembler geschrieben, oder das
>C-Compilat optimiert?
> Es hilft meist, Sachen in einer Hochsprache zu schreiben und die
> Übersetzung dann zu optimieren, da man in der Hochsprache vielleicht
> eher Fehler vermeiden bzw. entdecken kann. Meine Meinung halt.

Natürlich habe ich erstmal die komplette Library in C gecodet, gäbe es
einen genausoguten PASCAL Compiler wie es WinAVR für C gibt, hätte ich
den genommen.
Exakt bei der "Portierung" der menschlichen Denkmuster in eine
Programmiersprache zahlen sich ja Hochsprachen wie C/PASCAL usw. aus.
Es würde viel zu viel Streß und Zeit bedeuten, und wäre zum Top-Down
Design kontrahär, sofort das Programm in Assembler zu "denken".
Nein, ich gehe grundsätzlich so vor das ich ein Problem in logische
Module abstrahiere. Jedes einzelne Modul=Problem wird dann immer weiter
zerteilt, also Top-Down von der Idee über die Hochsprache hin zu
Assembler wenn unbedingt nötig. Irgendwann beginnt man dann den Source
in der Hochsprache so umzustellen das er von Natur aus besser auf die
Maschine abgestimmt ist. D.h. der C Source müsste sehr gut durch den
Optimierer in Assembler umgesetzt werden. Erst dann wird nach einer
Überprüfung der tatsächlichen Effizienz entschieden ob Assembler
überhaupt notwendig ist. Nur so hat man die Chance eine fertige Sache
hinzubekommen und denoch den Zeitaufwand zu jedem Zeitpunkt abschätzen
zu können. Aber diese "Weisheiten" kann man in jedem Programmierkurs
lernen.

Man muß sich mal vorstellen das man einen hochkomplexen Algorithmus
sofort in Assembler codet. Später stellt man fest das man wichtige
Parameter und Abarbeitsungsreihenfolgen des Algos. abändern muß. Mit
sofortiger Assemblercodierung verschleudert man dann aber wirklich
Zeit.

Nein, ich preferiere jede vernünftige Hochsprache gegenüber Assembler.
Allerdings verteufele ich Assembler nicht, sondern sehe diesen nur als
Root.

Das ich meine Library komplett aus C in Assembler portiert habe hatte
spezielle Gründe:
1.) hatte ich Zeit
2.) lief's gerade gut und ich hatte Lust drauf
3.) es war eine Übung um mein verstaubtest Wissen aufzufrischen
4.) das Ziel: ich benötige eine GLCD Library die auf dem ATMega8L läuft
und mir genügend Resourcen übriglässt damit ich den wesentlichen Part
in C schreiben kann ! Statt also 4600 Bytes nur 2800 Bytes zu
verbrauchen ist bei 8192 Bytes schon entscheidend.
5.) WENN ein Arbeitsmittel wie zB. gcc C NICHT in der Lage ist die von
mir gefordeten Bedingungen zu erfüllen, dann wechsele ich das
Arbeitsmittel ! ganz einfache Logik.
6.) lernen durch machen
7.) der Reiz... Ellipsen, Linien mal in Assembler zu coden. Das letzte
mal habe ich das für EGA/VGA Karten auf DOS 3.2 gemacht.
8.) tagtäglich verdiene ich Geld mit der Programmierung von
Personalmanagementsystemen, Einsatzplänen, Handheld Programmen für
PC's, Pentops und Palms. Ich brauche einfach mal ein Hobby im Hobby :)
und die Atmels sind echt überschaubare Resourcen. Sozusagen: bei den
AVR's ist man noch Gott, auf PC's ist man längst Sklave des
Marketings.

Zurück zur Frage: nach meiner Erfahrung haben die meisten Programmierer
mit Sprachen wie BASIC oder PASCAL angefangen. Ich kenne eigentlich
keinen Programmierer der von sich behauptet das er NICHT Basic kann,
und wenns nur das WinWord BASIC ist. Die meisten machen dann den
Schritt zu C/C++ oder JAVA, weil es entweder cooler für's Image ist
(man kann ja dann C) oder einfach weil man sich unnötige Arbeiten
sparen will, weil es in C/C++ so viele Sourcen gibt, egal warum.
Grundsätzlich bin ich der Meinung das PASCAL oder Modula dem C/C++ weit
überlegen ist, einfach weil diese Sprachen viel tiefer in das
Verständnis was moderne Programmierarbeit ist eingreifen, also
restriktiv sind. Aber, auch mit C/C++ kann man genausogut restriktiv
programmieren, man muß sich halt nur dazu zwingen.

Deshalb meine erste Aussage: entscheidend ist nicht die
Programmiersprache sondern die zur Verfügung stehenden Tools. Eine gute
IDE mit sauberen integriertem Debugger und expensiven Handbüchern ist
für eine Entscheidung viel wichtiger als die Sprache an sich. Dies
trifft auf denjenigen zu der überhaupt nicht weiß wo er anfangen soll.
Für denjenigen der Geld sparen muß sehen die Prioritäten ganz anders
aus. In diesem Falle kann man entweder nur WinAVR C oder gleich
Atmel's Assembler empfehlen.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hast Du deine GLCD komplett neu in Assembler geschrieben, oder das
>C-Compilat optimiert?

Hm, jetzt habe ich ertsmal deine Frage richtig gelesen.
Nein, der Assembler ist komplett neu geschreiben. Die Aufgaben der
einzelnen Module/Funktionen wurden vorher über C Source
getestet,abgestimmt und der Output analysiert. Erst danach habe ich
jede Funktion nach Assembler portiert, aber ohne den Assembler-Output
des C Compilers als Grundlage zu nehmen. Dies macht auch wenig Sinn, da
man den Aufwand der Portierung nach Assembler nur treiben sollten wenn
man 2 oder 3 Vorteile gewinnt. 1.) muß der Code kompakter sein, 2.)
sollte der Code schneller sein  3.) könnte der Code mehr Funktionalität
bieten, 4.) will man ja gerade die Schwächen in den Möglichkeiten des
Compilers mit Assembler umgehen. Nur wenn mehrere Punkte erfüllt sind
kann man sich sicher sein das sich der Aufwand auch lohnt. In den
wenigsten Fällen wird man nur weil man einen schnelleren Code benötigt
aufwändig Assembler nutzen.
Lässt man mal die schlechte Lesbarkeit/Wartbarkeit und die
Portierbarkeit von Assembler aussen vor, so ist eine
Assemblerprogrammierung immer effizienter wie jeder heutige Compiler.
Der einzigste verbleibende Vorteil des Compilers wäre dann seine enorme
Geschwindigkeit.

Gruß Hagen

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Werner,
ich glaub du hast die Büchse der Pandora geöffnet.
Aber das haben andere auch schon.

Heinz

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Meinung:
1. Lerne die erst beste Sprache.
2. Schlecht ist keine!
3. Nicht gleich Aufgeben und wieder umsteigen!
4. Schau dann über den Tellerand hinaus und beschäftige dich mit
anderen Sprachen.
5. Du solltest immer wieder Dazulernen wollen.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg:

>Klar kann man den Output eines Compilers aus Sport noch in
> irgendeiner Richtung optimieren (schneller heißt ja nicht immer
> auch kleiner).

> Schlechten Code kann man übrigens in jeder Programmiersprache
> schreiben.

Jörg, ich weis das du mit WinAVR gcc C eng liiert bist, das ist gut.
Allerdings muß ich dir widersprechen wenn du meine Arbeit als Sport
abtust und indirekt unterstellst das der zugrunde liegende C Source ein
schlechter Code wäre.

Im Gegenteil, wie man aus obigen Postings vielleicht ersehen konnte,
versuche ich "leidenschaftslos" und objektiv die Möglichkeiten der
verschiendenen Programmiersysteme abzuschätzen.

Im speziellen Falle das gcc C Compileres ist es leider tatsächlich so
das er in vielen Bereichen sehr wenig optimiert. Das gleiche gilt für
den gcc Linker der unbenutzte Funktionen nicht entfernt.
Mir ist in weiten Teilen auch bewusst WARUM dies so und nicht anders
ist. Aber eines ist für mich persönlich ganz gewiss: hätte ich die
vielen kleineren Schachstellen im gcc Compiler nicht genauer untersucht
und auch verifiziert, so hätte ich niemals eine so große Library
vollständig in Assebler gecodet. Ok, man könnte es als Sport
betrachten, nur dann muß ich definitiv auch feststellen das ich
innerhalb von 3 Tagen a 10 Stunden doppelt so schnell im Ziel bin und
dabei nur die Hälfte an Energie verbraucht habe, als der Compiler.

Wichtig erachte ich aber das man objektiv bleibt. Natürlich ist eine
gewisse Loyalität zu seinem perferierten Produkt gesund, aber zuviel
davon kann blind machen. Ich bevorzuge die Möglichkeiten seiner
Werkzeuge genau zu kennen, und dazu gehören auch deren Schachstellen.

Auch dies ist ein Grund warum ich die Meinung vertrete das es gut ist
wenn man Assembler kann. Denn im Gegensatz zu Compiliern oder
Interpretern hat man in Assembler ALLE Freiheiten, also auch die
Freiheit besseren Code, und sei es nur im sportlichen Sinne, zu coden
als es der Compiler jemals könnte.

Aber viel öfters tritt der Fall ein das durch aufwändige und
zeitraubende Assemblerprogrammierung die offensichtlichen Schwächen der
verwendeten Compiler ausgebügelt werden müssen.

Gruß Hagen

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, ich wollte nicht unterstellen, daß Du schlechten Code produziert
hättest, aber ein bißchen schon, daß Du Dir keine Mühe gegeben hast,
das in C zu optimieren. ;-)

Anyway, wenn Du das sauber in 3 Tagen in Assembler hinbekommst und
auch das Vertrauen hast, daß Du dabei nicht mehr Bugs reinbaust als in
C (das ist halt der Vorteil der Hochsprache: viele Trivialfehler
werden vom Compiler vermieden), dann ist das OK.  Ich habe auch schon
ein ganzes CP/M-BIOS in Assembler geschrieben, verstehe aber
mittlerweile meinen früheren Rechenstationsleiter viel besser als noch
vor 20 Jahren, der einen Assembler nie wieder anfassen wollte --
nachdem er in seiner Sturm- und Drangzeit das Bibliothekssystem der
Dresdner Unibibliothek in Maschinencode geschrieben hatte...

Von Dingen wie einer nicht automatischen Eliminierung ungenutzter
Funktionen (macht Dir aber in Assembler auch niemand als Du selbst ;-)
abgesehen, bin ich aber mit der Optimierung gerade des AVR-GCC im
Großen und Ganzen zufriedener als Du.  Ich kenne ein paar Dinge, die
er besser machen könnte (beispielsweise control expressions vom Typ
int auf 8 bits einkürzen, wenn nicht mehr Entscheidungswege
existieren, oder JMPs auf RJMPs verkürzen, wenn bei einem Controller >
8 KB ROM das Sprungziel nah genug ist), vielleicht widme ich mich dem
einen oder anderen Thema auch mal irgendwann.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ber ein bißchen schon, daß Du Dir keine Mühe gegeben hast,
> das in C zu optimieren. ;-)

Dies war ja der Hauptgrund. Nach einigen wiederholten Versuchen zB.
eine Linien/Ellipsen Funktion zu verbesseren, in C, habe ich den
Schritt in Richtung Assembler gemacht.

Ok, da Unterfunktionen nötig waren, konnte ich gerade in solchen
Algorithmen in Assembler viel mehr die Hardware ausnutzen als das der C
Compiler überhaupt darf. Zb. eben alle Register zu nutzen statt wie der
Compiler mit int zu arbeiten. Oder eben Registeroptimierungen über
Funktionsgrenzen hinweg.

Zudem, gerade bei Linien/Ellipsen Funktionen sind mit Assembler auch
mathematische Tricks möglich die mit dem Compiler überhaupt nicht
gehen. Zb. 24Bit signed Integer in der Ellipsen Funktion.

Nungut, mein idealer Compiler müsste einige spezial optimierungen
enthalten. Gerade für AVR's die enorm beschränkte Resourcen haben
wären ganz spezielle Optimierungen möglich:

- Eliminierung redundanter Funktions-Exits, zB. aus 2 POPS + 1 RET an
mehreren Stellen kann 1 RJMP werden, schon > 50% gespart. Dazu müsste
der Compiler die Registerreihenfolge beim PUSH'en imer gleich halten.
So entstehen ganz natürlich redundante Exists.
- Sprungziel bei AVR's < 8K immer mit rjmp/rcalls, in meinem
Assemblersource habe ich dazu Macros definiert. Allerdings wäre das ja
Aufgabe des Linkers ordentlich zu relocatieren (gibs das Wort überhaupt
?:).
- wichtig sind der Zugriff auf Variablen im RAM, hierbei habe ich
festgestellt das der Compiler diese nicht automatisch in Registern
hält. Dadurch erzeugt er zu viele Lese/Schreib-Befehle ins RAM, was
natürlich Code kostet. Komischerweise sind oft mehr als 8 Register
unbenutzt in Unterfunktionen, und denoch werden wiederholte Zugriffe
auf's RAM nicht automatisch lokal in der Funktion in Registern
gehalten. Das hat primär erstmal nichts mit volatile Definitions zu
tun.
- Als Finale Optimierung könnte der Compiler den Funktions-Tree von
innen nach aussen auf die Register optimieren. D.h. meistens ist es so
das die innersten Funktionen, die am häufigsten aufgerufen werden,
relativ unkompliziert und klein sind. Allerdings entwickelt sich
ausgehend von dieser Richtung der Registerdruck. Der Compiler vermeidet
dies indem er sein Register-Set funktional statisch aufteilt und in
übergeordneten Funktionen anfängt zu pushen. Nun, die Finale
Optimierung müsste wie gesagt von Innen nach Aussen im Funktionstree
die Register funktional automatisch auf die Funktionen verteilen. D.h.
er reserviert einzelne Register auf spezielle Funktionen für deren
Parameter. Nun kann er in den übergeordneten Funktionen auf andere
Register ausweichen und die Registernutzung in der Parameter-Übergabe
ist dynamisch.

Gerade in diesem Punkt erreichte ich durch die Assembler-Umsetzung die
Vorteile. Bis auf wenige Funktionen konnte ich ALLE Push/Pops
eliminieren. Die Grundidee dabei war ganz einfach: verteile die
verfügbaren Register von innen nach aussen, also von der innersten
Funktion auf die übergeordneten Funktionen.

Natürlich wollte ICH so einen Compiler NIEMALS programmieren wollen :)
Denoch wäre es eine super Optimierung, die der Mensch eben bei handmade
Assembler automatisch on the Way macht. Potential ist auf alle Fälle
noch ne Menge im AVR GCC.

Ich habe halt bisher noch keinerlei Vergleiche zu anderen verfügbaren
Compilern gemacht. Aus dieser Sicht gebe ich zu das meine Kritiken
unfair sein könnten. Allerdings nutze ich aus der Intel-Welt seit mehr
als 15 Jahren einige Compiler, sei es C, Pascal, Delphi oder Basic. In
Bezug auf diese Compiler musste ich schon einen Unterschied
feststellen. Generell habe ich das Gefühl das AVR GCC ziemlich statisch
optimiert. Nunmehr habe ich bei einigen anderen Routinen wie I2C,
EEPROM oder UART ebenfalls nach Assembler portiert. Dabei konnte ich
für mich persönlich eine kleine Pi * Daumen Regel aufstellen: Assembler
spart durchschnittlich minimal 30% an Code und ist denoch
Performancetechnisch schneller. Soviel Zugewinn konnte ich auf anderen
Systemen nur sehr selten erreichen. Die Portierung von gutem getesteten
C Code nach Assembler ist immer ein zusätzlicher Zeitaufwand und auch
Fehlerrisiko, das ist fakt. Allerdings hängen beide Faktoren nur von
den Fähigkeiten der benutzten Tools und dem Entwickler ab. Mir
persönlich fällt es relativ leicht einen C Source erstmal so umzubauen
das er fast 1 zu 1 nach Assembler umgesetzt werden kann. Meistens sehe
ich schon im C Source selber wo ein handmade Assembler mir automatisch
mehr Potential ausschöpfen kann. D.h. die 3 Tage der Portierung meiner
GLCD Library sind der REINE Schritt von vorher duchgestyletem C Code
nach Assembler. Die logischen Programmierfehler an der Funktionalität,
und der dazu nötige Zeitaufwand, fallen in die C Programmierung.
Würde man sofort in Assembler codieren müsste man diesen zeitlichen
Aufwand ja ebenfalls berücksichtigen, und gerade hier gewinnt wiederum
eine Hochsprache im Vergleich zu Assembler.

Über Bug's oder Wartungsarbeiten am Assemblercode brauchen wir nicht
zu diskutieren. Assembler verliert in diesem Vergleich immer, das ist
fakt. Man kann aber mit entsprechneder Arbeitsweise dieses Ratio
verkleinern.

Gruß Hagen

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Zudem, gerade bei Linien/Ellipsen Funktionen sind mit Assembler auch
> mathematische Tricks möglich die mit dem Compiler überhaupt nicht
> gehen. Zb. 24Bit signed Integer in der Ellipsen Funktion.

Gut, solche Dinge kann ein Compiler wirklich fast nicht tun.

> - Eliminierung redundanter Funktions-Exits, zB. aus 2 POPS + 1 RET
> an mehreren Stellen kann 1 RJMP werden, schon > 50% gespart. Dazu
> müsste der Compiler die Registerreihenfolge beim PUSH'en imer
gleich
> halten.

Ist meines Wissens beim GCC typisch der Fall.

> - Sprungziel bei AVR's < 8K immer mit rjmp/rcalls, ...

Macht AVR-GCC.  Kritischer ist der umgekehrte Fall: AVR > 8 KB ROM,
dort werden derzeit für alles außerhalb der eigenen Funktion JMP/CALL
genutzt, auch dann, wenn das Sprungziel noch innerhalb der
,,eigenen''
8 KB liegt, wo ein RJMP/RCALL genügt.  IAR ist hier besser und kann
das optimieren.  Laut Aussage von Denis Chertykov kann der GNU Linker
sowas auch, aber das müßte halt mal jemand implementieren.  Besonders
kraß ist das entstehende Mißverhältnis natürlich auf AVRs mit 16 KB
ROM, da dort die relative Verschwendung am größten ist.  Das merkt man
bspw. beim Butterfly (ATmega169).

> - Als Finale Optimierung könnte der Compiler den Funktions-Tree von
> innen nach aussen auf die Register optimieren.

Ich glaube, einen Compiler, der Dir wirklich den Aufrufbaum der
Funktionen (der ja zyklisch sein kann) analysiert, mußt Du erstmal
suchen...

Anderseits: ich glaube, daß Du das auch in Assembler ab einer gewissen
Größe kaum noch überblicken kannst.

Kann übrigens sein, daß der IAR da auch besser wegkommt als der GCC,
zumindest habe ich beim Analysieren von IAR-Code diesen Eindruck
gehabt.

Autor: Weide (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

jetzt muß ich auch mal meinen Senf dazu geben.

Bis vor Kurzem habe ich ausschließlich in Assembler programmiert und
bei solchen oder ähnlichen Fragen hier im Forum war ich eigentlich
immer ziemlich "pro-assembler". Jetzt habe ich es endlich geschafft,
mich durch c durchzubeissen und die ersten Anfangsschwierigkeiten
überwunden. Mittlerweile macht es mich richtig Spaß und ich ärgere mich
direkt über meine jahrelange Assemblerprogrammierung. Ich erwische mich
immer immer wieder dabei, Features in die Programme einzubauen, die ich
unter Assembler aufgrund der Komlexität weggelassen hätte.

Allerdings würde es mir noch mehr Spaß bringen, wenn sich nicht c
sondern Delphi/Pascal im Microkontrollerbereich durchgesetzt hätte(in
der PC-Programmierung verwende ich Delphi). Ich ärgere mich manchmal
maßlos über die hohe Fehlertoleranz der c-Compiler. Wenn ich in Delphi
ein Projekt compiliere und es kommt keine Fehlermeldung, dann kann man
in 95% aller Fälle davon ausgehen, dass das Programm auch läuft. In c
ist es völlig anders, da werden Dinge einfach ignoriert (Stichwort
Arraygrenzen), da kann man wild und ohne Fehlermeldung alle möglichen
Datentypen mischen (sowas nennt sich dann auch noch automatische(!)
Typkonvertierung) und vieles mehr - und alles ohne Fehlermeldung. Und
das alles nur weil der c-Compiler absolut einfach gestrickt ist und
nicht, wie die c-Profis gerne behaupten, weil man doch ach so viele
Freiheiten hat. Warum wird c eigentlich nicht in Sachen Fehlertoleranz
weiterentwickelt? Das Ganze könne man doch problemlos umschaltbar
gestalten. Der Profi kann dann weiterhin mit seinen "Freiheiten"
weiter arbeiten.

Ich will c, auch wenn's vielleicht so klingt, nicht schlecht machen,
es verschafft einem sicherlich viele Vorteile. Hätte sich Pascal als
DIE Sprache durchgesetzt, wäre meiner Meinung nach alles noch ein wenig
einfacher und fehlerfreier.

Gruß Weide

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg:

>> - Eliminierung redundanter Funktions-Exits, zB. aus 2 POPS + 1 RET
>> an mehreren Stellen kann 1 RJMP werden, schon > 50% gespart. Dazu
>> müsste der Compiler die Registerreihenfolge beim PUSH'en imer
>> gleich halten.

>Ist meines Wissens beim GCC typisch der Fall.

Du beziehst dich auf die gleiche Reihenfolge beim POP'en + RET ??
Von einer Entfernung der entstehenden Redundanz habe ich nichts
bemerkt. Kann es sein das ich am makefile irgendwelche speziellen
Einstellungen übersehen habe ?

@Weide:

Dies ist der typische Unterschied zwischen restriktiven und nicht
restriktiven Programmiersprachen. Nungut, beides kann seine Vorteile
und Nachteile haben, und als Programmierer sollte man die entsprechende
Intelligenz besitzen. Ich persönlich sehe auch das Unit-Konzept in
Pascal und vielen anderen Sprachen als Vorteil an.

Allerdings sehe ich den zusätzliche Präprozessor beim C, auch wenn er
als DAS Übel bei nicht-restriktiven Sprachen gefeiert wird, als
unschlagbaren Vorteil auf AVR's an. Auf die fehlende Typsicherheit,
ein Programmierer der noch nie in PASCAL gecodet hat weiß garnicht
wovon da tatsächlich die Rede ist, kann einiges an Umschreib-Arbeit
sparen. Das erspart aber niemals das Mitdenken beim Coden.

Man könnte nun eine Streit-Diskussion vom Zaun brechen, welche Sprache
besser ist. Aber das ist kontraproduktiv, denn eine Programmiersprache
ist NUR ein Werkzeug.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg:

> Ich glaube, einen Compiler, der Dir wirklich den Aufrufbaum der
> Funktionen (der ja zyklisch sein kann) analysiert, mußt Du erstmal
> suchen...

Dies gibt es. Jeder Optimierer der Funktions-übergreifend optimiert hat
alle Fertigkeiten die er dazu benötigt. Es geht auch im speziellen
garnicht darum bis in die letzten Untiefen zu optimieren. Sondern nur
darum die Registerverteilung in den Aufrufparametern zu optimieren. Aus
dieser Sicht heraus wäre der Suchbaum bei der Optimierung garnichtmal
so komplex, denn innerhalb dieser Suche wird jede Funktion als Blackbox
betrachtet. Grundvorraussetzung wäre aber auf AVR's die Anzahl der
verfügbaren Register virtuell zu verdopplen, indem eben ein uint8_t
auch als uint8_t übergeben wird und nicht als int. Wobei, die Übergabe
als solches ist garnicht entscheidend, sondern deren Berücksichtigung
innerhalb der Funktionen im Zusammenhang mit dem Aufruf von
Unterfunktionen.

Allerdings begebe ich mich mit dieser Diskussion so langsam auf
Glatteis, denn bisher habe ich nur einmal einen Compiler gecodet, und
kann nicht behaupten das ich ein erfahrener Compilerbauer bin.


Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß nun nicht wie gcc vorgeht, aber ich habe den Eindruck das
konzeptionell so wie in PASCAL vorgegangen wird. Man verteilt die
Register auf funktionelle Blöcke. Die Unterfunktion ist aus Sicht des
Optimierers eine Blackbox die sich an die virtuelle funktionale
Registeraufteilung zu halten hat. Exakt so gehen auch PASCAL Compiler
vor, zB. Delphi. Allerdings gerade dieser Punkt wird ja bei C Compilern
die Funktionsübergreifend optimieren können als unschlagbarer Vorteil
gegenüber Pascal Compilern angeriesen.
Geht man so wie in PASCAL vor erübrigt sich der Aufbau eines
Funktionstrees und der Suche darin. Nach meinen Erfahrungen aber wird
bei einem C Compiler aber eigentlich immer ein solcher Tree aufgebaut,
da alleine schon der Preprozessor mit seinen weitreichenden
Auswirkungen dies bedingt. Sollte gcc methodisch wie PASCAL vorgehen
dann sehe ich keinen Grund für die Behauptung das ein guter BASIC oder
PASCAL Compiler für AVR's schlechteren Code erzeugen sollte, bzw. das
der C Compiler kompakteren oder schnelleren Code im Vergleich erzeugt.

Gruß Hagen

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

nach dem ganzen ASM, C/C++ und Basic doch noch mal der Hinweis auf
Pascal. Es ist zwar vielleicht nicht DIE Sprache für Microcontroller
aber es gibt eine kommerzielle IDE komplett mit Treibern für (fast)
alle Möglichkeiten vom Flashloader über Multutasking bis zu PWM.
Unterstützt werden AVR und PIC (Phillips ARM's sind geplant). Bei

www.e-lab.de

findet man eine kostenlose Demo bis 4kByte Code. Ist nicht viel aber
zum probieren reichts.

Andreas

Autor: task (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Zusammen,

ein paar Tip's zur Sprache (egal welche):

--  Dokumentiere was Du programmiert hast !!

Schlecht dokumentierter Code ist tödlich. In Assembler in wenigen
Tagen. Bei den Hochsprachen etwas später lol ....

-- Erfinde das Rad nicht immer Neu !

Schreibe von Anfang an deine Programme so, dass möglichst viel davon
wiederverwertet werden kann. Übersichtlich, Modular, und mit vielen
Kommentaren (Damit ist nicht objektorientiert gemeint !)



Und doch noch zur Sprache:

-- Wenn Du Jobmässig mal Controller oder DSP's programmieren willst
   lerne C und Assembler. Das ist in der Industrie Standard.

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.