Da die ursprünglich von mir verwendete Yagarto-Toolchain von ihrem Entwickler Michael Fischer als »fertig« betrachtet wird, befürchte ich, dass diese nicht mehr weiter gepflegt wird. Aus diesem Grund habe ich den Wechsel auf die »GNU Tools for ARM Embedded Processors« vollzogen. Beim Kompilieren mit der Yagarto-Toolchain fiel auf, dass die Funktion _exit() in der Datei syscalls.c fehlt. Bei den GNU Tools ist diese Funktion implementiert, sodass diese Funktion hier nicht mehr implementiert werden darf, da sich sonst der Linker beschwert.

Theoretisch sollte der Wechsel der Toolchain keine Probleme bereiten, ganz sind diese aber nicht auszuschließen.

Einige der Beispiele in diesem Buch sind für die eingeschränkten Ressourcen des verwendeten Mikrocontrollers AT91SAM3S4B zu groß!

Der erste Schritt sollte in diesem Fall sein, die Größe des Stacks zu verringern: Mit 1 kByte (0x400) ist dieser in der Datei board_cstartup_gnu.c sehr großzügig bemessen.

Sollten die Ressourcen dann immer noch nicht ausreichen, empfiehlt sich die Verwendung der sogenannten Nano-Bibliotheken. Bei der Konfiguration des Linkers über Properties –> C/C++ Build –> Settings –> Cross ARM C Linker hängen Sie in diesem Fall in dem Eingabefeld, das Sie hinter Command: finden, die Optionen --specs=nano.specs -lc -lnosys an. Dies verringert die Größe des Programms um mehr als 50%. Nachteile habe ich hierdurch nicht festgestellt.

Allerdings muss bei Verwendung der Nano-Libs die Datei syscalls.c modifiziert werden: Kommentieren Sie hierfür die gesamte Funktion _exit() aus. Tun Sie dies nicht, beschwert sich wieder der Linker.

Die bereits in D.2 genannte Funktion _exit() wird in der Debug- bzw. der Release-Version unterschiedlich behandelt: In der Debug-Version ist _exit() implementiert, in der Release-Version fehlt sie. Wenn Sie also ein Projekt ohne Debug-Information freigeben wollen, muss die _exit()-Funktion zuvor wieder aktiviert werden, das heißt, die Kommentare müssen wieder entfernt werden.

Hier bin ich richtig in die Falle getappt: Nach einem empfohlenen Update des CDT, weil die ursprünglich von mir verwendete Version den End-of-Life-Status erreicht hatte, lief auf meinem System gar nichts mehr. Eine Unmenge an Fehlermeldungen machte die weitere Arbeit zur Qual. Ich habe schließlich das Entwicklungssystem vollständig neu aufgesetzt und die bis dahin entstandenen Beispiele vollständig überarbeitet.

Meine dringende Empfehlung lautet daher:

Wenn Sie ein lauffähiges Entwicklungssystem haben, ignorieren Sie die Aufforderung zu einem Update in diesem System! Installieren Sie stattdessen eine weitere Version von Eclipse und CDT und aktualisieren Sie nur dieses neue System! So bleibt Ihnen zumindest das lauffähige System erhalten.

Sporadisch kommt es auf meinem Entwicklungssystem immer wieder dazu, dass die Schaltfläche Build Project deaktiviert wurde. Ich kann diesen Effekt immer reproduzieren, wenn ich das Debug-Verzeichnis innerhalb des Projekts lösche, nicht selten kommt es aber auch vor, dass diese Schaltfläche »einfach so« deaktiviert wird. Abhilfe: Schließen Sie das Projekt und öffnen Sie es dann erneut. Die Schaltfläche ist dann wieder nutzbar.

