Mikrocontroller.net - Benutzerbeiträge [de]

Mini-Computer

2004-06-03T20:30:05Z

80.129.126.3:

Um 1970 entstandener Begriff für "kleine" Computer, hauptsächlich verwendet, um diese von den damals noch dominierenden Großrechnern abzugrenzen.

Ein typischer "Mini-Computer" hatte etwa die Größe eines raumhohen Aktenschranks mit einem Leistungsbedarf im Kilowatt-Bereich und lag preislich jenseits der Grenze von 100.000 Dollar.

Ein sehr verbreiteter Mini-Computer der 1970-er war die PDP-11 von Digital Equipment, mit einem maximal möglichen Hauptspeicherausbau von 128 KByte. Die PDP-11 war nicht nur die Wiege von [[Unix]] (nach ersten, eher prototyphaften Versuchen auf einer PDP-7), die Architektur der PDP-11 war auch Vorbild oder zumindest Inspiration für zahlreiche später entwickelte Mikro-Prozessoren, die wiederum die Basis der heutigen [[Mikrocontroller]] darstellen.

Prozessor

2004-06-03T20:19:26Z

80.129.126.3:

Kernstück praktisch aller "Elektronischen Rechenmaschinen" vom Großrechner über [[Mini-Computer]], Workstations und PCs bis zum [[Mikrocontroller]].

Daneben gehört zu einem arbeitsfähigen Rechner noch der Hauptspeicher, aus welchen der Prozessor die Instrukionen des auszuführenden Programms liest und in dem er bei Bedarf Daten ablegen kann.

Kernstück des Prozessors sind üblicherweise seine [[Register]] von denen eines eine besondere Stellung einnimmt: es zeigt auf den nächsten, auszuführenden Befehl im Hauptspeicher (andere Namen: PC = program counter oder IP = instruction pointer, beides außerhalb des Kontextes aber missverständlich, da mit einer weiteren wesentlichen Bedeutung belegt).

Eine Anzahl von Registern ist in der Regel frei verwendbar und ihre Inhalte können aus dem Hauptspeicher mit Werten geladen bzw. dort abspeichert werden.

Schließlich enthält ein typischer Prozessor noch eine "arithmetisch-logische Einheit" (= [[ALU]], arithmetic logical unit), welche die Inhalte eines Registers verarbeiten (negieren, verschieben ...) oder die mehrerer Register miteinander verknüpfen kann (addieren, subtrahieren, bitweises UND, bitweises ODER, ...), wobei das Ergebnis in der Regel wieder in einem Register abgelegt wird.

(Register sind nicht immer physischer Bestandteil eines Prozessors, manche Prozessoren verwenden auch Teile des Hauptspeichers als Registerbänke, ferner sind registerlose Architekturen denkbar, bei die mit der ALU möglichen Verknüpfungen "von Hauptspeicher zu Hauptspeicher" ausgeführt werden und natürlich sind auch beliebige Mischformen möglich.)

Transistor

2004-06-03T19:59:40Z

80.129.126.3:

Kunstwort aus "transfer resistor", was etwa so viel bedeutet wie "veränderlicher Widerstand".

In den 1950-ern als praktische Anwendung des Halbleiter-Effekts erfundenes "solid state" Schalt- und Verstärkerelement, welches sehr klein ist, ohne bewegte Teile auskommt (anders als ein klassisches Relais) und keine energiefressende Heizung benötigt (anders als eine Röhre).

Vom "bipolaren Transistor" (PNP, NPN) weiterentwickelt zum "Feldeffekt-Transistor" (FET), der heute - gefertigt mit einem preiswerten Verfahren unter Verwendung von Metall-Oxid-Schichten (MOS) - ein wesentliches Element integrierter Schaltkreise (ICs, integrated circuits) darstellt, und damit natürlich auch von [[Mikrocontroller]]n, um die es in diesem Wiki hauptsächlich geht (bzw. gehen sollte).

