Programmierung der µC & µP

Die „weiche Ware“ – Software und µC / µP

Was nützt die beste Hardware (die kleinen „schwarzen Kisten“) ohne Intelligenz (Nach Weizenbaum sollte man wohl eher nicht von Intelligenz sprechen). Trotzdem benötigen die µC & µP eine genaue Vorschrift, was sie denn nun tun sollen. Hier kommt die Software ins Spiel.
Zuerst wird sich der Anwender überlegen, was denn nun sein µC / µP an Aufgaben zu erledigen hat. Hierzu ist eine sorgfältige Planung auf dem Papier sicherlich sehr sinnvoll, der sogenannte „Schreibtischtest“. Man überlegt sich also welche Funktionen man umsetzen will und wie die Ergebnisse aussehen sollen.
Als nächstes „übersetzt“ der Entwickler seine Ideen in eine für den µC / µP verständliche Sprache. Hier stehen entsprechende systemnahe Programmiersprachen zur Verfügung: man „schreibt“ sein Programm in Maschinensprache bzw. Assembler. Wie der Name Maschinensprache schon vermuten lässt, ist die Sprache zur Programmierung sehr eng an die jeweilige Maschine, also den µC / µP gekoppelt. Jeder Prozessor hat halt seinen eigenen Sprachdialekt, der wiederum abgestellt ist auf die Leistungsfähigkeit (8-Bit/16-Bit-Systeme u.a.), aber auch auf den Funktionsumfang. Hier unterscheidet man RISC- und CISC-Systeme:
RISC => ReduzierterInstruktionsSatzComputer
CISC => ComplexerInstruktionsSatzComputer.
Diese Unterscheidung bestimmt auch die Leistungsfähigkeit der Systeme. Benötigt man viel „einfache“ Leistung empfiehlt sich ein RISC-System. Möchte man komplexe Aufgaben erledigen lassen, bietet sich ein CISC-System an. Meist findet man bei µC RISC-basierte Prozessorkerne, die aufwendigeren µP nutzen oftmals CISC-Architekturen. Dies soweit zu den Grundlagen in Bezug auf die Architekturen.

Wie kommt mein Projekt in den Chip ?
Nun kommen wir kurz zu der „Formulierung“ der Programme. Wie bereits beschrieben, benötige ich ein Programm – gleich ob als direkter Maschinencode oder in einer Hochsprache (Erklärung folgt) geschrieben – und nachher einen Compiler (Übersetzer) der das Programm in Maschinencode übersetzt. Letztlich muss das lauffähige Programm immer in einer „verständlichen“ Form für den µC / µP vorliegen. Meist scheibt man diese Programme für den menschlichen Entwickler besser verstehbar, in einer sogenannten Hochsprache. Der Begriff Hochsprache kennzeichnet hier eine höhere Programmiersprache, die einige Programmkonstrukte dem Entwickler zur Verfügung stellt, ohne das man sich Gedanken um die Umsetzung dieser auf Maschinenebene, also Hardwareebene machen muss. Als Beispiel sei hier die Programmiersprache „C“ genannt. Programme die in „C“ geschrieben sind, lassen sich problemlos auf vollkommen unterschiedliche Systeme bezüglich ihrer Hardware „übertragen“, also portieren. Es muss für dieses Systeme „nur“ eine Entwicklungsumgebung für „C“ vorliegen, bestehend aus einem einfachen Editor zur Bearbeitung des Programms, sowie dem eigentlichen „Übersetzer“ in den jeweiligen Maschinendialekt, gennannt „Compiler“ (Anm.: Eine vollständige Entwicklungsumgebung beinhaltet noch weitere Teile, wie zum Beispiel den „Linker“, auf diese möchte ich aber hier näher nicht eingehen). Daneben sollte auch der jeweilige „C“-Dialekt genormt sein (=> ANSI-C). Die Normierung der Programmierumgebung (z.B. ANSI-C) ermöglicht auch den Austausch der Programme zwischen der µP- und µC-Welt, natürlich unter Berücksichtigung der weiteren hardwarenahen Anforderungen wie zum Beispiel Schnittstellen und Peripherie. Ein Programm zur Wiedergabe von Music auf einem µP-System (PC) nutzt auf einem µC-System ohne Audioausgang schlicht nichts.