Wenn Sie während des Debuggens von Projekten häufig die Meldung erhalten, dass der Source-Code der Datei, die der Debugger als Nächstes aufruft, nicht gefunden wird, sollten Sie prüfen, ob in der Debugger-Konfiguration (erreichbar über das Menü Run –> Debug Configurations...) im unteren Teil des Dialogs (schauen Sie sich hierzu noch einmal Abbildung 3.27 und hier den mit »5« markierten Punkt an): Dort steht der Eintrag Using GDB (DSF) Hardware Debugging Launcher. Obwohl dies den Empfehlungen entspricht (und die DSF-Version auch die modernere Variante darstellt), habe ich selber die Erfahrung gemacht, dass die alternative Einstellung Using Standard GDB Hardware Debugging Launcher weniger Probleme bereitet.

Die Entwicklungsphase einzelner Beispiele hat sich teilweise über mehrere Tage erstreckt, wobei ich immer wieder sogenannte »Milestones« definiert hatte. Da mich selber in meiner langjährigen beruflichen Praxis immer wieder Änderungen an meiner eigenen Software auf den berüchtigten »Holzweg« geführt haben, die nur mit sehr großem Aufwand wieder zu beheben waren, habe ich mir sehr frühzeitig angewöhnt, Versionierungstools, wie z.B. CVS, SVN (Subversion) oder GIT zu verwenden. Versionsverwaltungen können auf dem lokalen PC, einem lokalen Netzwerk oder in einer Cloud genutzt werden. Hierbei existieren Cloud-Dienste, die in eingeschränktem Rahmen (z.B. 2 GByte Speicherplatz) kostenlos nutzbar sind. Sehr bekannt sind beispielsweise die Dienste CloudForge, TeamForge und GitEye von CollabNet. Gegen Gebühr besteht hier auch die Möglichkeit, weitere Dienste, wie z.B. Bugzilla, Publisher, Trac und WebDAV, hinzuzubuchen. Vorteile von Cloud-Diensten sind beispielsweise, dass Source-Codes bei Bedarf an nahezu jedem Ort der Welt verfügbar sind und dass kein eigener Server vorgehalten und gewartet werden muss. Als Nachteil steht hier sicherlich, dass Cloud-Dienste im schlimmsten Fall »gehackt« werden. Da es aber nirgendwo absolute Sicherheit gibt (es sollen ja auch schon Firmen-Netzwerke gehackt worden sein), stellt dies meiner Ansicht nach kein besonders großes Problem dar.

• »ARM Microncontroller Interfacing – Hardware and Software«, Warwick A. Smith, Elektor International Media BV, 2010, ISBN 978-0-905705-91-0

• »Bauelemente der Elektronik (Elektronik 2)«, 6. Auflage, Klaus Beuth, Vogel-Verlag, Würzburg, 1980, ISBN 3-8023-0529-9

• »Grundschaltungen der Elektronik (Elektronik 3)«, 3. Auflage, Klaus Beuth und Wolfgang Schmusch, Vogel-Verlag, Würzburg, 1979, ISBN 3-8023-0555-8

• »Halbleiterschaltungstechnik«, 5. Auflage, Ulrich Tietze und Christoph Schenk, Springer-Verlag Berlin Heidelberg New York, 1980, ISBN 3-540-09848-8

• »Analoge Schaltungen«, 5. Auflage, Manfred Seibert, Verlag Technik GmbH Berlin, 1996, ISBN 3-341-01175-7

• »Digitale Schaltungen«, 5. Auflage, Manfred Seibert und Helmut Beikirch, Verlag Technik GmbH Berlin, 1998, ISBN 3-341-01198-6

• »Eclipse für C/C++-Programmierer«, 2. Auflage, Sebastian Bauer, dpunkt.verlag GmbH Heidelberg, ISBN 978-3-89864-715-1

• »SAM3S Series Datasheet« (DOC 6500), Atmel Corporation, San Jose, USA, 2013

• »RealView Compilation Tools Version 2.2«, ARM Ltd., UK, 2002–2005,

• »Cortex-M3 Devices«, ARM Ltd., 2010

• »HSMCI on SAM9G15/G25/G35/X25/X35 Microcontrollers« (DOC 11126), Atmel Corporation, San Jose, USA, 2011