== Links ==
[http://de.wikipedia.org/wiki/transistor "Transistor" bei Wikipedia]

Transistor

2004-06-03T19:51:01Z

80.129.126.3:

Kunstwort aus "transfer resistor", was etwa so viel bedeutet wie "veränderlicher Widerstand".

In den 1950-ern als praktische Anwendung des Halbleiter-Effekts erfundenes "solid state" Schalt- und Verstärkerelement, welches sehr klein ist, ohne bewegte Teile auskommt (anders als ein klassisches Relais) und keine energiefressende Heizung benötigt (anders als eine Röhre).

Vom "bipolaren Transistor" (PNP, NPN) weiterentwickelt zum "Feldeffekt-Transistor" (FET) welcher mit einem preiswerten Herstellungsverfahrens unter Verwendung von Metall-Oxid-Schichten (MOS-FET) ein wesentliches Element integrierter Schaltkreise darstellt - und damit natürlich auch von Mikrocontrollern, um die es in diesem Wiki hauptsächlich geht (bzw. gehen sollte).

Unix

2004-06-03T19:37:57Z

80.129.126.3:

In den 1970-ern entstandenes [[Betriebssystem]] mit vielen innovativen Konzepten.

Der Unix-[[Kernel]] basiert auf der Programmiersprache [[C]], die eigens zu diesem Zweck als Ersatz für [[Assembler]] entwickelt wurde.

Direkt (als Weiterentwicklung des Original-Quelltextes) oder indirekt (als funktional ähnliche oder gleichwertige Neu-Implementierung) die Basis vieler späterer Betriebssysteme, wie etwa XENIX, UniFLEX, Coherent, BSD-Unix, Solaris, HP-UX, Irix, Sinix ... und natürlich Linux.

== Links ==
[http://de.wikipedia.org/wiki/Unix "Unix" bei Wikipedia]

Programmiersprache

2004-06-03T19:25:47Z

80.129.126.3:

In der Regel sind hiermit "höhere Programmiersprachen" ([[HLL]]s) gemeint.

(Generell könnte man auch [[Assembler]] sowie jede andere Art und Weise, einen erwünschten Programmablauf vorzugeben - in Textform, grafisch, durch gesprochene Sprache, ... - Programmiersprache nennen.)

Für eine Programmiersprache wird in der Regel eine [[Syntax]] sowie eine [[Semantik]] definiert sein, wobei erstere die Regeln für "gültige Programme" festlegt und letztere die Bedeutung der diversen Konstrukte beschreibt. (Allerdings bedeutet "gültiges" Programm nicht unbedingt "fehlerfrei abaufendes" Programm!)

Viele moderne Programmiersprachen werden ergänzt durch [[Bibliotheksfunktionen]], bei C und C++ wird in diesem Zusamenhang auch häufig von der Standardbibliothek gesprochen. Über Zusatzbibliotheken sind solche Programmiersprachen dann leicht erweiterbar, da neue Funktionalitäten keine Einfuss auf die Syntax haben. Die Syntax legt lediglich fest, WIE externe Funktionen aufzurufen (und zuvor ggf. anzukündigen) sind. Die Festlegung gilt dann für alle Funktionen, egal aus welcher Bibliothek sie kommen.

In [[C]] und reicht die Kenntniss der Syntax allein keineswegs nicht aus, selbst wenn man nur einfachste Programme schreiben möchte, denn bereits für so "triviale" Dinge wie Ein-/Ausgabe und Verarbeitung von Zeichenketten, die beinahe in jedem Programm nötig sind, muss man Funktionen der Standardbibliothek aufrufen.

Extremer noch ist die Situation bei [[C-Plusplus|C++]], wo eine sehr umfangreiche Standadrbibliothek bereitsteht, die aber kaum ein Programmierer oder eine Programmiererin in Gänze kennen wird, da man - abhängig vom Einsatzbereich - auch nur einen mehr oder weniger kleinen Teil der in der Standardbibliothek bereitgestellten Funktionen benötigt.

Die Auslagerung wesentlicher Teile in Bibliothekscode ermöglicht im Bereich der Programmierung von Mikrocontrollern interessante Ansätze: So könnte z.B. der Prototyp einer Applikation zunächst auf einen PC oder einer Workstation entwickelt werden und eine Bibliothek verwenden, welche wesentliche Teile der später vorhandenen Peripherie (Aktuatoren, Sensoren, ...) lediglich nachbildet, z.B. als Elemente einer grafischen Oberfläche. Später wird dann das selbe Programm mit einer Bibliothek übersetzt, welche (unter gleichem Namen) andere Funktionen bereitstelt, die nun tatsächlich I/O-Adressen (und darüber die wirklichen Aktuatoren und Sensoren) ansprechen.

Stack

2004-06-03T18:58:23Z

80.129.126.3:

Andere Bezeichnung: "Kellerspeicher".

Ein Stack ist ein Speicher nach dem LIFO-Prinzip (last in, first out). Man kann sich vergleichsweise einen Stack als einen Stapel von Tellern vorstellen, bei dem der zuletzt auf den Stapel gelegte Teller immer zuerst heruntergenommen werden muss um an die darunterliegenden Teller herankommen zu können.

In Prozessoren wird der Stack unter anderem dazu verwendet, um beim Aufruf einer Subroutine die Rücksprungadresse speichern zu können. Das bedeutet, dass man ohne einen Stack keine Unterfunktionen aufrufen könnte.

Auf dem Stack speichert man u.a. die Registerinhalte bei [[Interrupt]]- und Funktionsaufrufen und bei höheren Programmiersprachen ([[HLL]]s) auch die übergebenen Funktionsargumente sowie die lokalen Variablen.

Assembler

2004-06-03T18:56:59Z

80.129.126.3:

"[[Programmiersprache]]" die mit den grundlegenden ([[Hardware]]-mäßig vorhandenen) Befehlen arbeitet.

Alle Befehle sind in der Hardware des Mikroprozessors integriert und benötigen dadurch eine geringe Verarbeitungszeit. Sie werden auch so, wie sie sind, in den Prozessor übertragen. Befehle einer Hochsprache werden im Gegensatz dazu zu erst in die "Prozessor-Sprache", den Assembler-Befehlen, übersetzt (mittels [[Compiler]]).

Mit Assembler zu programmieren hat den Vorteil besonders geschwindigkeitsoptimierte Programme zu erstellen. Der Programmieraufwand ist aufgrund der "einfachen" Befehle jedoch um einiges höher als beim erstellen von Anwendungen mittels einer "höheren Programmiersprache" [[HLL]].

Der eigentliche Assembler ist ein Programm, dessen wichtigste Aufgabe es ist die mit [[Mnemonik]]s formulierten Befehle in die eigentlichen (Befehls)Bytes zu übersätzen.

Copy-und-Paste-Programmierung

2004-06-03T18:52:07Z

80.129.126.3:

Unter "Copy&Paste-Programmierung" versteht man das verbreitete Vorgehen, ein Programm oder einen Programmteil nicht "von Null" neu zu schreiben sondern ein etwa passendes Stück Quelltext zu kopieren und an die neuen Gegebenheiten anzupassen.

== Vor- und Nachteile ==
Der große Vorteil von Copy&Paste-Programmierung ist die dadurch erreichte Wiederverwendung - warum das Rad immer wieder völlig neu erfinden, wenn das, was man braucht, schon anderweitig vorhanden ist und nur etwas angepasst werden muss?

Deshalb ist dagegen zunächst auch nichts einzuwenden, insbesondere sollte sich der Chef doch freuen, wenn man nach einem halben Tag "10.000 lines of code" aus dem Boden gestampft hat?
Wird er auch - aber vielleicht auch nicht, abhängig davon, wie "geringfügig" die Anpassungen waren und ob hinterher noch jemand weiß, woher der Originaltext stammte und ob ggf. der Autor des Originals weiß, dass sein Programm die Vorlage für ein anderes war.

Je mehr gleichartiger Quelltext mit minimalen Variationen existiert, desto höher ist die Chance, irgendwo nachträglich noch einen Fehler zu finden, den eine andere Version auch enthält. Und so schön es ist, mit Copy&Paste-Programmierung in einem halben Tag fertig zu sein, so ärgerlich ist es, ein Jahr später nach drei Tagen Fehlersuche einen Bug zu finden, bei dem einem schließlich einfällt, dass man vor längerer Zeit genau die selbe Sache schon einmal an einem anderen Programm "reparieren" musste. (Nur gut, wenn man jetzt noch weiß, welche weiteren Kopien mit dem selben Bug im Umlauf sind.)

== Alternativen ==
Spätestens wenn per Copy&Paste-Programmieren die dritte oder vierte "nahezu" übereinstimmende Version erstellt wird, sollte man nach besseren Möglichkeiten der Wiederverwendung suchen. Diese sind
* Wiederverwendbare Unterprogramme (Assembler, C, C++, allg. prozedurale Sprachen)
* Wiederverwendbare Klassen (C++, allg. Objektorientierte Sprachen)
* Konfiguration über (Präprozessor-) Makros (Assembler, C, C++)
* Wiederverwendbare Templates (C++, allg. Generische Programmierung)
* Little Languages, problemspezifische Programgeneratoren

Der große Vorteil ist, dass der Quelltext in solchen Fällen nur ein einziges Mal existiert, nachträglich entdeckte Fehler somit auch nur einmal behoben werden müssen und evtl. Verbesserungen automatisch überall einfließen. (Vorausgesetzt ein Konfigurationsmamagement sorgt für ggf. erforderliche Neuerstellungen.)

Der große Nachteil ist, dass meist - bevor Wiederverwendung möglich ist - bestimmte Aspekte parametrisiert werden müssen, damit sie in zwei verschiedenen Verwendungen unterschiedliche Ausprägung haben können. Dies erfordert
* zum einen Zeit, die betreffenden Stellen zu identifizieren und zu parametrisisieren,
* birgt zum zweiten die Gefahr, Fehler in bisher funktionierende Programmteile einzubringen,
* und hat manchmal eine gewisse Tendenz, am Ende übermäßig flexible und schwierig zu handhabende Komponenten zu produzieren, deren Komplexität in einer EINZELNEN Verwendung unnötigen Overhead verursacht.

Letzteres kann bei der Mikrocontroller-Programmierung ganz und gar unerwünschte Auswirkungen haben. Z.B. könnte ein Stack-Überlauf entstehen, weil an ein Unterprogramm zusätzliche Argumente übergeben werden müssen, oder Werte, die in einer einzelnen Verwendung eigentlich Konstanten sein könnten, stehen in Variablen (= mehr RAM-Bedarf, zusätzlicher Initialisierungs-Code).

Somit ist eine Abwägung wichtig, welcher der oben genannten Mechanismen für ein bestimmtes Problem am besten geeignet ist. Handelt es sich bei den parametrisierten Aspekten um Dinge, die bereits zur Kompilierzeit feststehen, sind C-Präprozessor-Makros, C++-Templates oder problemspezifische Programmgeneratoren in der Regel der optimale Weg.

C vs C++

2004-06-03T17:31:12Z

80.129.126.3:

Speziell bei der Verwendung höherer Programmiersprachen ([[HLL]]s) im Bereich der Programmierung von Mikrocontrollern taucht häufig die Frage auf, ob eine Sprache wie [[C-Plusplus|C++]] für "kleinere" Mikroprozessoren nicht einen zu großen Overhead darstelle und ob man nicht besser bei [[C]] (oder gar [[Assembler]]) bleiben solle.

== Beziehung zwischen C und C++ ==
Ursprünglich entstand C++ als Erweiterung zu C (mit minimalen Ausnahmen - Leitlinie: "As close to C as possible, but no closer"). Damit ist C als Teilmenge in C++ enthalten und jedes C-Programm ist zugleich ein C++-Programm, denn es kann auch mit einem C++-Compiler übersetzt werden (nicht aber umgekehrt!!). Da ein weiterer Grundsatz bei der C++-Entwicklung lautete "You only pay for what you use", entsteht in einem Programm, das ausschließlich C-Features benutzt aber mit einem C++-Compiler übersetzt wird, kein prinzipiell bedingter Overhead.

So weit die Theorie.

== C++ Performance Fußangeln ==
Allerdings waren die Zielsysteme bei der Weiterentwicklung von C++ in den letzten 20 Jahren in der Regel PCs und leistungsfähige Workstations, was in der Praxis zwei wichtige Konsequenzen hatte:
* Die Sprachsyntax von C++ verschleiert mehr als die von C, womit man sich in einem Programm möglicherweise einen hohen, in der Programmierung von Mikrocontrollern unerwünschten Overhead ohne konkreten Nutzen einhandelt.
* Die tatsächlichen Implementierungen von C++ bemühen sich weniger als die von C, ausführbare Programme (Executables) in der sparsamsten, möglichen Form zu erzeugen.

== Fußangel-Beispiel 1 ==
Mitunter werden beim Einsatz von C++ Programmierrichtlininen angewendet, die im Bereich der Mikrocontrollern-Programmierung unsinnig sind oder zumindest nach anderen Kriterien bewertet werden müssen als im PC- und Workstation-Umfeld.
So führen etwa "vorsorglich angelegte", aber leere Konstruktoren und Destruktoren in der Regel zu vielen Unterprogramm-Sprungbefehlen, an deren Ziel sofort wieder ein Rücksprung steht.

Oder es werden - dem Beispiel von Java oder bestimmten Entwurfsmustern folgend - Objekte in jedem Fall dynamisch angelegt, was das Einbinden komplexer Unterstützungsroutinen für die Speicherverwaltung auslöst und in keinem Fall zu Ergebnissen führt, deren Performance vergleichbar zu einfachen Variablen auf dem Stack oder an festen Adressen ist.

== Fußangel-Beispiel 2 ==
Manchmal wird ein einfaches "hello, world"-Programm in C und eines in C++ auf einem PC kompiliert und die Größe des erzeugten Executables als Kriterium für den Resourcen-Bedarf der jeweiligen Programmiersprache herangezogen. Dieser Vergleich kann sehr in die Irre führen, da die typischen Ausgabe-Anweisungen der Sprachen C und C++ von Bibliotheksfunkionen abgewickelt werden, die aber mit Sicherheit bei der Kompilierung für einen Mikrocontroller ganz anders aussehen (wenn sie dort überhaupt vorhanden sind).

Bei der Strukturierung von unterstützenden Bibliotheksfunktionen wird im PC- und Workstationbereich kaum darauf geachtet, ob einem Minimal-Programm möglicherweise unnötiger Overhead mit hinzugebunden wird. So könnte beispielsweise - obwohl nur eine einfache Zeichenkette ausgegeben wird - durch eine Ausgabeanweisung die Unterstützung für die Ausgabe aller Datentypen inklusive Gleitpunktzahlen angesprochen werden, dies könnte wiederum das Hinzubinden der mathematischen Bibliothek auslösen und - bei Kompilierung für einen Prozessor ohne Hardware-Support für Gleitpunkt-Operationen - einer weiteren Bibliothek zu deren Emulation. Das alles, wie gesagt, obwohl überhaupt keine Gleitpunktzahl in der konkreten Ausgabe vorkommt.

== Vererbung und Aggregation ==
Beide Mechanismen sind aus Sicht der Umsetzung als geschachtelte Strukturen zu verstehen. Eventuelle kleinere Performance-Einbußen könnten durch die fehlende Möglichkeit der Register-Optimierung entstehen, die ein Compiler bei mehreren, nicht zu einer Struktur zusammengefassten Variablen prinzipiell hat. Allerdings sind die Vor- und Nachteile hier in C und C++ die selben, und insofern ist das Thema für einen Vergleich "C vs C++" nicht relevant.

In größeren Programmen überwiegt in aller Regel der Vorteil der besseren Strukturierung durch die Zusammenfassung von Einzelvariablen, insbesondere wenn auch die in C++ vorhandenen Mechanismen zum Zugriffsschutz eingesetzt werden. In kleinen Programmabschnitten mit extrem kritischer Performance kann ggf. eine "Hand-Optimierung" und Auflösung von Strukturen in Einzelvariablen erfolgen (oder gleich eine Re-Implementierung in Assembler).

== Virtuelle Methoden ==
Virtuelle Methoden sind im Grunde genommen Funktionszeiger und insofern überall dort sinnvoll, wo man in einem C-Programm zur Lösung des Problems einen Funktionszeiger eingesetzt hätte (oder in Assembler eine Einsprung-Adresse in Maschinencode hinterlegt oder übergeben hätte).
Werden Methoden in C++ unnötigerweise "virtual" deklariert (mit anderen Worten: steht die Einsprungadresse immer fest und hätte insofern auch der Compiler oder Linker sie bestimmen können), so ist der Overhead natürlich unnötig - aber auch leicht vermeidbar, indem man solche Methoden eben NICHT als "virtual" deklariert.

Dort, wo sinnvoll, also wo virtuelle Methoden tatsächlich ein PROBLEM lösen helfen, sind sie in der Regel eleganter und programmiertechnisch einfacher zu handhaben als explizite Funktionszeiger.

== Interfaces (Abstrakte Basisklassen) ==
Abstrakte Basisklassen sind im Grunde genommen Bündel von Funktionszeiger und ebenso wie virtuelle Methoden genau dort sinnvoll, wo sie ein Problem lösen helfen. Hierzu ein Beispiel: Ein Embedded-System hat eine Verbindung zu einem Host-Rechner zwecks Datenaustausch. Es besteht entweder ein LAN-Zugang oder an der seriellen Schnittstelle hängt ein Modem. Möglicherweise kommt es im laufenden Betrieb auch zu einer Umkonfiguration oder die Hostverbindung fällt komplett aus, dann sollen die Daten in einem lokalen, nicht-flüchtigen Speicher abgelegt werden.

Damit die Applikation nicht alle Eventualitäten an zahlreichen Stellen des Programms verteilt berücksichtigen muss, abstrahiert man den Datenaustausch z.B.
* Verbindung intiieren
* Daten übergeben
* Übernahme bestätigen
* Verbindung abbauen
in einem Interface. Jede der genannten Operationen entspricht dabei einem Zeiger auf ein entsprechendes Unterprogramms (also dessen Einsprungadresse). Tatsächlich implementiert werden diese Unterprogramm mehrfach (einmal für LAN, einmal für Modem, einmal für lokalen Speicher) und der eigentlichen Applikation wird - mehr oder weniger transparent - einfach das passende Funktionszeigerbündel übergeben, jenachdem, welche Art von Host-Verbindung derzeit möglich ist.

Auch hier ist es wieder so, dass ein Interface - realisiert durch eine abstrakte Basisklasse - im Vergleich zu expliziten Funktionszeigern eleganter und programmiertechnisch einfacher ausfällt (sofern man einmal das Prinzip verstanden hat). Eben so gilt, dass abstrakte Basisklassen zu unnötigem Overhead führen, falls man sie "nur mal so" einsetzt, also ohne dass sie, wie oben dagestellt, ein konkretes Problem lösen.

== Execptions (Ausnahmebehandlung) ==
Mit Exceptions lässt sich ein "alternativer Kontrollfluss" in einem Programm definieren, vorzugsweise zur Handhabung von Fehlersituationen oder anderer "außergewöhnlicher Ereignisse". Mit der Einführung von Exceptions musste in C++ aber auch die Leitlinie "You only pay for what you use" verletzt werden. Das heißt es entsteht stets etwas Overhead, wenn der C++-Compiler Exceptions unterstützt, auch für Programme, die Execptions überhaupt nicht benutzen. Aus diesem Grund lassen sich Execptions über Kommandozeilen-Argumente des Compilers oder in den Projekt-Optionen einer Tool-Chain häufig deaktivieren.

== Laufzeit-Typinformation ==
Laufzeit-Typinformation (auch Runtime Type Information oder RTTI genannt), verursacht unter Umständen ebenfalls einen geringen Overhead in C++, auch wenn ein Programm RTTI nicht benutzt. Insofern gilt wie für Execptions, dass man ggf. nach einer Möglichkeit suchen sollte, RTTI ganz abzuschalten, wenn man das Feature nicht braucht. Auf der anderen Seite ist der RTTI-Overhead im Vergleich zu Exceptions sehr gering und entsteht vor allem im Hinblick auf ein wenig zusätzlich benötigten Speicherplatz, nicht in Form unnötig ausgeführter Anweisungen. (Nach Abschalten der RTTI-Unterstützung darf man also kein "schnelleres" Programme erwarten.)

== Templates (Schablonen) ==
Templates sind ein Mechanismus, der zwischen Implementierungs- und Kompilierungs-Zeitpunkt greift. Im Grunde genommen steht mit einer C++-Template "ein bisschen Programmcode" stellvertretend für "möglicherweise sehr viel Programmcode", der aber noch in einem bestimmten Aspekt - einem Datentyp oder eine Konstante - variieren kann. Der allgemeine Teil (Template) wird nur einmalig implementiert und später in mehr oder weniger vielen Varianten kompiliert. (Das am ehesten vergleichbare Äquivalent zu C++-Templates sind in C die Präprozessor-Makros.)

Unter diesem Aspekt betrachtet sind Templates keine Verschwendung (wie manchmal behauptet) sonder sehr sparsam und ideal für Mikrocontroller, da sie im Vergleich zu einer Bibliotheksfunktionen, die quasi "auf Vorrat" viele Varianten berücksichtigen, von denen konkret aber nicht alle genutzt werden, einem Programm nur das hinzufügt, was wirklich benötigt wird.

Auf der anderen Seite sind Templates ein neueres Feature von C++ zu dem bis vor wenigen Jahren auf Seite der Compiler-Lieferanten kaum Erfahrung hinsichtlich der optimalen Umsetzung bestand. Auch in der Fachliteratur werden Templates meist mit viel geringerer Tiefe und weniger Praxisbezug behandelt als diejenigen Features, die schon sehr lange von C++ unterstützt werden (Vererbung usw.). Eine generelle Empfehlung, Templates bei der Verwendung von C++ im Bereich der Mikrocontroller-Programmierung NICHT einzusetzen, ist daraus aber keinesfalls abzuleiten - ganz im Gegenteil: Zur Lösung vieler Probleme sind Templates besser geeignet als etwa Präprozessor-Makros oder gar [[Copy&Paste-Programmierung]].

C++

2004-06-03T13:18:00Z

80.129.126.3:

Umfassende Erweiterung der Programmiersprache [[C]]; kompatibel in der Hinsicht, dass C als Teilmenge in C++ enthalten ist. Dadurch ist C++ ebenso wie C zur hardwarenahen Programmierung geeignet.

(Ein detaillierter Vergleich von C und C++ unter besonderer Berücksichtigung der für die Programmierung von Mikrocontrollern relevanten Aspekte findet sich unter [[C vs C-Plusplus]].)

== Links ==
[http://de.wikipedia.org/wiki/C_Plusplus "C++" bei Wikipedia]

C vs C++

2004-06-03T12:56:10Z

80.129.126.3:

C vs C++

2004-06-03T12:48:06Z

80.129.126.3:

Speziell bei der Verwendung höherer Programmiersprachen ([[HLL]]s) im Bereich der Programmierung von Mikrocontrollern taucht häufig die Frage auf, ob eine Sprache wie [[C-Plusplus|C++]] für "kleinere" Mikroprozessoren nicht einen zu großen Overhead darstelle und ob man nicht besser bei [[C]] (oder gar [[Assembler]]) bleiben solle.

== Beziehung zwischen C und C++ ==
Ursprünglich entstand C++ als Erweiterung zu C (mit minimalen Ausnahmen - Leitlinie: "As close to C as possible, but no closer"). Damit ist C als Teilmenge in C++ enthalten und jedes C-Programm ist zugleich ein C++-Programm, denn es kann auch mit einem C++-Compiler übersetzt werden (nicht aber umgekehrt!!). Da ein weiterer Grundsatz bei der C++-Entwicklung lautete "You only pay for what you use", entsteht in einem Programm, das ausschließlich C-Features benutzt aber mit einem C++-Compiler übersetzt wird, kein prinzipiell bedingter Overhead.

So weit die Theorie.

== C++ Performance Fußangeln ==
Allerdings waren die Zielsysteme bei der Weiterentwicklung von C++ in den letzten 20 Jahren in der Regel PCs und leistungsfähige Workstations, was in der Praxis zwei wichtige Konsequenzen hatte:
* Die Sprachsyntax von C++ verschleiert mehr als die von C, womit man sich in einem Programm möglicherweise einen hohen, in der Programmierung von Mikrocontrollern unerwünschten Overhead ohne konkreten Nutzen einhandelt.
* Die tatsächlichen Implementierungen von C++ bemühen sich weniger als die von C, ausführbare Programme (Executables) in der sparsamsten, möglichen Form zu erzeugen.

== Fußangel-Beispiel 1 ==
Mitunter werden beim Einsatz von C++ Programmierrichtlininen angewendet, die im Bereich der Mikrocontrollern-Programmierung unsinnig sind oder zumindest nach anderen Kriterien bewertet werden müssen als im PC- und Workstation-Umfeld.
So führen etwa "vorsorglich angelegte", aber leere Konstruktoren und Destruktoren in der Regel zu vielen Unterprogramm-Sprungbefehlen, an deren Ziel sofort wieder ein Rücksprung steht.

Oder es werden - dem Beispiel von Java oder bestimmten Entwurfsmustern folgend - Objekte in jedem Fall dynamisch angelegt, was das Einbinden komplexer Unterstützungsroutinen für die Speicherverwaltung auslöst und in keinem Fall zu Ergebnissen führt, deren Performance vergleichbar zu einfachen Variablen auf dem Stack oder an festen Adressen ist.

== Fußangel-Beispiel 2 ==
Manchmal wird ein einfaches "hello, world"-Programm in C und eines in C++ auf einem PC kompiliert und die Größe des erzeugten Executables als Kriterium für den Resourcen-Bedarf der jeweiligen Programmiersprache herangezogen. Dieser Vergleich kann sehr in die Irre führen, da die typischen Ausgabe-Anweisungen der Sprachen C und C++ von Bibliotheksfunkionen abgewickelt werden, die aber mit Sicherheit bei der Kompilierung für einen Mikrocontroller ganz anders aussehen (wenn sie dort überhaupt vorhanden sind).

Bei der Strukturierung von unterstützenden Bibliotheksfunktionen wird im PC- und Workstationbereich kaum darauf geachtet, ob einem Minimal-Programm möglicherweise unnötiger Overhead mit hinzugebunden wird. So könnte beispielsweise - obwohl nur eine einfache Zeichenkette ausgegeben wird - durch eine Ausgabeanweisung die Unterstützung für die Ausgabe aller Datentypen inklusive Gleitpunktzahlen angesprochen werden, dies könnte wiederum das Hinzubinden der mathematischen Bibliothek auslösen und - bei Kompilierung für einen Prozessor ohne Hardware-Support für Gleitpunkt-Operationen - einer weiteren Bibliothek zu deren Emulation. Das alles, wie gesagt, obwohl überhaupt keine Gleitpunktzahl in der konkreten Ausgabe vorkommt.

== Vererbung und Aggregation ==
Beide Mechanismen sind aus Sicht der Umsetzung als geschachtelte Strukturen zu verstehen. Eventuelle kleinere Performance-Einbußen könnten durch die fehlende Möglichkeit der Register-Optimierung entstehen, die ein Compiler bei mehreren, nicht zu einer Struktur zusammengefassten Variablen prinzipiell hat. Allerdings sind die Vor- und Nachteile hier in C und C++ die selben, und insofern ist das Thema für einen Vergleich "C vs C++" nicht relevant.

In größeren Programmen überwiegt in aller Regel der Vorteil der besseren Strukturierung durch die Zusammenfassung von Einzelvariablen, insbesondere wenn auch die in C++ vorhandenen Mechanismen zum Zugriffsschutz eingesetzt werden. In kleinen Programmabschnitten mit extrem kritischer Performance kann ggf. eine "Hand-Optimierung" und Auflösung von Strukturen in Einzelvariablen erfolgen (oder gleich eine Re-Implementierung in Assembler).

== Virtuelle Methoden ==
Virtuelle Methoden sind im Grunde genommen Funktionszeiger und insofern überall dort sinnvoll, wo man in einem C-Programm zur Lösung des Problems einen Funktionszeiger eingesetzt hätte (oder in Assembler eine Einsprung-Adresse in Maschinencode hinterlegt oder übergeben hätte).
Werden Methoden in C++ unnötigerweise "virtual" deklariert (mit anderen Worten: steht die Einsprungadresse immer fest und hätte insofern auch der Compiler oder Linker sie bestimmen können), so ist der Overhead natürlich unnötig - aber auch leicht vermeidbar, indem man solche Methoden eben NICHT als "virtual" deklariert.

Dort, wo sinnvoll, also wo virtuelle Methoden tatsächlich ein PROBLEM lösen helfen, sind sie in der Regel eleganter und programmiertechnisch einfacher zu handhaben als explizite Funktionszeiger.

== Interfaces (Abstrakte Basisklassen) ==
Abstrakte Basisklassen sind im Grunde genommen Bündel von Funktionszeiger und ebenso wie virtuelle Methoden genau dort sinnvoll, wo sie ein Problem lösen helfen. Hierzu ein Beispiel: Ein Embedded-System hat eine Verbindung zu einem Host-Rechner zwecks Datenaustausch. Es besteht entweder ein LAN-Zugang oder an der seriellen Schnittstelle hängt ein Modem. Möglicherweise kommt es im laufenden Betrieb auch zu einer Umkonfiguration oder die Hostverbindung fällt komplett aus, dann sollen die Daten in einem lokalen, nicht-flüchtigen Speicher abgelegt werden.

Damit die Applikation nicht alle Eventualitäten an zahlreichen Stellen des Programms verteilt berücksichtigen muss, abstrahiert man den Datenaustausch z.B.
* Verbindung intiieren
* Daten übergeben
* Übernahme bestätigen
* Verbindung abbauen
in einem Interface. Jede der genannten Operationen entspricht dabei einem Zeiger auf ein entsprechendes Unterprogramms (also dessen Einsprungadresse). Tatsächlich implementiert werden diese Unterprogramm mehrfach (einmal für LAN, einmal für Modem, einmal für lokalen Speicher) und der eigentlichen Applikation wird - mehr oder weniger transparent - einfach das passende Funktionszeigerbündel übergeben, jenachdem, welche Art von Host-Verbindung derzeit möglich ist.

Auch hier ist es wieder so, dass ein Interface - realisiert durch eine abstrakte Basisklasse - im Vergleich zu expliziten Funktionszeigern eleganter und programmiertechnisch einfacher ausfällt (sofern man einmal das Prinzip verstanden hat). Eben so gilt, dass abstrakte Basisklassen zu unnötigem Overhead führen, falls man sie "nur mal so" einsetzt, also ohne dass sie, wie oben dagestellt, ein konkretes Problem lösen.

== Execptions (Ausnahmebehandlung) ==
Mit Exceptions lässt sich ein "altervativer Kontrollfluss" in einem Programm definieren, vorzugsweise zur Handhabung von Fehlersituationen oder anderer "außergewöhnlicher Ereignisse". Mit der Einführung von Exceptions musste in C++ aber auch die Leitlinie "You only pay for what you use" verletzt werden. Das heißt es entsteht stets etwas Overhead, wenn der C++-Compiler Exceptions unterstützt, auch für Programme, die Execptions überhaupt nicht benutzen. Aus diesem Grund lassen sich Execptions über Kommandozeilen-Argumente des Compilers oder in den Projekt-Optionen einer Tool-Chain häufig deaktivieren.

== Laufzeit-Typinformation ==
Laufzeit-Typinformation (auch Runtime Type Information oder RTTI genannt), verursacht unter Umständen ebenfalls einen geringen Overhead in C++, auch wenn ein Programm RTTI nicht benutzt. Insofern gilt wie für Execptions, dass man ggf. nach einer Möglichkeit suchen sollte, RTTI ganz abzuschalten, wenn man das Feature nicht braucht. Auf der anderen Seite ist der RTTI-Overhead im Vergleich zu Exceptions sehr gering und entsteht vor allem im Hinblick auf ein wenig zusätzlich benötigten Speicherplatz, nicht in Form unnötig ausgeführter Anweisungen. (Nach Abschalten der RTTI-Unterstützung darf man also kein "schnelleres" Programme erwarten.)

== Templates (Schablonen) ==
Templates sind ein Mechanismus, der zwischen Implementierungs- und Kompilierungs-Zeitpunkt greift. Im Grunde genommen steht mit einer C++-Template "ein bisschen Programmcode" stellvertretend für "möglicherweise sehr viel Programmcode", der aber noch in einem bestimmten Aspekt - einem Datentyp oder eine Konstante - variieren kann. Der allgemeine Teil (Template) wird nur einmalig implementiert und später in mehr oder weniger vielen Varianten kompiliert. (Das am ehesten vergleichbare Äquivalent zu C++-Templates sind in C die Präprozessor-Makros.)

Unter diesem Aspekt betrachtet sind Templates keine Verschwendung (wie manchmal behauptet) sonder sehr sparsam und ideal für Mikrocontroller, da sie im Vergleich zu einer Bibliotheksfunktionen, die quasi "auf Vorrat" viele Varianten berücksichtigen, von denen konkret aber nicht alle genutzt werden, einem Programm nur das hinzufügt, was wirklich benötigt wird.

Auf der anderen Seite sind Templates ein neueres Feature von C++ zu dem bis vor wenigen Jahren auf Seite der Compiler-Lieferanten kaum Erfahrung hinsichtlich der optimalen Umsetzung bestand. Auch in der Fachliteratur werden Templates meist mit viel geringerer Tiefe und weniger Praxisbezug behandelt als diejenigen Features, die schon sehr lange von C++ unterstützt werden (Vererbung usw.). Eine generelle Empfehlung, Templates bei der Verwendung von C++ im Bereich der Mikrocontroller-Programmierung NICHT einzusetzen, ist daraus aber keinesfalls abzuleiten - ganz im Gegenteil: Zur Lösung vieler Probleme sind Templates besser geeignet als etwa Präprozessor-Makros oder gar "Copy&Paste"-Programmierung.

HLL

2004-06-03T10:49:21Z

80.129.126.3:

HLL steht für "High Level Language", also "Höhere Programmiersprache".

Vorweg:
Die "richtige" oder gar "beste" (höhere) Programmiersprache gibt es nicht! Wer in Diskussionsforen danach fragt, wird regelmäßig religiöse Kriege auslösen.
(Wer seine persönliche Lieblingssprache schon gefunden hat, kann sich den Rest dieses Beitrags schenken, insbesondere dann, wenn diese Sprache für den in seinem Projekt verwendeten Prozessor auch verfügbar ist.)

== Assembler und HLLs ==
Anders als Assembler sind höhere Programmiersprachen in aller Regel nicht an einer bestimmten Hardware-Architektur ausgerichtet sondern verfolgen andere Ziele, wie etwa leichte Erlernbarkeit, Standardisierung, Abfangen bestimmter, "typischer" Programmierfehler usw. Höhere Programmiersprachen erfordern dabei ein Hilfsprogramm, "Compiler" genannt, welches den endgültigen Maschinencode für eine bestimmte Hardware generiert. Im Bereich der Mikrocontroller-Programmierung wird der Compiler typischerweise ein "Cross-Compiler sein", also auf einem anderen System (i.d.R. einem PC) laufen als das System, für welches Maschinencode erzeugt wird.

== Kompilierung ==
Die Kompilierung ist zwar in aller Regel sehr viel aufwändiger als die Assemblierung (d.h. die Umsetzung der mnemonischen Abkürzungen eines Assembler-Programms in die "Bits und Bytes", die schließlich vom Mikrocontroller als Programm ausgeführt werden), bietet aber auch einen wesentlichen Vorteil: Dadurch, dass man lediglich den Compiler austauscht, lässt sich ein und dasselbe Programm für sehr unterschiedliche Zielsysteme kompilieren. In höheren Programmiersprachen geschriebene Programme sind somit leichter portierbar, eine einmal - in Form von Software-Entwicklung - getätigte Investition ist in einem sehr viel größeren Rahmen nutzbar (= Anzahl der möglichen Zielplattformen über unterschiedliche Architekturen und/oder lange Zeiträume hinweg betrachtet).

== Vorurteile ==
Der Einsatz höherer Programmiersprachen im Bereich von Mikrocontrollern (= Embedded Programmierung) unterlag lange Zeit genau den selben Vorurteilen, die höheren Programmiersprachen vor ihrem Einzug in die Großrechnerwelt vor rund 30 Jahren entgegengebracht wurden: Zu ineffizient, zu speicherfressend, niemals als "Ersatz" für Assembler geeignet. Das war zumindest noch um 1990 herum die Meinung vieler "Experten" im hardwarenahen Bereich.

== C ==
Vor etwas mehr als 10 Jahren setzte dann - zuerst bei leistungsfähigen Mikrocontrollern - ein Umdenken ein und die Programmiersprache [[C]] fand im embedded Bereich zunehmend Verbreitung. C ist heute für die meisten der größeren Mikrocontroller verfügbar und passt insofern recht gut zu Mikrocontrollern, als diese Sprache ursprünglich (Mitte der 1970er) entworfen wurde, um die Verwendung von Assembler bei der Implementierung des Unix-Betriebssystemkerns vermeiden zu können. Im Unterschied zu vielen anderen höheren Programmiersprachen ist daher in C der direkte Hardware-Zugriff kaum eingeschränkt.

== C++ ==
Mit der ständig zunehmenden Leistungsfähigkeit moderner Mikrocontroller und entsprechend komplexer werdender Software ist heute auch ein Trend zum Einsatz von [[C-Plusplus|C++]] auf Mikrocontrollern zu beobachten. Bei C++ handelt es sich um eine (Anfang der 1980er entstandene) Erweiterung von C. Die über C hinausgehenden Teile von C++ liegen überwiegend im Bereich der "Objektorientierten Programmierung" ([[OOP]]), die heute als eines der vielversprechendsten Vorgehensmodelle zur Beherrschung komplexer Software-Architekturen gilt.

== Basic, Pascal, ... ==
Darüberhinaus liefern die Anbieter einiger Controller z.B. auch Basic- oder Pascal-Compiler. Da für deren Nutzung im Bereich der Mikrocontroller-Programmierung der Standard-Umfang dieser Sprachen stets erheblich erweitert werden muss, spielen sie hauptsächlich für Hobbyprogrammierer oder sehr spezialisierte Entwicklungen eine Rolle. Das ansonsten in der Regel angestrebte Ziel einer verbesserten Portierbarkeit und Wiederverwendung von Software(-teilen) ist nicht annäherend in dem Maße zu erreichen wie mit C/C++.

== Standardisierung ==
Da eines der wesentlichen Ziele beim Einsatz höherer Programmiersprachen der Investitionsschutz ist - Software(-teile) sollen leicht wiederverwendbar sein - ist eine Standardisierung wichtig. Diese sollte vorzugsweise durch unabhängige Gremien erfolgen und nicht als "de-facto"-Standard von einigen Anbietern für Compiler oder Tool-Chains, da ansonsten wiederum leicht eine Abhängigkeit von wenigen, marktbeherrschenden Firmen entstehen könnte.

== ISO/ANSI-C ==
Seit 1989 gibt es für C einen ISO/ANSI-Standard, der 1999 nochmal geringfügig überarbeitet wurde. Spezielle, über diesen Standard-Sprachumfang hinausgehende Erweiterungen sind für den Mikrocontroller-Bereich nicht erforderlich. Man kann in C z.B. freizügig auf Speicheradressen und damit ohne Umwege direkt auf die Hardware, also Ports und andere Peripherie zugreifen. (Lediglich Interrupts, Einzelbitadressierung und I/O über spezielle Maschinenbefehle erfordern proprietäre Unterstützung des Compilers.) In C geschriebene Software ist damit vergleichsweise einfach - ganz oder in Teilen - auf andere Prozessoren portierbar.

== ISO/ANSI-C++ ==
Auch für C++ gibt es seit 1999 einen ISO/ANSI-Standard, womit C++ im Hinblick auf Portierbarkeit ähnliche Vorteile hat wie C. Bei der Weiterentwicklung und Standardisierung von C++ war eines der Ziele "You only pay for what you use", was auch weitgehend erreicht wurde (Ausnahme: Exceptions).
Andererseits enthält der C++-Standard eine Vielzahl sehr komplexer Features, die zumindest 1999 noch kein Compiler vollständig implementiert hatte.
Auch heute sind Compiler, die C++ gemäß der vollen ISO/ANSI-Spezifikation bieten, für Mikrocontroller noch rar, aber die "Lücken" hinsichtlich der Implementierung des Standard-Sprachumfangs werden ständig kleiner.

== EC++ ==
Mittels einer Hersteller-Initiative im Mikrocontroller-Bereich wurde dem sehr komplexen ISO/ANSI-Standard für C++ eine "abgespeckte" Variante nachgeschoben, "EC++" genannt (= embedded C++). Dieser enthält im Wesentlichen die "langjährig erprobten" Sprachfeatures von C++. Compiler, welche den EC++-Sprachumfang bieten, sind für die meisten der etwas größeren Mikrocontroller verfügbar.
Einige Compiler bieten darüberhinaus Mischformen zwischen ISO/ANSI-C++ und EC++ und erlauben beispielsweise das Ein-/Ausschalten bestimmter Sprachfeatures in der projektspezifischen Konfiguration. (So lassen sich etwa Exceptions - und der damit unvermeidlich einhergehende Overhead - ausschalten, wenn dieses Feature in einem Projekt nicht benötigt wird.)

== Vergleiche ==
Um zu entscheiden, welcher Programmiersprache in welchem Fall der Vorzug gegeben werden sollte, kann auch der direkte Vergleich eine Hilfe sein.

== Assembler vs. C (siehe auch: [[ASM vs C]]) ==
Keine Frage: Bei intimer Kenntnis einer Hardware-Architektur und der zugehörigen Maschinensprache wird eine Assembler-Expertin oder ein Assembler-Experte den von einem Compiler aufgrund eines C-Quelltextes erzeugten Code i.d.R. schlagen - oft allerdings nur marginal im Bereich einiger weniger Prozent. So wichtig diese paar letzten Taktzyklen auch in einer zeitkritischen Interrupt-Routine sein mögen, so sehr kommt bei umfangreicheren Projekten die Tatsache ins Spiel, dass eine einzelne Person kaum den Überblick über das gesamte Programm haben wird. Damit ist ein Compiler in einer sehr viel besseren Position, Heuristiken und andere Techniken anzuwenden, so dass das Kompilier-Ergebnis in der Qualität "lokal hand-optimiertem" Code nicht nachstehen muss sondern diesen sogar in der Summe häufig übertreffen wird.

Im Übrigen ist es auch beim Einsatz von C nützlich und hilfreich, gewisse Grundlagenkenntnisse hinsichtlich die Architektur des verwendeten Mikrocontrollers zu besitzen und insbesondere zu verstehen, wie die Konstruktionen der Hochsprache C schließlich in Maschinensprache abgebildet werden.

== C vs. C++ (siehe auch: [[C vs C-Plusplus]]) ==
Da C quasi als "Teilmenge" in C++ enthalten ist, sollte sich jedes C-Programm auch mit einem C++-Compiler übersetzen lassen und gemäß dem oben zitierten Leitsatz ("You only pay for what you use") sollte der erzeugte Machinencode in diesem Fall nicht aufwändiger sein als bei der Übersetzung mit einem C-Compiler. Dies ist tatsächlich so - auch in C++ geschriebene Programm sind nicht grundsätzlich "ineffizienter" als reine C-Programme. Das gilt um so mehr, als viele Projekte, die "offiziell" in C++ abgewickelt werden, diese Sprache nur als "besseres" C nutzen, also viele der in C++ möglichen Konstruktionen überhaupt nicht verwenden.

Mit zunehmender Nutzung der über C hinausgehenden Erweiterungen von C++ sollten die Beteiligten allerdings auch ein TIEFES Verständnis dafür besitzen,
wie C++ in C abgebildet wird. Ansonsten werden - letzten Endes aus Unkenntnis - leicht Programme entstehen, die deutlich weniger performant sind oder mehr (Speicher-) Ressourcen benötigen als äquivalenter C-Code. Es wäre allerdings falsch, diesen Effekt dann der Verwendung von C++ zuzuschreiben ...

== EC++ vs. ISO/ANSI-C++ ==
Dem EC++-Standard ist es einerseits gelungen, einen sofort umsetzbaren C++-Standard für die Embedded-Programmierung zu definieren, lange bevor C++-Compilern die Marktreife erreicht haben, die den ISO/ANSI-Standard voll implementieren. An der langfristigen Bedeutung des EC++-Standards müssen allerdings Zweifel angemeldet werden. Zwar mag das Ausklammern von Exceptions und die damit verbundenen Einsparungen für Programme, die Exceptions überhaupt nicht benutzen, noch längere Zeit interessant sein. Das Fehlen von Templates nimmt aber wesentliche und gerade im Bereich der Embedded-Programmierung nützlich erscheinende Freiheitsgrade, wenn es um die Code-Konfiguration zwischen Implementierungs- und Kompilierungs-Zeitpunkt geht.

== C/C++ vs. Code-Generatoren ==
Auch wenn wie hier dargestellt C (schon heute) und C++ (vielleicht morgen) die dominierenden höheren Programmiersprachen bei allen größeren Projekten sind, in denen Mikrocontroller zum Einsatz kommen, sollte man Alternativen kennen und abwägen können. Hierzu gehören beispielsweise problemspezifisch entworfene "Little Languages" (oft relativ simple, interpretierte Datenstrukturen, evtl. unterstützt durch C-Makros) oder durch Code-Generatoren erzeugte Programmteile. Für in einigen Domänen häufig wiederkehrende Aufgabenstellung - etwa UI/GUI (= User Interface / Graphical User Interface), Realisierung von FSMs (= Finite State Machines) u.ä. - stellen solche Ansätze oft die in jeglicher Hinsicht effizienteste Vorgehensweise dar.

HLL

2004-06-03T10:37:10Z

80.129.126.3:

HLL steht für "High Level Language", also "Höhere Programmiersprache".

Vorweg:
Die "richtige" oder gar "beste" (höhere) Programmiersprache gibt es nicht! Wer in Diskussionsforen danach fragt, wird regelmäßig religiöse Kriege auslösen.
(Wer seine persönliche Lieblingssprache schon gefunden hat, kann sich den Rest dieses Beitrags schenken, insbesondere dann, wenn diese Sprache für den in seinem Projekt verwendeten Prozessor auch verfügbar ist.)

== Assembler und HLLs ==
Anders als Assembler sind höhere Programmiersprachen in aller Regel nicht an einer bestimmten Hardware-Architektur ausgerichtet sondern verfolgen andere Ziele, wie etwa leichte Erlernbarkeit, Standardisierung, Abfangen bestimmter, "typischer" Programmierfehler usw. Höhere Programmiersprachen erfordern dabei ein Hilfsprogramm, "Compiler" genannt, welches den endgültigen Maschinencode für eine bestimmte Hardware generiert. Im Bereich der Mikrocontroller-Programmierung wird der Compiler typischerweise ein "Cross-Compiler sein", also auf einem anderen System (i.d.R. einem PC) laufen als das System, für welches Maschinencode erzeugt wird.

== Kompilierung ==
Die Kompilierung ist zwar in aller Regel sehr viel aufwändiger als die Assemblierung (d.h. die Umsetzung der mnemonischen Abkürzungen eines Assembler-Programms in die "Bits und Bytes", die schließlich vom Mikrocontroller als Programm ausgeführt werden), bietet aber auch einen wesentlichen Vorteil: Dadurch, dass man lediglich den Compiler austauscht, lässt sich ein und dasselbe Programm für sehr unterschiedliche Zielsysteme kompilieren. In höheren Programmiersprachen geschriebene Programme sind somit leichter portierbar, eine einmal - in Form von Software-Entwicklung - getätigte Investition ist in einem sehr viel größeren Rahmen nutzbar (= Anzahl der möglichen Zielplattformen über unterschiedliche Architekturen und/oder lange Zeiträume hinweg betrachtet).

== Vorurteile ==
Der Einsatz höherer Programmiersprachen im Bereich von Mikrocontrollern (= Embedded Programmierung) unterlag lange Zeit genau den selben Vorurteilen, die höheren Programmiersprachen vor ihrem Einzug in die Großrechnerwelt vor rund 30 Jahren entgegengebracht wurden: Zu ineffizient, zu speicherfressend, niemals als "Ersatz" für Assembler geeignet. Das war zumindest noch um 1990 herum die Meinung vieler "Experten" im hardwarenahen Bereich.

== C ==
Vor etwas mehr als 10 Jahren setzte dann - zuerst bei leistungsfähigen Mikrocontrollern - ein Umdenken ein und die Programmiersprache [[C]] fand im embedded Bereich zunehmend Verbreitung. C ist heute für die meisten der größeren Mikrocontroller verfügbar und passt insofern recht gut zu Mikrocontrollern, als diese Sprache ursprünglich (Mitte der 1970er) entworfen wurde, um die Verwendung von Assembler bei der Implementierung des Unix-Betriebssystemkerns vermeiden zu können. Im Unterschied zu vielen anderen höheren Programmiersprachen ist daher in C der direkte Hardware-Zugriff kaum eingeschränkt.

== C++ ==
Mit der ständig zunehmenden Leistungsfähigkeit moderner Mikrocontroller und entsprechend komplexer werdender Software ist heute auch ein Trend zum Einsatz von [[C-Plusplus|C++]] auf Mikrocontrollern zu beobachten. Bei C++ handelt es sich um eine (Anfang der 1980er entstandene) Erweiterung von C. Die über C hinausgehenden Teile von C++ liegen überwiegend im Bereich der "Objektorientierten Programmierung" ([[OOP]]), die heute als eines der vielversprechendsten Vorgehensmodelle zur Beherrschung komplexer Software-Architekturen gilt.

== Basic, Pascal, ... ==
Darüberhinaus liefern die Anbieter einiger Controller z.B. auch Basic- oder Pascal-Compiler. Da für deren Nutzung im Bereich der Mikrocontroller-Programmierung der Standard-Umfang dieser Sprachen stets erheblich erweitert werden muss, spielen sie hauptsächlich für Hobbyprogrammierer oder sehr spezialisierte Entwicklungen eine Rolle. Das ansonsten in der Regel angestrebte Ziel einer verbesserten Portierbarkeit und Wiederverwendung von Software(-teilen) ist nicht annäherend in dem Maße zu erreichen wie mit C/C++.

== Standardisierung ==
Da eines der wesentlichen Ziele beim Einsatz höherer Programmiersprachen der Investitionsschutz ist - Software(-teile) sollen leicht wiederverwendbar sein - ist eine Standardisierung wichtig. Diese sollte vorzugsweise durch unabhängige Gremien erfolgen und nicht als "de-facto"-Standard von einigen Anbietern für Compiler oder Tool-Chains, da ansonsten wiederum leicht eine Abhängigkeit von wenigen, marktbeherrschenden Firmen entstehen könnte.

== ISO/ANSI-C ==
Seit 1989 gibt es für C einen ISO/ANSI-Standard, der 1999 nochmal geringfügig überarbeitet wurde. Spezielle, über diesen Standard-Sprachumfang hinausgehende Erweiterungen sind für den Mikrocontroller-Bereich nicht erforderlich. Man kann in C z.B. freizügig auf Speicheradressen und damit ohne Umwege direkt auf die Hardware, also Ports und andere Peripherie zugreifen. (Lediglich Interrupts, Einzelbitadressierung und I/O über spezielle Maschinenbefehle erfordern proprietäre Unterstützung des Compilers.) In C geschriebene Software ist damit vergleichsweise einfach - ganz oder in Teilen - auf andere Prozessoren portierbar.

== ISO/ANSI-C++ ==
Auch für C++ gibt es seit 1999 einen ISO/ANSI-Standard, womit C++ im Hinblick auf Portierbarkeit ähnliche Vorteile hat wie C. Bei der Weiterentwicklung und Standardisierung von C++ war eines der Ziele "You only pay for what you use", was auch weitgehend erreicht wurde (Ausnahme: Exceptions).
Andererseits enthält der C++-Standard eine Vielzahl sehr komplexer Features, die zumindest 1999 noch kein Compiler vollständig implementiert hatte.
Auch heute sind Compiler, die C++ gemäß der vollen ISO/ANSI-Spezifikation bieten, für Mikrocontroller noch rar, aber die "Lücken" hinsichtlich der Implementierung des Standard-Sprachumfangs werden ständig kleiner.

== EC++ ==
Mittels einer Hersteller-Initiative im Mikrocontroller-Bereich wurde dem sehr komplexen ISO/ANSI-Standard für C++ eine "abgespeckte" Variante nachgeschoben, "EC++" genannt (= embedded C++). Dieser enthält im Wesentlichen die "langjährig erprobten" Sprachfeatures von C++. Compiler, welche den EC++-Sprachumfang bieten, sind für die meisten der etwas größeren Mikrocontroller verfügbar.
Einige Compiler bieten darüberhinaus Mischformen zwischen ISO/ANSI-C++ und EC++ und erlauben beispielsweise das Ein-/Ausschalten bestimmter Sprachfeatures in der projektspezifischen Konfiguration. (So lassen sich etwa Exceptions - und der damit unvermeidlich einhergehende Overhead - ausschalten, wenn dieses Feature in einem Projekt nicht benötigt wird.)

== Vergleiche ==
Um zu entscheiden, welcher Programmiersprache in welchem Fall der Vorzug gegeben werden sollte, kann auch der direkte Vergleich eine Hilfe sein.

== Assembler vs. C ==
Keine Frage: Bei intimer Kenntnis einer Hardware-Architektur und der zugehörigen Maschinensprache wird eine Assembler-Expertin oder ein Assembler-Experte den von einem Compiler aufgrund eines C-Quelltextes erzeugten Code i.d.R. schlagen - oft allerdings nur marginal im Bereich einiger weniger Prozent. So wichtig diese paar letzten Taktzyklen auch in einer zeitkritischen Interrupt-Routine sein mögen, so sehr kommt bei umfangreicheren Projekten die Tatsache ins Spiel, dass eine einzelne Person kaum den Überblick über das gesamte Programm haben wird. Damit ist ein Compiler in einer sehr viel besseren Position, Heuristiken und andere Techniken anzuwenden, so dass das Kompilier-Ergebnis in der Qualität "lokal hand-optimiertem" Code nicht nachstehen muss sondern diesen sogar in der Summe häufig übertreffen wird.

Im Übrigen ist es auch beim Einsatz von C nützlich und hilfreich, gewisse Grundlagenkenntnisse hinsichtlich die Architektur des verwendeten Mikrocontrollers zu besitzen und insbesondere zu verstehen, wie die Konstruktionen der Hochsprache C schließlich in Maschinensprache abgebildet werden.

== C vs. C++ ==
Da C quasi als "Teilmenge" in C++ enthalten ist, sollte sich jedes C-Programm auch mit einem C++-Compiler übersetzen lassen und gemäß dem oben zitierten Leitsatz ("You only pay for what you use") sollte der erzeugte Machinencode in diesem Fall nicht aufwändiger sein als bei der Übersetzung mit einem C-Compiler. Dies ist tatsächlich so - auch in C++ geschriebene Programm sind nicht grundsätzlich "ineffizienter" als reine C-Programme. Das gilt um so mehr, als viele Projekte, die "offiziell" in C++ abgewickelt werden, diese Sprache nur als "besseres" C nutzen, also viele der in C++ möglichen Konstruktionen überhaupt nicht verwenden.

Mit zunehmender Nutzung der über C hinausgehenden Erweiterungen von C++ sollten die Beteiligten allerdings auch ein TIEFES Verständnis dafür besitzen,
wie C++ in C abgebildet wird. Ansonsten werden - letzten Endes aus Unkenntnis - leicht Programme entstehen, die deutlich weniger performant sind oder mehr (Speicher-) Ressourcen benötigen als äquivalenter C-Code. Es wäre allerdings falsch, diesen Effekt dann der Verwendung von C++ zuzuschreiben ...

== EC++ vs. ISO/ANSI-C++ ==
Dem EC++-Standard ist es einerseits gelungen, einen sofort umsetzbaren C++-Standard für die Embedded-Programmierung zu definieren, lange bevor C++-Compilern die Marktreife erreicht haben, die den ISO/ANSI-Standard voll implementieren. An der langfristigen Bedeutung des EC++-Standards müssen allerdings Zweifel angemeldet werden. Zwar mag das Ausklammern von Exceptions und die damit verbundenen Einsparungen für Programme, die Exceptions überhaupt nicht benutzen, noch längere Zeit interessant sein. Das Fehlen von Templates nimmt aber wesentliche und gerade im Bereich der Embedded-Programmierung nützlich erscheinende Freiheitsgrade, wenn es um die Code-Konfiguration zwischen Implementierungs- und Kompilierungs-Zeitpunkt geht.

== C/C++ vs. Code-Generatoren ==
Auch wenn wie hier dargestellt C (schon heute) und C++ (vielleicht morgen) die dominierenden höheren Programmiersprachen bei allen größeren Projekten sind, in denen Mikrocontroller zum Einsatz kommen, sollte man Alternativen kennen und abwägen können. Hierzu gehören beispielsweise problemspezifisch entworfene "Little Languages" (oft relativ simple, interpretierte Datenstrukturen, evtl. unterstützt durch C-Makros) oder durch Code-Generatoren erzeugte Programmteile. Für in einigen Domänen häufig wiederkehrende Aufgabenstellung - etwa UI/GUI (= User Interface / Graphical User Interface), Realisierung von FSMs (= Finite State Machines) u.ä. - stellen solche Ansätze oft die in jeglicher Hinsicht effizienteste Vorgehensweise dar.

C++

2004-06-03T10:32:49Z

80.129.126.3:

Umfassende Erweiterung der Programmiersprache [[C]]; kompatibel in der Hinsicht, dass C als Teilmenge in C++ enthalten ist. Dadurch ist C++ ebenso wie wie C zur hardwarenahen Programmierung geeignet.

== Links ==
[http://de.wikipedia.org/wiki/C_Plusplus "C++" bei Wikipedia]

Entscheidung Mikrocontroller

2004-06-03T10:21:00Z

80.129.126.3:

Die meisten Anfänger stellen sich die Frage, welchen [[Mikrocontroller]] sie verwenden sollen. Es gibt dutzende Hersteller, und jeder davon hat unzählige Varianten im Angebot. Stellt man die Frage in einem Diskussionsforum, dann bekommt man viele verschiedene (sich teilweise widersprechende) Antworten. Bei der Entscheidung sollten u.a. folgende Kriterien beachtet werden:

== Verfügbarkeit ==
* Während man manche Mikrocontroller an jeder Straßenecke bekommt, sind andere nur in großen Stückzahlen und mit Gewerbenachweis erhältlich.
* Ab und zu kündigen Hersteller ein neues Modell an (und veröffentichen das Datenblatt dazu), können aber erst ein Jahr später nennenswerte Stückzahlen liefern.
* Lebenszyklus: Kein Modell wird ewig hergestellt, deswegen sollte man überprüfen, ob der Hersteller vielleicht schon angekündigt hat, dass er ein bestimmtes Modell nicht mehr herstellen will. Für Neuentwicklungen oder den Einstieg sollte man folgende Modelle nicht verwenden:
** AVR AT90-Reihe,
** AVR ATMega 103(L), 161(L), 163(L), 323(L).

== Preis ==
Mikrocontroller: Einerseits kann es lästig sein, wenn man durch die Verwendung eines kleineren Modells 2¤ gespart hat und dann mit dessen Unzulänglichkeiten kämpft, andererseits ist ein versehentlich zerstörter Chip für 30¤ ziemlich ärgerlich. Auch ist es oft ganz praktisch, wenn man einige Controller auf Vorrat hat.

Zum Preis eines einzelnen Mikrocontrollers kommen noch die Kosten für die Programmiersprache und die Programmübertragung hinzu (s.u.).

== Bauformen ==
Neben den klassischen (bedrahteten) Bauformen setzt sich heutzutage [[SMD]] immer mehr durch. Manche Mikrocontroller sind nur noch in SMD-Bauformen erhältlich. Für SMD benutzt man üblicherweise geätzte Platinen oder Adapter/Sockel (die aber wieder extra kosten). Will man mit Lochrasterplatinen oder [[Breadboard]]s arbeiten, dann braucht man die klassischen Bauformen, z.B. PDIP. Zu beachten ist dabei, daß es PDIP oft nur bis DIP40 (also mit 40 Pins) gibt, d.h. einen Mikrocontroller mit 50 I/O-Pins kann es dann nur als SMD geben.

Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:
* MSP430
* AVR ATMega 64, 128, 169

== Spannung ==
Während früher die meisten Mikrocontroller und die gesamte Peripherie mit 5V liefen, so gibt es heute auch alle möglichen anderen Varianten. Zu beachten ist:
* Controller und Peripherie müssen zusammenpassen. Man kann nicht einfach (ohne weitere Vorkehrungen) ein 3,3V-RAM an einen 5V-Controller anschließen und umgekehrt.
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-Kompatible IO-Pins (Beispiel: [[LPC2100]]).
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2100]].

* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein Spannungsregler (z.B. [[78xx]]) ist also Pflicht!
* Bei Batterien und Akkus sinkt die Spannung ab, wenn sie leerer werden. Braucht der Controller z.B. mindestens 2,7V, dann wird man mit zwei 1,5V-Batterien nicht lange Freude haben (außer man benutzt spezielle Schaltregler).

== Stromverbrauch ==
Im Vergleich zu PC-Prozessoren (Pentium, Athlon usw.) brauchen Mikrocontroller relativ wenig Strom. Will man sie allerdings mit Batterien betreiben, dann wird der Stromverbrauch plötzlich doch wichtig. Die meisten Mikrocontroller besitzen hierfür Stromsparmodi, mit denen man den Controller teilweise abschalten kann. Für einen extrem geringen Stromverbrauch sind z.B. die [[MSP430]]-Controller optimiert.

Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab.

{| border=1 cellspacing=0
|+ Werte eines ATMega8
!   !!2,7V !!5,0V
|-
! 32KHz
|62µA||80µA
|-
! 100KHz
|0,3mA||0,5mA
|-
!1MHz
|1,5mA ||2,3mA
|-
!8MHz
|5mA ||11mA
|-
!16MHz
| - ||20mA
|}

== Takt/Geschwindigkeit ==
Einerseits wünscht man sich oft einen möglichst schnellen Controller, insbesondere als Anfänger, wenn man effiziente Lösungen noch nicht so kennt, andererseits schlägt sich ein hoher Takt auch im Stromverbrauch und im Preis nieder.

Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann:
* Während manche Controller 12 Takte für einen Befehl brauchen (z.B. die Original-[[8051]]), kommen andere mit einem Takt pro Befehl aus (z.B. [[AVR]]).
* Manche Controller beherrschen keine Multiplikation. Dort muss man das nachbilden, was dann aber 'sehr' langsam ist.
* Die Datenbus- bzw. Registerbreite spielt eine wichtige Rolle, weil man z.B. für eine 16-Bit-Addition auf einer 8-Bit-CPU zwei Befehle und auf einer 16-Bit-CPU nur einen Befehl braucht.

== Speicher ==
Während früher oft nur die [[Register]] im Mikrocontroller waren, und der gesamte restliche Speicher extern angebunden werden musste, so sind heute die Speicher oft komplett im Mikrocontroller integriert. Das bedeutet aber teilweise auch, dass man sie nicht erweitern kann. Wichtig ist dabei u.a. die Größe des Programmspeichers (meist ein [[Flash-ROM]]) und das [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.

Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur]] und [[Harvard-Architektur]]. Bei letzterer liegen Programmspeicher (ROM) und Datenspeicher (RAM) in getrennten Speicherbereichen; dies hat den Nachteil, dass für den Zugriff auf den Programmspeicher spezielle Befehle notwendig sind (was die Verwendung von im ROM abgelegten Daten in C-Compilern ziemlich umständlich macht), und dass man keine Programmteile direkt aus dem Datenspeicher ausführen kann.

== Onboard-Peripherie ==
Mikrocontroller haben meist eine ganze Menge Funktionen integriert, z.B. [[AD-Wandler]], [[I2C]]-Bus, [[SPI]], [[PWM]], [[RS232]] usw. usf. Der Vorteil liegt darin, dass der Controller damit mehrere Dinge gleichzeitig machen kann. Dadurch steigt zum einen die Gesamtleistung des Controllers, zum anderen sind viele Dinge zeitkritisch, und die Programmierung ist deutlich einfacher, wenn man zehn zeitkritische Dinge gleichzeitig erledigen muss.

== Programmiersprachen ==
Den direktesten Zugriff auf die "Innereien" eines Prozessors hat man mit [[Assembler]]. Dies ist jedoch gleichzeitig - zumindest auf den ersten Blick - die "abschreckendste" Sprache, denn sie erfordert einen hohen Lernaufwand und das Gelernte ist nur auf einen einzigen Prozessor oder allenfalls auf eine Familie "verwandter" Produkte anwendbar. In bestimmten Bereichen oder Teilen eines Projekts wird die Verwendung von Assembler dennoch unabdingbar sein. (Diese Teile mögen projektabhängig zwischen 100% oder auch nur deutlich unter 1% umfassen.)
Für größere Entwicklungen werden mittlerweile auch höhere Programmiersprachen ([[HLL]]) eingesetzt. Hier ist [[C]] klar dominierend, bei umfangreichen Projekten ist ein deutlicher Trend zu [[C-Plusplus|C++]] erkennbar. Andere Sprachen (z.B. Basic, Pascal) kommen demgegenüber nur in verschwindend geringem Umfang zum Einsatz.

== Programmübertragung ==
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.

== Störfestigkeit ==
Eigentlich ein wichtiges Thema, andererseits findet man dazu nur sehr wenig Informationen. Bekannt ist beispielsweise, dass bei der [[AVR]]-Famile die ATmegas deutlich störfester sind als die alten AT90S.

== Unterstützung/Community ==
Gerade als Anfänger ist man oft auf die Hilfe anderer angewiesen. Da empfiehlt es sich, der Masse hinterherzulaufen und keine exotischen Typen zu verwenden.

Entscheidung Mikrocontroller

2004-06-03T10:15:22Z

80.129.126.3:

Die meisten Anfänger stellen sich die Frage, welchen [[Mikrocontroller]] sie verwenden sollen. Es gibt dutzende Hersteller, und jeder davon hat unzählige Varianten im Angebot. Stellt man die Frage in einem Diskussionsforum, dann bekommt man viele verschiedene (sich teilweise widersprechende) Antworten. Bei der Entscheidung sollten u.a. folgende Kriterien beachtet werden:

== Verfügbarkeit ==
* Während man manche Mikrocontroller an jeder Straßenecke bekommt, sind andere nur in großen Stückzahlen und mit Gewerbenachweis erhältlich.
* Ab und zu kündigen Hersteller ein neues Modell an (und veröffentichen das Datenblatt dazu), können aber erst ein Jahr später nennenswerte Stückzahlen liefern.
* Lebenszyklus: Kein Modell wird ewig hergestellt, deswegen sollte man überprüfen, ob der Hersteller vielleicht schon angekündigt hat, dass er ein bestimmtes Modell nicht mehr herstellen will. Für Neuentwicklungen oder den Einstieg sollte man folgende Modelle nicht verwenden:
** AVR AT90-Reihe,
** AVR ATMega 103(L), 161(L), 163(L), 323(L).

== Preis ==
Mikrocontroller: Einerseits kann es lästig sein, wenn man durch die Verwendung eines kleineren Modells 2¤ gespart hat und dann mit dessen Unzulänglichkeiten kämpft, andererseits ist ein versehentlich zerstörter Chip für 30¤ ziemlich ärgerlich. Auch ist es oft ganz praktisch, wenn man einige Controller auf Vorrat hat.

Zum Preis eines einzelnen Mikrocontrollers kommen noch die Kosten für die Programmiersprache und die Programmübertragung hinzu (s.u.).

== Bauformen ==
Neben den klassischen (bedrahteten) Bauformen setzt sich heutzutage [[SMD]] immer mehr durch. Manche Mikrocontroller sind nur noch in SMD-Bauformen erhältlich. Für SMD benutzt man üblicherweise geätzte Platinen oder Adapter/Sockel (die aber wieder extra kosten). Will man mit Lochrasterplatinen oder [[Breadboard]]s arbeiten, dann braucht man die klassischen Bauformen, z.B. PDIP. Zu beachten ist dabei, daß es PDIP oft nur bis DIP40 (also mit 40 Pins) gibt, d.h. einen Mikrocontroller mit 50 I/O-Pins kann es dann nur als SMD geben.

Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:
* MSP430
* AVR ATMega 64, 128, 169

== Spannung ==
Während früher die meisten Mikrocontroller und die gesamte Peripherie mit 5V liefen, so gibt es heute auch alle möglichen anderen Varianten. Zu beachten ist:
* Controller und Peripherie müssen zusammenpassen. Man kann nicht einfach (ohne weitere Vorkehrungen) ein 3,3V-RAM an einen 5V-Controller anschließen und umgekehrt.
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-Kompatible IO-Pins (Beispiel: [[LPC2100]]).
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2100]].

* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein Spannungsregler (z.B. [[78xx]]) ist also Pflicht!
* Bei Batterien und Akkus sinkt die Spannung ab, wenn sie leerer werden. Braucht der Controller z.B. mindestens 2,7V, dann wird man mit zwei 1,5V-Batterien nicht lange Freude haben (außer man benutzt spezielle Schaltregler).

== Stromverbrauch ==
Im Vergleich zu PC-Prozessoren (Pentium, Athlon usw.) brauchen Mikrocontroller relativ wenig Strom. Will man sie allerdings mit Batterien betreiben, dann wird der Stromverbrauch plötzlich doch wichtig. Die meisten Mikrocontroller besitzen hierfür Stromsparmodi, mit denen man den Controller teilweise abschalten kann. Für einen extrem geringen Stromverbrauch sind z.B. die [[MSP430]]-Controller optimiert.

Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab.

{| border=1 cellspacing=0
|+ Werte eines ATMega8
!   !!2,7V !!5,0V
|-
! 32KHz
|62µA||80µA
|-
! 100KHz
|0,3mA||0,5mA
|-
!1MHz
|1,5mA ||2,3mA
|-
!8MHz
|5mA ||11mA
|-
!16MHz
| - ||20mA
|}

== Takt/Geschwindigkeit ==
Einerseits wünscht man sich oft einen möglichst schnellen Controller, insbesondere als Anfänger, wenn man effiziente Lösungen noch nicht so kennt, andererseits schlägt sich ein hoher Takt auch im Stromverbrauch und im Preis nieder.

Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann:
* Während manche Controller 12 Takte für einen Befehl brauchen (z.B. die Original-[[8051]]), kommen andere mit einem Takt pro Befehl aus (z.B. [[AVR]]).
* Manche Controller beherrschen keine Multiplikation. Dort muss man das nachbilden, was dann aber 'sehr' langsam ist.
* Die Datenbus- bzw. Registerbreite spielt eine wichtige Rolle, weil man z.B. für eine 16-Bit-Addition auf einer 8-Bit-CPU zwei Befehle und auf einer 16-Bit-CPU nur einen Befehl braucht.

