Mikrocontroller-Dokumentation verstehen (Teil 3): Blockschaltungen und mehr

In den vorangegangenen Teilen dieser Reihe gibt es um Prinzipielles, Register und die Takterzeugung. Nun kommen weitere Blockschaltungen und Hinweise, wo Sie weitere Dokumentation finden können.

Noch einmal: Start nach Reset

Wenn die Taktperipherie der zentrale Teil eines Mikrocontrollers ist, dann kommt die Implementierung der Reset-Schaltung direkt im Anschluss. Wie der Takt muss sie nur einmal konfiguriert werden (falls Konfigurationsoptionen vorhanden sind). Ein gutes Verständnis der Reset-Thematik erspart später viel Ärger.
 
Im Beispiel von Seite 100 sieht man zwei Pins (Quadrate mit einem Kreuz, links), die Resets generieren können. Diese externen Resets kommen zu einer Reihe anderer interner Quellen hinzu. Eine davon ist der Befehl RESET, zwei stammen vom Unter- und Überlauf des Stacks und ein weiterer hat mit dem Watchdog-Timer zu tun.
 
In der orangen Markierung sind eine Reihe von Reset-Mechanismen, wie z.B. die Power-on-Erkennung und der sogenannte Brown-out (Unterspannung), die mit dem Versorgungsspannung des Mikrocontrollers verbunden sind. Hier gibt es wenig Eingriffsmöglichkeiten, wobei alle Interrupt-Quellen ein potenzielles Reset-Signal generieren, das in der grünen Markierung zusammengefasst wird. Wie schon zuvor beim Register STATUS lässt sich in einigen Fällen die Ursache des erfolgten Reset feststellen.
 

Blockschaltungen der Periphere

Die Blockschaltungen für die integrierte Peripherie-Elektronik sind ebenso vielfältig wie komplex. Nachfolgend sieht man einen Teil eines einfachen Timers (TIMER0) von Seite 396. Die orange markierte Gruppe von Bits in (vermutlich einem) Register dient zur Auswahl einer Reihe von Quellen für TIMER0. Auf ein externes Signal an einem Pin (grün markiert, links) kann eine Quelle sein. Das Timer-Signal kann auch an einem Pin (grün markiert, rechts) extern zur Verfügung gestellt werden.
 
Leicht erkennbar ist zwar das mit Pin TMR0 verbundene D-Flip-Flop rechts, aber viele der Blöcke sind kaum mehr als simple Rechtecke. Einige wie z.B. Vor- und Nachteiler sind selbsterklärend. Der Block SYNC scheint lediglich selbsterklärend zu sein, erfordert aber wohl die ausführliche Lektüre des beschreibenden Textes, will man seine Funktion voll verstehen. Diagramme und Text bauen in Datenblättern oft aufeinander auf. Manchmal ist es sogar notwendig, etwas Test-Code zu schreiben, um wirklich zu verstehen, wie diese Peripherie genau funktioniert.

Platinen-Layout

Irgendwann muss die frisch konzipierte Mikrocontroller-Schaltung auf eine Platine übertragen werden, wenn man einen sauberen Aufbau haben möchte oder gar eine Serienproduktion plant. Die meisten CAD-Programme für Platinen verfügen wohl über „Schaltzeichen“ für die meisten üblichen Mikrocontroller zusammen mit dem Layout der zugehörigen Gehäuseformen. Wenn diese jedoch fehlen, enthält das Datenblatt wahrscheinlich technische Zeichnungen für die möglichen Gehäuse samt genauen Angaben zu den Pads. In diesem Fall finden sich diese Informationen ab Seite 639.
 
Das hier verwendete SOIC-Gehäuse ist auf den Seiten 645 und 646 zu finden. Für den Entwickler sind heute auch Daten wie die Höhe des Gehäuses wichtig, wenn das verfügbare Volumen begrenzt ist. Etliche Gehäuse weisen auch eine integrierten Metallfläche auf, der zur besseren Wärmeableitung auf die Platine gelötet werden muss. Zwar ist dies hier nicht der Fall, aber wenn doch, dann gäbe es auch hierfür Details zur Verlötung etc. im Datenblatt. Eventuell muss man dann auch darauf achten, ob diese Metallfläche eine Verbindung mit Masse benötigt oder schon mit einem anderen Pin verbunden ist.
 

Was fehlt gelegentlich im Datenblatt?

Ein Datenblatt enthält eine Menge Informationen. Und trotzdem werden gelegentlich einige Aspekte ausgelassen, weil das Datenblatt sonst zu lang würde, oder weil die Informationen für viele Chips gleich und somit zu redundant sind, um eigenen Platz in der Dokumentation zu verdienen. Dazu gehört typischerweise:
 
