Es gibt ja für den 8051 nen Basic Interpreter (Tiny Basic) gibt es so etwas ähnliches auch für die neuen Atmel Chips?
Das kenn ich schon. Ich suche aber etwas das auf dem Chip Läuft. Tiny Basic konnte man z.B. über ein Terminal uber den seriellen Port bedienen.
Hallo Johannes, was heisst konnte?!? Ich habe das Ding immernoch - läuft langsam, aber läuft! Gruß Axel
Ja klar kann es das noch war bei mir aber ne weile her als ich das dass letzte mal genutzt habe. So war das gemeint. Hab das teil auch noch hier rumliegen.
ich habe ihn beim Umzug gefunden, sonst wüsste ich nicht mal, das ich das gute Teil noch besitze. Aber gut, tut nichts zur Sache...
Diese Anfrage gab es schon öfters - vielleicht kann man sich ja zusammentun, und so etwas schreiben? Angedacht hatte ich so etwas schon öfters, aber immer wieder aus zeitgründen verworfen. Ein Interpreter ist eigentlich kein Hexenwerk, allerdings als "Hobby"-Projekt schon ein wenig groß für eine einzelne Person. Zutrauen würde ich mir das schon, aber Zeit hätte ich nicht... Ich habe gerade aktuell auch das MCS-51 Basic wieder ausgegraben, genau aus dem Grund, weil man es eben vor Ort ohne PC und Flash-Upload direkt benutzen kann. Allerdings hat es den einen, großen Makel: Es ist wirklich langsam. Die Hauptursache sehe ich darin, daß alle Variablen grundsätzlich als Float definiert sind, da wäre einiges Potential, wenn man Integer implantieren könnte. Nächstes Problem bei einer solchen Lösung: Wohin mit dem Code? Ähnlich wie bei der C-Control in einem I2C-EEProm wäre zwar elegant, würde wieder einiges an Geschwindigkeit kosten (man könnte mit der Hardware-TWI einiges herausholen, Prefetch usw.) oder ins Flash, das bei den Selbstprogrammierbaren eigentlich auch kein Problem wäre. Bleiben die Laufzeitvariablen, die müssen natürlich in den internen RAM - und da kann es eng zugehen. Ein Compiler kann da von vornherein einiges optimieren, ein Interpreter muß auf Speed optimiert werden und man hat nicht die Rechenpower eines PC im Genick. Da ließe sich evtl. beim Tokenizer etwas machen. Der nächste Punkt: Benennung von Variablen. Da der Name von Variablen im Quelltext steht, ist natürlich klar, daß sie zwecks Speicherersparnis möglichst kurz sein müssen - das wiederum ist der Lesbarkeit abträglich. Und es ist nicht unbedingt wünschenswert, daß der Interpreter ausschließlich im Mega-128 lauffähig ist... Eine Alternative wäre das Deklarieren von Variablen in einem Header (sowieso sinnvoll), dort würde Typ und der volle Name angegeben, der Interpreter substituiert dann einen 2-Byte Code (das wären 65536 verschiedene Variablen), der die Variable beschreibt und beim Befehl "List" würden diese Variablennamen wieder im Klartext erscheinen. Übrigens: Wer interesse hat.. ich habe momentan, wie schon oben erwähnt, zu Testzwecken ein MCS-51 Basic-System am Laufen - vollkommen Stand-alone, mit einem Terminal bestehend aus einem 40x16 (240x128 Grafik auf T6963-Basis) Display und einer alten PC-Tastatur, die Brücke bildet ein Mega-8, der sogar eine primitive Edit-Funktion zur Verfügung stellt. Allerdings ist der Code des Terminals ziemlich Spaghetti, ist so an zwei- drei Abenden "gewachsen" - müßte ich erst einmal entwirren...
Hi, ich habe den MC51Bsic als Steuerung für meine alte 2Meter Mühle am laufen. War mal ein Handfunkgerät für 144 bis 146 Mhz. Bei diesem musste man die Frequenz mit einem Mäuseklavier an der Oberseite einstellen. Das ganze habe ich nun(damals) in ein Gehäuse gepackt und mit einem 4x16 Display als Anzeige, einige574er als Latch und 5Tasten zur Menüsteuerung versehen. Die Idee mit dem Interpreter hat wohl auch Sony-Ericsson aufgegriffen: Im GSM-Modul GR47 ist auch ein Interpreter drinn, allerdings in C. Leider ist die IDE nicht der Brüller, grobe Schnitzer werden schon hier erkannt, kleinerer Fehler werden sang-und klanglos übernommen, beim Upload gibt es auch noch nicht wirklich Trödel, aber beim Ausführen des Codes im Modul kommt es dann zu unerklärlichen Fänomenen(wie schreibt man das?). Auch leidet die Lesbarkeit der Quelle, da die Einrückungen alle mit als Tabs in den Quelltext eingehen und platz verschwenden würden, wenn man diese drinnen ließe. Einen Interpreter zu schreiben, traue ich mir nicht zu. Maximal das bunte PC-Interface in Delphi -> das kann ich. Gruß Axel
@AxelR. ich glaube, auch mit der neuen Rechtschreibung bleibt es bei Phänomen. Grüße Quark
Bei kleinem Programmspeicher (AVR) eignet sich Basic nicht so gut. Wer einen Interpreter selbst programmieren will, der PC-unabhängig direkt auf dem Mikrocontroller laufen soll, sollte stattdessen Forth vorziehen. Diese Sprache ist einfacher zu implementieren und läuft um ein Vielfaches schneller als Basic, da zuerst in einen Zwischencode compiliert wird und dieser recht schnell ausgeführt wird. Bei Forth ist der Interpreter aber nach dem Minimalprinzip ausgeführt, um Speicherplatz zu sparen. Ausdrücke müssen in Postfix-Schreibweise notiert werden (siehe alte HP-Taschenrechner).. ansonsten ist es aber eine vollwertige Hochsprache. Wer sich mit der Sprache anfreunden kann (viele Informationen im Netz, meist nur englisch), dem könnte ich Tipps geben, wie man es auf dem AVR umsetzen kann.. Grüße Daniel
Naja, es hindert ja keinen daran auch BASIC Sourcen vor dem ausführen in einen Zwischencode -> PCode, umzuwandeln. Nur benötigte man dann AVRs die auch ein gutes Stück an SRAM enthalten, bzw. externen SRAM haben. Am cleversten wäre es aber immer noch auf dem PC den Source in PCode umzuwandeln und im AVR selber nur den PCode Interpreter zu bauen. Dies ist sogar die üblichste Vorgehensweise, zB. gibt es eine solchen PASCAL Interpreter für AVR's oder die BasicCards, SmartCards der Firma ZeitControl arbeiten so. Übrigens einige SmartCards der BasicCards laufen auf AVR SmartCard Prozessoren. Gruß Hagen
@Hagen: stimmt, so wird es üblicherweise gemacht.. wenn der Compiler auf dem PC läuft, kann einiges an Intelligenz reingesteckt werden und ordentlich optimiert werden. Der Nachteil ist, dass man immer einen PC im Schlepptau hat und ein Programmierer, der den Compiler bedienen kann. Dieser Aufwand ist nicht nötig, wenn man nur eine kleine Steuerung braucht, die sich vielleicht in der Garage befindet. Dann wäre es schön, wenn die Entwicklungsumgebung (im einfachsten Fall eine Eingabezeile) sich direkt auf dem Zielrechner (hier Mikrocontroller) befindet. Ein Interpreter hat zudem den Vorteil, dass direkt Kommandos ausgeführt werden können, ohne das ein Compilieren, Übertragen und Neustarten des Programms nötig ist. Um externen SRAM kommt man natürlich nicht drum herum. Daniel
@Daniel: Warum in Gottes Namen hält sich das Gerücht, Basic sei langsam, so lange? Schau Dir mal "PureBasic" für den PC an, da wird Visual C blaß. Ob ich Basic, C oder Pascal als Interpreter irgendwo implementiere, ist absolut wurscht, es kommt auf die Effektivität des Interpreter - Codes an. Daß auf einem 2313 ein vollwertiger Interpreter nicht laufen wird, ist auch klar, aber es muß nicht unbedingt ein Speicherriese sein. Und das sog. "vorcompilieren" hat schon der ZX-80 von Sinclair gemacht... Nur mal zur Information: Der ZX-81 hatte 1KB RAM. Eigentlich alle Interpreter auf den damaligen Homecomputern hatten einen Tokenizer, der die Befehle in einen Byte-Code umgesetzt hat. Lediglich Ausdrücke waren noch im Klartext. Verzichtet man auf verschachtelte For-Next und auf Gosub, kommt man sogar ohne einen Stack aus. Und wenn wir wieder einen PC zum Kompilieren von Byte-Code brauchen, dann kann man gleich auf BASCOM umsteigen und erhält nativen Code.
>Warum in Gottes Namen hält sich das Gerücht, Basic sei langsam, >so lange? Na aus dem gleichen Grund warum IBM-HD's "immer" Schei** sind,ATI immer Mackige Treiber hat,Nvidia immer Schlechte Bilder liefert,AMD immer Heiß und empfindlich ist,Intel immer viel zu Teuer für die Leistung ist und Audi's immernoch schneller Rosten als se fahren ;)
Muß ich einfach sagen: Das MCS 51 Basic war und ist genial. Für neuere Projekte würde ich es aber nicht mehr nehmen. Es gibt bereits sehr gute, verbesserte Versionen, die im Eprom ablaufen. (zB: bei Ribu.at, MICRO515-Basic / 32 KB EEPROM ). SG Josef
[Daniel:] > Um externen SRAM kommt man natürlich nicht drum herum. Warum nicht? Wenn Du kein Basic nimmst, sehe ich da keine Probleme. [thkais:] > Daß auf einem 2313 ein vollwertiger Interpreter nicht laufen > wird, ist auch klar Der könnte gerade die untere Grenze darstellen, wenn man Bedienung über die UART akzeptiert (Standalone mit LCD und Tastatur würde ich nicht unter atmega8xxx anfangen, denn dann muß auch ein minimaler Editor mit rein). Platz für gewaltige Programme bleibt da wohl nicht, aber sinnvoll wäre es durchaus, um z.B. die Funktion einer Platine interaktiv zu prüfen, das Zusammenspiel mit anderen Komponenten zu testen und einfache Aufgaben zu realisieren. Voraussetzung wäre wohl ein Minimalsystem plus Aufbaubibliothek, aus der man sich einfach den Umfang zusammenstellen kann, den man braucht. Gruß, Philipp.
@thkais: Es geht darum, ein komplettes Interpreter-System auf dem AVR unterzubringen. Also wie Philipp schon schreibt: einfacher Editor über LCD und Tastatur. Was meinst du dann mit PureBasic oder BASCOM, die sind doch fehl am Platz, oder ?! @philipp: Ich hab Bedenken wegen der maximalen Schreibvorgänge des FLASHs. Da ein Interpreter vom Umprogrammieren lebt, würde ich lieber SRAM verwenden und einen AVR mit ext. Speicherinterface wie mega8515. Daniel
@Daniel: Bitte richtig lesen. "Purebasic" und "Bascom" fielen in
einem anderen Zusammenhang als Antwort auf einen Beitrag
("Geschwindigkeit von Basic allgemein" und Stichwort "vorcompilieren
auf einem PC").
Man könnte ein Speicherinterface mit 64K Adressraum und parallelem
8-Bit Zugriff mit 10 I/O-Pins aufbauen. Oder, wie schon weiter oben
erwähnt, per I2C oder SPI einen externen Speicher aufbauen - allerdings
auf Kosten der Geschwindigkeit.
@thkais: Die "Geschwindigkeit von Basic allgemein" hatte ich nicht gemeint, sondern nur die von Basic-Interpretern auf Mikrocontrollern, die nicht in Maschinencode compilieren können. Also klassisch aneinander vorbeigeredet.. :) Daniel
Könnte man so sagen ;) Aber weshalb sollte Forth schneller als Basic sein? Ich habe mir mal den Intel-Basic Interpreter angeschaut, und der ist hauptsächlich so lahm, weil er nur Floating-Point Operationen kennt (und die sind BCD-basiert) und weil er die Syntax zur Laufzeit prüft. Würde man einen Pre-Run (ähnlich wie Qbasic) machen, d.h. den Syntax-Check vom eigentlichen Programmablauf abtrennen, und dann noch Integer-Variablen einführen, ließe sich mit Sicherheit etwas machen. Und den Expression-Interpreter kann man auch vereinfachen, indem man nur einfache Operationen nach Schema A=B+C zuläßt, d.h. der Anwender muß die Rechenoperationen in einzelne Pakete aufteilen. Auch interessant wäre das Vorberechnen der Sprungmarken (für Gosub, For-Next, Repeat-Until). Die werden z.B. beim MCS-51 Basic erst berechnet, wenn es soweit ist; Sprich: Der Interpreter wuselt sich bei Sprungmarken durch alle Zeilen durch, bis er sie findet. Würde man diese Sprungmarken im PreRun berechnen und als Binärwert (Pointer direkt zur Zeile) ablegen, würde man im Programmverlauf einiges an Zeit sparen. Ist also alles eine Frage der Optimierung. Ob ein Ausgabebefehl dann "print" oder "write" heißt, ist dann wurscht...
@thkais: hast schon Recht, man könnte aus Basic einiges herausholen, wenn es speziell für den AVR optimiert ist. Forth ist halt nur einfacher aufgebaut als Basic, deshalb hatte ich mich damit versucht, weil das Leben wohl zu kurz ist, um selbst einen kompletten Basic-Interpreter in der Freizeit zu entwickeln... :) Forth hat wie Basic zwei Interpreter: der erste wandelt die Eingaben in einen Zwischencode und der zweite führt diesen so schnell wie möglich aus. Dieser zweite Interpreter fällt bei Forth extrem kurz aus (beim AVR beispielsweise 5 Assemblerbefehle bei Hardware-Speicherinterface), da der Zwischencode im Grunde nur aus vorberechneten Adressen besteht. Das alles basiert auf einen Stackprozessor, den man mit den AVR nachbildet (AVRs eignen sich dafür ganz gut, auf einen 8051 ist mehr Aufwand erforderlich) Daniel
Ich habe mir nochmal ein paar Gedanken gemacht und stehe nun vor einem ziemlichen Problem. Eigentlich hätte ich gerne auf Zeilennummern verzichtet, aber das wird wohl nicht gehen: Wenn wir von einer Editierung "vor Ort", also z.B. über eine Terminalverbindung per RS-232, ausgehen, dann klappt das nicht ohne Zeilennummern - schließlich soll auch ein "dummes" Terminal, das nur aus Display und Tastatur besteht, in der Lage sein, damit zu arbeiten. Auch beim Editieren wird man das Problem haben, daß man garnicht weiß, welche Zeile genau denn nun gerade editiert wird, weil man eben keinen Full-Screen Editor implementieren kann. Eine Alternative wäre die automatische Nummerierung, wobei die Nummern nur vom Editor erzeugt, aber nicht im Programmcode gespeichert werden - sozusagen als Hilfsanker. Die andere Alternative besteht darin, dem Basic-Interpreter ein eigenes Display zu spendieren, auf dem dann ein Full-Screen Edit möglich ist - zu aufwendig und zu speziell. Eigentlich würde mir ja dieser minimal-Zeileneditor aus dem MCS-51 reichen - nur der benötigt definitiv Zeilennummern. Hat vielleicht einer eine Idee, die ich nicht sehe?
kleiner einwandt zum thema zeilen nummern und so... bild doch ein vt-100 terminal nach ;) dann kannst über die serielle mit hyperterm drauf herumbasteln wenn du willst wie auf ner unix-shell mit telnet g forth müsst ich mir mal anschaun..hab schon einiges drüber gehört... im prinzip is das eine gute idee...aber warum implementiert man dann nicht gleich eine java virtual maschine... dann könnte man java laufen lassen g wär doch witzig ;) und nebenbei wäre dann das simulator-basteln ein klax... sind die virtual-maschine-specs eigentlich frei ?? würd mich interessieren... 73 de oe6jwf
@Philipp: Sorry, von Forth habe ich vor 15 Jahren mal etwas gehört - aber bevor es so interessant wurde, daß ich mich damit beschäftigt hätte, war es wieder in der Versenkung verschwunden. Ich verstehe nicht so ganz, wieso Forth das Problem, einen Source-Text editieren zu können, lösen soll. Mir geht es darum, daß man unter Umständen auch nur ein ein- oder zweizeiliges Display an der Kiste haben könnte. Unter diesen Umständen ist es ohne eine Zeilennummerierung quasi unmöglich, sich zu orientieren - denn man weiß ja nie, wo man sich gerade befindet, weil die Zeilen vor- und nachher nicht sichtbar sind. Einen Interpreter zu basteln, der ohne Zeilennummern auskommt, ist kein grundsätzliches Problem. Es ist nur so, daß Zeilennummern den Editor vereinfachen würden. Wie kann mir da Forth helfen - schließlich brauche ich auch dort Anhaltspunkte, in welchem Teil des Source-Codes ich mich befinde. Java? Sorry, da klinke ich mich genauso aus, wie bei Forth. Weder die eine noch die andere Sprache beherrsche ich. Ob Java frei ist, weiß ich nicht so richtig - war da nicht irgendetwas mit Sun?
@Hans: VT-100 war ein gutes Stichwort. Ich kannte diesen Terminal-Standard zwar schon, aber wußte nicht, daß der Befehlsumfang so groß ist. Damit ließe sich tatsächlich ein Full-Screen Editor aufbauen. Ist nur die Frage: Braucht man das? Ein Full-Screen Editor ist nur sinnvoll mit einem großen Display. Ein großes Display ist eigentlich nur sinnvoll in Form eines Laptops. Und wenn ich jedesmal den Laptop anwerfen muß, dann ist der Schritt vom Interpreter weg zum Compiler auch nicht mehr groß. Wie schon oben erwähnt: Man muß auch mit einem kleinen Display arbeiten können. Das größte, das noch einigermaßen bezahlbar ist, ist ein 240x128 = 40 Zeichen auf 16 Zeilen.
vt100 kennt zwar recht viele befehle aber die wirklich wichtigen lassen sich an ein bis zwei händen abzählen und sind sehr einfach zu implementieren. Ich denke UART und ein terminalprogramm wär schon das gegebene, man muss ja kein Laptop nehmen ein PDA würde es da ja auch schon tun (obwohl ich nicht weiß ob man für die vt100 terminal software bekommt) Java? Das soll ein Witz sein oder? Ich mag Java, aber ein AVR dürfte damit wohl etwas überfordert sein. Es ist auf jeden Fall 32bittig und durch die Objekt orienttiertheit brauch man auf jeden Fall vviiiiieeeeeeellll RAM, und wenn du mit dem virtual machine code arbeiten willst brauchst du ja wieder einen Compiler auf dem PC...
@thkais: in Forth schreibt man ja praktisch nur 1-zeiler Prozeduren, die dann von anderen wieder aufgerufen werden. Es heißt, wer Mehrzeiler braucht, hat schlecht programmiert. (-: @Hans: Java VM auf einem AVR? Ist weder realisitisch noch sinnvoll, denn für interaktives Arbeiten ist Java auch wieder nicht geeignet. Ich habe ohnehin den Eindruck, daß hier viele unterschiedliche Zielsetzungen durcheinandergeraten. Der eine will ohne PC entwickeln, der andere debuggen; einem geht es um die Einfachheit, dem anderen um die Interaktivität. Wenn man alles unter einen Hut bringen will, wird der Hut keinem passen ... (-;
@thkais: Zeilennummern wären bei einem kleinen Display sehr hilfreich. Die Zeilennummern müssten aber schon einen festen Abstand haben (1,2,3,...) und nicht beliebig wie typischen Basic, wo man noch mal eine Zeile hinterher dazwischenmogeln kann (10,20,25,30,40). Danach kann man es sich dann zeilenweise auslisten. Ich sehe auch keinen Ausweg, ohne Zeilennummerierung auszukommen. Zeilenorientiert kann ja jedes einfache Terminalprogramm (Enter und Backspace). Daniel
@Daniel: So habe ich mir das auch vorgestellt: Keine feste Nummerierung, sondern eine vom Editor generierte. Scheint die einzig sinnvolle Idee zu sein. Naja, die Tage werden jetzt kürzer - ich wollte eigentlich schon länger mal einen einfach gehaltenen Interpreter basteln, so eine Art SPS-Ersatz um schnell mal irgendwo ein Progrämmchen reinzuhacken. Mal sehen, ob was draus wird.
..schon einen Algorithmus ausgetüftelt, um Ausdrücke / Befehle auszuwerten ?? Daniel
Befehle sind kein Thema, das ist eine einfache Sprungtabelle Token->Adresse. Bei Ausdrücken wirds schon interessanter, wenn man Punkt vor Strich, Klammerregel und sonstige Prioritäten beachten muß. Um das Ganze zu vereinfachen, umgehe ich dieses Problem zunächst - es wird nur zwei Argumente geben (wie schon weiter oben erwähnt). Das dürfte der Übersichtlichkeit und auch der Geschwindigkeit zuträglich sein. Heißt also: Ein Ausdruck kann nur die Form <Ergebnis> := <Argument1> <Operand> <Argument2> haben - Ausgenommen Funktionen wie z.B. ABS() oder INT(). Das Internet sollte so etwas auch hergeben. Vor fast 20 Jahren habe ich mal mit einem Schulkollegen innerhalb eines Referats einen Compiler gebastelt - da war eine entsprechende Auswertung von Ausdrücken drin, aber frage mich keiner, wie das Ding funktionierte. Alles in Allem werde ich aber vor Weihnachten nicht dazu kommen - wenn überhaupt... wäre (leider) nicht das erste Projekt, das aus Zeitgründen die Schublade nicht verläßt :(
Was ist denn inzwischen aus dem Projekt geworden?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.