% Content-encoding: UTF-8
\documentclass[ngerman]{article}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\setcounter{secnumdepth}{0}
\setcounter{tocdepth}{0}

%\begin{document}
\label{m16c}

\title{Der M16C von Renesas lernt Forth}
\author{Albert van der Horst}
\maketitle

Mit freundlicher Genehmigung der HCC--Forth--gebruikersgroep aus dem
Niederländischen übersetzt von Fred Behringer. Das Original erscheint
oder erschien etwa zur gleichen Zeit im Vijgeblaadje 65. Der Autor des
vorliegenden Artikels war maßgeblich an der Entwicklung des elektronisch
angesteuerten Metall--Xylofons Tingel--Tangel beteiligt. Wir, die aktiven
Besucher der Jahrestagungen der Forth--Gesellschaft, haben 2004 auf
Fehmarn die Bekanntschaft des Tingel--Tangels machen dürfen, als Willem
Ouwerkerk und Albert Nijhof, die bei uns zu Gast waren, eine Vorführung
veranstalteten (Bericht im VD--Heft 3/2004). Die Vorführung schlug ein
wie eine Bombe. Alle waren begeistert und gleich zum Linux--Tag im
anschließenden Jahr, wo auch die Forth--Gesellschaft einen Stand
unterhielt, wurde auf Einladung des Direktoriums das Tingel--Tangel als
\emph{Kassenmagnet} mitgenommen, diesmal vorgeführt von Albert Nijhof und dem
Autor des vorliegenden Artikels. Ganz beiläufig wurden die
linux--interessierten Besucher so auch auf Forth aufmerksam und wir
konnten einen Zuwachs an FG--Mitgliedern verzeichnen. Der Autor ist in
Forth--Kreisen seit Längerem als Entwickler von ciForth bekannt.

\begin{multicols}{2}

\section{Einleitung}

Die meisten von uns führen ihre Entwicklungen auf demselben Computer
durch, auf dem dann auch das Programm läuft. Bei eingebetteten Systemen
ist das aber längst nicht selbstverständlich. Sie sind zu klein, um
darauf auch noch ein Entwicklungssystem mit grafischen Möglichkeiten und
einen optimierenden C--Compiler laufen zu lassen.

In den 70--er Jahren wurden winzige Systeme als Entwicklungssystem
eingesetzt, z.B. mit sagen wir 8 kByte RAM und einer 100--kByte--Floppy.
Eine solche Technik ist auch heute noch im Einsatz. Ein Beispiel dafür
ist der BASIC--Interpreter in den Lego--Roboter--Bausteinen. Aber der beste
Repräsentant dieser Technik heißt Forth.

Da hat man dann also ein ganz kleines Betriebssytem auf seinem
eingebetteten System mit einem Befehls--Interpreter. Das ist ein großer
Vorteil, wenn man unverlässliche, in Entwicklung befindliche Hardware
verwendet, so z.B., wenn man sich selbst was zusammengelötet hat. Aber
auch in der Industrie zählt dieser Vorteil. Schlechte Dokumentation hat
übrigens dieselbe Wirkung wie unzuverlässige Hardware.

\section{Demonstration einer Ansteuerung}

Auf dem Treffen der Forth--gebruikersgroep am zweiten Samstag im
vergangenen Oktober habe ich mit einem Einplatinen--Computer von Renesas
ein Steuerungsproblem vorgeführt. Das Tingel--Tangel (ein
Metall--Xylophon) spielte die Big--Ben--Melodie und schlug die Stunde. Auf
dem Sig--Embedded--Treffen von Cimsolutions die Woche zuvor war diese
Demonstration noch nicht gelungen. Immerhin wurden die Primzahlen bis zu
100.000 berechnet: Der Compiler arbeitete gut. Auch konnte ich
hoffentlich vermitteln, welche Vorteile ein interaktiver Interpreter mit
sich bringt: Mit einfachen Befehlen wurde nachgeprüft, dass die
Leitungen zum Tingel--Tangel korrekt angelötet waren. Ich denke, dass man
die Geschwindigkeit beim Entwickeln mit Forth in der Tat als einen
Vorteil betrachten kann.

Die Ansteuerung mit den Timings und Ähnlichem ist nicht trivial, hat
aber nicht mehr als nur einen Abend Arbeit gekostet (wobei allerdings
das Löten nicht mit eingerechnet ist).

\section{Dies ging voraus.}

