\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 } 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}