\documentclass[11pt,a4paper]{article}
% language support
\usepackage[german]{babel}
\usepackage[utf8]{inputenc}
\usepackage{pslatex} % use native PostScript fonts
\usepackage{multicol}
\usepackage{url} % \url{} \path{} with correct "hyphenation"
\usepackage{fancyvrb} % for code examples

% \voffset-10mm
% \pagestyle{empty}
% \pagestyle{plain}
% \pagestyle{headings}
% \renewcommand{\baselinestretch}{1.08}
%\usepackage{xspace}
\parindent=0pt
\newcommand{\Forth}{Forth}
\newcommand{\amforth}{\emph{amforth}\space}
\begin{document}

\title{amforth}[amforth für Atmel AVR–ATmega]

\author{Matthias Trute}

\maketitle



\begin{multicols}{2}

% ====================================================================
\section{Überblick}
\label{sec:overview}

  \amforth ist ein interaktives \Forth--System für die 
  ATmega--Mikrocontrollerbaureihe der
  Firma Atmel. Es ist geeignet, sowohl \emph{im} als auch interaktiv
  \emph{mit} dem Zielsystem zu arbeiten. In diesem Artikel werden die Entstehung und
  das Design von \amforth beschrieben.

  \amforth klingt seltsam, aber avrforth war schon vergeben: \amforth steht einfach für
  {\bf A}t{\bf M}ega{\bf FORTH}.

  Warum ein eigenes \Forth--System aufbauen, wo es doch offensichtlich schon eines
  gibt\footnote{Es gibt sogar viele \Forth s für AVR--ATmega. Sie sind in C
  programmiert oder kosten Geld oder haben sonst einen Makel ;=)}? Warum überhaupt ein
  Forth neu schreiben?

  Nun, avrforth von Daniel Kruszyna (\url{krue.net/avrforth}) ist nach seinen eigenen
  Worten ein colorless colorforth. Nach einigen Mails wurde klar, dass er das nicht
  ändern will und ich das nicht haben will. Da mir zudem sein Programmcode zu kompliziert
  ist, habe ich "`einfach"' mein eigenes System begonnen. Wer Daniels Code betrachtet,
  wird rasch feststellen, dass \amforth einige seiner Ideen übernommen hat. Die wichtigste
  ist vielleicht, dass \amforth direkt in den Flash--Speicher des Controllers compiliert.

  Der zweite wichtige Ratgeber war Ron Minke mit seiner Artikelfolge "`Forth von der
  Pike auf"'. An dieser Stelle der Dank auch an die Redaktion der Vierten Dimension,
  die Vereinszeitschrift elektronisch verfügbar gemacht zu haben. Als dritte Quelle
  hat Stephen Pelcs Buch "`Programming Forth"' meine Entscheidung, dem 
  ANS--Forth--Standard
  nachzueifern, maßgeblich beeinflusst.

  Nachdem ich bereits gute Erfahrungen mit dem Entwicklerportal \url{sourceforge.net} sammeln
  konnte, habe ich ebendort das Projekt \amforth angemeldet und auch problemlos einrichten
  können. Damit standen Webspace für die Homepage des Projekts (\url{amforth.sourceforge.net}),
  ein Softwareverwaltungssystem (ich habe mich für Subversion entschieden), Mailinglisten und
  Trackingmodule bereit. Nicht zu vergessen die Downloadangebote und natürlich nette Statistiken.
  Alles kostenlos und gut gemacht, vor allem aber auch für den Einzelnen ohne Mühe verwendbar.

  Die Entscheidung, von vornherein auf Englisch zu setzen, hat sich bewährt, wie ich an den
  E--Mails erkennen kann, die mich aus verschiedenen Ländern erreichen. Auch ist auf
  der Homepage des Projekts eine kleine Weltkarte zu sehen, auf der die Besucher der
  Einstiegsseite einen kleinen (oder wenn sie öfter kommen auch größeren) roten Punkt
  hinterlassen. Sehr interessant, selbst wenn man unterstellt, dass da nur Google--Roboter
  drauf zugreifen\ldots

  \amforth ist unter der Gnu Public License GPL veröffentlicht. Damit stehen die Quelltexte
  frei zur Verfügung. Jeder kann damit machen, was er will, Änderungen müssen jedoch
  unter GPL wieder veröffentlicht werden.






