neu übersetzen, ohne daß es zu Fehlermel-
dungen kommt. Zumindest bei (mathemati-
schen) Algorithmen kann man so durch Über-
nahme vorhandener Quellen viel Zeit sparen.
Weniger erfolgversprechend hingegen ist der
Transfer von Programmteilen, die bestimmte

Der HC12 ist ein typischer CISC-
Mikrocontroller und verfügt damit
über vergleichsweise viele Befehle
mit vergleichsweise komplexer Wir-
kungsweise. Tendenziell lässt sich
solch ein Controller leichter in
Assembler programmieren als Ver-
treter der RISC-Fraktion. Letztere
verleiten (notwendigerweise) zu
Spaghettikode, also langen und
dementsprechend unübersichtlichen
Kodesequenzen. Das muß kein
Nachteil sein, solange man die
Kodegenerierung einem Compiler
überläßt. Da wir aber mit Assem-
blersprache einsteigen wollen,
kommt uns der HC12 gerade recht.
Fast 200 verschiedene Befehle
machen die Assemblersprache des
HC12 aus - das klingt für den Ein-
steigen nach einer entmutigenden
Menge. Dennoch handelt es sich kei-
neswegs um ein aussichtsloses
Unterfangen, denn die Befehle sind
einerseits in logischen Gruppen
zusammengefaßt, andererseits kom-
men nicht alle Befehle gleicher-
maßen häufig zum Einsatz. Geht
man das Problem schrittweise an,
kann man sich das Befehlsgewusel
nach und nach ganz gut erschließen.

Vom HC11 zum HC12

Besonders einfach haben es bishe-

rige HC11-Anwender. Sie finden all
die vertrauten HC11-Befehle beim
HC12 wieder, müssen sich also gar
nicht erst umstellen. Vorhandene
HC11-Programme kann man mit
einem geeigneten HC12-Assembler

MIKROPROZESSOR

49

12/2000

Elektor

16-Bit-

Mikrocontroller HC12

Teil 2. Programmierung und Tools

Von Dipl.-Ing. Oliver Thamm

Nachdem sich im ersten Teil unseres HC12-Beitrags alles um die
Hardware drehte, geben wir diesmal einen Überblick über die
Programmierung und die dazu erforderlichen Tools.

Bild 1. NoICE - ein typischer Vertreter der grafischen BDM-Debugger.

Steuerregister des Controllers ansprechen.
Ganz klar wird ein HC11-Programm, das die
serielle Schnittstelle (SCI) anspricht, auf dem
HC12 nicht mehr funktionieren, wenn sich die
Adresse und die Bedeutung der SCI-Steuer-
register verändert hat.
Der HC12 ist aber keineswegs nur als
schnellerer, kompatibler HC11-Nachfolger
zu verstehen. Die neue Controllerfamilie
bringt eine Menge zusätzlicher Verbesse-
rungen, beispielsweise neue Befehle und
Adressierungsarten. In der nebenstehenden
Übersicht werden einige wichtige Neue-
rungen erläutert.

Programmiertools

Um den HC12 programmieren zu können,
benötigt man, wie bei jedem anderen Mikro-
prozessor auch, eine Reihe von Hilfsmitteln.
Das beginnt mit einem PC, auf dem man mit
einem (Programmier-) Editor Quellprogramme
schreibt und mittels Crossassembler oder -
compiler in Maschinensprache übersetzt.
Danach muß man das fertige Programm (Neu-
deutsch: das Executable) auch noch zum Ziel-

system übertragen. Schließlich soll
es vorkommen, daß die selbstge-
schriebene Software nicht gleich auf
Anhieb funktioniert. Demzufolge ist
es ratsam, einige Ideen und Hilfs-
mittel zum Debuggen vorzuhalten.
Am Anfang steht immer der Quell-
text. Um sich Programme auszuden-
ken, sollte man sich einen guten Pro-
grammiereditor zulegen. Das Krite-
rium “qualitativ hochwertig” ist
dabei weniger am Preis festzuma-
chen. Man sollte eher darauf achten,
daß man persönlich mit der Soft-
ware auch gut zurechtkommt. Gute
Erfahrungen hat der Autor mit PFE
(Programmers File Editor) gemacht,
ein frei erhältliches Tool von Alan
Phillips.