== Speicher ==
Während früher oft nur die [[Register]] im Mikrocontroller waren, und der gesamte restliche Speicher extern angebunden werden musste, so sind heute die Speicher oft komplett im Mikrocontroller integriert. Das bedeutet aber teilweise auch, dass man sie nicht erweitern kann. Wichtig ist dabei u.a. die Größe des Programmspeichers (meist ein [[Flash-ROM]]) und das [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.

Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur]] und [[Harvard-Architektur]]. Bei letzterer liegen Programmspeicher (ROM) und Datenspeicher (RAM) in getrennten Speicherbereichen; dies hat den Nachteil, dass für den Zugriff auf den Programmspeicher spezielle Befehle notwendig sind (was die Verwendung von im ROM abgelegten Daten in C-Compilern ziemlich umständlich macht), und dass man keine Programmteile direkt aus dem Datenspeicher ausführen kann.

== Onboard-Peripherie ==
Mikrocontroller haben meist eine ganze Menge Funktionen integriert, z.B. [[AD-Wandler]], [[I2C]]-Bus, [[SPI]], [[PWM]], [[RS232]] usw. usf. Der Vorteil liegt darin, dass der Controller damit mehrere Dinge gleichzeitig machen kann. Dadurch steigt zum einen die Gesamtleistung des Controllers, zum anderen sind viele Dinge zeitkritisch, und die Programmierung ist deutlich einfacher, wenn man zehn zeitkritische Dinge gleichzeitig erledigen muss.