\begin{figure*}
\begin{center}
\includegraphics[width=0.8\textwidth]{2007-Sonderheft-AVR/amforth-p16-board}
\caption{\label{amforth:board}amforth wurde auf einem Pollin--AVR--Board entwickelt.}
\end{center}
\end{figure*}





\section{Historie}

  Die ersten Schritte waren mühsam, da die Hardware keinen Mucks von sich gab.
  Hier half der Simulator des AVR--Studios, die kleineren und größeren Fehler zu entdecken.
  Dann war es soweit: Das Terminal gab den Prompt aus. Danach ging es rasch
  vorwärts. Jetzt wurden die Stackdiagramme und Beschreibungen der Dutzenden an
  Forthworten wieder und wieder gewälzt, von Hand in die Folge der Execution Tokens
  oder in Assemblercode umgesetzt und auf den Controller gebrannt. Irgendwann war der Interpreter
  fertig: Worte konnten eingegeben werden (\texttt{accept}), wurden mit \texttt{find}
  gefunden und per \texttt{execute} ausgeführt.

  Der nächste Meilenstein war das Wort \texttt{i!}, das eine Zelle im Flash neu beschreibt.
  Jetzt konnten die Compilerworte wie \texttt{if} und \texttt{again} implementiert werden.
  Hier half Google. Viele dieser Worte wurden bereits irgendwann von irgendwem mit Quellcode
  beschrieben, so dass es an einigen Stellen eigentlich nur Abschreiben war.

  Eine Hürde war das Wort \verb,does>,. Es zu implementieren, erschien mir jedoch wichtig. Der
  Grund ist in einem Paper von Julian V.\ Noble im Journal of Forth Application and
  Research zu finden: Finite State Machines. Diese werden in der Robotik gerne
  eingesetzt und seine Implementierung basiert auf diesem Wort. \verb,does>, ist das
  einzige Wort, in dem Forthcode und Assemblercode gemischt vorkommen. Alle anderen
  sind entweder reine Colon-- oder reine Assemblerworte. Zudem haben mit \verb,does>,
  definierte Worte eine weitere Unschönheit: Das Flash durchläuft bei Worten, die es
  benutzen, mindestens einen Löschzyklus. Mehr dazu weiter unten.

  Die Version 1.0 von \amforth war ein kleiner Meilenstein, denn das System hatte für mich
  seinen ersten Abschluss erreicht. Zudem ist die "`magische"' Versionsnummer geeignet,
  größere Aufmerksamkeit zu wecken.

\section{Umgebung}

  \amforth wird unter Linux (Kubuntu 6.10) entwickelt und gelegentlich unter Windows
  im Simulator ausgeführt. Als Assembler nutze ich \texttt{avra} (\url{avra.sourceforge.net} 
  und \url{cdk4avr.sourceforge.net}) zusammen mit dem aus der höheren Programmierung bekannten 
  \texttt{make}. Der Upload auf den Controller erfolgt mit dem Programm \texttt{avrdude} 
  (\url{www.nongnu.org/avrdude}) mit ISP durch einen kleinen STK200--kompatiblen Dongle
  am Parallelport oder den mysmartUSB--Dongle von \url{www.myavr.de}. Letzterer hat zudem den Vorteil, 
  die Entwicklungsplatine auch mit Strom aus dem USB versorgen zu können. Als Terminal nutze ich
  meist \texttt{minicom}.

  Unter Windows kommt natürlich das AVR--Studio zum Einsatz. Die Unterschiede in der Syntax der
  Assemblerquelltexte zwischen den beiden Welten sind glücklicherweise gering. Von Anwendern
  weiß ich, dass das Hyperterminal von Windows eingesetzt werden kann, selbst nutze ich es jedoch
  nicht.