Übersetzer

Im nächsten Schritt übergibt man
den Quelltext an einen Assembler.
Dieser versucht, im Programm syn-
taktische Fehler aufzuspüren. Ist
alles (soweit) fehlerfrei, erhält man

ein Programm in Maschinensprache.
Bei Motorola-Prozessoren hat sich
dafür das S-Record-Format etabliert.
Bei einem solchen S-Record-File han-
delt es sich um eine Textdatei, die
sowohl alle Kodebytes des erzeugten
Maschinenprogramms repräsentiert,
als auch die Information, an welche
Adressen die Bestandteile des Pro-
gramms geladen werden sollen.
Für den HC12 gibt es bereits eine
erkleckliche Anzahl von Assemblern
unterschiedlicher Hersteller. Wer im
Besitz eines C-Compilers für den
HC12 ist (zum Beispiel dem preis-
günstigen ICC12 von ImageCraft),
hat diesbezüglich ausgesorgt, denn
ein Assembler ist in den Crosscom-
pilern stets enthalten. Man hat also
die Wahl zwischen Assembler, C
oder einer Kombination aus beidem.
Einsteigen sollte man auf jeden Fall
zunächst mit Assemblersprache,
denn nur so sieht man unmittelbar,
wie die Interaktion zwischen Hard-
ware- und Softwarekomponenten
des Mikrocontrollers vonstatten
geht. Die so gewonnenen Einblicke
kann man gut gebrauchen, wenn
man sich später den Hochsprachen
widmet. Wer sich auf die Suche nach
einem geeigneten Assembler begibt,
wird bald auf den Namen Alfred
Arnold stoßen. Der Autor des Uni-
versalassemblers AS hat den HC12
schon seit 1996 mit im Programm.
Zwei Vorteile zeichnen AS beson-
ders aus: Er ist hinsichtlich des Pro-
zessortyps universell einsetzbar,
also auch für den HC11 und eine
ganze Reihe anderer Mikrocontroller
geeignet. Und er ist frei erhältlich -
ein Kriterium, das besonders bei Pri-
vatanwendern Überzeugungskraft
besitzt.
Das Schreiben von Assemblerpro-
grammen ist sicherlich nicht ganz
einfach, Erfahrung muß man erst in
der Praxis sammeln. Wer noch gar
nichts davon versteht, sollte sich in
den Büchern zum HC11 von Sturm
[1] und Wallrabe [2] informieren. Was
man dort über den HC11 lernt, kann
man sogleich wieder beim HC12 zur
Anwendung bringen.
Die Bedienung des Assemblers ist
recht trivial - zumindest im Vergleich
zum Entwerfen der Quelltexte. Der
Kasten zeigt eine Beispielsequenz in
Form einer DOS-Batchdatei, die den
Assembler aufruft, die gewünschte
Assemblerdatei übergibt und

MIKROPROZESSOR

50

Elektor

12/2000

Neue HC12 Befehle

MOVB #$0D,$1234

Um eine Konstante in eine bestimmte Speicherzelle zu schreiben, mußte man beim HC11
immer das LDAA-STAA-Spiel spielen. Danach war aber der Wert im Akku weg! Abhilfe
schaffte eine Umrahmung mit PSHA und PULA. Zum Glück bringt der HC12 den lange
ersehnten Move-Befehl mit, der diese Prozedur verkürzt.

DBNE B,Loop

Überall Schleifen! Mit dem gezeigten “Decrement and Branch if not equal” Befehl ist diese
wichtige Grundstruktur, die man in jedem Assemblerprogramms dutzendweise antrifft,
ganz einfach zu implementieren!

LDAA 1,X+

Was wird hier in den Akku geladen? Der Wert, auf den das Indexregister X verweist. Ein
alter Hut? Mitnichten, denn nebenbei wird hier X inkrementiert (also um 1 erhöht). Da
kann man auf den alten HC11-Befehl INX fast verzichten. Vor allem, wenn man um 2, 3,
4... inkrementieren will!