• »Passive InfraRed Reference Design (PIRRD) for SAM3S Motion Detector Camera«, Atmel Corporation, San Jose, USA

• »Getting Started with CMSIS«, Doulos, UK, 2009

• »Cortex-M3 Technical Reference Manual (Rev. r1p1)«, ARM Ltd., UK, 2005/2006

• »SAM3-P256 User Manual (Rev. A)«, Olimex Ltd., UK, 2011

• »I²C-bus specification and user manual« (UM10204), NXP Semiconductors B.V., NL, 2012

• »SD Specifications Part 1 Physical Layer Simplified Specification (V 4.10)«, Technical Committee SD Card Association, 2013

• »Connecting the Atmel ARM-based Serial Synchronous Controller (SSC) to an I²S-compatible Serial Bus« (DOC 6020), Atmel Corporation, San Jose, USA, 2003

• Datasheet »1N/FDLL 914/A/B, 916/A/B, 4148, 4448 Small Signal Diode«, Fairchild Semiconductor, 2007

• »Datasheet XDMR14A, 14.2 mm SINGLE DIGIT NUMERICAL DISPLAY«, SunLED, China, 2005

• »Datasheet AV1640 16x4 Character Display«, ANAG VISION, Veröffentlicht durch dst GmbH, Deutschland

• »Datasheet LCD MODULE 164A (Version 1.0)«, Displaytech Ltd.

• »Datasheet T-1 3/4 (5mm) BI-COLOR INDICATOR LAMP (V7)«, Kingbright, 2005

• »Datasheet TLHG/R/Y460 High Efficiency LED 3mm«, Vishay Intertechnology Inc., USA

• »Datasheet BSS138 N-Channel Logic Level Enhancement Mode FET«, Fairchild Semiconductor, San Jose, USA, 2005

• »Datasheet MAX3232E«, Texas Instruments, Dallas, USA, 2007

• »Two-wire Serial EEPROM (DOC5279)«, Atmel Corporation, San Jose, USA, 2008

• »Datasheet EIA RS-485 Transceiver ADM485«, Analog Devices Inc., Massachusetts, USA, 2008

• »Datasheet 74HCT00«, Koninklijke Philips Electronics N.V., NL, 2003

• »Datasheet 74HC05«, NXP B.V., NL, 2009

• »Datasheet CD74HCT4511«, Texas Instruments, Dallas, USA, 2003

• »Datasheet 74HCT245 Octal Bus Transceiver«, SGS-Thomson, STMicroelectronics, USA, 1994

• »Datasheet TLP181 Toshiba Photocoupler«, TOSHIBA, JPN, 2007

• »Datasheet 2381 NTC Thermistors«, Vishay Intertechnology Inc., USA, 2005

• »Datasheet 2N2222 NPN Switching Transistors (Discrete Semiconductors)«, Philips Electronics N.V., NL, 1997

• »Comparing the I²C Bus to the SMBus«, http://www.maximintegrated.com/app-notes/index.mvp/id/476

• »System Management Bus, Specifications«, http://www.smbus.org

• »A Tutorial on Pointers and Arrays in C«, Ted Jensen, http://www.cs.dartmouth.edu/~chris/cs23/tedjensen/

1. http://www.mikrocontroller.net

2. http://www.stackoverflow.com

3. http://de.wikipedia.org

4. http://en.wikipedia.org

In den folgenden Tabellen finden Sie eine kleine Auswahl von Bezugsquellen für die erforderliche bzw. empfohlene Hard- und Softwareausstattung, die zur erfolgreichen Arbeit mit diesem Buch erforderlich ist bzw. werden kann. Selbstverständlich gibt es weitere Bezugsquellen, die aus Platzgründen hier leider nicht berücksichtigt werden können.

In Tabelle B4 finden Sie eine Auflistung der für die Arbeit mit diesem Buch benötigten Softwareausstattung.