\subsection{Hardware}

  Die ursprünglich geplante Laufzeitumgebung für \amforth sind einfache Roboter wie der Asuro
  (\url{www.arexx.com}) und (schon anspruchsvoller) der c't--bot des c't--Computermagazins aus
  dem Heise--Verlag. Daneben sollte \amforth auf einer noch zu schaffenden Modellbahnsteuerung
  (Vergleichbar mit \url{www.opendcc.de}) Einsatz finden. Zusätzlich habe ich noch einige
  Entwicklungsboards der Fa.\ Pollin im Einsatz, die den Prozessorwechsel unkompliziert ermöglichen.
  Nun hat mich die Forth--Gesellschaft überredet, auch den Atmel--Butterfly mit in die Liste aufzunehmen\ldots

  Wer die Hardware der Zielsysteme betrachtet, wird feststellen, dass es weder externes RAM oder EEPROM
  noch sonstige Anbauten gibt (der Butterfly kam erst später). Das Gesamtsystem  muss mit 8KB Code und
  wenigen Bytes RAM zurechtkommen. Wobei natürlich nicht nur \amforth laufen sollte, sondern auch für
  die Umgebung nützlicher Code. Dieses Ziel hat \amforth erreicht.

  Auf die Mikrocontroller kommt das Hexfile\footnote{eigentlich sind es zwei
  Dateien, eine für den Flash--Speicher und eine für das EEPROM} mit \amforth über die üblichen
  Verdächtigen: ISP oder JTAG. \amforth und Bootloader sind einander nicht fremd,
  ihr Verhältnis ist dergestalt, dass \amforth sein eigener Bootloader ist, der keinem Standard
  oder den Atmel--Appnotes folgt. Die Gründe hierfür werden weiter unten noch deutlich.

%%%
\begin{figure*}
\begin{center}
\includegraphics[width=0.9\textwidth]{2007-Sonderheft-AVR/amforth-bootstrap}
\end{center}
\caption{amforth 1.3 für AVR-Butterfly auf dem Macintosh assemblieren, flashen und booten}
\end{figure*}

%%%






\subsubsection{Fuses}
  Atmel hat die AVR--Controller mit einigen Konfigurations--Bits (Fuses) versehen, die wesentliche Eigenschaften
  festlegen.  Diese Bits sind sehr sensibel und die Standardwarnung ist, sie nur nach sorgfältiger Prüfung
  zu ändern. Im laufenden Betrieb sind in der Regel weder les-- noch änderbar.

  \amforth hat auf den bislang getesteten Controllern mit deren Lieferzustand gut funktioniert.
  Darüber hinausgehend habe ich lediglich die Fuses für die Taktquelle angepasst, denn der Lieferzustand
  lässt die Controller mit nur 1MHz aus dem internen Oszillator laufen, was natürlich wenig
  ist, wenn extern ein 16MHz--Quarz bereitsteht.

\subsubsection{Evaluationboards}
  Die Boards der Fa.\ Pollin müssen selbst zusammengelötet werden. Dies gelingt auch einem mäßig
  talentierten Bastler (wie ich es einer bin) ohne größere Blessuren. Auf den Boards werden die
  Controller in Fassungen aufgenommen und können unkompliziert ausgetauscht werden. Die Schnittstellen
  umfassen ISP, JTAG, serielles Programmierinterface und einen RS232--Anschluss. Zusätzlich
  dabei sind (abschaltbare) LED, Summer und Taster. Als Prozessoren steht die ganze Bandbreite der
  im DIL--Format produzierten ATmegas zur Verfügung. Bei mir sind es der ATmega32 und der ATmega8,
  andere nur gelegentlich.

\subsubsection{AREXX--Asuro}
  Der Asuro ist eigentlich nur eine Platine mit zwei Motoren. Der Prozessor ist ein ATmega8 mit 8MHz.
  Der Kontakt zur Außenwelt kommt über Odometrie an den Antriebsachsen (Lichtreflexschranken zur Ermittlung
  der Drehzahl), einer Reihe von Tastern vorn und seitlich, einem Linienfolgemodul und einer
  Infrarotschnittstelle zum PC zustande. Letztere soll auch als Terminal für \amforth dienen
  und ist bislang ein hartnäckiges Hindernis für die erfolgreiche Kommunikation.

