Ladekapazität beträgt 6100 mAh

<p>Lithium-Akkus von Ultralife sind kompakt, flach, extrem leistungsfähig, weisen keinen Memory-Effekt auf und sind für mobile Anwendungen universell einsetzbar.

Eine gute Unterstützung für die Programmierung von Mikrocontrollern in der Hochsprache C ist das Ergebnis einer Reihe von Faktoren, die nicht so einfach beim Überfliegen des Datenblatts offensichtlich werden. Vielmehr liegen diese Details im Aufbau der Architektur begründet. Bei der Entwicklung der „Z8 Encore!“-Familie wurde das durch die moderne Prozesstechnik erweiterte Transistorbudget konsequent zur Optimierung der C-Programmierbarkeit genutzt.

Lithium-Akkus von Ultralife sind kompakt, flach, extrem leistungsfähig, weisen keinen Memory-Effekt auf und sind für mobile Anwendungen universell einsetzbar. Die aktuellste Neuentwicklung trägt die Bezeichnung UBBL07, verfügt über eine Kapazität von 6100 mAh bei einer Spannung von 3,7 V. Als Basis für das Akkumodul dienen Lithiumzellen vom Typ 18650, das Gewicht liegt bei 160 g. Der Akku hat als Anschluss einen 6,3 cm langen Kabelstrang, der mit einem vierpoligen Stecker abschließt.

Beck GmbH & Co.Elektronik Bauelemente KG

Tel. (09 11) 9 34 08 – 731
###www.beck-elektronik.de###

Für viele Mikrocontroller-Architekturen ist ihre Herkunft zu einer Zwangsjacke geworden. Fortschritte bei der Prozesstechnologie stellen den Mikrocontroller-Entwicklern mittlerweile wesentlich mehr Transistoren zur Verfügung, und das im Vergleich zu den vorhergehenden Generationen zu niedrigeren Kosten. Überraschend wenige Hersteller haben diese Fortschritte zur Verbesserung ihrer Mikrocontroller-Architekturen voll genutzt. Mit dem Aufkommen von C als Sprache der Wahl für viele Mikrocontroller-Anwendungen ermöglicht es die Verfügbarkeit einer größeren Zahl von Transistoren den Mikrocontroller-Anbietern, ihre Angebote zu verfeinern, die Code-Entwicklung besser zu unterstützen und die Leistung zu steigern.

Der Z8 Encore! ist durch eine Architektur gekennzeichnet, die die Veränderungen widerspiegelt, die durch den Fortschritt in der Siliziumprozesstechnik erst möglich gemacht wurden. Er optimiert darüber hinaus die CPU-Leistung, wenn in Hochsprachen wie C geschriebene Programme ablaufen.

Viele der frühen Mikrocontroller wurden direkt von Mikroprozessor-Architekturen abgeleitet, die Mitte der 70er Jahre erdacht wurden. Dabei lebten Merkmale der Architektur weiter, die nicht notwendigerweise auch für „embedded“ Steueraufgaben geeignet waren. Vielmehr war die Integration sowohl von Peripheriefunktionen als auch komplexer Speicherbereiche auf dem Chip von entscheidender Bedeutung.

Die Entwickler von Mikrocontrollern der frühen Generationen fällten ihre Entscheidungen im Wesentlichen aus Kostengründen, da jeder Transistor und I/O-Pin auf einem Chip von hohem Wert war. Deshalb verwenden noch heute viele die Von-Neumann-Architektur mit einem gemeinsamen Code- und Datenbereich, wobei lediglich ein einziger Bus den Prozessor und den zur Speicherung von Programmbefehlen und Daten verwendeten Speicher verbindet. Das Problem bei der Von-Neumann-Architektur: Da man sowohl Programm- als auch Datenzugriffe über denselben Bus abwickelt, kann es doppelt so lange dauern, um einen gegebenen Befehl auszuführen.

Die Harvard-Architektur (Bild 1) erlaubt den parallelen Zugriff auf Befehle und Daten über getrennte Busse. Sie ermöglicht also das Holen des nächsten Befehls, während der laufende Befehl seine Daten verarbeitet. Dieses Pipelining von Befehlen stellt sicher, dass die CPU stets zur Verarbeitung von Daten bereit ist, was ihren Gesamtwirkungsgrad verbessert. Ein größeres Transistorbudget macht es nicht nur durchführbar, sondern sogar wünschenswert, die Befehls- und die Datenspeicher zu trennen. Es ist also heute bei Mikrocontrollern sinnvoller, die rationellere Harvard-Architektur einzusetzen. Außerdem bietet diese Architektur einen weiteren Vorteil in Bezug auf eine einfache Programmierung: Durch die Trennung von Programm- und Datenspeicher ist ein unbeabsichtigtes Schreiben in den Programmspeicher weitgehend ausgeschlossen, so dass der im Programmspeicher untergebrachte Applikationscode sicherer vor Verfälschung ist. Das verbessert die Gesamtsicherheit und Zuverlässigkeit des Systems.