Es ist nun schon wieder zwei Jahre her, dass die europäische
(ursprünglich niederländische) Elektronik--Zeitschrift Elektor ihrem
Dezemberheft 2005 eine Mikro--Computer--Platine als Geschenk beilegte, ein
Reklame--Bravourstückchen des Renesas--Importeurs Glyn. (Der Übersetzer:
Ich kann mich noch gut daran erinnern: Heinz Schnitter hatte uns darauf
aufmerksam gemacht, als es schon fast zu spät war. Sämtliche
Zeitschriften--Kioske waren elektor--ausverkauft. Nach vielem Herumlaufen
wurde ich schließlich in Vaterstetten in der Umgebung von München
(j.w.d.) fündig. Die wussten nicht, dass sie auf einem Schatz saßen.)
Renesas, vormals Mitsubishu (wichtig für die Suche nach Informationen),
ist der Marktführer auf dem Gebiet der mittelgroßen flashbasierten
Mikro--Controller. Wir haben es hier also nicht mit Kleinstcomputern zu
tun, die eine flackernde Leuchtdiode ansteuern (künstliche Wachslichter
mit eingebautem Computer, 2 für 1 Euro 50, inklusive 
Lithium--Batterie\footnote{Ja, das ist auch ein eingebettetes System, und nein, es läuft nicht
unter Windows CE.})
), sondern mit etwas größeren Systemen.

Für die anstehenden 10 Euro wollte ich da gern noch mehr davon wissen
und ich machte mich daran, meinen Forth--Compiler (ciforth) auf diesen
Chip zu portieren. Der Befehlssatz und die übrigen Eigenschaften
stimmten mich enthusiastisch. Mit dem (gratis!) mitgelieferten
Entwicklungspaket lief der Compiler schon unter dem Emulator recht
ordentlich. Für eine serielle Verbindung zum Computer war noch etwas
Hilfselektronik nötig. Als das nicht auf Anhieb hinhaute, beschloss ich,
gleich mit einem größeren Evaluation--Board, das von Glyn für 50 Euro
komplett geliefert wurde, ans Werk zu gehen. (Ich danke hiermit
Cimsolutions für die Vermittlung bei der Anschaffung: Glyn scheute sich
davor, an privat liefern. Da habe ich dann zehn davon kommen lassen, von
denen noch einige weitergegeben werden können. Inklusive CD--ROM und
seriellem Kabel.) Hiermit habe ich dann losgelegt, mit dem Ergebnis,
dass ich jetzt ein ausgetestetes, dokumentiertes und vor allem
brauchbares Entwicklungssystem habe.

\section{Flash--basierte Mikro--Controller}

Was enthält nun so ein mittelgroßer Controller heutzutage? Zunächst
einmal kommen sie mit einer schwindelerregenden Vielfalt daher, was die
eingebauten Steuerungsmöglichkeiten betrifft. Normale digitale E/A, um
z.B. etwas anzuschalten, AD--Wandler, um z.B. einen Sensor auszulesen,
programmierbare Timer, spezielle Hardware zum Ansteuern von Motoren,
Schnittstellen zum CAN--Bus, wie er in Autos verwendet wird, ja man kann
jederzeit einen Chip finden, der genau das tut, was man haben will, und
nicht mehr. \emph{Nicht mehr}, was natürlich vom Kostenstandpunkt aus gesehen
sehr wichtig ist. Dieselbe Vielfalt findet man in Bezug auf den
Speicher. Da geht es von 48 kByte Flash bis in die Megabytes. Diese
kleinen Computer werden im Allgemeinen als Turnkey--Geräte verwendet. Man
denke an Bordcomputer im Auto. Man schaltet sie ein und sie beginnen
ihre Arbeit. Die Renesas--Prozessoren können Programme im Flash direkt
ausführen.\footnote{Populär ausgedrückt: Es sind PCs mit nur BIOS und keiner Festplatte.}) Das RAM ist dann nur für Daten da. Mein Evaluation--Board
hat 32 kByte RAM und 512 kByte Flash an Bord.

\section{Was wollen wir eigentlich tun?}