Allgemein betrachtet existieren zwei Architekturen von Mikroprozessoren: RISC (Reduced Instruction Set Computer) und CISC (Complex Instruction Set Computer). Die RISC-Architektur verwendet im Allgemeinen wenige verschiedene (Assembler-)Befehle, bietet dafür aber eine Vielzahl von Registern. Bei der CISC-Architektur ist dies in der Regel genau anders herum: Einem recht umfangreichen Befehlssatz steht nur eine relativ geringe Anzahl von Registern gegenüber, die dann aber viel universeller nutzbar sind, was allerdings die Programmierung erschwert.

Eine andere Möglichkeit, die Architektur zu beschreiben, bezieht sich auf die Breite der Register. Typische Register haben eine Breite von 8, 16 oder 32 Bit. In jüngster Zeit (z.B. bei Apples iPhone) kommen aber inzwischen auch 64-Bit-Mikrocontroller zum Einsatz.

Ein dritter Ansatz, die Architektur von Mikroprozessoren zu beschreiben: Hier kommen die Begriffe Harvard-Architektur und Von-Neumann-Architektur. Der wesentliche Unterschied zwischen beiden Architekturen liegt in der Behandlung von Befehls- und Nutzdaten: Während in der Harvard-Architektur Befehle und Daten strikt voneinander getrennt sind, wird der Speicher in Von-Neumann-Architekturen von Befehlen und Daten gemeinsam genutzt.

Seit dem Jahr 1985 wurde die Architektur von ARM-Prozessoren mehrmals überarbeitet. Die aktuelle Architektur hat den Namen ARMv8, der in diesem Buch beschriebene Cortex-M3 gehört noch der Vorgängerarchitektur ARMv7 an.

Die ARM Holdings Inc. wurde ursprünglich als Advanced Risc Machines von der britischen Firma Acorn gegründet. Es handelte sich hierbei um die Auslagerung von Acorns Mikroprozessorsparte in Zusammenarbeit mit den Firmen Apple Computer (heute: Apple Inc.) und VLSI Technology.

Im Gegensatz zum Thumb-Befehlssatz (siehe unten) sind alle Befehle 32-bittig ausgelegt. Dies reduziert den Programmieraufwand und erhöht die Ausführungsgeschwindigkeit von Programmen, führt aber auch zu größeren Programmen, was bei Controllern, die nur über sehr geringe Hardware-Ressourcen verfügen (z.B. wenig Flash- oder SRAM-Speicher) von Nachteil sein kann. Das Mischen von ARM- und Thumb-Code ist möglich.

Modernere Varianten der ARM-Technologien besitzen mehrere CPU-Kerne, von denen der eine besonders leistungsfähig, aber energiehungrig ist, und der andere sehr energieeffizient bei geringerer Leistungsfähigkeit ist. Bei Anforderungen, deren Priorität niedriger angesetzt ist, wird dann der leistungsfähigere Kern abgeschaltet und nur der leistungsschwächere Kern verwendet.

Das BSS-Segment ist vergleichbar mit dem Heap. Der Unterschied besteht darin, dass Daten nicht initialisiert sind, das heißt, dass sie noch keine (definierten) Daten enthalten. Die Definition der Daten erfolgt erst während der Ausführung (der Laufzeit oder Runtime) eines Programms. Dem Compiler wird hier nur mitgeteilt, dass er bitteschön nicht den gesamten zur Verfügung stehenden dynamischen Speicher »verballern« soll.

CMSIS ist eine Abkürzung für Cortex Microcontroller Software Interface Standard. Hiermit hat die Firma ARM eine herstellerunabhängige Software-Bibliothek eingeführt, mit deren Hilfe die Entwicklung von Cortex-M-Software vereinfacht wird. Die Vereinfachung beruht darauf, dass durch den Einsatz dieser Software-Bibliothek Programme oder Teile hiervon wiederverwendet werden können. Eine weitere Vereinfachung besteht darin, dass die Cortex-Hardware abstrahiert wird, was gleichzeitig die Lernkurve flacher werden lässt. Durch die Wiederverwendbarkeit einzelner Module erreichen Neuentwicklungen darüber hinaus schneller die Marktreife. Auch die Portierung bereits existierender Software auf die Controller der Cortex-Baureihe wird hierdurch vereinfacht.

