\nLaut Wikipedia gibt es die Programmiersprache „BASIC“ jetzt \u00fcber 50 Jahre. Dem einfachen Syntaxaufbau mag es geschuldet sein, dass auch heute noch neue Projekte damit realisiert werden.<\/p>\n
Auch ich habe mit Basic ein paar Jahre programmiert und obwohl h\u00f6here Programmiersprachen viele Vorteile besitzen, kann man dennoch auch mit Basic einiges anfangen.<\/p>\n
Dieses Projekt zeigt einen Basic-Interpreter, der auf einem 32Bit ARM-M0 System von Infineon l\u00e4uft und mit dem der User, mit Hilfe von ein paar Buttons und einem Graphic-LCD, einfache Spiele und Anwendungen selbst erstellen kann.<\/p>\n
Das ganze habe ich „uPlay<\/strong>“ getauft…abgeleitet von dem benutzten Basic-Interpreter „uBasic“ und als batteriebetriebenen kleinen „Handheld“ designed.<\/p>\n Inhaltsverzeichnis<\/strong><\/p>\n Das „uPlay<\/strong>“ basiert auf dem Basic-Interpreter „uBasic<\/strong>“ von Adam Dunkels<\/strong> der von mir etwas „erweitert“ wurde. Als CPU-Board kommt ein XMC-2Go<\/strong> von Infineon mit dem XMC1100 Prozessor zum Einsatz. Als Display habe ich ein 84×48 Pixel Grafik-Display benutzt und zur Eingabe gibt es 5 Buttons. Die Hardwarekosten f\u00fcr einen Nachbau belaufen sich auf etwa 15 EUR. Der Aufbau der Hardware sollte an einem regnerischen Wochenende erledigt sein.<\/p>\n Als Minimalhardware wird eigentlich nur eine CPU ben\u00f6tigt, wenn das Basic-Programm im Flash vorhanden ist und man kein Display zur Ausgabe ben\u00f6tigt.<\/p>\n Mehr „Spa\u00df“ bringt es nat\u00fcrlich, wenn man ein Display benutzen kann und zur Eingabe ein paar Buttons vorhanden sind. In dieser Beschreibung gehe ich davon aus, das die Hardware so aufgebaut wird, wie im Schaltplan beschrieben. Es kann aber auch eine andere Kombination gew\u00e4hlt werden, wenn die Software entsprechend angepasst wird.<\/p>\n Wie schon geschrieben habe ich das ganze f\u00fcr das XMC2-2Go Board von Infineon und die XMC1100 CPU programmiert. Prinzipiell kann hier auch jede andere CPU benutzt werden, solange genug RAM f\u00fcr das Basic-Programm vorhanden ist und sie schnell genug ist um die Anwendung auch in einer vern\u00fcnftigen Zykluszeit abzuarbeiten.<\/p>\n Hier ein paar Eckdaten der XMC1100 :<\/p>\n Mit dieser CPU liegt die Zykluszeit von einer Basic-Zeile (je nach Umfang) bei ca. 500 us.<\/p>\n Am XMC-2Go Board sind nur 14 GPIO-Pins an Pfostenleisten zug\u00e4nglich, was den Einsatz der restlichen Hardware nat\u00fcrlich einschr\u00e4nkt. Aber wie an dem Projekt zu sehen ist, reicht es trotzdem f\u00fcr alle Funktionen.<\/p>\n Als Display habe ich das vom Nokia Handy 5110<\/strong> benutzt. Das ist g\u00fcnstig zu bekommen, hat eine Aufl\u00f6sung von 84×48 Pixel und wird per SPI-Schnittstelle betrieben. Als LCD-Controller ist ein PCD8544<\/strong> verbaut.<\/p>\n Ein weiterer Vorteil von dem Display ist, das f\u00fcr einen kompletten Refresh vom Grafik-Inhalt nur 504 Bytes Daten \u00fcbertragen werden m\u00fcssen. Bei der max SPI-Frq die das Display mitmacht (4MHz), dauert das rechnerisch nur 1ms.<\/p>\n Zum Betrieb des Displays werden 5 GPIO Pins ben\u00f6tigt\u00a0:<\/p>\n Um Strom zu sparen, habe ich die Hintergrundbeleuchtung per Jumper abschaltbar gemacht.<\/p>\n Der MISO Pin der SPI-Schnittstelle wird f\u00fcr das Display nicht ben\u00f6tigt. Damit dieser PIN nicht unbenutzt bleibt, habe ich daran einen „Break-Button“ angeschlossen mit dem man ein laufendes Basic-Programm abbrechen kann.<\/p>\n Der Pin hat einen internen PullUp, es reicht also einen Taster gegen GND einzubauen.<\/p>\n Der Status vom Button wird automatisch bei jedem refresh vom Display abgefragt. Falls er nicht bet\u00e4tigt ist, ist der R\u00fcckgabewert 0xFF. Falls er bet\u00e4tigt ist, wird eine 0x00 zur\u00fcckgeliefert.<\/p>\n Einen Pin der CPU habe ich als 10bit ADC-Eingang initialisiert. Dieser kann vom Basic-Programm aus abgefragt werden. In wie weit man das in seiner Anwendung benutzen will, bleibt jedem selbst \u00fcberlassen.<\/p>\n Im\u00a0„uPlay“<\/b>\u00a0wird der ADC nicht benutzt und ist nur im Schaltplan vorhanden.<\/p>\n Beim abfragen vom Basic-Programm aus wird ein Integer Wert von 0…1023 zur\u00fcckgeliefert, was einer Spannung von 0 bis 3,3V entspricht.<\/p>\n Die Umrechnungsformel „ADC->VOLT“ lautet demnach\u00a0: Spannung = 3,3V \/ 1023 x ADC_WERT<\/p>\n Von den 14 Pins des XMC-2Go sind 7 vom Display und ADC belegt, bleiben also noch 7 GPIOs \u00fcbrig. Um Spiele zu realisieren braucht man mindestens 5 Buttons „Steuerkreuz + Enter“ als Eingabe.<\/p>\n Ich habe das\u00a0„uPlay“<\/b>\u00a0also mit 5 Inputs und 2 Outputs designed. Wer das ganze Projekt f\u00fcr andere Zwecke benutzen will, kann das nat\u00fcrlich ab\u00e4ndern wie er lustig ist.<\/p>\n Beachtet werden muss nur, das nicht jeder Pin vom XMC-2Go als Ausgang geschaltet werden kann\u00a0:<\/p>\n Damit User-Eingaben ausgewertet werden k\u00f6nnen, habe ich 5 Buttons angeschlossen. 4 als „Steuerkreuz“ und 1 „Enter“.<\/p>\n Per Software sind die PullUps der CPU aktiviert also reichen Taster gegen GND zum schalten. Daraus folgt, das ein nicht bet\u00e4tigter Button eine „1“ beim einlesen vom Basic-Programm zur\u00fcckliefert und ein gedr\u00fcckter Button eine „0“.<\/p>\n Zwei der GPIO-Pins habe ich als Digital-Ausgang initialisiert, um z.B. eine LED oder ein Piepser anzuschlie\u00dfen.<\/p>\n Die Outputs sind als PushPull geschaltet. Im\u00a0„uPlay“<\/b>\u00a0werden die Outputs nicht benutzt und sind nur im Schaltplan vorhanden. (laut Datenblatt sind die PortPins nur bis max 10mA belastbar)<\/p>\n Die UART vom XMX-2Go Board wird ben\u00f6tigt um Basic-Programme nachzuladen. Sie wird auch im laufenden Basic-Programm als Standardausgabe der „PRINT“ Befehle benutzt.<\/p>\n Die Schnittstelle wird mit 115200 Baud initialisiert mit dem Frame-Parameter „8N1“.<\/p>\n Als Spannungsversorgung ist eine 3V Lithium Knopfzelle mit 550mAh vorgesehen (CR-2450). Wenn der USB Stecker an den PC angeschlossen ist, wird das Board per USB versorgt.<\/p>\n Eigentlich sollte man am Board, wenn es per USB versorgt wird, keine externe Spannung an die Stiftleiste anlegen. Ich habe aus dem Grund zum Schutz eine Diode vor der Batterie vorgesehen. Ein Jumper zum trennen der Batterie ist auch vorhanden (weil diese trotz Diode leergesaugt wird).<\/p>\n Die Stromaufnahme vom Board+Display (ohne Hintergrundbeleuchtung) betr\u00e4gt ca. 9 mA.<\/p>\n Als Entwicklungsumgebung habe ich KEIL uVision5<\/strong> benutzt. Davon gibt es eine kostenlose Version zum download die auch das XMC-2Go Board unterst\u00fctzt. Die max. 32k Flash Einschr\u00e4nkung ist f\u00fcr dieses Projekt nicht relevant.<\/p>\n Unter dem gleichen Link wie uVision gibt es auch den USB-Treiber f\u00fcr das Debug-Interface von Segger „JLink“<\/p>\n Die Software besteht im Prinzip aus zwei Teilen\u00a0:<\/p>\n 1. Dem\u00a0„uPlay“<\/b>\u00a0System das die angeschlossene Hardware kontrolliert (LCD, Buttons, UART usw). \u00dcber dieses System kann ein Basic-Programm per UART nachgeladen werden und dieses startet dann auch den Basic-Interpreter.<\/p>\n 2. Dem Basic-Interpreter „uBasic“ der ein Basic-Program das im RAM liegt \u00fcbersetzt und abarbeitet.<\/p>\n Nach dem PowerOn vom\u00a0„uPlay“<\/b>\u00a0steht das System im „Standby-Mode“ und es wird ein Menu auf dem Display angezeigt.<\/p>\n Man kann hier entweder ein Basic-Programm aus dem internen Flash der CPU starten oder ein schon geladenes Programm aus dem RAM. Die Auswahl erfolgt durch die Buttons „Left\/Right\/Enter“.<\/p>\n Zur Demo habe ich eine Version von dem Spiel „Snake“ programmiert und als Basic-Programm ins Flash gepackt. Das Programm liegt als Quellcode in der Datei\u00a0: „bas_snake.h“.<\/p>\n Alternativ kann auch eine UART Verbindung aufgebaut werden. Mit dem UART-Befehl „HELP“ kann man die Versions-Nummer vom „uPlay“ und vom „uBasic“ auslesen.<\/p>\n Um ein Basic-Programm zum\u00a0„uPlay“<\/b>\u00a0zu senden, muss dieses zuerst im „Standby-Mode“ stehen. Danach kann mit dem UART-Befehl „LOAD“ in den „Load-Mode“ gewechselt werden. (Es wird jetzt auf die \u00dcbertragung von einem Basic-Programm gewartet)<\/p>\n W\u00e4hrend der \u00dcbertragung wird die Anzahl der empfangenen Zeilen auf dem Display angezeigt. Um das Ende der \u00dcbertragung zu signalisieren muss ein „END“ \u00fcbertragen werden. Damit wird wieder in den „Standby-Mode“ gewechselt.<\/p>\n Das Programm steht jetzt im RAM und kann entweder mit dem UART-Befehl „RUN“ oder \u00fcber die Buttons gestartet werden.<\/p>\n Hinweis\u00a0: das Basic-Programm wird solange abgearbeitet, bis es zu dem Basic-Befehl „END“ kommt oder der „Break-Button“ bet\u00e4tigt wird.<\/p>\n Hier ein Bild wie ein Download per UART und die Ausgabe dazu aussieht. Das ganze funktioniert auch nur mit dem reinen XMC-2Go (also auch ohne Display und Buttons).<\/p>\n Die beiden LEDs auf dem XMC-2Go zeigen den aktuellen Status vom System an\u00a0:<\/p>\n F\u00fcr das Display gibt es einen 504 Byte gro\u00dfen Graphic-Puffer im RAM (84 x 48 Pixel). Die Befehle aus dem Basic-Programm schreiben\/lesen in diesen Puffer und alle 100ms wird der komplette Inhalt vom Puffer zum Display gesendet.<\/p>\n Im Moment ist nur eine Schriftart implementiert in der Gr\u00f6\u00dfe 6×8 Pixel. Damit passen 6 Zeilen auf das Display mit je 14 Zeichen.<\/p>\n Der ADC wird im Single-Conversation-Mode betrieben, wird also bei jedem Aufruf vom Basic-Programm aus neu gestartet.<\/p>\n Die Basic-Befehle f\u00fcr Digital-IN, Digital-OUT werden direkt an die entsprechenden GPIOs weitergegeben.<\/p>\n Durch die relativ langsame Zykluszeit vom Basic-Programm ist ein entprellen der Eing\u00e4nge nicht notwendig. (zumindest denke ich das\u00a0\ud83d\ude42<\/p>\n Die UART ist die standard Ausgabe der „PRINT“-Befehle vom Basic-Programm aus.<\/p>\n Ein „10 PRINT 123“ sendet also den String „123“ \u00fcber die UART. Als Stringendekennung wird ein CarriageReturn+Linefeed (0x0D,0x0A) angeh\u00e4ngt.<\/p>\n Beim senden von Daten vom PC an das\u00a0„uPlay“<\/b>\u00a0muss der PC ein CarriageReturn (0x0D) am Ende von jedem String anh\u00e4ngen.<\/p>\n Der Basic-Interpreter von Adam Dunkels ist sehr einfach aufgebaut und die Funktionsweise ist auch ohne Dokumentation leicht per Debugger zu verstehen.<\/p>\n Dieser Interpreter wurde schon von vielen als Basis benutzt. Bekannt aus diesem Forum sind z.B. die Portierungen f\u00fcr den AVR von Rene Boellhoff und Uwe Berger.<\/p>\n Ich selbst habe nur mit der original Version von Adam Dunkels gearbeitet und wollte diese so wenig wie m\u00f6glich ab\u00e4ndern um den einfachen Aufbau nicht zu verlieren.<\/p>\n Der Interpreter besteht nur aus 4 Files\u00a0: Dem „uBasic.c.+h“ File und dem „Tokenizer.c+h“ File.<\/p>\n Im „Tokenizer“ sind alle Basic-Sprachbefehle hinterlegt. Dieser liefert beim Aufruf der Funktion „get_next_token“ zur\u00fcck, um welchen Befehl oder welches Zeichen es sich im geladenen Basic-Programm gerade handelt. Der R\u00fcckgabewert besteht aus einem einzelnen Bytewert, dem „Token“.<\/p>\n Um z.B. die Basic-Zeile „10 PRINT a“ zu zerlegen, m\u00fcsste man den Tokenizer 3mal aufrufen und dieser w\u00fcrde 3 Tokens zur\u00fcckliefert mit den Namen\u00a0: „LINENUM“ , „PRINT“ , „VARIABLE“<\/p>\n Das „uBasic“ k\u00fcmmert sich um das aufrufen vom Tokenizer und entscheidet je nach empfangenen Token was daraufhin gemacht werden soll. Hier sind die Funktionen aller Basic-Befehle „ausprogrammiert“ das bedeutet in unserem Beispiel w\u00fcrde die Funktion „print“ angesprungen werden, der Inhalt der Variable „a“ w\u00fcrde ausgelesen und per UART versendet werden.<\/p>\n Das ganze ist recht simpel gestrickt und kann dementsprechend leicht ge\u00e4ndert und angepasst werden.<\/p>\n Die ersten \u00c4nderungen die ich am uBasic gemacht habe, waren reine Bugfixes\u00a0:<\/p>\n Als zweiten Schritt habe ich das uBasic etwas „erweitert“\u00a0:<\/p>\n Der dritte Schritt war das vergr\u00f6\u00dfern vom Basic-Sprachumfang um die angeschlossene Hardware zu steuern. Dazu geh\u00f6ren folgende Punkte\u00a0:<\/p>\n Hier w\u00e4re eigentlich die Arbeit am Basic-Interpreter fertig gewesen (und hat auch soweit funktioniert) wenn nicht die Durchlaufzeit der Basic-Programme erb\u00e4rmlich langsam gewesen w\u00e4re.<\/p>\n Der Tokenizer der das Basic-Ascii-Programm durchackert muss jedes einzelne Zeichen untersuchen um aus dem String „print“ (in allen m\u00f6glichen Schreibweisen) das Token „PRINT“ zu ermitteln. Und das bei jedem Durchlauf obwohl sich der Befehl nie mehr \u00e4ndert.<\/p>\n Auch das Suchen der Zeilen-Nummern bei „GOTO\/GOSUB\/NEXT\/RETURN“ verbraucht immens viel zeit, weil jedes Mal von der ersten Zeile des Basic-Programmes aus gesucht wird.<\/p>\n Ich habe mich darauf hin entschlossen diese zwei Sachen zu verbessern und einen „Pre-Parser“ einzubauen, der vor dem eigentlichen Programmstart einmal abgearbeitet wird. Dieser Eingriff \u00e4ndert die Original-Version nur minimal aber das Ergebnis ist um ein vielfaches besser.<\/p>\n Der Pre-Parser ist 3 Teilig aufgebaut und hat folgende Aufgaben\u00a0:<\/p>\n Zuerst wird das komplette Basic-Programm nach Ascii-Keywords durchsucht (z.B. „PRINT“ oder „GOTO“) und durch einen zwei Byte Hex-Code ersetzt. Da jedes Keyword mindestens zwei Zeichen lang sein muss, ist das kein Problem. Das erste Byte ist eine Kennungs-ID mit dem Wert 0x01. An dieser Kennung erkennt der Parser sp\u00e4ter das es sich um eine Ersetzung handelt. Das zweite Byte ist direkt die Array-Nummer vom gefundenen Keyword. Das bedeutet der Parser muss sp\u00e4ter nicht mit einer For-Schleife das passende Keyword suchen, sondern kann direkt mit der Array-Nummer arbeiten. (damit es zu keiner Verwechslung mit anderen Ascii-Zeichen kommt, wird zus\u00e4tzlich das Bit7 gesetzt)<\/p>\n In diesem Schritt wird das Basic-Programm nach Keywords durchsucht, die ein Sprung zur folge haben (also „GOTO“,“GOSUB“,“FOR“). Bei so einem Keyword, wird das Sprungziel (bzw. R\u00fccksprungziel) als Zeilen-Nummer in einem Array gespeichert. Doppelte Eintr\u00e4ge werden abgefangen.<\/p>\n Hier wird das Programm noch mal durchsucht und zwar um rauszufinden welche Programm-Adresse welchem Sprungziel entspricht. Es werden also zu allen gefundenen Sprungzielen die passenden Einsprungadressen gespeichert. Sp\u00e4ter im eigentlichen Programmlauf wird dann z.B. bei einem „GOTO 100“ im Array nachgesehen welche Pointeradresse die Zeilen-Nummer 100 hat und es wird direkt dort mit dem Programmlauf weitergemacht.<\/p>\n Das Ergebnis vom Pre-Parsing ist eine enorme Geschwindigkeitsverbesserung im Vergleich zur Ur-Version von Adam Dunkels. hier eine Vergleichsmessung mit zwei For-Schleifen die 1000 mal eine Subroutine mit einer Print-Anweisung aufrufen\u00a0:<\/p>\n Dieses Programm dauert ohne Pre-Parser 45 Sekunden und mit Pre-Parser nur noch 1,8 Sekunden\u00a0! Das ist 25 mal so schnell. Mit dieser Geschwindigkeit lassen sich auch kleine Spiele realisieren.<\/p>\n Hier eine kurz Zusammenfassung \u00fcber die Syntax vom uBasic\u00a0:<\/p>\n Es folgt eine Liste aller im Moment unterst\u00fctzten Basic-Keywords\u00a0:<\/p>\n![\"\"](\"http:\/\/mikrocontroller.bplaced.net\/wordpress\/wp-content\/uploads\/2017\/12\/300px-UPlay.jpg\")
<\/a>
\nFertig aufgebautes uPlay<\/div>\n\n
\n
\n
\n
\n
Einleitung<\/h2>\n
\n
Hardware<\/h2>\n
CPU\/BOARD<\/h3>\n
\n
\n
DISPLAY<\/h3>\n
\n
\n
Break-Button<\/h3>\n
\n
ADC<\/h3>\n
\n
GPIOs<\/h3>\n
\n
INPUTS<\/h4>\n
\n
OUTPUTS<\/h4>\n
\n
UART<\/h3>\n
\n
Spannung\/Strom<\/h3>\n
Entwicklungsumgebung<\/h2>\n
\n
uPlay<\/h2>\n
Startmenu\/Kommunikation<\/h3>\n
Basic-Programm download<\/h3>\n
![\"\"](\"http:\/\/mikrocontroller.bplaced.net\/wordpress\/wp-content\/uploads\/2017\/12\/300px-Terminal_Test.jpg\")
<\/a>
\nTest per Terminal-Programm<\/div>\nStatus-LEDs<\/h3>\n
\n
DISPLAY<\/h3>\n
ADC<\/h3>\n
GPIOs<\/h3>\n
UART<\/h3>\n
uBasic<\/h2>\n
\n
\n
Anpassungen<\/h3>\n
\n
\n
\n
Verbesserungen<\/h3>\n
1. Schritt\u00a0: Ersetzung aller Basic-Keywords<\/h4>\n
2. Schritt\u00a0: Speichern der Sprungziele<\/h4>\n
3. Schritt\u00a0: Suchen der Pointer-Adressen der Sprungziele<\/h4>\n
Ergebnis<\/h4>\n
10 REM =============\r\n15 REM Speed-Test\r\n20 REM =============\r\n25 PRINT \"Start\"\r\n30 CLRTIC\r\n35 FOR n = 0 to 10\r\n40 FOR m = 0 to 100\r\n45 GOSUB 100\r\n50 NEXT m\r\n55 NEXT n\r\n60 GETTIC a\r\n65 PRINT \"Stop\"\r\n70 PRINT a,\"ms\"\r\n75 END\r\n80 REM --------------\r\n100 PRINT n,m\r\n110 RETURN\r\n<\/pre>\n
Syntax<\/h3>\n
\n
![\"\"](\"http:\/\/mikrocontroller.bplaced.net\/wordpress\/wp-content\/uploads\/2017\/12\/300px-UPlay_Aufbau.jpg\")
<\/a>![\"\"](\"http:\/\/mikrocontroller.bplaced.net\/wordpress\/wp-content\/uploads\/2017\/12\/300px-Xmc2go.jpg\")
<\/a>![\"\"](\"http:\/\/mikrocontroller.bplaced.net\/wordpress\/wp-content\/uploads\/2017\/12\/300px-Xmc2go_montiert.jpg\")
<\/a>![\"\"](\"http:\/\/mikrocontroller.bplaced.net\/wordpress\/wp-content\/uploads\/2017\/12\/300px-UPlay_komplett.jpg\")
<\/a>