LBRA Label

Mit BRA sprang man schon beim HC11 - aber immer zu kurz. LBRA macht Schluß mit dem
8-Bit Sprungbereich. Der Befehl benötigt allerdings auch ein Byte mehr.

EXG D,X

Kennen Sie XGDX? Das hier ist dasselbe. Und der Vorteil? EXG funktioniert mit jeder Regi-
sterkombination, sogar 8 und 16 Bit kann man mischen!

PSHD

PSHB, PSHA kann man jetzt auch schneller haben. PSHD erledigt die ganzen 16 Bit am
Stück.

SEX

wurde aufgenommen, damit sich das CPU12 Reference Manual besser verkauft. Den Befehl
“Sign EXtend” kann man aber auch in C-Compilern gut gebrauchen.

MIKROPROZESSOR

51

12/2000

Elektor

Tipps und Tricks beim Programmieren

Wenn das Programm endlich fertig ist, aber trotzdem nicht funktioniert, dann ist guter Rat
oft teuer. Es gibt aber ein paar besonders häufige Fehler beziehungsweise Probleme. Die
fünf wichtigsten Fallen bei der HC12-Programmierung:

COP

Viele Programmierer standen schon kurz vor dem Verzweifeln, wenn der Code im Moni-
torprogramm oder mit dem Debugger prima funktionierte, aber schließlich “stand-alone”
keinerlei Reaktion mehr von sich gab. Häufige Ursache: Der Watchdog-Timer (COP) ist
nach Reset aktiv! Auch wenn man dieses Feature nicht benutzt, muß man sich darum küm-
mern. Zumindest muß man ihn gleich nach Reset abschalten!

Program Counter

Nach einem Reset holt sich die CPU ein Wort von den Adressen $FFFE und $FFFF. Dieses
Wort enthält den Resetvektor und bestimmt, wo die CPU mit der Ausführung von Maschi-
nenbefehlen beginnt. Wenn im eigenen Programm gar nichts laufen will, dann sollte man
sich an die hilfreiche Existenz des Resetvektors schnellstens erinnern!

Stack Pointer

Der Stack Pointer wird von der CPU bei jedem Unterprogrammaufruf benutzt. In diesem
RAM-Bereich merkt sich der Controller Daten vorübergehender Lebensdauer. Kommt es
zu undefinierbaren Abstürzen (insbesondere nach einiger Zeit erfolgreicher Programmier-
bemühungen), dann sollte man den Stack-Bereich einmal kritisch unter die Lupe nehmen.
Prüfen sollte man: Wird der Stackpointer auf den korrekten RAM-Bereich initialisiert? Gibt
es Überschneidungen mit anderen Nutzungen des RAM? Ist der Stackbereich ausreichend
dimensioniert?

Interrupts

Interrupts können ein laufendes Programm asynchron, also an einer nahezu beliebigen
Stelle unterbrechen. Unschön ist es nur, wenn die Interruptroutine nie wieder zum Haupt-
programm zurückkehrt. Liegt diese Vermutung nahe, sollte man auf jeden Fall zwei Dinge
sofort prüfen: Endet die Interruptroutine korrekt mit dem Befehl ISR? Und werden lokale
Interruptflags in der Routine korrekt gelöscht? Ohne Freigabe der lokalen Interruptflags
dreht man sich nur im Kreise - der Interrupt ist nach Beendigung der ISR immer noch
anhängig und so geht es halt wieder von vorne los...

Monitor vs. Interruptvektoren

Wird auf dem Zielsystem ein Monitorprogramm verwendet, dann “blockiert” dieses mei-
stens die am Ende des Adreßraumes liegenden Interruptvektoren. Um diese dennoch
durch das Anwenderprogramm nutzen zu können, ist es üblich, daß der Monitor die (selbst
nicht besetzten) Vektoren in einen RAM-Bereich leitet. Dort kann der Anwender so
genannte Pseudo-Interruptvektoren eintragen, die aus einem 3-Byte Sprungbefehl der Art
JMP Addr bestehen. HC11-Kennern wird das Verfahren vertraut vorkommen, dort kam es
beim Special Bootstrap Mode zum Einsatz.

