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
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
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
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
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
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
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
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.
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
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
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.
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
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
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
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
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
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
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.
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
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
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???
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.
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
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
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.
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 ;-)
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
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
>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
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
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
@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.
@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
>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
Hallo Werner, ich glaub du hast die Büchse der Pandora geöffnet. Aber das haben andere auch schon. Heinz
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.
@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
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.
> 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
> 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.
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
@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
@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
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
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.