Ein ausgewachsenes ciForth unter Linux belegt so an die 30 kByte\footnote{Beta 5.18 : 28.542 Bytes, um genau zu sein (und alles sitzt drin, nix mit dynamisch gelinkten Bibliotheken).}) und
die Quellbibliothek beläuft sich auf einige Hundert kByte. Ein
ciForth--System möchte gern im RAM laufen und die Bibliothek passt prima
ins Flash. Mit anderen Worten, das Evaluation--Board erfüllt reichlich
die Anforderungen, die man stellen muss, um ein Entwicklungssystem
aufzubauen. Worauf wollen wir hinaus? Wir wollen die serielle Verbindung
zur Kommunikation mit einem Forth verwenden, das auf der Platine läuft.
Das ist das uralte Konsolen--Modell: Man tippt was ein, der Computer
führt es aus, liefert seine Antwort ab und meldet sich mit einem Prompt.
Sowas nennt man häufig eine DOS--Box\footnote{Abfällig. Computer--Fachleute verwenden den Ausdruck \emph{Console--Window}.
Selbst Microsoft kommt übrigens zur Einsicht, dass für
Computer--Fachleute ein Konsolenfenster unverzichtbar ist. Man google
sich durch nach \emph{Powershell}.
}). Dann kann man beispielsweise mit
ein paar interaktiven Befehlen austesten, wie man seinen Prozessor
achtmal so schnell laufen lassen kann, ob man seine LEDs überhaupt
richtig angeschlossen hat, was der Temperatursensor meldet usw. Zu
alldem ist es nötig, dass das Forth--Programm beim Starten (aus dem Flash
heraus, anders geht es nicht) erst ins RAM kopiert und dort dann
ausgeführt wird.

\section{Schwierigkeiten beim Entwickeln}

Das Entwicklungssystem von Renesas (in Visual--Studio--Aufmachung) wurde
unter Windows 98 SE installiert, da ich kein XP--System mit dem
erforderlichen seriellen Anschluss habe. Aber damit funktionierte es
dann auch auf Anhieb. Es wurde jedoch ganz schnell deutlich, wie stark
C--orientiert das System ist. Es traten verschiedene Schwierigkeiten auf,
die teilweise im Kontakt mit Glyn beseitigt werden konnten. Ärgerlich
war auch das Extra--System, das nötig war, um über den zweiten seriellen
Anschluss mit Forth kommunizieren zu können. Als es sich auch noch
herausstellte, dass nach dem Laden einige RAM--Adressen systematisch mit
0FF belegt wurden, war das Maß voll. Ich erfuhr, dass es für diesen Chip
einen Flasher für Linux gab und dass auch die Version 2.0, die
freigegebene DOS--Version des Assemblers, unter dosemu, dem DOS--Emulator
von Linux, ausgezeichnet lief. Das ciForth--Entwicklungssystem, das die
Assembler--Datei erzeugt, im Verein mit Dokumentation und Testen, läuft
natürlich unter Linux. Windows wurde definitiv als Entwicklungssystem
verworfen. Es beunruhigte natürlich sehr, dass die eigentliche Struktur
eines C--Programms unter niederen h--Dateien verborgen blieb, was um
Himmels willen das Monitor--Programm im Flash\footnote{Wo das Windows--Entwicklungssystem mitspricht.}) alles tat, wie die ganze
Interrupt--Struktur da eigentlich aussah, wie das mit dem id--Code
eingerichtet war, den man fürs Flashen benötigt, und dann die
Restart--Vektoren --- neben den Interrupts --- Watch--Dogs,
nicht--maskierbare Interrupts, Single--Step--Gebahren ...

Bevor es dann richtig losgehen konnte, gab es noch ein Problem. Das
Programm muss im RAM laufen, aber im Flash aufbewahrt werden. Das
Renesas--Entwicklungssystem, aber auch der Linux--Flasher konnten damit
nicht umgehen. Vom Linux--Flasher stand der Quelltext zur Verfügung, so
dass ich nach einem Wochenende an harter Arbeit einen Flasher in Forth
geschrieben hatte. Dieser Flasher hat noch einen anderen wesentlichen
Vorteil. Er löscht nur die Blöcke, die er beschreiben will, so dass ich
die Bibliothek und das Forth--System unabhängig voneinander flashen kann.

\section{Es beginnt zu funktionieren.}

