Hardware Reference
In-Depth Information
einen Flicken aufsetzt. In die Computersprache übersetzt heißt das, dass man, ohne den
eigentlichen Fehler zu beheben, die Schwierigkeit einfach dadurch überwindet, dass
man ein neues Programmstückchen einschreibt. Und so werden die Systeme immer
komplizierter und immer undurchschaubarer. Der naive Leser wird nun denken, dass
derjenige, der das Programm eingeschrieben hat, das System verstehe? - Dem ist nicht
so, weil es diesen einen nicht gibt: vielleicht sind es zehn, zwanzig oder hundert Pro-
grammierer, die an diesem System schon gearbeitet haben, und zwar zu verschiedenen
Zeiten und an verschiedenen Orten, sodass keiner weiß, was der andere gemacht hat.
So etwas wie eine strenge Architektur, an die man sich halten könnte, ist nicht vorhan-
den
[Eisberg].
Diese Aussage ist nahezu ein Viertel Jahrhundert alt, und die verstrichene Zeit hat
nicht nur bestätigt, dass sie richtig ist, sondern auch, dass sie nach wie vor Gültig-
keit hat. Heute werden Programmflicken (Patches) wie selbstverständlich akzep-
tiert. Nur gut, wenn man für das Programm, das man verwendet, auch die richtigen
und aktuellsten Patches hat. Wenn man sich die Zeit nimmt, einmal in Ruhe darü-
ber nachzudenken, wie viele einzelne Komponenten zusammenwirken, um eine
Entwicklung wie das vorgestellte Beispielgerät zu ermöglichen, wird einem schnell
klar, dass es wohl keine zwei Personen auf dieser Welt gibt, die identische Entwick-
lungsumgebungen haben, angefangen vom PC, auf dem die Entwicklungswerk-
zeuge laufen. Unterschiedliche Hardware-Systemkonfigurationen ziehen meistens
unterschiedliche Betriebssystem-Softwarekonfigurationen nach sich. Darauf reagie-
ren nun oft genug auch die Anwendungsprogramme unterschiedlich. Obendrein ist
es sehr wahrscheinlich, dass einzelne Softwarekomponenten des Systems in unter-
schiedlichen Entwicklungsumgebungen verschiedene Versionen haben. Und nicht
alle Kombinationen harmonieren miteinander. So ist z. B. bekannt, dass die Version
1.3 des USB-Compliance-Testprogramms USBCV nicht mit MSXML 4.0 und Ser-
vice Pack 1 zusammen läuft. Auch nicht alle Hardwarekomponenten funktionieren
gleich gut. Für den im Beispielgerät eingesetzten Mikrocontroller PIC18F4550 gibt
es diverse Fertigungslose, die jeweils unterschiedliche Fehler aufweisen. Auf der
Website des Herstellers Microchip finden sich zu den jeweiligen Chargen die Fehler-
berichte, aus denen hervorgeht, welche Funktionen des Mikrocontrollers nicht so
arbeiten, wie im Datenblatt beschrieben ist, und welche Methoden (Workarounds)
es gibt, das Fehlverhalten zu umgehen. Im Beispielgerät wurde ein Chip mit der
Revisionsbezeichnung A3 eingesetzt, zu dem es eine vierzehnseitige Fehlerbeschrei-
bung gibt (DS80220G). Als Entwickler muss man derartige Dokumente sorgfältig
darauf prüfen, ob die dort beschriebenen Fehler Auswirkungen auf das Projekt
haben werden. Im genannten Beispiel werden bei einem Interrupt unter bestimm-
ten Bedingungen die Inhalte einiger Register verändert, sodass die Standardproze-
duren der Interruptprogrammierung nicht anwendbar sind. Auch im Zusammen-