Aufruf der Assembler AS

@echo off
rem
rem -L erzeugt xxx.lst
rem -E erzeugt xxx.log (Fehlerliste)
rem
c:\as\bin\as.exe %1.a -L -E -g noice
rem
rem -F Moto legt S-Record Output fest
rem +5 entfernt S5-Records
rem -r dehnt das Image Fenster aus
rem
c:\as\bin\p2hex %1.p %1.s19 -F Moto +5 -r $0000-$ffff
if exist %1.p del %1.p

schließlich (bei AS in einem separa-
ten Schritt) das ladbare S-Record-File
erzeugt. Die gezeigte Batchdatei
kann man per Hotkey gleich aus dem
Editor PFE heraus aufrufen, das
sorgt für ein wenig Komfort beim
Programmieren.

Transferierer

Bald kommt der spannende Moment,
in dem wir das fertige Programm
zum ersten Mal starten. Zunächst
aber muß es in den Speicher des
Zielsystems geladen werden. Dazu
gibt es mehrere Möglichkeiten.
Beginnen wir mit der klassischen
Monitor-Variante. In diesem Fall
befindet sich auf dem Controllerbo-
ard ein Monitorprogramm. Dieses
Stück Firmware belegt einem klei-
nen Bereich des Zielsystem-Spei-
chers, etwa im EEPROM der MCU.
Schließt man das Zielsystem seriell
an den PC an, kann man die Start-
meldung des Monitorprogramms
beobachten. Man benötigt hierzu auf
der PC-Seite ein Terminalprogramm,
um ankommende Zeichen auf dem
Bildschirm darzustellen sowie Tasta-
tureingaben des Benutzers über die
serielle Schnittstelle zum Zielsystem
zu senden.
Das Terminalprogramm sollte zudem
eine Upload-Funktion haben, um
eine Datei von der Festplatte des
PCs zum Zielsystem zu übertragen.
Diese Funktion benötigt man zum
Laden des HC12-Programms in Form
einer S-Record-Datei. In der Praxis
läuft das wie folgt ab: Zunächst star-
tet das Monitorprogramm und man
sieht im Terminalfenster die
Begrüßungsmeldung. Nun kann man
über die Tastatur den Ladebefehl
eintippen, beispielsweise
L<ENTER>. Daraufhin meldet das
Monitorprogramm die Bereitschaft,
jetzt eine S-Record-Datei entgegen-
zunehmen. Man startet daraufhin im
Terminalprogramm die Upload-Funk-
tion, wählt die gewünschte Datei
aus und der PC sendet diese zum
Zielsystem. Bei Erreichen des Datei-
endes meldet sich der Monitor mit
dem Systemprompt zurück - die Pro-
gramm befindet sich nun im Spei-
cher des HC12-Systems.
Wichtig bei der Auswahl eines
geeigneten Terminalprogramms ist
lediglich, daß auch Timingbedingun-
gen des Zielsystems berücksichtigt

MIKROPROZESSOR

52

Elektor

12/2000

Beispielprogramm serielle Schnittstelle

;====================================================================;

; File: SCI12.A
; Func: Serial-I/O via the Serial Communication Interface (SCI0)
;====================================================================;

; CPU 68HC12
; include “reghc12.inc”

SC0BD equ SC0BDH
SC0CR equ SC0CR1

; Func: Initialize SCI (9600 Baud, 8N1, Polling Mode)
; Args: -
; Retn: -
; Dest: D
;
initSCI ldd #26 ; 19200 Bd

std SC0BD
ldd #$000c ; 8N1, TE + RE
std SC0CR ; A:B -> SC0CR1:SC0CR2
rts

; Func: Test if any character available (received)
; Args: -
; Retn: A = 0 (Z = 1) -> no char
; A <> 0 (Z = 0) -> char available
; Dest: -
;
testSCI ldaa SC0SR1 ; read status

