Mit der neuen LPC4300-Familie kombiniert NXP einen ARM Cortex-M4 mit einem Cortex-M0. Das Resultat ist eine asymmetrische Dual-Core-DSC-Architektur (Digital Signal Controller). Der Cortex-M4 verbindet die Vorteile eines Mikrocontrollers (Interrupts, Stromsparen, Debugging, einfache Entwicklung) mit leistungsfähigen DSP-Funktionen, etwa Single-Cycle-MAC, SIMD (Single Instruction Multiple Data), Arithmetik mit Sättigungsverhalten sowie eine Gleitkommaeinheit. NXP nutzt im LPC4300 alle optionalen Blöcke, die ARM mit dem Cortex-M4 anbietet: Wake-up-Steuerung, NVIC (Nested Vectored Interrupt Controller), Gleitkommaeinheit und MPU (Memory Protection Unit) fehlen ebenso wenig wie der gesamte Bestand an Debug- und Trace-Funktionen. Dazu kommt eine Menge Speicher: bis zu 1 MByte Flash und bis zu 264 KByte SRAM. Hervorzuheben sind ferner die konfigurierbaren Peripheriefunktionen SPI-Flash-Interface, State-Configurable-Timer-Subsystem und die so genannte Serial-GPIO-Funktion.
Der Cortex-M0 dient als Co-Prozessor und übernimmt zahlreiche Datenbewegungs- und I/O-Aufgaben, die sonst den Cortex-M4 belasten würden. Letzterer kann sich deshalb auf Rechenaufgaben konzentrieren. Für Entwickler stellt sich also damit die Frage: Wie verteilt man seine Software auf beide Prozessorkerne und wie kommunizieren die miteinander?
Dual-Core-Architektur des LPC4300
Welche Argumente sprechen überhaupt für einen Dual-Core-Baustein? NXP stellte fest, dass sich der Cortex-M4 hervorragend für Algorithmen, Signalverarbeitung sowie Steuerungsalgorithmen für die Audioverarbeitung eignet. Um dessen Möglichkeiten optimal auszuschöpfen, erachtete man es als sinnvoll, einem Coprozessor – in diesem Fall einem Cortex-M0 – die Echtzeitsteuerung der Peripheriefunktionen zu übertragen, möglicherweise ergänzt durch eine Protokollemulation für USB oder CAN. Es besteht somit eine klare Arbeitsteilung: der Cortex-M4 ist für die Verarbeitungsaufgaben zuständig, der Cortex-M0 für die Echtzeitsteuerung. Diese Architektur macht es möglich, mit dem Cortex-M4 ein Maximum an Performance zu erzielen.
Beide Prozessoren verfügen zur Interrupt-Steuerung über jeweils einen eigenen NVIC. Wichtiger noch: beide sind an die interne Busmatrix angeschlossen und können deshalb auf alle Speicher- und Peripherie-Ressourcen zugreifen. Takt und Stromversorgung werden separat geregelt, sodass es möglich ist, einen Core herunterzufahren, während der andere aktiv bleibt. Ein ROM-residentes API implementiert außerdem einen IPC-Mechanismus, der die Synchronisation von Tasks zwischen Cortex-M4 und Cortex-M0 erleichtert.
Beide Cores haben über die AHB-Busmatrix Verbindung zu sämtlichen Speichern und Peripheriefunktionen. Wenn die Systemarchitektur also sorgfältig geplant ist und man dafür Sorge trägt, dass sich die vom Cortex-M0 zu verarbeitende Applikation in einem anderen Speicherbereich befindet als die Applikation des Cortex-M4, ist gewährleistet, dass beim Laden von Befehlen keine Buskonflikte auftreten. Beide Cores können mit einer maximalen Taktfrequenz von 150 MHz arbeiten und gemeinsam die größtmögliche Performance erreichen.
Anwendungsbeispiele
Das Beispiel eines Systems, das Audiosignalen verarbeitet, verdeutlicht die Aufgabenteilung zwischen Cortex-M4 und Cortex-M0: Der M4 kann vollständig der Graphic-Equalizer-Funktion vorbehalten bleiben und muss sich in keiner Weise um die Interrupts und Protokolle kümmern, die ins Spiel kommen, wenn Daten per USB übertragen oder per I²S an ein Headset ausgegeben werden. Für all diese Peripheriefunktionen ist der M0 zuständig, der via USB beispielsweise Daten von einem PC erhält. Er entfernt die Header und legt die Daten in einem gemeinsamen Pufferspeicher ab. Von dort übernimmt sie der Cortex-M4, um sie zu verarbeiten und wieder in den Puffer zu legen, woraufhin sie der Cortex-M0 per I²S ausgibt.
Die Arbeitsteilung ist dank der AHB-Busmatrix ohne allzu große Buskonflikte möglich. Der Cortex-M0 kann über verschiedene Busverbindungen auf die APB-Peripherie (Advanced Peripheral Bus) und das USB-Interface zugreifen, während der Cortex-M4 wiederum – über eine andere Busverbindung – auf den Speicher zugreift. Da es während dieser Operationen zu keinerlei Konflikten kommt, können alle mit maximaler Performance ablaufen.
Als weiteres Beispiel ist eine einfache Motorregelung denkbar, bei der beide Prozessoren mit Peripherie interagiert. Beide Cores haben Zugriff auf alle Speicher- und Peripherie-Ressourcen, und damit lässt sich das System so konzipieren, dass sich der Cortex-M4 mithilfe des SCT um die Motorregelung kümmert, während sich der Cortex-M0 um die Protokollverarbeitung für das CAN-Interface kümmert und unter anderem Befehle empfängt und Bestätigungen sendet.
Debugging eines Dual-Core-Systems
Beide Cores sind an ein gemeinsames Jtag-Interface angeschlossen. Per J-Link, U-Link oder über das Debug-Interface ist die Kommunikation mit beiden Cores möglich, die dabei wie zwei beinahe separate Mikrocontroller behandelt werden. Bei der Entwicklung von Software in verschiedenen Einzelprojekten kann diese per Jtag in den internen Speicher des LPC4300 geladen werden, um anschließend wahlweise die Cortex-M4- oder die Cortex-M0-Applikation zu debuggen.
Es ist möglich, die Cortex-M4-Applikation auszuführen und den Cortex-M0 im Single-Step-Betrieb laufen zu lassen, um Variablen zu überwachen oder Breakpoints zu setzen. Dabei kann man die Cortex-M0-Applikation entweder per Debugger anhalten oder in den normalen Betriebsmodus versetzen, um anschließend die gleichen Maßnahmen (Single-Step-Betrieb, Breakpoints setzen, Variablen beobachten) mit dem Cortex-M4 vorzunehmen. All dies ist mit einem einzigen J-Link- oder U-Link-basierten Jtag-Debugger sowie zwei Instanzen der verwendeten IDE mit den Projekten für den Cortex-M4 und den Cortex-M0 möglich.
Trotz oder gerade wegen der beiden Kerne ist das Entwickeln für den LPC4300 kaum schwieriger als bei Single-Core-Systemen. Praktischerweise gibt es ein pinkompatibles Gegenstück auf Cortex-M3-Basis, sodass man mit der einfacheren Architektur beginnen kann. Seine Stärke zeigt der Cortex-M4 vor allem bei DSP-intensiven Aufgabe. Für dieses Feld hat ARM kürzlich die CMSIS-DSP-Library mit 61 Algorithmen angekündigt, die die Softwareentwicklung weiter vereinfacht.
Peripherie
Zu den speziellen, konfigurierbaren Peripheriefunktionen von NXP, die in der LPC4000-Familie verfügbar sind, gehören ein State-Configurable-Timer, ein SPI-Flash-Interface und ein Serial-GPIO-Interface. Der State-Configurable-Timer-Subsystem ist im Prinzip ein gewöhnlicher Timer, ergänzt durch State- und Event-Logik. Mit dem SPI-Flash-Interface ist es möglich, einen externen seriellen Speicher exakt wie einen internen, in das Adressierungsschema eingebundenen Speicher erscheinen zu lassen. Es werden Datenraten bis zu 40 MByte/s unterstützt, und die Verarbeitung von Code aus diesem Speicher ist ebenfalls möglich. Es ist kompatibel sowohl zu standardmäßigem SPI-Flash als auch zu Quad-SPI-Flash. Bei der Serial-GPIO-Einheit, handelt es sich um GPIO-Funktion im Verbund mit einem Timer-Schieberegister. Mikrocontroller müssen häufig mit nicht standardkonformen Interfaces arbeiten. Das so genannte Bit-Banging, auf das man hierfür oft zurückgreift, ist extrem CPU-intensiv.
Einige Vertreter der Familie bieten weitere Peripheriefunktionen, etwa zwei HS-USB-Controller, On-Chip-HS-PHY, einem 10/100T Ethernet-Controller mit hardwaremäßiger TCP/IP-Prüfsummenberechnung oder ein hochauflösenden Farb-LCD-Controller. Zu den Standard-Features der LPC4000-Familie gehören 32 KByte ROM für Boot-Code und Chip-interne Treibersoftware, AES-128-Entschlüsselung (einige Bausteine auch mit Verschlüsselungsfunktionen), ein achtkanaliger General-Purpose-DMA-Controller (GPDMA), zwei 10-Bit-ADCs und ein 10-Bit-DAC mit einer Wadlerrate von 400 KSample/s, ein Motorregelungs-PWM- und Quadratur-Encoder-Interface, vier UARTs, zwei Fast-Mode Plus I²C-Schnittstellen, ein I²S-Interface, zwei SSP/SPI-Schnittstellen, ein Smartcard-Interface, vier Timer, ein Windowed-Watchdog-Timer, ein Alarm-Timer, eine sparsame Echtzeituhr mit 256 Bytes an batteriegepufferten Backup-Registern sowie bis zu 146 General-Purpose-I/O-Pins
Gordon Cooper
(lei)