== Programmiersprachen ==
Den direktesten Zugriff auf die "Innereien" eines Prozessors hat man mit [[Assembler]]. Dies ist jedoch gleichzeitig - zumindest auf den ersten Blick - die "abschreckendste" Sprache, denn sie erfordert einen hohen Lernaufwand und das Gelernte ist nur auf einen einzigen Prozessor oder allenfalls auf eine Familie "verwandter" Produkte anwendbar. In bestimmten Bereichen oder Teilen eines Projekts wird die Verwendung von Assembler dennoch unabdingbar sein. (Diese Teile mögen projektabhängig zwischen 100% oder auch nur deutlich unter 1% umfassen.)
Für größere Entwicklungen werden mittlerweile auch höhere Programmiersprachen ([[HLL]]) eingesetzt. Hier ist [[C]] klar dominierend, bei umfangreichen Projekten ist ein deutlicher Trend zu [[C-PlusPlus|C++]] erkennbar. Andere Sprachen (z.B. Basic, Pascal) kommen demgegenüber nur in verschwindend geringem Umfang zum Einsatz.

== Programmübertragung ==
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.

== Störfestigkeit ==
Eigentlich ein wichtiges Thema, andererseits findet man dazu nur sehr wenig Informationen. Bekannt ist beispielsweise, dass bei der [[AVR]]-Famile die ATmegas deutlich störfester sind als die alten AT90S.