\subsubsection{c't--Bot}
  Der Roboter der c't wurde im Laufe des Jahres 2006 vorgestellt. Im Prinzip ist er dem Asuro
  ähnlich, aber deutlich leistungsfähiger. So hat er einen ATmega32 mit 16MHz. Zusätzlich besteht
  die Möglichkeit, ein Display anzuschließen oder über WLAN mit dem Roboter zu kommunizieren.
  Für \amforth ist die Sache zunächst einfacher, da im Gegensatz zum Asuro die Infrarotschnittstelle
  nicht als serielles Terminal genutzt wird und die für selbiges notwendigen Pins separat bereitstehen.

\subsubsection{AVR Butterfly}
  Michael Kalus hat mich geradezu genötigt, der kleinen Platine mehr Aufmerksamkeit zu widmen.
  Nachdem selbst so wichtige Argumente wie \emph{Termine werden nicht eingehalten} und
  \emph{Funktionsumfang kann auch null sein} bei ihm verpufften, hat er mir
  freundlicherweise zwei Exemplare dieser kleinen Systeme zur Verfügung gestellt.

  Die erste \amforth--Portierung erfolgte buchstäblich binnen weniger Minuten. Das Schwierigste war,
  die Taktfrequenz des ATmega169 herauszufinden. Die im Internet verfügbaren Unterlagen schwiegen
  sich weitgehend aus, resp.\ meinten, es wäre offensichtlich oder widersprachen sich. Die Ursache
  für diese Verwirrung wurde aber rasch klar und der Prozessor arbeitet unter \amforth derzeit
  mit 8MHz und ohne Stromsparfunktionen.

  Als sich \amforth am seriellen Terminal mit dem Prompt meldete, war das Thema Portierung
  beendet. Nun hat der Butterfly nicht nur den Prozessor, sondern auch recht viel Peripherie
  wie ein LCD, ein über SPI angeschlossenes sehr großes Flash, einen Summer, einen kleinen
  Joystick, einen Licht-- und einen Temperatursensor. Nicht zu vergessen: Eine Li--Ion Knopfzelle.

  Damit ergeben sich faszinierende Möglichkeiten, Fehler in \amforth zu finden und auszumerzen.
  Und natürlich auch Einsatzgebiete.

\subsubsection{Und die Modellbahn?}
  Da gibt es schlicht noch nichts zu vermelden. Die Hardware hat Wolfgang Kufer unter \url{www.opendcc.de}
  beschrieben, sie tut jedoch erst mal ihren Zweck wie es vom Erschaffer vorgesehen ist. Wer aber mit
  Schlagworten zufrieden ist, hier kommen ein paar: SRCP und embeddedloconet.

\subsubsection{Andere Systeme}
  Es bleibt nicht aus, dass \amforth auch auf anderen Systemen eingesetzt wird. So liegt eine
  kleine Platine mit einem ATmega88 und Ethernet--Anschluss vor mir. Dann gibt es einige Prozessoren
  der ATtiny--Reihe, die über hinreichend viel Flash verfügen.

\section{Umsetzung}

  \amforth ist ein 16Bit--\Forth\ in der indirect--threaded--Ausführung für die
  AVR--ATmega--Mikrocontroller. Leider hat Atmel die ATmegas nicht vollständig
  softwarekompatibel gestaltet, so dass es unumgänglich ist, für jeden Prozessortyp
  einige Einstellungen vorzunehmen und ein eigenes Hexfile für \amforth zu erstellen.
  Diese Einstellungen umfassen alle nicht zur Laufzeit änderbaren Parameter, wie z.~B.\ 
  die Taktfrequenz oder Adressbereiche und einige Startwerte, um überhaupt Kontakt
  aufnehmen zu können.

  \amforth ist als Stand--alone--\Forth--System konzipiert. Es wird einmalig auf dem PC
  aus den Quellen übersetzt und auf den Mikrocontroller übertragen. Anschließend arbeitet
  es autonom. Kommandos werden über das serielle Terminal entgegengenommen bzw.\ über
  einen \texttt{turnkey} getauften Mechanismus bei Programmstart automatisch ausgeführt.

  \amforth hat einen Compiler. Damit definierte Worte erweitern
  das Dictionary im Flash direkt und ohne weitere Aktionen im laufenden Betrieb.
  Der Compiler arbeitet klassisch. Er kennt keine Optimierung oder Codeanalysen,
  wie sie von modernen Compilern (auch für \Forth) angeboten und eingesetzt werden.

  \amforth lehnt sich an den vielfach im Internet vorhandenen Text Dpans94--draft6 an.
  Dabei folgt es dem Standard nicht sklavisch. Die Stackeffekte wie auch die grundsätzliche
  Funktion stimmen überein, aber in Details ergeben sich Abweichungen. So arbeitet \texttt{find}
  case--sensitiv und die Worte im Dictionary sind alle in Kleinbuchstaben notiert. Mir erschien
  es aber nicht hinreichend wichtig, vollständige Konformität herzustellen, zumal einige Aspekte
  auf dem Mikrocontroller meiner Meinung nach keinen Sinn ergeben.

  Der Zugriff auf die verschiedenen Speichertypen erfolgt über die Standardworte ggf.\ ergänzt mit
  Präfixen. Der Einsatz dieser Präfixe ist reine Konvention. Das Präfix \texttt{e} steht für EEPROM, das
  Präfix \texttt{i} für Flash (== Instruction)  Memory. Die Worte \texttt{@} und \texttt{!} (also ohne Präfix)
  operieren mit den RAM--Adressen. Nur für das RAM existieren auch byte--weise Zugriffsoperationen: \texttt{c@}
  und \texttt{c!}. Diese sind insbesondere bei den I/O--Registern unverzichtbar. Dafür fehlt
  \texttt{c,}, da auf das Flash ohnehin nur wortweise zugegriffen werden kann. Einen byte--weisen
  Zugriff auf das EEPROM hielt ich bislang für unnötig, da bis auf den Sonderfall mit den I/O--Adressen ohnehin
  immer 16Bit große Worte verarbeitet werden.

  Aus dem CORE-word-set fehlen Worte wie \texttt{environment}, \texttt{evaluate} (und auch \texttt{s"}),
  da ich für diese (noch) keinen Nutzen gefunden habe. Eine Strukturierung des Dictionarys in einzelne 
  Vocabularys wird ebensowenig realisiert.

  Einige Eigenschaften sind dem angestrebten Minimalsystem (ATmega8 ohne Zusatzspeicher)
  geschuldet. So ist die Fehlertoleranz eher gering ausgeprägt. Wer z.B. Worte mit mehr als 31
  Zeichen definiert, wird daran nicht gehindert. Es wird nur nicht funktionieren. Außerdem ist
  \amforth sehr schweigsam, auch im Fehlerfall. Es gibt keine kleinen "`Romane"', die erläutern,
  was wie warum falsch lief und was man alles tun könnte. Einzig die Position in der aktuellen
  Eingabezeile und ein Errorcode werden ausgegeben.

  Keine der Eigenschaften ist in Stein gemeißelt. Beispielsweise kann man sich vorstellen, das
  Dictionary teilweise in andere Speicherbereiche auszulagern und dabei verschiedene Vocabularies
  zu benutzen\footnote{Eine vielleicht etwas eigenwillige Interpretation des \Forth--Standards.}.
  Auch kann eine Blockverwaltung sinnvoll werden, wenn beispielsweise SD--Cards einbezogen werden.

\subsection{Architektur}

  Die Architektur von \amforth lehnt sich stark an die an, die von Ron Minke in seiner Artikelfolge
  "`Forth von der Pike auf"' beschrieben wird. Zum Glück hat Ron erst im letzten Artikel
  seine Hardware enthüllt, \amforth wäre anderenfalls vielleicht nicht entstanden. Die von ihm
  genutzte Hardware ist deutlich komplexer und seine \Forth--Implementierung viel aufwändiger als
  \amforth.

  Die Verwendung der CPU--Register der ATmega--Controller ist wie bei ihm beschrieben. Hinzu kommen
  die Register \texttt{r16} bis \texttt{r27} für temporäre Zwischenspeicher. Bei der Multiplikation kommt
  zudem das Register \texttt{r0} zum Einsatz. Weiter werden die Register r2 bis r5 für interne Zwecke
  genutzt. Die restlichen Register sind noch ungenutzt, im Ausblick am Endes dieses Artikels werden
  auch sie eventuell noch Nutzen finden.

% mehr zur Architektur
\subsubsection{Interrupts}
  \amforth kann Interrupts durch \Forth--Worte ausführen. Hierfür kommt ein zweistufiges Verfahren
  zum Einsatz, das den Interrupt auf Maschinenebene in einen Interrupt auf \Forth--Ebene umsetzt.
  Hierfür wird das sonst ungenutzt $t$--Bit im Statusregister genutzt. Wenn es gesetzt ist, verzweigt
  der innere Interpreter in die Interruptverarbeitung. Damit ist die Latenz bis zur Verarbeitung des Interrupts
  recht hoch. Im Gegenzug hat man alle Freiheiten eines \Forth--Interpreters. Interrupts
  wirken nur beim Einsprung in den inneren Interpreter. Das bedeutet, dass alle Assemblerworte
  als atomare Operationen wirken und sich der Forth--Interpreter in einem wohlbekannten Zustand
  befindet.
  
  \Forth--Worte, die als Interrupt aufgerufen werden, sollten natürlich keine Seiteneffekte haben. 
  Das eigentliche Programm wird es danken\ldots

  Gegenwärtig stehen nicht alle ATmega--Interrupts auch als Forth--Interrupts zur Verfügung. Die
  Anzahl und auch die Auswahl werden über die prozessor-- und plattformspezifischen Steuerdateien
  festgelegt.

\subsubsection{Multitasking}
  Multitasking wird über das Wort \texttt{pause} organisiert. \amforth selbst definiert
  \texttt{pause} vektorisiert (deferred) als \texttt{noop} (No Operation), es macht also nichts.
  \texttt{pause} wird bei den I/O--Routinen bereits intern aufgerufen. Wer das Abenteuer sucht,
  definiert \texttt{pause} über einen Timerinterrupt...

\subsubsection{Ein/Ausgabe}

  Der Kontakt zur Außenwelt wird über 4 Worte hergestellt: \texttt{emit}, \texttt{emit?},
  \texttt{key} und \texttt{key?}. Diese sind über Uservariablen (die Namen derselben beginnen
  mit einem \texttt{'}) vektorisiert. Default ist die Nutzung des ersten seriellen Ports (usart0).
  Denkbar ist aber ebenso eine Nutzung von TWI (I2C) oder SPI oder (bei passenden ATmegas) des
  CAN--Busses zur Entgegennahme von Befehlen. Ebenso lässt sich \texttt{emit} auf ein LCD (z.~B.\
  des Butterflys oder des c't--Roboters) oder TV umsetzen --- Die ATmegas sind in der Lage, ein 
  FBAS--Fernsehsignal zu generieren, Schaltungen im Internet.

\subsection{Flash}

  Der Flash--Speicher wird in \amforth in mehrere Teile untergliedert. Eine wichtige Gliederung wird
  von Atmel vorgegeben: NRWW-- und RWW--Speicher. Der NRWW(non read while write)--Speicher liegt im
  Bootsektorbereich am oberen Ende des Speichers. Programmcode, der sich hier befindet, kann auf
  das Flash im RWW--Bereich schreibend zugreifen, sofern nicht Fuses oder Lockbits dies verhindern.
  Die hierfür genutzte Instruktion \texttt{spm} ist im RWW--Bereich wirkungslos. Dieser von Atmel
  in verschiedenen Appnotes beschriebene Vorgang wird z.~B.\ von Bootloadern genutzt, die ein Firmwareupdate
  ermöglichen. \amforth hat in diesem Bereich seinen gesamten in Assembler codierten Sprachkern und einige
  Colonworte, um das Wort \texttt{i!} ausführen zu können. Jetzt wird sicher auch verständlich, warum
  \amforth keinen Bootloader mag (er wird überschrieben): Kein Platz mehr frei.

  Aus einer anderen Perspektive ist \amforth selbst ein Bootloader: Über das serielle Terminal lassen
  sich Befehle eingeben, die das Dictionary verändern und so die Funktion des Controllers verändern.
  Die Kommandosprache ist nur nicht kompatibel zu den in den Appnotes beschriebenen Befehlen. Aber
  vielleicht findet sich ja jemand, der die Syntax der Bootloader--Kommandos in \amforth einbaut.

  Damit sind wir im unteren, mit RWW bezeichneten Bereich. Hier sind die Interruptvektoren (ab Adresse 0),
  die für die Interrupts zuständigen Maschinencodebefehle, weitere Routinen, die für die konkrete
  Laufzeitumgebung wichtig sind, und nicht als \Forth--Worte codiert werden, und der zweite, größere Teil
  des Dictionarys. Neue Worte werden an diesen, unteren Teil des Flashs angehängt. Hier ist auch der
  Grund für das große Hexfile: Die "`Lücke"' im Flash kann recht groß sein (\amforth ist derzeit
  (Version 1.3) ca.\ 5,5 KB groß, trotzdem wird immer der gesamte Flash neu programmiert).

  Flash--Speicher hat beim Schreibzugriff einige Besonderheiten. Die erste ist, dass es keinen
  Zugriff auf einzelne Zellen (Eine Zelle ist so groß wie ein Maschinenwort für den
  Prozessor: 16Bit), sondern nur auf eine Page gibt, die "`am Stück"' geschrieben wird. Wenn
  man eine einzelne Zelle ändern möchte, muss man also zunächst den aktuellen Inhalt der betreffenden
  Page in einen eigens vorhandenen Puffer einlesen, die gewünschte Zelle richtig eintragen (Der Puffer
  kann nur einmal beschrieben werden), das Flash löschen, und kann dann die Page neu schreiben. Um die
  Anzahl der Löschvorgänge zu minimieren, prüft \amforth, ob überhaupt ein Löschvorgang erforderlich ist.
  Dies ist der Fall, wenn ein Bit von 0 nach 1 geändert wird. Von 1 nach 0 geht auch ohne Löschen und
  damit flash--schonend. Solange immer nur neue Worte eingetragen werden ist \amforth flash--schonend, die
  Ausnahme bei Worten, die \verb,does>, benutzen wurde erwähnt: \verb,does>, ändert das von \texttt{create}
  angelegte und bereits geschriebene Execution--Token von \texttt{DO\_VARIABLE} nach \texttt{DO\_COLON}.

  Bevor jetzt Befürchtungen aufkommen: \amforth wird immer noch auf dem ersten Mikrocontroller
  entwickelt.

\subsection{RAM}
  Die Hardware der ATmegas bietet ungewöhnliche Zugriffsmethoden. So sind die CPU--Register und die 
  I/O--Ports über eine RAM--Speicheradresse les-- und beschreibbar. Register \texttt{r0} hat die Speicheradresse
  0, I/O--Port 0 hat die Speicheradresse 32. Das "`wirkliche"' RAM (RAM--Zellen sind
  im Unterschied zu Flash--Zellen 8Bit groß) hat eine prozessorabhängige Startadresse. Der ATmega32 z.~B.\ fängt
  bei Adresse 96 (hex 60) mit RAM an; der Atmega169 erst bei 256 (hex 100).

  Der Vorteil dieser Adressierung ist, dass man mit einem Wort (\texttt{c@} resp.\ \texttt{c!}) sowohl auf den
  Hauptspeicher als auch auf I/O--Ports zugreifen kann. CPU--Register sollte man nur nach reiflicher Überlegung
  nutzen.

  \amforth benötigt RAM, um die verschiedenen \Forth--Datenbereiche abzubilden (\texttt{hld}, \texttt{pad} etc.).
  Hier zeigt sich eine weitere Besonderheit des \amforth: PAD wandert nicht mit dem Dictionary mit, sondern ist ortsfest.
  Hinzu kommen einige Bytes, um dem seriellen Terminal Platz für Ein-- und Ausgabepuffer bereitzustellen und die 
  Interruptverwaltung zu erledigen. Ebenso wird eine Userarea initialisiert. Dafür werden ca.\ 200 Bytes benötigt. 
  Der Rest wird über \Forth--Worte wie \texttt{heap} und \texttt{variable} (das \texttt{heap} intern nutzt) 
  verwaltet.

\subsection{EEPROM}

  Das in die Prozessoren eingebaute EEPROM wird auf den ersten Blick fast gar nicht genutzt. Das zugehörige Hexfile
  umfasst nur wenige Bytes, so dass man geneigt sein könnte, es wegzulassen. Nur: Ohne diese Bytes arbeitet
  \amforth nicht.
  
  Im EEPROM werden Variablen geführt, die die Verwaltung der zentralen Datenstrukturen realisieren.
  Sie können nicht im RAM liegen, da sie einen Stromausfall überstehen müssen, können aber andererseits
  nicht in das Flash geschrieben werden, da sie oft geändert werden und dies das Flash sehr schnell ruinieren
  würde.

  Im EEPROM sind die beiden Einstiegspunkte in das Dictionary (\texttt{dp} und \texttt{head}) gespeichert und 
  auch die nächste freie RAM--Adresse für z.B. \texttt{variable}. Ebenso ist der erwähnte \texttt{turnkey}--Mechanismus 
  im Grunde nur eine EEPROM--Variable, die das Execution--Token eines Forthwortes enthält, das durch das Wort 
  \texttt{quit} ausgeführt wird, bevor der \texttt{accept}/\texttt{interpret}--Zyklus startet.

\subsection{Assemblerumsetzung}

  Jedes Wort besitzt seine eigene Quelldatei mit der Endung \texttt{.asm}, auch wenn es als Folge von
  Execution--Tokens definiert wird. Bei diesen Worten ist zudem Vorsicht geboten: Es kann sein, dass sie nicht
  in korrekten \Forth--Code zurückübersetzt werden können. 

  Es werden außerdem Worte verwendet, die keinen \Forth--Header haben. Dies betrifft vor allem
  Worte, die von immediate--Worten in das Dictionary compiliert werden, um zur Laufzeit
  aktiv zu werden. In anderen \Forth--Systemen werden z.~B.\ runde Klammern genutzt, um
  diese Worte zu markieren. \amforth verbirgt sie hier für eine Optimierung des
  Platzbedarfs. Es ist nicht vorgesehen, dass diese "`hidden words"' von anderen als den
  zugehörigen \texttt{immediate}--words genutzt werden. Also spart sich \amforth den Speicherplatz
  für den Dictionary--Eintrag und compiliert nur das Execution--Token (XT). Damit werden Worte 
  wie \texttt{see} natürlich problematisch. Aber die sind ohnehin unnötig, da der Quelltext zur Verfügung
  steht.

  In der Regel wird der relative Sprungbefehl des ATmega--Prozessors verwendet. Dieser ist
  schneller und benötigt weniger Platz. Der Nachteil ist, dass nicht der gesamte Flash--Speicher
  erreicht werden kann. Dies ist ein weiterer Grund, warum \emph{alle} in Assembler codierten
  Worte im NRWW--Bereich des Flashs platziert sind. 

\section{Updates}

  Ein Update des \amforth im Mikrocontroller ist ein aufwändigeres Verfahren. Zuerst muss das
  Basissystem mit ISP oder JTAG neu geladen werden. Anschließend muss die eigentliche Anwendung
  wieder aus den Quellen oder per Hand im seriellen Terminal eingespielt werden.

  Es ist sehr empfehlenswert, die interaktiv definierten Worte anderweitig abzulegen, um sie
  erneut einspielen zu können. Von \amforth ist hier keine Unterstützung zu erwarten, da
  es als mikrocontroller--basiertes System keine Ahnung von Filesystemen hat und somit
  einen Befehl wie \texttt{include <filename>} nicht bereitstellen \emph{kann}.

\section{Libraries}

  Es wurde bereits angedeutet, wie Libraries bei \amforth funktionieren: Gar nicht. Es
  ist Aufgabe des Nutzers, die Definitionsfiles in der richtigen Reihenfolge auf den
  Controller zu übertragen.

\section{Ausblick}

  \amforth hat trotz seines geringen Alters eine gewisse Aufmerksamkeit geweckt. Die Mails
  der Nutzer umfassen sowohl Erfolgs-- wie auch Fehlermeldungen bzw.\ Unklarheiten des
  Systems betreffend. Die Einarbeitung dieser Informationen hat \amforth auch schon ein 
  gutes Stück vorangebracht.
  
  Für die Zukunft ist eine Sammlung von Routinen wünschenswert, die Standardaufgaben abdeckt.
  Auch wenn es kein Library--Konzept seitens \amforth gibt, können Routinen für beispielsweise
  den Zugriff auf den SPI-- und TWI/I2C--Bus bereitgestellt werden. Darauf können dann Worte aufsetzen,
  die spezielle I2C--Bausteine ansprechen. Idealerweise kann diese Bibliothek mit anderen
  Hardwareplattformen kombiniert werden, z.~B.\ mit den Artikeln von Erich Wäldes "`Adventures
  in Forth"'.

  Weitere zukünftige Änderungen betreffen die Organisation des obersten Stackelements TOS.
  Anton Ertl hat herausgefunden, dass dies Geschwindigkeitsvorteile bringen kann. Auf jeden
  Fall wird durch entfallene push/pop--Operationen der Code kleiner, was auch einen Wert an sich
  darstellt.

\begin{thebibliography}{9}
\bibitem{trute} amforth~Homepage, \url{http://amforth.sourceforge.net/}
\bibitem{ronminke} Ron Minke "`Forth von der Pike auf"' in: Vierte Dimension 3/4--2005 bis 1--2007
\bibitem{pelc} Stephen Pelc "`Programming Forth"' MPE Limited, 2005, \url{http://www.mpeltd.demon.co.uk/}\\\url{arena/ProgramForth.pdf}
\bibitem{noble} Julian V.\ Noble "`Finite State Machines in Forth"' in: THE JOURNAL OF FORTH
APPLICATION AND RESEARCH, \url{http://dec.bournemouth.ac.uk/forth/jfar/vol7/}\\\url{paper1/paper.html}
\bibitem{waelde} Erich Wälde "`Adventures in Forth"' in: Vierte Dimension 3--2006
\end{thebibliography}

\end{multicols}
\end{document}