Der Befehlssatz des Prozessors. Wenn die Anzahl der Befehle gering ist (weniger als etwa 70), werden sie oft dennoch im Datenblatt beschrieben. Falls nicht, gibt es wahrscheinlich ein separates Dokument, in dem jeder Befehl ausführlich erklärt wird.
Code-Beispiele. Solche gab es häufiger, als Mikrocontroller gewöhnlich noch in Assembler programmiert wurden. Beispiele in Hochsprachen wie C machen weniger Sinn, da der passende Compiler die verwendeten Anweisungen genau definiert.
Schaltungsbeispiele. Diese finden sich am häufigsten in Verbindung mit Funktionen, die für den gewählten Mikrocontroller einzigartig sind. Zu nennen wären etwa wie der Oszillator, ein Netzteil oder etwas komplexere Schnittstellen wie USB, die spezifische Anforderungen an die Signale haben. Es ist jedoch wahrscheinlicher, dass diese Aspekte in ergänzenden Dokumentationen ausführlicher behandelt werden.

Was fehlt generell im Datenblatt?

Die folgenden Punkte sind üblicherweise nicht im Datenblatt enthalten und finden sich stattdessen in anderer Dokumentation. Dies liegt normalerweise daran, dass sie Themen behandeln, die für eine breite Palette von Mikrocontrollers gemeinsam gelten.
 

• Beschreiben des Flash-Speichers von Mikrocontrollern. Dies Thema wird eher separat bei der Programmierung von Mikrocontrollern in der Massenproduktion behandelt.
• Verwendung von Tools. Der Compiler, die empfohlene IDE und Debugging-Tools haben typischerweise ihre eigene Dokumentation.
• Detaillierte Erläuterung des Prozessors. Auch dieser Aspekt wird oft in einem separaten Dokument behandelt; gerade bei 16- und 32-bit-Controllern.
• Ausführliche Erläuterung komplexer Peripheriegeräte. USB, Grafikschnittstellen und Ethernet-Peripherie werden normalerweise in separaten Dokumenten behandelt, da deren Umfang die Größe eines Mikrocontroller-Datenblatts locker verdoppeln könnte.
• Fehler. Alle Fehler in der Dokumentation oder Workarounds zur Behebung von Fehlern im Chip, werden hier behandelt.

Welche andere Dokumentation gibt es?

Zusätzlich zum Datenblatt werden üblicherweise die folgenden Dokumente zur Verfügung gestellt:
 

• Family Reference Manual. Während das Datenblatt genau angibt, was ein konkreter Mikrocontroller leistet, bieten solche Dokumente einen übergeordneten Überblick darüber, was die Mikrocontroller einer Gerätefamilie leisten können.
• Application Notes. Diese gehen detaillierter darauf ein, wie bestimmte Peripherie verwendet werden kann, um eine Anwendung oder Schnittstelle zu implementieren. Das Datenblatt behandelt zwar z.B. CAN-Schnittstellen, aber die Application Notes erläutern, wie sie als Teil eines CAN-Netzwerks eingesetzt werden. Oft geben sie Hinweise zu Softwareprotokollen auf höherer Ebene und zur Auswahl geeigneter Transceiver.
• Programming. Speziell für die Programmierung bei der Serienproduktion werden die erforderlichen Spannungen und Timings sowie alle für die Programmierschnittstelle verwendeten Protokolle im Detail erläutert.

Wie man Mengen an Dokumenten konsumiert

Leider gibt es keine Möglichkeit, schnell alle Daten zu lesen und zu verarbeiten, die mit einem Mikrocontroller und all seinen Werkzeugen in Zusammenhang stehen. Als Anfänger ist es wahrscheinlich am besten, das Datenblatt zusammen mit einem Buch oder Artikel über den verwendeten Mikrocontroller zu lesen. Bei Elektor gibt es nicht nur Bücher über PIC-Mikrocontrollern, sondern auch für den Einstieg geeignete Bücher zum STM32 und zu ARM-basierten SoCs. Man kann auch schlicht ein einfaches MSP430-Projekt ausprobieren.
 
Die Kombination von praktischen Beispielen in Verbindung mit zwei Arten schriftlicher Information (ein Buch/Artikel + das Datenblatt selbst) ist besonders hilfreich. Fortgeschrittene konzentrieren sich am besten auf die Abschnitte, die den Prozessor, die Takterzeugung und den Reset-Block abdecken. Interessant ist auch noch die verwendete Peripherie. Außerdem sollte man sich mit der Dokumentation der sogenannten Tool-Chain vertraut machen. Nutzen Sie auch ausgiebig Software-Bibliotheken und Beispiele, um Ihr eigenes Verständnis zu vertiefen. Bei Fragen kann man sich auch in spezialisierten Foren helfen lassen.
 
Datenblätter können schwierig zu lesen und zu verstehen sein - sie sind nicht unbedingt für jeden die spannendste Form der Literatur. Sie sind jedoch (meistens) genau und bieten die notwendige technische Beschreibung der Funktionen. Anhand von Errata können Sie sehen, inwieweit sie Datenblättern vertrauen können. Wenn Sie sich durch die Dokumentation durcharbeiten, werden Sie mit der Zeit ein vertieftes Verständnis dafür entwickeln, wie sie aufgebaut und formuliert sind.
 

---

Lesen Sie alle Teile dieser Serie zur Mikrocontroller-Dokumentation!