== Unterstützung/Community ==
Gerade als Anfänger ist man oft auf die Hilfe anderer angewiesen. Da empfiehlt es sich, der Masse hinterherzulaufen und keine exotischen Typen zu verwenden.

Entscheidung Mikrocontroller

2004-06-03T10:03:30Z

80.129.126.3:

Die meisten Anfänger stellen sich die Frage, welchen [[Mikrocontroller]] sie verwenden sollen. Es gibt dutzende Hersteller, und jeder davon hat unzählige Varianten im Angebot. Stellt man die Frage in einem Diskussionsforum, dann bekommt man viele verschiedene (sich teilweise widersprechende) Antworten. Bei der Entscheidung sollten u.a. folgende Kriterien beachtet werden:

== Verfügbarkeit ==
* Während man manche Mikrocontroller an jeder Straßenecke bekommt, sind andere nur in großen Stückzahlen und mit Gewerbenachweis erhältlich.
* Ab und zu kündigen Hersteller ein neues Modell an (und veröffentichen das Datenblatt dazu), können aber erst ein Jahr später nennenswerte Stückzahlen liefern.
* Lebenszyklus: Kein Modell wird ewig hergestellt, deswegen sollte man überprüfen, ob der Hersteller vielleicht schon angekündigt hat, dass er ein bestimmtes Modell nicht mehr herstellen will. Für Neuentwicklungen oder den Einstieg sollte man folgende Modelle nicht verwenden:
** AVR AT90-Reihe,
** AVR ATMega 103(L), 161(L), 163(L), 323(L).