Das erste Programm, zum Anschalten einer LED, war drei
(Assembler--)Befehle groß. Des Weiteren musste nur noch der Reset--Vektor
so gesetzt werden, dass er auf dieses Programm zeigt. Kurz und gut, alle
Lösungen waren simpel. Interrupts? Aus! Id? Auf null! Monitor? Diesen
Happen dumpen! Restart: Den Reset setzen. Das war's! Und ... es
funktionierte tatsächlich. Jetzt mal schnell etwas einbauen, das dieses
3--Befehls--Programm sich selbst ins RAM kopieren lässt, so dass es dann
da laufen kann. Da ging zunächst einmal nichts.\footnote{Mehr erzähl ich nicht. Wer es mir nicht glaubt, der probiere sowas
mal selbst aus.}) Nach dem vierten
Anlauf lief es dann schließlich. Nun denselben Spaß in Forth einbauen
und das Debuggen konnte beginnen. Zwei Stunden später konnte ich die
Start--up--Botschaft von ciForth bewundern: 
\texttt{R16C ciforth beta \$RCSfile: cir30.gnr,v \$ \$Revision: 1.33 \$}.
Das bedeutete zugleich, dass das
Ausführen von Tests möglich war. Jetzt ging es etwas besser voran. Der
Arbeitszyklus bestand aus \mbox{flashen}, Jumper umstecken, erneut starten,
Kermit aufrufen. Kermit ist ein \emph{Terminal Emulator}, ein Programm, das
sich über eine serielle Schnittstelle mit Forth unterhält. Jetzt kann
ich also ein und dieselbe serielle Schnittstelle benutzen. Es ist kein
zweites System und kein zweites Kabel mehr nötig.

\section{Testen, testen.}

Nun konnte damit begonnen werden, die 328 Blöcke, aus denen dieses Forth
besteht, zu debuggen. Viele Blöcke sind zum Glück systemunabhängig und
bereits ausgiebig getestet, aber 75 Blöcke sind in Assembler geschrieben
und enthalten unvermeidlich Fehler. Forth ist interaktiv, höchst modular
und hat viele eingebaute Debug--Möglichkeiten. Zehn Tage, nachdem das
LED--Programm lief, konnte ich bereits den Hayes--Test --- eine Art
Validation der ISO--Aspekte eines Forth--Compilers --- auf mein Forth
loslassen, wodurch noch zwei Bugs aufgespürt wurden.

Sowohl Kermit wie auch ciForth sind flexibel. Nach Anpassungen des
Prompts von ciForth, der dann wieder von Kermit verstanden wird, kann
der Test völlig automatisch laufen, bis hin zur Überwachung der Ausgabe.
Und für die Experten: Auch alle Ausnahmefälle (exceptions) werden
getestet. Das geht, weil der Test über den Interpreter läuft und das
System bei einer Ausnahmesituation im Interpreter landet. Automatisch
testen ist vielleicht ein von allerlei Marketing--Gags ausgehöhlter
Begriff. Unter automatisch verstehe ich Folgendes

\begin{verbatim}
   albert@apple ~/renesas>make test
   albert@apple ~/renesas>echo $?
   0
   albert@apple ~/renesas>
\end{verbatim}

Der Befehl \verb'make test' hat kein Ergebnis geliefert, sehr wohl jedoch
einen Return--Code von 0, d.h. okay. Spaßeshalber frage ich den hier
explizit ab. Die Struktur ist also so beschaffen, dass dieser Test
selbst wieder in einem anderen Test als Baublock verwendet werden kann,
und so gehört es sich auch. Das ciForth--Stammprogramm enthält für jeden
Baublock neben dem Programm--Code und der Modulbeschreibung auch einen
oder mehrere Tests. Jeder Test besteht aus einem Befehl und dem
erwarteten Ergebnis. Das alles zusammen bildet den endgültigen Test und
der wird neben Hayes auf den Befehl \verb'make test' hin ausgeführt.

\section{Die Verwendung des Flash--Speichers}

Der Controller auf dem Renesas--Board verfügt über 7 Bereiche von 64
kByte, die getrennt geflasht werden können, 1 von 32 kByte, und dann
noch 3 von 8 kByte und 2 von 4 kByte. Der oberste Bereich von 4 kByte
erklärt der Platine, wo sie anzufangen hat, und muss immer belegt
werden. Er zeigt auf das Startprogramm und an das kommen wir nicht mehr
heran. 2 Bereiche von 8 kByte enthalten zusammen das Forth--System, 4
kByte bleiben übrig. Das erste Stück davon ist das Startprogramm, das
das besprochene Forth--System ins RAM kopiert. Aber zuerst wird
nachgeprüft, ob der Bereich von 32 kByte noch jungfräulich ist, was man
nach dem Flash--Säubern an den 0FFs ablesen kann. Wenn nicht, dann ist
dieser Bereich von einem Programm belegt. Das kann sowohl ein
erweitertes Forth sein, wie auch ein Programm, das etwas Nützliches tut,
wie z.B. das Abspielen von Big--Ben oder ein ferngesteuerter
Mehrkanal--Lichtdimmer. Zwei Bereiche von 64 kByte enthalten die
Forth--Bibliothek. Das lässt uns noch 5 Bereiche von 64 kByte und noch
ein paar kleinere Bereiche.