Die ersten Cortex-Mikrocontroller wurden mit der Architektur ARMv6 eingeführt und gelten als Nachfolger der sehr beliebten ARM7TDMI-Controller. Cortex-Controller stehen in optimierten Varianten für folgende Anwendungsgebiete zur Verfügung:

Cortex-A: Der Buchstabe »A« steht für Applications. Der Begriff »Applications« steht hierbei für die Unterstützung bzw. besondere Eignung der entsprechenden Controller für den Einsatz sogenannter »rich operating system (OS) platforms«. Typische Einsatzgebiete sind Smartphones, Set-top Boxes, digitale Fernsehgeräte etc., deren Funktionalität auf vollwertigen Betriebssystemen, wie z.B. (Embedded) Linux oder Android, basiert.

Cortex-M: Das »M« wurde dem zweiten Buchstaben des Wortes »Embedded« entnommen. Das bevorzugte Einsatzgebiet dieser Mikrocontroller sind Stand-Alone-Geräte ohne eigenes Betriebssystem. Typischerweise wird solche Software denn auch als Firmware bezeichnet.

Cortex-R: Mikrocontroller dieser Familie sind auf Echtzeitanwendungen (»R« = Real-time) optimiert. Überall dort, wo besonders schnelle Reaktionen auf bestimmte Ereignisse erforderlich sind (z.B. in der Automobilindustrie), können Cortex-R-Mikrocontroller gut eingesetzt werden.

Die Firma ARM hat in alle (mir bekannten) Mikrocontroller eine Debug-Einheit implementiert, die das Aufspüren von Fehlern in der Programmierung erheblich erleichtert. Es existieren verschiedene Möglichkeiten, diese integrierte Debug-Einheit zu nutzen, die allerdings nicht von allen Entwicklungsumgebungen unterstützt werden. Zu diesen Möglichkeiten zählen das JTAG-, das SWD- oder das OCD-Interface. Diese Interfaces können neben weiteren Möglichkeiten auch dazu genutzt werden, neue Programme in den Flash-Speicher des Controllers zu übertragen.

Der Begriff »Echtzeit-Betriebssysteme« ist einerseits sehr einfach zu erklären, andererseits meiner Meinung nach aber nicht sehr gut gewählt. Unter Echtzeit-Betriebssystemen versteht man solche Betriebssysteme, die sehr schnell auf Änderungen reagieren können. Dies erscheint logisch und einfach. Das »andererseits« hingegen muss die Frage erlauben: Wie ist Echtzeit denn definiert? Wenn gleichzeitig zwei unterschiedliche Ereignisse mit verschiedener Priorität eintreten, so wird das mit der höheren Priorität bevorzugt behandelt. Kann man in diesem Fall bei dem Fall des anderen Ereignisses noch von Echtzeit sprechen?

Hierbei handelt es sich um vollwertige Linux-Betriebssysteme, die auf die entsprechenden Mikrocontroller portiert wurden. Sie lassen sich im Regelfall an herkömmliche Monitore und Tastaturen anschließen, lassen aber häufig/meistens auch die Nutzung von Touch-Displays zu. Je nach geplantem Einsatzgebiet existieren sehr unterschiedliche Linux-Versionen. Einige sind sehr gut geeignet als NAS-Geräte, während andere besonders stark im Home-Entertainment sind.