Der gemeinsame Weg trennt sich – Unterschiede zwischen µC und µP
Auch wenn man eine standartisierte Programmiersprache wie „C“ zur Entwicklung seiner Programme verwendet, gestaltet sich doch das Einfügen der Programme in den µC oder µP (eigentliche physikalische Programmierung) vollkommen unterschiedlich. Wenn bei µP-Systemen oftmals nur ein Minimalprogramm zum Starten des Systems und zum Nachladen des eigentlichen „Betriebssystems“ nötig ist, beinhaltet das Programm für den µC doch alle Funktionen, die für die Anwendung benötigt werden. Das µP-System nutzt einen externen Festspeicher (ROM = ReadOnlyMemory/NurLeseSpeicher) für sein Grundprogramm. Nach Start/Ablauf dieses Programmes startet dann von einem Massenspeicher (Festplatte/CDROM/DVDROM/USB-Stick) das eigentliche Betriebssystem, welche wiederum die Basis für weitere Programme, also auch unser Anwenderprogramm, darstellt. In fast allen Fällen ist das „Bootsystem“ im ROM des µP-Systems bereits vom Lieferanten Systems vorprogrammiert und wird mitgeliefert. Minimal-Systeme enthalten hier oftmals einen Editor mit Assembler zur absoluten Basisprogrammierung.
Das µC-System unterscheidet sich hier nun grundlegend, alleine schon vom Aufbau. Der Programmspeicher ist ja Teil des µC und wird daher auch im System programmiert. Weitere Peripherie zum Start ähnlich den Massenspeichern fehlen hier ebenfalls. Auch darf das Programm hier nicht enden (Endlosschleife), schließlich folgt ja kein Nachladen eines Betriebssystems und weiterer Start von Anwenderprogrammen wie beim µP-System. Man muss daneben mit dem internen Speicher, meist übrigens nicht besonders groß, auskommen. Oftmals ist dieser Speicher als Flash-Speicher ausgelegt. Dies bedeutet das man eine Neu-Programmierung ohne externe Löschhilfen (einfache EPROM-Speicher benötigen hier UV-Licht) vornehmen kann und dies teilweise bis zu 100.000-fach.
Die Hersteller garantieren teilweise bis zu 40 Jahre Datenerhalt dieser Speicher. Ähnlich wie die bei µP-Systemen verwendeten EPROMs kann man den ganzen µC in ein externes Programmiergerät setzen und sein „fertiges“ Anwendungsprogramm einprogrammieren.

Warum kompliziert wenn es auch einfach geht ? 
Nun ist es sicherlich nicht sehr bequem, ständig den µC aus der eigentlichen Schaltung zum Programmieren zu entfernen und dann in ein externes Programmiergerät einzusetzen. Hierzu hat man das In-System-Programmiersystem entwickelt. Bei der Entwicklung der Schaltung berücksichtigt man hier einfach die Programmierbarkeit des fertigen Systems. Hierzu besitzen alle µC einen Programmierport. Dieser kann durch geschickte Entwicklung des Herstellers auch als Ein/Ausgang genutzt werden und durch bestimmte Umstände halt als Programmierzugang genutzt werden. Vielfach beinhalten die µC aber auch einen sogenannten „Bootloader“, also schon ein Programm herstellerseitig, welches die Programmierung nach bestimmten Aktionen (In den Bootmodus setzen) erlaubt. Wichtig ist bei allen Lösungen, dass man hier einen „Programmieradapter“ benötigt. Dieser sorgt dann für die Übertragung aus dem Entwicklungssystem (meist auf einem PC) über die serielle/USB-Schnittstelle des PC auf das µC-System unter Berücksichtigung der speziellen Anforderungen desselben. Manchmal muss man dennoch die µC in ein externes Programmiergerät setzen, zum Beispiel wenn man den vorgenannten Bootload auf den neuesten Stand (Updaten) bringen will, aber auch wenn man durch „zu viel“ Spielen die Konfiguration des µC durcheinander gebracht hat (Oftmals bei ATMEGA/ATTiny der Fa. ATMEL der Fall). Seltener werden die µC´s auch als OTP-System genutzt (OTP = OneTimeProgrammierung/EinmalProgrammierung). Hier ist nach erfolgter Programmierung das System „fertig“ und kann nicht mehr in Bezug auf die Software geändert werden – dies bietet sich bei sicherheitrelevanten Anwendungen an, ist dann aber ohne Austausch des kompletten µC nicht mehr änderbar. Für den Hobby-Entwickler ist dies sicher nicht erstrebenswert – wir wollen ja Erfahrungen sammeln und auch unsere Fehler nach und nach beheben.