== Preis ==
Mikrocontroller: Einerseits kann es lästig sein, wenn man durch die Verwendung eines kleineren Modells 2¤ gespart hat und dann mit dessen Unzulänglichkeiten kämpft, andererseits ist ein versehentlich zerstörter Chip für 30¤ ziemlich ärgerlich. Auch ist es oft ganz praktisch, wenn man einige Controller auf Vorrat hat.

Zum Preis eines einzelnen Mikrocontrollers kommen noch die Kosten für die Programmiersprache und die Programmübertragung hinzu (s.u.).

== Bauformen ==
Neben den klassischen (bedrahteten) Bauformen setzt sich heutzutage [[SMD]] immer mehr durch. Manche Mikrocontroller sind nur noch in SMD-Bauformen erhältlich. Für SMD benutzt man üblicherweise geätzte Platinen oder Adapter/Sockel (die aber wieder extra kosten). Will man mit Lochrasterplatinen oder [[Breadboard]]s arbeiten, dann braucht man die klassischen Bauformen, z.B. PDIP. Zu beachten ist dabei, daß es PDIP oft nur bis DIP40 (also mit 40 Pins) gibt, d.h. einen Mikrocontroller mit 50 I/O-Pins kann es dann nur als SMD geben.

Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:
* MSP430
* AVR ATMega 64, 128, 169