anda #$20 ; receive data reg full?
rts ; returns 0, if no data

; Func: Get character from SCI (wait for)
; Args: -
; Retn: A = char
; Dest: -
;
getSCI brclr SC0SR1,$20,getSCI ; receive data reg full?

ldaa SC0DRL ; read out data
rts

; Func: Send a character via SCI
; Args: A = char
; Retn: -
; Dest: -
;
putSCI brclr SC0SR1,$80,putSCI ; transmit data reg empty?

staa SC0DRL ; send data
rts

weiteres Fenster den Inhalt des Programm-
speichers in disassemblierter Form an. Man
kann in diesem Fenster Unterbrechungs-
punkte eintragen und den Programmverlauf
im Einzelschrittbetrieb verfolgen (Bild 1).
Soviel Komfort hat natürlich seinen Preis. Für
grafische Debugging-Tools der Profiliga (zum
Beispiel Cosmics ZAP) muß man einige tau-
send Mark einplanen. Natürlich ist dies
durchaus gerechtfertigt, wenn man auf eine
möglichst große Zahl leistungsfähiger Pro-
grammfeatures zurückgreifen möchte. Sind
die Ansprüche etwas moderater, kann man
aber auch für wesentlich kleinere Beträge
interessante Debugginglösungen für den
HC12 ausmachen. Gute Erfahrungen hat der
Autor unter anderem mit StingRay (Autor: Sid
Price) und mit John Hartman’s NoICE Debug-
ger gemacht.

Fazit

Mit dem HC12 in die Programmierung einzu-
steigen lohnt sich in zweierlei Hinsicht. Die
16-Bit-Familie von Motorola bietet eine solide
Leistung, ohne den Programmierer vor allzu
hohe Hürden hinsichtlich der Komplexität des
Controllers zu stellen. Außerdem bekommt
man alle erdenklichen Softwaretools auch im
Bereich der Freeware, Shareware bezie-
hungsweise Low-Price-Ware. Lediglich die
Kosten für eine Controllerplatine muß man
einkalkulieren. Für den “ersthaften” Anwen-
der sollte ein BDM-Debugger zur Ausstattung
gehören.
Links zu der im Beitrag genannten HC12-Soft-
ware und eine Vielzahl weiterer Informatio-
nen und Ressourcen zum HC12 findet man
auf der Website des Autors

http://hc12web.de

(000077-2)rg

Literatur:

[1] Matthias Sturm: Elektronik-Aufgaben III:

Mikrorechentechnik,
Fachbuchverlag Leipzig 1994

[2] Arnulf Wallrabe: Mikrocontroller-Praxis, Ein-

stieg mit dem MC68HC11;
Hanser, München 1997

[3] Thamm, Sibigtroth: Nabelschnur - Single-

wire Background Debug Mode Interface des
68HC12, ELRAD 11/1996 S. 40ff.

werden können. Die Übertragungs-
geschwindigkeit (Baudrate) einzu-
stellen ist sicherlich kein Problem.
Zusätzlich sollte es aber möglich
sein, eine Wartefunktion aktivieren
zu können. Erfolgt der Programm-
transfer nämlich in Speicherbereiche
mit einer signifikanten Program-
mierzeit, so muß das Terminalpro-
gramm nach jeder übertragenen
Zeile auf eine Quittung vom Monitor
warten. Somit wird sichergestellt,
daß die erforderliche Programmier-
zeit (so zum Beispiel 10 ms je
EEPROM-Zelle) nicht durch Eintref-
fen der nächsten S-Record-Zeile vor-
zeitig unterbrochen wird. Diese
Anforderung erfüllt das gute alte
TERMINAL.EXE aus Windows 3.1.
Wer es etwas moderner mag, kann
sich Uwe Altenburgs kostenloses
Terminalprogramm OC-Console von
der Elektronikladen-Website
(

http://www.elektronikladen.de

)

laden.

Hintertür

