Also Ich hatte das gleiche mit C++ vor und bin auf den Entschluss gekommen das das fast unmöglich ist.
Wie gut kanst du den die Prog.Sprache (und welche)
Dazu müstes du Asamber lernen
Gruß Kevin
Hi,
wie programmiere ich den eine Neue Programmiersprache für uC-Controller?
Ich möchte gerne eine Programmiersprache so ähnlich wie "LOGO" entwickeln, mit dessen Hilfe man dem Roboter ganz einfach seine Umgebung beibringen kann.
Geht so etwas???
Ich denke man brächte so eine Art Bios für den Controller oder BootLoder.
Seh ich das richtig???
Und wie schreibe ich so etwas, ich muß ja dann einen Compiler schreiben der zwischen der Neuen Programmiersprache und ASM vermittelt - oder???
Gruß Manuel
Also Ich hatte das gleiche mit C++ vor und bin auf den Entschluss gekommen das das fast unmöglich ist.
Wie gut kanst du den die Prog.Sprache (und welche)
Dazu müstes du Asamber lernen
Gruß Kevin
Man sagt, kein Programmieren darf sterben, ehe er nicht wenigstens EIN Betriebssystem und EINEN Kompiler geschrieben hat.
Was willst du denn erreichen ?
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Das würde ich in C machen aus Effizienzgründen, und zwar folgendermassen:
- Du überlegst dir Syntax und Semantik deiner Sprache. Die Spache wird kontextfrei sein. Falls nicht. hast du mit Sicherheit einen Designfehler in deiner Sprache.
Oder willst du in Schwyzerdütsch proggen? Das ist teilweise kontextfrei )- Du schreibst einen Lexer oder nimmst einen Lexer-Generator. Der Lexer fasst die Zeichen deiner Eingabe zu Tokens (Schlüsselworte) deiner Sprache zusammen. Freie Lexer sind zB flex (C) oder jflex (Java). Der Lexer generiert Code in der Sprache, in der du dein LOGO proggen willst.
- Du schreibst einen Parser oder nimmst einen Parser-Generator. Als freien Parser-Generator für C/C++ gibt es zb den bison, für Java gibt es *namevergessen* (irgendwas mit cup).
- Der Lexer liefert die Tokens an den Parser. Der Parser führt immer bestimmte Aktionen aus, wenn ein bestimmtes Konstrukt erkannt wird. Auf diese Weise erhälst du die Repräsentation deines LOGO-Programms in einer von dir implementierten internen Darstellung (Programm-Baum).
- Diese Darstellung gibst du als C-Code (zum Beispiel) aus, und compilierst das zu Objekten.
- Du linkst die benötigte Standard-Funktionen aus einer vorher von dir erstellten Bibliothek dazu.
Lexer und Parser sind Bestandteile eigentlich jedes Übersetzers/Compilers/Interpreters.
Die Sprachbeschreibung im bison geht anhand der Regeln, in der du deine kontextfreie Grammatik formuliert hast. Genau so, wie es in den Büchern steht. Du gibst die Terminals und Produktionen an, und bison generiert dir den Parser. Um genau zu sein, muss deine Sprache LARL-kontextfrei sein, darf also nur eine Teilmenge der kontextfreien Sprachen sein. Aber für die Praxis reicht das allemal. Man muss nur etwas darauf achten, wie man die Produktionen hinschreibt.
Aber wozu eine neue Sprache bemühen. Eine Bibliothek mit den Funktionen tut's doch auch. Oder?
::EDIT::
Eine eigene, selbstgebastele Sprache hat natürlich auch was für sich:
Sie ist selbstgemacht! Aber wird auch nie wirklich fertig...
Disclaimer: none. Sue me.
Prinzipiell hat man zudem zwei grundlegende Möglichkeiten der Ausführung:Weg b entspricht etwa der einer Java-VM, die Bytecode interpretiert und zur Ausführung bringt. Weg a entspricht einer nativ durchcompilierten und statisch gelinkten Java-Applikation.
- Auf einem Host generiert man wie ober ausführbaren Code und lädt diesen in den µC
- Man erzeugt mit sich einen Bytecode. Auf dem µC befindet sich ein Interpreter, der sich Bytecode nachladen kann und diesen interpretiert und ausführt. Die benötigten Funktionen hält der Interpreter bereit, oder zieht diese nach, falls benötigt. Im letzten Falle erfordert das relokatiblen Code!
Während b zu halbwegs portablem Code führt (etwa Java Byte-Code), ergibt a idR schnelleren Code, der aber nicht portabel ist (vergleichbar Intel-Hex).
Disclaimer: none. Sue me.
Also ich habe schon mehrere Sprachen implementiert / weiterentwickelt (Eine Sprache zum Implementieren von Webservices).
Als Grundlage habe ich Java benutzt. Auf der Zielplattform (da war auch schon ein PDA dabei) läuft dann eine einfache JavaVM (die frei erhältlichen, die JDK 1.3 unterstützen, reichen aus).
Mit AntLR oder JavaCC erstellst du dann die Grammatik.
Dann musst du natürlich um die Grammatik noch ein System erstellen, die dann aus den Konstrukten, die der Parser erkennt, etwas macht. Du musst also Expressions, Statements, einen Statementgraphen, etc. implementieren, damit deine Befehle der neuen Programmiersprache dann auch effektiv etwas bewirken.
Will man eine komplette umfangreiche Programmiersprache entwickeln, dauert das, wenn man es alleine macht, recht lange. Ich würde dir also vorschlagen, such dir ein Team
Das Ganze müsste aber auch in C oder C++ realisierbar sein, da gibt es sicherlich auch freie Parser/Lexer-Generatoren.
In Java ist das natürlich etwas bequemer
Unwissenheit ist ein Segen
Hi,
Ich bastel grad an meiner eigenen kleinen Scriptsprache. Allerdings ist die nicht für den µC gedacht.
Ich benutze dazu nur C++ und keine fremden Parser oder Lexer oder was SprinterSB auch immer gerade beschrieben hat .
Ich habe mir gedacht, dass ich dabei wirklich bei NULL anfange, denn sonst ist es ja witzlos
Die Sprache hat dann eine VirtualMachine die in Windows läuft, und ich in alle meine Programme einbinden kann.
Grob gesagt macht mein "compiler" eine Liste mit Tokens und speichert sich dann die im source definierten Typen, dann die Funktionen und daraus dann generiert er den assembler code für meine VM. Ich könnte vermutlich auch eine VM für den µC schreiben - aber das mach ich aus performance-Gründen lieber nicht(und meine Scriptsprache den fertigen µC asm code generieren zu lassen ist mir zu kompliziert), und für den µC ist C eh vollig ausreichend...
MrQu: du willst ja nicht nur eine Programmiersprache für den µC machen. Du willst auch noch, dass man damit "dem Roboter ganz einfach seine Umgebung beibringen kann" was ich für ein eigenes Thema halte...
Du solltest dir einfach eine Lib machen wo die Funktionen drinnen sind.
Das erspart dir viele Probleme.
MfG Alex
Erst mal danke für die Vielllen Tipps!!! **
Ich weiß jetzt nicht genau ob einer von Euch "LOGO" noch kennt, die Sprache war so 85 ganz bekannt. Auf Atari 520 und 1040.
Es ist eine Mischung aus Basic und (vielleicht am ehesten) Java und HTML.
Sie ist stark am der Englischen Sprache orientiert.
z.B. Circle x,y,Radius,360
Ergebnis:
- x,y position vom linken oberen Bildschirmrand
- Radius = Radius
- 360 = Winkel, mit 180 zeichnet LOGO einen Halbkreis
Wenn man so eine ähnliche Sprache in einen uC bringt könnte man ganz einfach eine Karte der Umgebung eingeben, bzw. der uC könnte selber lernen.
Was haltet Ihr davon???
Jetzt hab ich so etwas noch nie gemacht, wer kann mir den da helfen???
Gruß Manuel
Einen Interpreter halte ich für besser. Der Compiler kann immer den gleichen P-Code für jeden Mikrocontroller erstellen. Nur der Runtime-Interpreter muss der jeweiligen Hardware angepasst werden.
Mein Vorbild: Interactive-C http://www.botball.org/ic/index.html
Das ist ein (pseudo) Multitask-Betriebssystem mit guter Doku.
Eigentlich braucht man da nur noch einen Interpreter für den AVR schreiben. Wie so etwas aussehen kann, ist an den Sources für den Motorola 6811 zu sehen.
http://www.cs.uml.edu/~fredm//cher/p...tive-c/source/
Prostetnic Vogon Jeltz
2B | ~2B, That is the Question?
The Answer is FF!
Ich nochmal *))*
Ich stelle mir so etwas wie das "BASCOM" Paket vor.
Ist so etwas schwer zu erstellen, hat von Euch so etwas schon einmal gemacht.
Stell mir das nur ein bischen ander vor!
Ich hätte gern ein IC2-EEprom genommen im dem die Sprache hinterlegt ist, man schreibt dann das Programm in irgendeinem Editor und schickt es dann mit z.B. PonyProg (über SPI, ISP, ...) in den uC und das übersetzen geschieht im System.
Gruß Manuel
Lesezeichen