FIFO ist die Abkürzung für »First-in first-out«: Der weiter unten bei der Erklärung des Begriffs »Stack« erwähnte Lagerraum hat hier zwei voneinander getrennte Bereiche für die Warenannahme und die Warenausgabe. Es gibt somit keine Verwechslungsmöglichkeit. Man kann sich das auch so vorstellen, dass Daten vom Eingang zum Ausgang weitergeschoben werden. Dies gilt natürlich dann auch für die Daten, die sich bereits im Lagerraum befinden: Diese werden immer weiter in Richtung des Warenausgangs geschoben, sodass die Daten, die zuerst im Lagerraum gespeichert wurden, auch zuerst den Ausgang erreichen.

Firmware ist nichts anderes als herkömmliche Software. Die Unterscheidung wird nur gemacht, um darauf hinzuweisen, dass die entsprechenden Geräte nur von den Herstellerfirmen vor der Auslieferung an den Kunden programmiert werden.

Der Heap ist ein dynamischer Speicher, der Daten temporär aufnehmen kann. Dabei ist es unerheblich, ob diese Daten relativ klein sind (im kleinsten Fall ein Byte) oder aber größere Bereiche einnehmen, die zur Aufnahme von Bild-, Audio- oder Videodaten geeignet sind. Die Verwaltung dieses dynamischen Speichers ist recht aufwendig. Da der Heap dynamisch mit Daten beschrieben bzw. Daten aus ihm gelesen werden können, kann der Heap nur im RAM (oder SRAM) liegen. Fehler in der Verwaltung werden häufig von böswilliger Software (sogenannter Malware) ausgenutzt.

JTAG ist die Abkürzung von Joint Test Action Group. Eine der verschiedenen Möglichkeiten, die interne Debug-Einheit einzusetzen. Ein typisches Beispiel nutzt der SAM-ICE (ICE = In-Circuit-Emulator​). Hiermit kann man Stellen in einem Programm markieren, an denen die weitere Ausführung des zu untersuchenden Programms unterbrochen werden kann. Von diesem Punkt aus kann man dann im Einzelschrittmodus​ (Single Step Tracing​) das weitere Verhalten dieses Programms detailliert untersuchen. Das dynamische Einleiten des Debug-Modus ist hiermit, anders als beim SWD, nicht möglich.

LIFO steht, wie auch bei der Erklärung des Stacks erwähnt, für »Last-in First-out«, das heißt, dass Stackdaten in der umgekehrten Reihenfolge ihres Eingangs wieder ausgeliefert werden. Einfach ausgedrückt: Neuere Daten haben Vorrang, alte Daten müssen warten.

OCD steht für On-Chip-Debugging. Dies ist der Oberbegriff für die verschiedenen Debugging-Optionen, die von ARM unterstützt werden (siehe auch JTAG, SWD).

SAM-BA ist die Abkürzung für Boot Assistent (BA) für SAM-Mikrocontroller. Hierbei handelt es sich um Programmcode, der von ARM in einen geschützten und daher vom Programmierer nicht manipulierbaren Bereich fest einprogrammiert wurde, der dafür sorgt, dass sich der Prozessor nach einem Reset selber »in das Reich der Lebenden« begeben kann. Selbstverständlich ist es möglich, sich seinen Boot-Loader auch selber zu schreiben. Die Wahrscheinlichkeit, dass dies erforderlich wird, ist relativ gering.