Jenseits von Harvard

Der Z8 Encore! geht über die klassische Harvard-Architektur hinaus. Er separiert nicht nur die Code- und die Datenbereiche, sondern er reserviert für den Steuerregister-Block einen dritten Bereich. Dadurch trennt die Architektur bei der Verarbeitung von I/O-Daten sauberer als dies viele Konkurrenzprodukte tun. Bild 2 zeigt den Speicherbelegungsplan (Memory Map) der „Z8 Encore! 64 Kbyte“-Familie.

In anderen Architekturen verursacht die Vermischung von Daten- und I/O-Bereichen Komplikationen für Linker-Tools, die zur Abbildung von im Compiler erzeugtem Code in den Adressbereich des Mikrocontrollers verwendet werden. Beim Z8 Encore! liegen die I/O- und die Steuerregister stets in den oberen 256 Byte des Registerbereichs, was dazu beiträgt, die Code-Kompatibilität zwischen den Mitgliedern verschiedener Familien zu erhalten.

Im Gegensatz zur klassischen Harvard-Architektur können beim Z8 Encore! Daten im Programmspeicher abgelegt werden. Der spezielle LDC-Befehl ermöglicht als einziger den Austausch zwischen Daten- und Programmspeicher – und zwar in beide Richtungen, also lesend und schreibend. Dies hilft dem Entwickler, den Speichereinsatz, besonders bei datenintensiven Anwendungen, zu optimieren. So ist es beispielsweise möglich, den Programmspeicher zum Speichern von Nachschlagetabellen (Look-up Tables) oder anderen Daten mit konstanten Werten im nicht-flüchtigen Speicherbereich zu nutzen. Das Programm kann diese Daten nutzen, ohne dass es die Nachschlagetabellen beim Booten in den Datenbereich kopieren muss, was den Datenbereich sonst zusätzlich einschränken würde.

Viele Mikrocontroller setzen eine auf Akkumulator-Registern basierende Architektur ein, bei der die gesamte Datenverarbeitung über ein einziges schnelles Register erfolgen muss. Dies machte durchaus Sinn, als die Chipfläche für den Prozessor-Kern von vorrangiger Bedeutung war, doch das ist jetzt nicht mehr der Fall. Die Entwickler des Z8 Encore! verwarfen die Akkumulator-basierte Architektur zugunsten einer großen universellen Registerdatei. Man unterschätzt leicht die Wichtigkeit einer direkten Register-zu-Register-Architektur hinsichtlich des durch einen C-Compiler erzeugten Codes, besonders wenn die Registerdatei vergleichsweise groß ist.

Ein Code-Beispiel für eine Akkumulator- und eine Universalregister-Architektur:

• Akkumulator-basierte MCU:

LD A, reg1    ;Laden von Operand 1
              ;in den Akkumulator
XOR A, reg2   ;Aithmetische
              ;Verknüpfung mit
              ;Operand 2
LD reg1, A    ;Ergebnis speichern

• Universalregister-basierte MCU:

XOR reg1, reg 2 ;Ausführen der 
                ;Arithmetik
                ;direkt im
                ;Zielregister

Compiler sind zum Einsatz vielfältiger Optimierungen ausgelegt, die sowohl zur Verbesserung der Zugriffsgeschwindigkeit von Datenvariablen dienen als auch die Durchführung redundanter Arbeitsgänge verhindern sollen.

Typischerweise sind bei jeder beliebigen Mikroprozessor- oder Mikrocontroller-Architektur die Zugriffe auf den Datenspeicher langsamer als die auf eine Registerdatei. Indem er eine große Registerdatei von bis 4 Kbyte zur Verfügung stellt, bietet der Z8 Encore! dem C-Compiler oder dem Assembler-Programmierer Gelegenheit, die Programmgeschwindigkeit zu verbessern, indem er häufig verwendete Variablen vom Datenspeicher in den Registerbereich verschiebt und vorkalkulierte Werte abspeichert, die wiederholt eingesetzt werden. Die meisten C-Compiler enthalten Optimierer, die beide Betriebsarten offerieren.