So funktioniert also der Programm-
transfer, wenn sich bereits ein Moni-
torprogramm auf dem Zielsystem
befindet. Findige Programmierer
werden nun sicherlich fragen, wie
man den Monitor selbst in den HC12
lädt. Diese Frage soll nicht unbeant-
wortet bleiben.
Motorola hat sich für den HC12 eine
besondere Hintertür einfallen lassen.
Über diese Hintertür kann man sich
Zugang zu allen Speicheradressen
verschaffen. Man kann gewisser-
maßen in den Controller hinein-
schauen. Aber damit nicht genug: Es
ist sogar möglich, aktiv Speicherzel-
len zu verändern, die CPU anzuhal-
ten, die Prozessorregister zu modifi-
zieren und Controllerprogramme im
Einzelschrittbetrieb abzuarbeiten.
Die Betriebsart des HC12 zur Nut-
zung dieser Hintertür heißt Backgro-
und Debug Mode, kurz BDM. Die
Schnittstelle dazu - das BDM-Inter-
face - besteht aus einer einzigen Sig-
nalleitung. Sie trägt die Bezeichnung
BKGD und arbeitet bidirektional. Das
Signalspiel auf dem BDM-Interface
ist recht komplex (siehe 1. Teil des
Artikels und die Veröffentlichung in
[3]) und vor allen Dingen schnell.
Das ist auch der Grund dafür, daß
zwischen Entwicklungs-PC und
BDM-Interface des Zielsystems stets

ein BDM-Pod geschaltet werden
muß. Dieses BDM-Pod übersetzt den
Datenstrom hinsichtlich Inhalt, Sig-
nalpegel und Timing von BDM etwa
auf RS232 und umgekehrt.
Über BDM arbeitende Debugginglö-
sungen gibt es in zwei Ausprägun-
gen. Da wäre zunächst der komman-
dozeilenorientierte Ansatz. Dabei
verwendet man ein Terminalpro-
gramm, um das Pod nebst ange-
schlossenem Zielsystem zu steuern.
Das ganze ist der oben beschriebe-
nen Monitorlösung sehr ähnlich, mit
einem entscheidenden Unterschied:
Die Monitorfirmware läuft auf dem
Pod ab und nicht auf dem Zielsy-
stem, belegt also auch keine Res-
sourcen des Zielsystems! Da man
sich hinsichtlich der Kodegröße nicht
an Beschränkungen des Zielsystems
halten muß, kann man sehr lei-
stungsfähige BDM-basierte Monitor-
programme realisieren.
Ein typischer Vertreter dieser Art
BDM-Tools ist das B32EVB von
Motorola. Es handelt sich hierbei um
eine handflächengroße Platine mit
einem RS232-Anschluß (Sub-D9) und
einem BDM12-Ausgang in Form des
standardisierten 6-poligen Pfosten-
verbinders. Witzigerweise kommt
auf dem Board selbst ein HC12 zum
Einsatz (ein HC912B32) - relevant für
die Funktion als BDM-Pod ist diese
Tatsache jedoch nicht. Zwar gibt es
in letzter Zeit häufig Lieferengpässe
bei diesem recht preiswerten
Motorola-Tool, man kann jedoch auch
auf den ZWERG12 (Elektronikladen)
ausweichen.

Fensterwelt

Die zweite Kategorie BDM-Tools sind
Debugger mit einer grafischen
Benutzeroberfläche. Sie kommen
meist als Windows-basierte Soft-
ware daher und nutzen ein seriell
oder parallel angeschlossenes Pod
zur Kommunikation mit der Zielhard-
ware. Der grafische Ansatz erlaubt
es natürlich viel besser, eine Vielzahl
von Informationen gleichzeitig anzu-
zeigen und zugleich die Einzelheiten
der BDM-Steuerung vor dem Benut-
zer zu verbergen. Man kann sich in
der Regel Speicherbereiche als Hex-
dump anzeigen lassen, in einem
separaten Fensterbereich wird der
aktuelle Status der Prozessorregister
dargestellt. Darüber hinaus zeigt ein

MIKROPROZESSOR

53

12/2000

Elektor