\section{Die Bibliothek}

Zwei Bereiche von 64 kByte enthalten ein klassisches Forth--Block--System.
Das bedeutet, dass es in Blöcken von 1 kByte mit Quelltext unterteilt
ist, die allesamt getrennt voneinander eingeladen werden können. In
herkömmlicher Weise enthält jede erste Zeile ein Kommentar mit dem
Befehl, der hinzugefügt wird, sowie ein bisschen
Buchhaltungsinformation. Das wird in ciForth über den Befehl WANT als
eine \emph{On--Demand--Bibliothek} verwendet. So sorgt \verb'WANT class' dafür, dass
der Befehl \verb'class', eine Erweiterung mit objekt--orientierten
Möglichkeiten, geladen wird. Die Renesas--Bibliothek enthält das meiste
von dem, was die ciForth--Systeme unter Linux und Windows auch haben:

Generische Algorithmen: Binärsuche, Quicksort, Merge\-sort
Code--Untersuchung: Decompiler, Aufsuchen der Wortquellen
Objekte: Definieren von Klassen und Methoden
Beispiele und Benchmarks: Primzahlensieb, Verschachtelungsbenchmark,
Byte--Benchmark, Automatisierung des Entwicklungskreislaufs
Nützliche Tools: Speicherdump, Umschalten auf case--insensitive,
\verb'SAVE-SYSTEM' , \verb'TURNKEY'

Was fehlt, ist der Pentium--Assembler, der hier keinen großen Nutzen hat.
Auf die Werkzeuge \verb'SAVE-SYSTEM' und \verb'TURNKEY' gehen wir jetzt noch etwas
näher ein.

\section{Das Tingel--Programm als Turnkey}

Die Quelle des Tingel--Programms ist in einem der freien Flash--Bereiche
untergebracht, im Block--Stil. Mein Flash--Programm kann auch diese
Bereiche beschreiben, so dass der Quelltext auf Wunsch unter Linux
gehalten bleiben kann. (Hatte ich schon erzählt, dass mein \mbox{Flasher} mit
Quelltexten genauso leicht umgehen kann wie mit Code?). Auf diese Weise
kann es mit den gebräuchlichen Befehlen (\verb|THRU|) eingeladen werden. Danach
haben wir dann ein Forth, an das u.a. Befehle wie big ben boing big--ben
angefügt wurden. Nach dem Eintippen von \verb'12 big-ben' und bei
angeschlossenem Tingel--Tangel wird dann also die Big--Ben--Melodie
gespielt und anschließend erklingen 12 Glockenschläge. Der Befehl
\verb|SAVE-SYSTEM| bereitet den 32--kByte--Flash--Bereich sauber vor und legt dort
unser neues System komplett mit Big--Ben hinein. Wenn wir am Morgen das
Evaluation--Board wieder anschalten, können wir direkt \verb'6 big-ben'
eintippen, da anstelle des gewohnten Forth--Systems das erweiterte System
eingeladen wird.

Der Befehl TURN--KEY geht noch einen Schritt weiter. Hierbei startet
Forth nicht mehr mit dem Befehls--Interpreter, sondern mit einem
mitzugebenden Befehl wie beispielsweise bei \verb'SPOKENUUR TURN-KEY'. Der
Befehl \verb|SPOKENUUR| (zu Deutsch: Geisterstunde) ist dabei als \verb'12 big-ben'
definiert. Jedesmal wenn das System angeschaltet wird, ertönt nun die
\emph{Geisterstunde}.

\section{Zusammenfassung}

Die heutigen Mikro--Controller sind kräftig genug, um einfache
Entwicklungssysteme mit aufzunehmen. Entwickeln auf dem Zielsystem hat
gewaltige Vorteile, vor allem beim Hardware--Debuggen. Der Einsatz von
Flash--Speicher erlaubt es, ohne spezielle Apparatur, wie
EPROM--Programmierer, Turnkey--Systeme zu entwickeln und diese auch
schnell weiter anzupassen. Evaluation--Boards sind dermaßen preiswert,
dass sie als Turnkey eingesetzt werden können. Für 53 Euro zuzüglich
Versandkosten können bei mir noch einige ECBM16C/62P--Evaluation--Boards
bezogen werden.

\end{multicols}

\end{document}