Der Stack dient zur Speicherung von Daten, die aufgrund spezieller Ereignisse gesichert werden müssen. Diese speziellen Ereignisse können Aufrufe von Unterprogrammen oder Interrupt-Anforderungen sein. Beide genannten Ereignisarten veranlassen den µC dazu, den normalen Ablauf eines Programms zu unterbrechen und an einer anderen Stelle mit der Behandlung dieses Ereignisses fortzufahren, bevor das Programm an der Stelle fortfährt, an der das Ereignis aufgetreten ist. Damit das Programm an dieser Stelle wieder fortgesetzt werden kann, muss mindestens die entsprechende Adresse, die sogenannte Rücksprungadresse, gespeichert werden. Hierfür wird der sogenannte Stack verwendet. Nicht selten werden in den Unterprogrammen bzw. Interrupt-Serviceroutinen auch Register der CPU mit anderen Werten überschrieben (dies ist aber nur in reinen Assembler-Programmen zu erwarten). Dann obliegt es der Aufmerksamkeit des Programmierers, dass die Inhalte dieser Register ebenfalls gesichert werden. Geschähe dies nicht, würde das Programm mit anderen Werten als erwartet fortfahren, was im Allgemeinen zu fatalen Fehlfunktionen des gesamten Programms führen wird. Anders als beim Heap-Speicher ist der Zugriff auf den Stack nicht wahlfrei: Die Daten werden in der umgekehrten Reihenfolge, in der sie auf dem Stack gespeichert wurden, wieder an das Programm zurückgeliefert. Man spricht in diesem Zusammenhang von einem sogenannten LIFO-Prinzip, wobei LIFO für »Last-in First-out« steht. Man kann sich das als einen Lagerraum vorstellen, dessen Zugang für die Warenannahme und die Warenausgabe gemeinsam genutzt wird. Der Stack liegt wie auch der Heap immer im RAM (bzw. SRAM). Vergleiche hierzu auch FIFO.

SWD steht für Serial Wire Debug: Hierbei handelt es sich um eine modernere Möglichkeit zum Debuggen (verglichen mit JTAG). So ist es beispielsweise auch möglich, den Debug-Modus auf die Änderung einzelner Werte triggern zu lassen (Single Step Tracing) bis zu dem Punkt, der näher untersucht werden soll. Hierdurch kann praktisch der Debug-Vorgang dynamisch gestartet werden. Diese Möglichkeit wird meines Wissens aber nur durch kommerzielle Entwicklungsumgebungen mit entsprechend hohem Preis abgedeckt.

TDMI bezeichnet folgende Merkmale von ARM-basierten Mikrocontrollern: Das »T« steht für Thumb (Daumen, siehe auch Thumb-Befehlssatz). Das »D« weist darauf hin, dass der Controller Erweiterungen für das Debuggen enthält. Das »M« zeigt an, dass der Controller eine 32x8-Einheit zum Multiplizieren enthält. Das »I« schließlich bedeutet, dass der Controller In-Circuit-Emulatoren unterstützt.

Die sogenannte »Text section« oder auch Text-Segment ist der Speicherbereich, in dem der von einem Compiler erzeugte Programmcode (also der Maschinencode und nicht zu verwechseln mit dem Quelltext) gespeichert wird. Früher wurden für diesen Bereich ROMs, PROMs oder EPROMs eingesetzt; moderne Mikrocontroller stellen hierfür Flash-Speicher zur Verfügung. Dieser Speicher kann während der Ausführung eines Programms nicht mit anderen Daten überschrieben werden. In Linkerscripts wird dieser Bereich daher auch häufig mit RO bzw. R/O bezeichnet, was für »Read only« steht. Um diesen Speicher zu überschreiben, muss der Prozessor in einen speziellen Modus versetzt werden, der im »normalen« Programm üblicherweise nur durch eine besondere Aktion (z.B. eine trickreiche Tastenkombination, die im üblichen Betrieb nicht verwendet und auch selten im Handbuch dokumentiert wird) erreicht wird. In diesem Modus ist es dann z.B. möglich, eine neue Firmware in Form eines Updates »einzuspielen«.

Kernpunkt ist, dass ARM hier 16-Bit-Befehle vorgesehen hat, obwohl die Register 32 Bit breit sind. Aus Sicht des Assemblerprogrammierers ergibt sich somit, dass im Regelfall ein höherer Programmieraufwand erforderlich ist bzw. sein kann, die Gesamtgröße des Codes aber dennoch deutlich kleiner ausfällt. Dies ist besonders dann wichtig, wenn beispielsweise nur sehr wenig Speicher zur Verfügung steht. Als Nachteil wird häufig angeführt, dass die Ausführungsgeschwindigkeit der Programme geringer ist. Das Mischen von ARM-Code (32 Bit) mit Thumb-Code (16 Bit) ist möglich.