Druckbare Version
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 ?
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...
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).
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 :)
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/
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
Wie mein Robotor aussehen soll:
Ich möchte für jede Funktion einen eigenen uC verwenden, d.h. einen uC für jedes Antriebsrad, einen uC als Datensammler, einen uC als Online-Compiler, einen für die Akku kontrolle, ...
- interne Komunikation über IC2 (5 Drahtbus = 2 Datenleitungen, 2 Betriebsspannung, 1 Alarmleitung)
Deshalb auch meine Idee das Programm in einem uC übersetzen zu lassen.
Ihr denkt jetzt bestimmt ich "Spinne" oder ???? *:-)*
Aber ich denke aus ist das beste um einen Autargen-Robotor zu bekommen.
Nice to have.Zitat:
Zitat von MrQu
Du musst zunächst mal unterscheiden zwischen der Sprache, in der du das formulieren willst (Umsetzung jetzt mal zweitrangig) und dem 'Lernen'.
So was komplexes als Sprachkonstrukt einzubauen ist nicht sinnvoll, weil das viel zu speziell ist. Ein Befehl wie 'lerne das Zimmer kennen' wirst du eher als Modul/Funktion/Bibliothek oder was auch immer selber zusammenbasteln, und nicht als Sprachelement zur Verfügung stellen.
Wenn deine Sprache sehr einfach ist, und nur Befehle hat wie
GOTO
GOTO_XY
TURN
TURN_TO
SPEED
WAIT
BEEP
kannst du die Codes irgendwo ablegen und mit einer recht einfachen Prozedur interpretieren und evtl verändern. Eine Implementierung im Sinne einer komplett neuen Sprache mit Lexer, Parser, etc. ist das dann zwar nicht, dafür kommst du schneller zu brauchbaren Resultaten und musst dich nicht mir Krempel rumschlagen, der mit deiner eigentlichen Fragestellung "Robby soll lernen" wenig zu tun hat.
Wenn du keine Vorstellung davon hast, wie er etwas lernen/erinnern/vergessen/verändern/erkennen/bewerten kann, hilft dir auch keine neue Sprache weiter, vor allem dann nicht, wenn du sie selber erst noch bauen musst...
@SprinterSB:
Hast Du so etwas schon einmal gemacht, Du scheinst ja echt Ahnung von so etwas zu haben.
In welcher Sprache schreibst Du den????
Hast Du von so einer Lösung mal ein Beispiel?
UND was hällst Du von der Idee die einzelnen Funktionen eines Robot auf einzelne uC zu verteilen und diese dann untereinander komunizieren zu lassen?
Gruß Manuel
Jo, das war in Java. Ein Applet für Geometrie-Visualisierung war das. Die Quelle der jeweiligen Progrämmchen stand innerhalb des Applet-Tags. Die Visualisierung dann durch Maus und Weiterclicken etc, zB Umkreis in Abhängigkeit von der Geometrie des Dreiecks oder Schritt-für-Schritt Ani, wie so ne Konstruktion von statten gehen kann. Das ganze war ne prozedurale Sprache. Was ich schon hatte waren Grundtypen wie ganze Zahlen, Fliesskommas, Vektoren und Geraden, Kreise und Listen und Grundoperationen auf den Typen wie Sinus, Vektorprodukt, Schnittmengen von Objekten etc. rekursive Funktionen und so klappten...laber...laberZitat:
Zitat von MrQu
Jedenfalls hab sich's irgendwann aus den Augen verloren und jetzt gammelt's irgendwo rum...
PicNick...wir warten auf dich :-DZitat:
Zitat von PicNick
*Joke*
Hallo MrQu, deine Idee ist Klasse.
Ich progge immer noch mit MSLOGO. Ist sehr flexibel und nicht übertrieben
voll mit Floskeln.
Dort kannst du auch die serielle Schnittstelle und die parallele Schnittstelle
ansprechen. Ist der erste Schritt zum Proggen mit dem AVR.
Castle
FORTH ist auch eine exotische Sprache, beschäftige mich seit 1985 damit.
Damit kann man sehr leicht eine eigene selbstsändige Oberfläche entwickeln.
Castle
@super_castle
abend,
MSLOGO kenn ich garnicht, was ist das für eine Version die du verwendest?
Hast du nen Link zu der Version???
Gruß Manuel
Welcome to MSWLogo: http://www.softronix.com/logo.html
Wenn du mit MSLOGO arbeiten tust, setze die nicht in deutsch um.
Es gibt eine deutsche Übersetzung für dieses LOGO, es werden dann aber nicht mehr alle Funktion erreichbar sein.
Castle
Hast du dir vorher mal ganz unabhängig von der Programmiersprache überlegt, wie du einem Roboter überhaupt so ganz einfach seine Umgebung beibringen willst?Zitat:
Ich möchte gerne eine Programmiersprache so ähnlich wie "LOGO" entwickeln, mit dessen Hilfe man dem Roboter ganz einfach seine Umgebung beibringen kann.
Selbst wenn mein Roboter Deutsch als Sprache verstehen würde und ich ihn stundenlang zuquatschen könnte, stell ich mir das nicht so einfach vor.
Ich könnte ihm sämtlliche Koordinaten aller in seiner Umgebung befindlichen Gegenstände eingeben.
Das ergäbe dann wahrscheinlich einen Array aus Kordinatenpaaren, einen mehrdimensionalen Array oder irgendwein ähnliches Konstrukt, das bereits in fast allen Programmiersprachen exisitiert und damit wohl auch einfacher zu beschreiben ist, als in Umgangssprache.
Ich glaube nicht, dass es sich lohnt dafür eine neue Sprache zu entwickeln.
Aber was nutzt es, wenn ich dem Roboter eine Karte seiner Umgebung eingeben kann?
Der Roboter müsste sich dann auch irgendwie mit Hilfe der Karte in seiner Umgebung orientieren können.
Das erfordert aber auch die notwendige Hardware und Sensorik.
Du könntest dem Roboter auch einprogrammieren seine Umgebung selber kennenzulernen. Aber auch das stellt recht hohe Anforderungen an Hardware und Sensorik und erfordert erst mal eine Lösung wie der Roboter sich überhaupt orientieren und seine Position bestimmen soll.
Es gibt hier eine ganze Menge Threads zum Thema Navigation, Kartenerstellung usw. und viele Leute die daran rumtüfteln.
Ich glaube da gibt es noch eine ganze Menge Probleme zu lösen, bevor man sich Gedanken drüber machen muss wie, bzw. in welcher Sprache man möglichst einfach die passende Software dazu schreibt.
Damit will ich dir deine Idee eine eigene Sprache zu entwickeln nicht ausreden.
Wäre nur doof, wenn es dir wrklich hauptsächlich darum geht dem Roboter seine Umgebung beizubringen, du eine eigene Programmiersprache dafür entwickelst und dann erst feststellst, dass es an ganz anderen Dingen scheitert.
Die Probleme die bei Odometrie auftauchen, die Ungenauigkeit von GPS, die Reflektionen von IR-Signalen in geschlossenen Räumen usw. sind ja alles keine Softwareprobleme.
@recycle
Guten Morgen, *:-)*
da hab ich mir auch schon meine Gedanken gemacht.
Als erstes möchte ich an jedem Rad eine Lachscheibe anbringen, ähnlich wie in alten mechanischen C.Mäusen damit der uC mitzählen kann wie er seine Räder bewegt hat.
Rundherum so eine Art Stoßstange mit Microschaltern und Ultraschallsensoren, damit er feststellen kann ob er wo angefahren ist und zur Abstandsmessung bevor er wo anfährt.
Ich habe auch gelessen das man so etwas wie ein "Lasergitter" zur Orientierung verwenden kann.
Das soll auf zwei Arten funktionieren (angeblich).
Entweder der Roboter erzeugt dieses Gitter selbst (wie bei Barcodscannern) und orientiert sich an den Reflecktionen oder man bringt die Laser an den Wänden an mit unterschiedlicher Pulsung (Leuchtfeuer) und der Robo orientiert sich an dem Gitter.
Ahhh, Frage - Hast Du mit Lasern zur Messung schon mal gearbeitet???
Gruß Manuel
du wartest, daß ich sterb' oder daß ich ein Sys schreib ? :mrgreen:Zitat:
Zitat von Rage_Empire
Ich denk, mit einem Sys können wir mehr anfangen :cheesy:
Ich hab' insgeheim gehofft, daß du das sagen würdest.
Kleiner Tipp: ALT GR + m = µ
Dann musst du nicht immer uC schreiben :)
@maze2k:
Danke für den Tipp, hab das "Ding" immer gesucht! *:-)*
Du scheinst dich ja auch gut auszukennen, mit Programmieren.
Du hast geschrieben du machst solche Sachen in JAVA.
Wie verträgt sich den JAVA mit einem µC (ATMega32)???
BASIC, ASM, C - OK und wie ist das mit JAVA?
Was hälst Du eigendlich von der Idee mehrere µC für einen Roboter zu verwenden, jeden für eine Aufgabe (z.B. einer für das linke Rad, einer fürs rechte, einer für die Lenkung, ... und so weiter)
Komunikation für 5 Drahtbus.
Gruß Manuel
"NanoVM - Java für AVR"
Such das mal mit Google..... Es gibt veschiedene Artikel darüber.
Castle
Hallo MrQu,
man kann mit C relativ einfach eine "Art" Programmiersprache erzeugen. Ich mache das manchmal in meinen Programmen. Hier ein Ausschnitt aus dem Nikolaushaus-Code, der Programmteil malt ein Nikolaushaus mit einem Asuro-Roboter und dürfte recht nahe an Deinem Logo-Problem liegen:
Gruss,Zitat:
#define w2vor { go(70); Msleep(200);go(73); Msleep(200);}
#define w2halbe_vor { go(30); Msleep(200);go(41); Msleep(200);}
#define vor { go(50); Msleep(200);go(50); Msleep(200);}
#define links45 { turn(180); Msleep(200);turn(135);Msleep(200);}
#define links90 { turn(90); Msleep(200);}
#define links135 { turn(135); Msleep(200);}
void nikolaus(void)
{
links45;
w2vor;
links90;
w2halbe_vor;
links90;
w2halbe_vor;
links90;
w2vor;
links135;
vor;
links90;
vor;
links90;
vor;
links90;
vor;
}
stochri