== Spannung ==
Während früher die meisten Mikrocontroller und die gesamte Peripherie mit 5V liefen, so gibt es heute auch alle möglichen anderen Varianten. Zu beachten ist:
* Controller und Peripherie müssen zusammenpassen. Man kann nicht einfach (ohne weitere Vorkehrungen) ein 3,3V-RAM an einen 5V-Controller anschließen und umgekehrt.
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-Kompatible IO-Pins (Beispiel: [[LPC2100]]).
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2100]].

* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein Spannungsregler (z.B. [[78xx]]) ist also Pflicht!
* Bei Batterien und Akkus sinkt die Spannung ab, wenn sie leerer werden. Braucht der Controller z.B. mindestens 2,7V, dann wird man mit zwei 1,5V-Batterien nicht lange Freude haben (außer man benutzt spezielle Schaltregler).

== Stromverbrauch ==
Im Vergleich zu PC-Prozessoren (Pentium, Athlon usw.) brauchen Mikrocontroller relativ wenig Strom. Will man sie allerdings mit Batterien betreiben, dann wird der Stromverbrauch plötzlich doch wichtig. Die meisten Mikrocontroller besitzen hierfür Stromsparmodi, mit denen man den Controller teilweise abschalten kann. Für einen extrem geringen Stromverbrauch sind z.B. die [[MSP430]]-Controller optimiert.

Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab.

{| border=1 cellspacing=0
|+ Werte eines ATMega8
!   !!2,7V !!5,0V
|-
! 32KHz
|62µA||80µA
|-
! 100KHz
|0,3mA||0,5mA
|-
!1MHz
|1,5mA ||2,3mA
|-
!8MHz
|5mA ||11mA
|-
!16MHz
| - ||20mA
|}

== Takt/Geschwindigkeit ==
Einerseits wünscht man sich oft einen möglichst schnellen Controller, insbesondere als Anfänger, wenn man effiziente Lösungen noch nicht so kennt, andererseits schlägt sich ein hoher Takt auch im Stromverbrauch und im Preis nieder.

Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann:
* Während manche Controller 12 Takte für einen Befehl brauchen (z.B. die Original-[[8051]]), kommen andere mit einem Takt pro Befehl aus (z.B. [[AVR]]).
* Manche Controller beherrschen keine Multiplikation. Dort muss man das nachbilden, was dann aber 'sehr' langsam ist.
* Die Datenbus- bzw. Registerbreite spielt eine wichtige Rolle, weil man z.B. für eine 16-Bit-Addition auf einer 8-Bit-CPU zwei Befehle und auf einer 16-Bit-CPU nur einen Befehl braucht.

== Speicher ==
Während früher oft nur die [[Register]] im Mikrocontroller waren, und der gesamte restliche Speicher extern angebunden werden musste, so sind heute die Speicher oft komplett im Mikrocontroller integriert. Das bedeutet aber teilweise auch, dass man sie nicht erweitern kann. Wichtig ist dabei u.a. die Größe des Programmspeichers (meist ein [[Flash-ROM]]) und das [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.

Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur]] und [[Harvard-Architektur]]. Bei letzterer liegen Programmspeicher (ROM) und Datenspeicher (RAM) in getrennten Speicherbereichen; dies hat den Nachteil, dass für den Zugriff auf den Programmspeicher spezielle Befehle notwendig sind (was die Verwendung von im ROM abgelegten Daten in C-Compilern ziemlich umständlich macht), und dass man keine Programmteile direkt aus dem Datenspeicher ausführen kann.

== Onboard-Peripherie ==
Mikrocontroller haben meist eine ganze Menge Funktionen integriert, z.B. [[AD-Wandler]], [[I2C]]-Bus, [[SPI]], [[PWM]], [[RS232]] usw. usf. Der Vorteil liegt darin, dass der Controller damit mehrere Dinge gleichzeitig machen kann. Dadurch steigt zum einen die Gesamtleistung des Controllers, zum anderen sind viele Dinge zeitkritisch, und die Programmierung ist deutlich einfacher, wenn man zehn zeitkritische Dinge gleichzeitig erledigen muss.

== Programmiersprachen ==
Den direktesten Zugriff auf die "Innereien" eines Prozessors hat man mit [[Assembler]]. Dies ist jedoch gleichzeitig - zumindest auf den ersten Blick - die "abschreckendste" Sprache, denn sie erfordert einen hohen Lernaufwand und das Gelernte ist nur auf einen einzigen Prozessor oder allenfalls auf eine Familie "verwandter" Produkte anwendbar. In bestimmten Bereichen oder Teilen eines Projekts wird die Verwendung von Assembler dennoch unabdingbar sein. (Diese Teile mögen projektabhängig zwischen 100% oder auch nur deutlich unter 1% umfassen.)
Für größere Entwicklungen werden mittlerweile auch höhere Programmiersprachen ([[HLL]]) eingesetzt. Hier ist [[C]] klar dominierend, bei umfangreichen Projekten ist ein deutlicher Trend zu [[C++]] erkennbar. Andere Sprachen (z.B. Basic, Pascal) kommen demgegenüber nur in verschwindend geringem Umfang zum Einsatz.

== Programmübertragung ==
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.

== Störfestigkeit ==
Eigentlich ein wichtiges Thema, andererseits findet man dazu nur sehr wenig Informationen. Bekannt ist beispielsweise, dass bei der [[AVR]]-Famile die ATmegas deutlich störfester sind als die alten AT90S.

== Unterstützung/Community ==
Gerade als Anfänger ist man oft auf die Hilfe anderer angewiesen. Da empfiehlt es sich, der Masse hinterherzulaufen und keine exotischen Typen zu verwenden.