Weiterhin kann man ebenfalls diese Programmierschnittstelle auch zum Austesten der eigenen Programme verwenden. Die Entwicklungsumgebung wie auch der Programmierdapter übernehmen dann die Funktionen eines „Debuggers“ (Entwanzers). Hiermit kann in ein auf dem µC laufendendes Programm „hineingeschaut“ werden, um dann systemnah Fehler zu lokalisieren bzw. das Anwendungsprogramm optimieren zu können. Komfortable Systeme können hier auch sehr schnell sehr kostenintensiv werden, zu Beginn reicht meist ein einfaches Blinkprogramm mit ca. 10 Bauteilen aus zum grundätzlichen Test des µC aus. Debugger sind für sehr komplexe Anwendungen sehr hilfreich, aber halt auch (kosten-)aufwändig.

Zusammenfassung – was bedeutet das für mich ? 
Letztlich sollte der Entwickler also auch die Programmierbarkeit bei seiner Auswahl des Systems beachten. Ein superschnelles, leistungsfähiges System bringt dem Entwickler nichts, wenn einerseits die Entwicklungsumgebung unerschwinglich ist (bei manchen Systemen geht das in die zehntausende Euro) oder aber für den „Küchentisch“ nicht nutzbar, sprich die Programmierung einfach zu aufwendig wird. Glücklicherweise sind alle Marktführer hier in Bezug auf die Programmierbarkeit doch sehr entgegenkommend – welches System verkauft sich schon, wenn es kompliziert programmiert werden muss. Daneben gibt es für die verbreitesten µC-Familien Entwicklungsumgebungen für den „kleinen Geldbeutel“ oder aber gleich kostenlos also Opensource-Lösung.
Komplexere Systeme wie z.B. FPGA-Bausteine sind hier als Premiumdisziplin zu sehen: Sie sind zwar technisch ähnlich einfach zu programmieren wie klassische µC, aber die Programmentwicklung selber benötigt doch sehr viel Hintergrundwissen und Verständnis der Grundlagen der Digitaltechnik. Systeme wie der Raspberry Pi (SoC=System-on-a-Chip) u.a. nutzen meist als Betriebssystem angepasste Linux-Distributionen und sind auch hier als Zwischenlösung zwischen µP und µC zu sehen. Die Programmentwicklung für µP-Systeme ist neben den Grundlagenfunktionen nicht trivial und daher sehr komplex. Meist nutzt man hier maschinennahe, einfache Programme auf Maschinensprachenbasis um die grundsätzliche Funktion des Systems zu verstehen. Weitergehende Entwicklung sprengt den Rahmen der hardwarenahen Programmierung und führt zur Disziplin der allgemeinen Anwendungsentwicklung für die jeweiligen Systeme und Betriebssysteme (Windows, Linux, MacOS u.a.). Der Fokus in diesem Websystem liegt jedoch mehr auf der Entwicklung von µC-Systemen und kleinen (sehr kleinen), einfachen µP´s.

[maxbutton id=“1″]
[maxbutton id=“2″]