www.mikrocontroller.net

Forum: PC-Programmierung C-Interpreter zum Steuern/Erfassen


Autor: Matthias Weisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es gibt eine Menge Programmierhilfsmittel.
Leider fand ich bisher nichts Geniales
außer das HP-Basic, das heute scheinbar nur
noch einen geringen Stellenwert besitzt.

HP-Basic:
 + extrem stabil
 + rasch etwas zu schreiben
 + hält bei Fehlern an, beheben und weiter mit Continue
 + Interpreter und Compiler
 + sehr gute Bibliotheken
 - recht teuer auf PC (HT-Basic)

Visual Basic:
 - buggy
 - teilweise umständlich und problembehaftet
 - keine rasche Portierung nach C
 + rasch eine schöne Oberfläche machbar
 + das freie Gambas verfügbar -> Linux

Labview:
 + graphisch übersichtlich
 + sehr große Bibliothek
 - ziemlich teuer
 - kein einfacher Weg zu C-Code für kleine uC

C-Interpreter
 + rasch etwas austesten
 + Variablen abfragen, ändern, dann weiter
 + rascher Weg zu C auf uC
 + Verwendung von Bibliotheken
 + preisgünstig
 - welche Bibliotheken für Graphikausgaben?
 - wer hat Erfahrung?

Ich halte die Lösung mit dem C-Interpreter
für interessant.
Ich fand zu diesem Thema:

PAWN  embedded scripting language
CH    leicht wie Basic
CINT  C/C++ Interpreter
CSL   C Scripting language

Hat jemand mit diesen Sachen bereits gearbeitet
und kann etwas über seine Erfahrungen damit sagen?

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also was willst du jetzt genau wissen/tun? ;-)

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, hast du eventuell Links zu den letzten 4 Themnen (PAWN...CSL). Finde
da nicht sehr viel nützliches im Netz.

mfg W.K.

Autor: volly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

wie wär es mit Python

+ für Windows und Linux verfügbar
+ Unmengen an Bibliotheken
+ C-Code Integration über Module möglich
+ Hochwertige Graphiktools wxpython
+ Open Source
+ Debugmöglichkeiten (man kann sich sogar einen eignen bauen)

Python ist allerdings objektorientiert, dies kann je nach Anforderung
etwas aufwendiger sein, aber hat enorme Vorteile.

Eine andere Alternative wäre Lisp oder Perl, aber damit habe ich keine
Erfahrung bzw. habe ich Lisp noch nie verstanden.

Gruss
Volly

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Python ist allerdings objektorientiert, dies kann je nach Anforderung
etwas aufwendiger sein, aber hat enorme Vorteile."


Python ist hybrid, wie C++ auch.
Wer nicht OO will, muss sie auch nicht nutzen.

Autor: Matthias Weisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@volly: Python hört sich interessant an.
Ich möchte trotzdem erstmal die Interpreter
etwas näher ansehen.

@W.K.: Es gibt eine Menge im Netz:
The Small language. A little scripting language.
Small is now called pawn. www.compuphase.com/small.htm
http://www.compuphase.com/pawn/pawn.htm

Die letzte Version ist 3.1.3526 (2006-03-04).
Es tut sich da also noch was.

Die Seite
http://www.compuphase.com/pawn/pawnprojects.htm
zeigt Projekte, die PAWN nutzen wie Apple iPod,
programmable MP3 player/controller, Wagencontroller
von Carl Schenck AG, CIZGI nutzt es zur Gebäudeautomation
und Krankenhausklimatisierung. Fa. Artran steuerte
Maschinen. Auch Spiele wurden damit programmiert oder
von der Bedienerseite unterstützt.
RemotelyAnywhere, ein PC-Fernsteuerprogramm benutzt Small
als Scriptsprache und der Fenstermanager Enlightenment.

    * pawn is a simple, C-like, language.
    * pawn is a robust language with a compiler that performs a maximum
of static checks, and an abstract machine with (static) P-code
verification and dynamic checks.
    * For porting purposes, pawn is written in ANSI C as much as
possible; Big Endian versus Little Endian is handled.
    * To suit internationalization and localization, pawn supports
Unicode/UCS-4 and UTF-8, as well as codepages. The compiler can convert
source code entered in a particular codepage to Unicode; it also
supports source code files in UTF-8 format.
    * pawn is quick (especially with Marc Peter's assembler
implementation and/or his "just-in-time" compiler)
    * pawn is small. It has been fitted on an Atmel ATmega128
microcontroller, a Philips LPC2138 (ARM7 core with 32 kiB RAM), as well
as on a Texas Instrument's MSP430F1611 (MSP430 core with 10 kiB RAM and
48 kiB Flash ROM).
    * Documenting the source code can be done with "documentation
comments"; the pawn compiler extracts those comments, combines them
with information it deduces from the source code and writes an XML file
that is immediately viewable (and printable) with a web browser.
    * pawn supports states and automatons in the language, including
state-local variables.
    * pawn is free and it is published under the zLib license (this is
a liberal license, and it allows using pawn in commercial
applications).
    * More features... see the separate "feature page"

Gruss
   Matthias

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> @volly: Python hört sich interessant an.
> Ich möchte trotzdem erstmal die Interpreter
> etwas näher ansehen.

Python ist ein Interpreter.
Dann gäbe es da noch Lua und natürlich diverse Ecmascript-Varianten.

Autor: Mighty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn ich in Lisp nicht entsthaft entwickeln
würde, ist es einen oder zwei Blicke wert.
Ganz schön p*rn Daten wie auch Code und dessen
Strukturen zur Laufzeit ohne Einschränkungen
in irgendeiner Form zu verändern.

Aber das war ja nicht deine Frage ;)

Denn Lisp ist wirklich "gewöhnunhsbedürftig"
(aber hald sehr mächtig, wie gesagt)

Autor: Matthias Weisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rolf: Danke für den Hinweis zu Python.

@Mighty: Danke für den Tipp zu Lisp.

@Alle: Leider scheint niemand hier
PAWN und die anderen genannten C-Interpreter
zu kennen.
Schade, daß ich auf diese Weise nicht
auf diesem Gebiet hinzulernen kann.
Ich hoffte über ein paar Erfahrungen mit
diesen Tools aus erster Hand zu hören. :-)

Gruss
   Matthias

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Äh, was suchst du eigentlich genau?
Eine Sprache um Prototypen auf einem PC zu entwickeln, die du dann
gegebenenfalls auf einen uC portieren willst?
Wenn ja, was spricht dann gegen einen X-beliebigen C Compiler?

Autor: Matthias Weisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bartli: wie ich oben sagte suche ich etwas um
+ rasch etwas zu schreiben
+ was bei Fehlern anhält
+ die Möglichkeit gibt diese zu beheben
+ und dann mit "Continue" weiterzumachen
+ ohne neu zu kompilieren
+ ohne den Versuch neu zu starten und
  zeitaufwendig bis zu der Absturzstelle
  laufen zu lassen.

C-Compiler sind ok, wenn es keine Fehler gibt.
Keine Fehler gibt es aber nie.

Und so stürzt jedes Prog. meist dann ab,
wenn man es nicht brauchen kann - meist
mit einem RunTimeError und ohne Hinweis,
warum der jetzt nun auftrat und wo.

Ein Interpreter hält im Gegensatz dazu an
der Fehlerstelle an und erlaubt das Feststellen
und Beheben der Fehlerursache und die Fortsetzung
genau an der Stelle.

So ist es aus meiner Sicht ein interessanter Weg.

Der C-Compiler kann ggf. bei Geschwindigkeitsproblemen
später immer noch zum Einsatz kommen. Bis dahin hat der
Interpreter jedenfalls jede Menge Zeit und Nerven gespart. :-)

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, aber wenn du also etwas suchst, was Zeit und Nerven spart, dann
such nicht nach einem Tool was Edit & Continue unterstützt, sondern
such dir eine Sprache aus, für die du ein anständiges Unittest
Framework zur Verfügung hast (ausser du willst selbst eins
schreiben/portieren).

Ich versprech dir, Unittests sparen Zeit und Nerven wie kaum etwas
anderes.

Autor: volly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

also ich denke die Arbeitsweise -- direkt Fehlererkennung & beheben &
und weitermachen -- funktioniert nur bei den einfachen Fehlern. Wenn Du
z.B. ein Feldüberlauf und Deklarationsfehler hast, fängst Du dort auch
wieder von vorne an.

Versuch es doch mal mit dem Ansatz von Bartli, die Testunits kosten
zwar in der Anfangsphase viel Zeit, aber die Zeit bekommst Du später
ohne Probleme wieder raus. Andererseits gibt es bei den
Programmiersprachen try-catch-Befehle, mit denen Du auch nicht
erwartende Fehler abfangen kannst, ohne daß das Programm abstürzt.

Im würde die Zeit eher in ein sauberes Konzept, vielleicht mit UML, und
Testunits stecken, als mich der Hoffnung eines Interpreters hingeben.
Ich denke Du wirst später enttäuscht sein.

Gruss
Volly

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> die Testunits kosten zwar in der Anfangsphase viel Zeit

Ja, das ist ganz wichtig. Nur weil die ersten Versuche mit Unittesting
sinnlos erscheinen (du hast das Gefühl, nicht voranzukommen, weisst
nicht, wann was wie testen), nicht gleich aufgeben. Es ist
gewöhnungsbedürftig.

Empfehlen kann ich dieses Buch:
http://www.amazon.de/exec/obidos/ASIN/0974514012/r...
Es beschreibt zwar JUnit, es ist aber eigentlich egal, was für eine
Sprache/Testframework Kombination man benutzt. Das Prinzip ist immer
dasselbe.

Autor: Matthias Weisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bartli, Volly:
Danke für Eure Sichtweise, auch wenn Sie erst
mal völlig neu und ungewohnt für mich ist
und ich mir so noch wenig darunter vorstellen
kann.

Es gibt offenbar sehr viele verschiedene
Möglichkeiten.

Wenn Ihr den Interpreter nicht für so toll
haltet bin ich fast geneigt eher so ein
System mit dem alten HPBASIC wieder irgendwo
auszugraben, mit dem ich vor 20 Jahren so
rasch so gute Erfolge hatte.
Da lief der Laden - viel rascher und problemloser
als heute mit Labview. Das ist sicher subjektiv.
Damals war ich mit der Lösung sehr zufrieden.

Liebe Grüße
  Matthias

Autor: Yussarian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Mess-, Steuer- und Regelaufgaben erledige ich mit Testpoint.

http://www.cec488.com/index.html

Lad dir das Programm runter, ist bis auf die Speicherfunktion voll
funktionfähig.

Zu kaufen bei KEITHLEY-Deutschland. Kostet ca.1600,-EUR.
Kostenloser Support.
Beliebig viele kostenlose Runtime-Versionen. Ist Objektorinetiert. Du
kannst im Programm Fehlerbehandlungsobjekte einfügen.

Nachteil, falls es ein Nachteil ist: Das Design ist unverkennbar
Windows 3.1.

Hier mal ein Anwendungsbeispiel:

www.lieven-instruments.com

Autor: Volly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Da lief der Laden - viel rascher und problemloser
> als heute mit Labview. Das ist sicher subjektiv.
> Damals war ich mit der Lösung sehr zufrieden.

So, nun paßt garnichts mehr zusammen, was willst Du eigentlich machen.
Woran willst Du Labview koppeln, wo liegen die Probleme?

Gruss
Volly

Autor: Matthias Weisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Yussarian:
Danke für den Tipp zu Testpoint.
Es ist halt leider keine freie Software.

@Volly:
Zu Deiner Frage: Ich will mich nicht
mit Tools herumärgern, sondern meine
Anwendung rasch zum Laufen bringen
und Tests machen können, wobei ich nicht
viel Zeit zur Programmierung aufwenden
möchte, da das Ergebnis zählt.

Später kann es sein, daß mal ein C-Programm
aus dem einen oder anderen Teil werden soll.
Daher die Idee mit dem C-Interpreter.
Zum MSP430 und Atmel AVR gibt es ja den GNU.
Und die Toolkette mit dem C-Interpreter
läuft wohl auf beiden Familien.

Labview ist eigentlich viel zu groß und
unhandlich für das, was ich da vor habe.
Der Pluspunkt ist, daß es wohl eine Light-
Variante geben soll und eine Linux-Variante gibt.

In Richtung C auf uC ist es aber wohl eher
ungeeignet.

Autor: pittbull_nt@yahoo.com (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,
ich mache solche tests immer auf 'nem normalen pc mit dem ollen visual
studio 6. der c-compiler (im gegensatz zum c++ compiler) ist sehr gut.
es kompiliert/linkt rasend schnell und man kann prima debuggen
(source-level). vorteil: bis auf hardware-spezifische sachen kann man
den c-code fast 1:1 übernehmen und man hat keine downloads zum target.
z.b. habe ich auf diese weise einen prism2-kompatiblen wlan-treiber
geschrieben, der jetzt in einer embedded  umgebung eingesetzt wird.
zugriffe auf die hardware mache ich über makros. die werden je nach
umgebung zu den richtigen api-aufrufen bzw i/o port zugriffen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und eines sollte man auch mal sagen:
Mit einem guten Debugger kannst Du fast dieselben
Dinge machen, die Du auch mit einem Interpreter
machen kannst. Zumindest die Dinge, die in
einem Program noch relativ gefahrlos geändert
werden können, während das Program läuft.
Variablen anschauen, überwachen, neue Werte
zuweisen. Point of Execution umsetzen,
Return Stack anschauen (Wichtig für die Frage:
Woher ist die Funktion eigentlich aufgerufen
worden), im Stackframe in der Aufrufhierarchie
zurückgehen und dort Variablen anschauen (ist
besonders interessant bei Rekursionen, etc.).
Programmcode ändern während das Pgm läuft ist
sowieso immer eine haarige Sache, geht aber auch
zb. mit Visual C/C++ ab 6.0

Da hat dann ein Interpreter keine wirklichen
Vorteile mehr. Zumal auf heutigen Desktop-Systemen
alles was weniger als 10000 Zeilen hat sowieso
so schnell kompliliet wird, dass man sich noch nicht
mal eine Zigarette anzünden kann.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein guter Interpreter hat schon Vorteile. Wenn in einem Ruby-Programm an
einer bestimmten Stelle unerklärliches Verhalten auftritt setze ich
einen Breakpoint, bekomme eine Interpretershell und kann an dieser
Stelle mit dem Zustand des Programmes beliebig experimentieren,
Programmschnipsel ausführen, Funktionen umdefinieren, Variablen ändern
- all das direkt in der Sprache, ohne irgend ein zusätzliches Werkzeug.

Autor: HW-Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es nicht umbedingt C sein muss, dann schau Dir mal FORTH
(wikipedia)an. Ist Interpreter, Compiler, Debugger, OS in einem. Die
Arithmetik ist allerdings sehr sehr sehr gewöhnungsbedürftig!

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer programmierbare Taschenrechner von HP mag (wie den HP48), der wird
mit Forth glücklich.
Für anders ausgerichtete Menschen ist Forth ziemlich grässlich.
(Ich weiß, wovon ich rede, mein erster "Homecomputer" war ein
Forth-Rechner. Mich schaudert's noch heute)

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was war denn das für eine Kiste ? Ein Jupiter Ace ?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau. Der Joghurtbecher.

Autor: HW-Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rufus

Kann ich gut nachvollziehen, geht mir genauso. Was aber interessant
ist, ist die Realisierung bzw. die Philosophie, die dahinter steckt.
Hatte damals ein echt gutes Buch über FORTH, nicht ein reines
Syntaxbuch sondern wie es impementiert ist. War mal kurz davor für die
C-Control 2 (C164) eine Entwicklungsumgebung unter C nach den
Grundlagen (Funktionsprinzip von FORTH) zu entwickeln, d.h.
Interpreter, Debugger, OS. Naturlich OHNE "umgekehrte polnische
Notation" (ist nicht rassistisch, heist wirklich so).

Im Prinzip sind Befehle wie "printf" nichts anderes als
Forth-Wörter.

Da FORTH eine stackorientierte Sprache ist, läst sie sich leicht
portieren. Im Prinzip war FORTH das erste Java (virtuelle Machine).

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ekligste an Forth ist eben die UPN gewesen. Naja, und der
Joghurtbecher mit sagenhaften 956 Bytes, die für Programme und Daten
zur Verfügung standen, der war halt auch nicht gerade das gelbe vom Ei
als Entwicklungssystem.
Kurrzeitig hatte ich mir damals ein Forth-System namens GraForth
angesehen, das auf einem Apple II lief ... die UPN hat mich dann aber
erfolgreich davon abgehalten.

Mehr Informationen zum Jupiter Ace (auch Schaltpläne und ein
kommentiertes ROM-Listing!) gibt es übrigens hier:

http://www.jupiter-ace.co.uk/

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ekligste an Forth ist eben die UPN gewesen.

Hmm, UPN ist doch schön. Das schätze ich am meisten am HP48.

> Naja, und der Joghurtbecher mit sagenhaften 956 Bytes, die für
> Programme und Daten zur Verfügung standen, der war halt auch nicht
> gerade das gelbe vom Ei als Entwicklungssystem.

Da hab ich ja auf dem kleinsten AVR mehr ;-)

PS: Schon mal in PostScript programmiert?

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Volkmar e. P. (keepitsimple)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

nachdem hier alle möglichen Programmiersprachen durch sind, ist Deine
Ursprungsfrage eigentlich noch nicht richtig beantwortet.

Wenn Du mit keiner der Programmiersprachen so richtig glücklich bist
bzw. der Protierungsaufwand Dir zu gross ist, dann "baue" Dir doch
eine eigene Sprache.

Sprachaufbau definieren (Grammatik) und dann mit lex/yacc o.a. Parser +
Sprachinterpreter einen eigenen Compiler oder Interpreter bauen. Damit
bist Du flexibel und wenn Du es in ANSI C realisierst, dann ist auch
eine Anpassung an unterschiedliche Platformen kein Problem.

Ich habe für verschiedene Projekte, nicht nur mit Mikros, solche
Steuersprachen erstellt. Ich gebe zu, dass die Einarbeitung erstmal ein
bisschen Zeit erfordert, aber dann gehts leicht von der Hand und es
macht auch noch Spaß :-)

Gruß
Volkmar

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn Du mit keiner der Programmiersprachen so richtig glücklich bist
[...] dann "baue" Dir doch eine eigene Sprache.

Ist so oder ähnlich nicht auch FORTH entstanden ?
:D

Autor: Matthias Weisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Volkmar:
Danke für den Beitrag. Im Prinzip halte ich den Vorschlag
für sehr gut. Nur leider habe ich die Zeit für so
etwas im Moment nicht. Es sind zuviele andere
Dinge neben dem Beruf zu tun.

Daher hoffte ich auf die Nutzung von etwas
bereits Vorhandenem. Es gibt ja eine Menge im Netz.
Und ich habe sicher nicht den Überblick über die
große Menge an Lösungen.

Mir ist ein OpenSource-Produkt lieb, das auf
Resonanz stößt, weil es da dann auch eine Zukunft
geben wird.

Keep it small und simple sind wichtige Ansatzpunkte.

Schade finde ich, daß sich bisher niemand gemeldet
hat mit konkreten Erfahrung zu meinen oben genannten Interpretern.
Ch scheint nicht so übel zu sein. Und Small/Pawn wohl auch
nicht. Da gibt es eine ganze Entwicklungsumgebung dazu, die
nicht erst noch erstellt werden muss.

Conrad vermarktet die C-Control - mit Basic.
Es gab aber auch mal C für die C-Control auf dem 80C167.
Ein Interpreter eben.

So etwas müsste doch interessant für den einen oder anderen
sein. Es sieht aber so aus, als ob eindeutig Basic die
Nase vorn hat. Vielleicht ist dann Gambas für Oberflächen
ein gar nicht so dummes Tool.

Ich dachte an etwas wie Gambas in C. Dann kann man die
Oberfläche in C machen und den Code für den uC auch.
Eine Sprache für alles.

Der Overhead schreckt manche wohl ab bei den
objektorientierten C-Tools.
Daher dann teure Ansätze wie Labview, Testpoint etc.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Wenn Du mit keiner der Programmiersprachen so richtig glücklich
>> bist [...] dann "baue" Dir doch eine eigene Sprache.
>
> Ist so oder ähnlich nicht auch FORTH entstanden ?

Ist so oder ähnlich nicht jede Programmiersprache entstanden?

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, C# z.B. wohl eher nicht.

Aber sicher viele, z.B. Perl und Ruby.

Autor: Volkmar e. P. (keepitsimple)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

um noch mal auf Deine Eingangsfrage zu kommen. Ich habe mir die von Dir
beschriebenen Sprachen angesehen. Sie sind alle ganz interessant, aber
was möchtest Du konkret damit programmieren? Einen PC, eine Steuerung,
einen Mikrocontroller?

Ich prgrammiere gerade eine virtuelle Maschine für ein von mir
entwickeltes Steuerungssystem. Die VM läuft sowohl auf einem MEGA64/128
als auch auf dem IPC von Beck, ist multitaskingfähig und ist z.Z. in
Assembler programmierbar. Für die direkte Programmierung übers Netz
bzw. Terminal baue ich gerade einen simplen Basic-Interpreter, könnte
aber genausogut ein C-Interpreter sein, aber in Zukunft ist eher eine
Anpassung an GCC geplant. Aber bis dahin gibts noch viel zu tun.

Die entscheidende Frage dabei ist das Zielsystem. Nicht jede der o.a.
Interpreter lassen sich einfach in einen Mikrocontroller packen, weil
die Ressourcen dafür nicht ausreichen.

Also, für welches Zielsystem suchst Du?

Gruß
Volkmar

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Volkmar:
danke, daß Du auf die Frage zurückkommst.
Ich habe 2 Zielsysteme im Auge.
Auf der einen Seite den PC, der etwas
messen und steuern soll.

Und auf der anderen Seite den uC, der
das Frontend darstellt, worauf der PC
zugreift.

Die Idee ist eine Controllerplatine zu
nehmen mit AVR oder MSP430 mit ADC und DAC
und diese über USB abzufragen oder Daten
auf den DAC oder einen Speicher auszugeben,
woraus der DAC dann per DMA arbeitet.

Es gibt ja auch diese Minilabs. Die sind gut,
haben aber meist nur 10bit. Mit dem MSP430
hätte ich mehr bit und mehr Flexibilität.

Ich möchte durchgängig bei einer Sprache
bleiben für Oberfläche auf dem PC und die
Treibersoftware auf dem uC.

Soweit die Idee.

Vielleicht hat ja jemand Lust da mitzumachen.
Bei mir wird es aber langsam gehen, weil ich
noch einen Beruf habe und eine Homepage.

Gruss
   Matthias

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich hab auch schon lange soetwas im Hinterkopf. Einen Teil hab ich
bereits: Eine Platine mit AT89C2051 der I2C, 1wire, RTC und einige
GPIO's hat. Über RS232 wird mittels einem eigenen Protokoll dann vom
PC aus (Master) alles gehandhabt. Für den PC habe ich eine Klasse
geschrieben (Delphi-Pascal), wo ich nur mehr sage Dev.I2CStart oder
Dev.owWriteByte(x). Das Board is der Wahnsinn und hat schon viele Tests
und Versuche enorm erleichtert. Geplant wäre eben noch eine kleine VM am
µC gewesen, mit der man das Ding auch als kleine SPS laufen lassen
kann.

Was fehlt ist ist eben die ADC und DAC Komponente (habs zwar über I2C
auch schon laufen, aber nicht sehr schnell).

Nun zu deiner Idee: MSP430 find ich gut. USB find ich auch gut nur
würde ich keine FTDI-Geschichte verwenden sondern entweder einen USB
tauglichen µC oder einen USB-IC mit SPI oder so. Hab erst vor kurzen
eine Post von Maxim bekommen, die da was interessantes hatte. Mit USB
hab ich bereits was gemacht http://www.ime.jku.at/tusb und würde die
Variante über libusb empfehlen.

Das mit der Sprache wird so ne Sache sein. Kann mir nicht ganz
vorstellen dass sie gleich ist für PC und µC. Was ich mir vorstellen
kann ist ein kleiner universeller Befehlssatz der am µC interpretiert
wird auf einer VM. Die VM kommuniziert dann über einen virtuellen
Adressbus und Datenbus (im endeffekt 2 Register) mit der realen
Maschine. Problem dafür ist halt ein C-Compiler. Vielleicht kenn jemand
so nen universellen Befehlssatz mit VM (nicht Java oder so). Man könnte
ja auch z.B. einen 8051 abbilden. Über USB wird das Programm in die VM
downgeloaded.

PC-Seitig einfach ne ordentliche DLL. Habs bei meinem USB-Projekt
gesehen. Ne ordentliche DLL und man kann die in jeder Umgebung
verwenden. Ich hab dabei versucht, nur Integer als Parameter zu
verwenden wodurch es keine Typkonflikte gibt.

Hoffe einige Ideen in den Raum gestellt zu haben und warte gespannt auf
die Fortsetzung dieses Threads.

mfg W.K.

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

Wenn z.B. den 8051 in MSP430 virtuell nachbildet, kann man das ja auch
problemlos am PC machen und die ganze Hardware mit Scroller und Leds
visualisieren. Somit hat man auch die Möglichkeit das ordnetlich zu
testen ohne die Hardware zu verwenden.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Weinga-Unity:
Das hört sich interessant an, was Du da machst.
Der C2051 wäre nicht mein Ding und von Delphi
habe ich keine Ahnung.
Ich würde eben einen MSP430 favorisieren auf so
einem Olimex-Board. Da ist ADC und DAC drauf.
Und es gibt den GNU. SMALL/PAWN müsste da ggf. zum
Laufen zu bringen sein.

Die Software auf dem PC sollte auf den MSP
zugreifen können. Von TI gibt es jetzt übrigens
einen winzigen USB-Emulator mit vorne dran einem
MSP430F2013. Das Teil kostet 20$, braucht nur 1uA
im Standby und hat einen 16bit ADC an Bord.

Das ist für mich so ein Beispiel für eine einfache,
aber geniale Messtechnik.

Es sollte möglich sein später auch von Linux
aus auf das Teil zugreifen zu können. Offene SW
ist schon sinnvoll.

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

MSP430 kenn ich und hab auch schon viel gemacht (MSP430F149 und noch
nen kleineren). Ich würde für nen externen USB Transiver tendieren mit
SPI oder I2C, da man das dann auch für andere µC's verwenden kann
(selbst den Code). Ich weiß net, ob SMALL/PAWN (is ja ein
C-Interpreter) so ideal ist für nen Betrieb auf nen µC (so nach
Gefühl). Wie schon gesagt würde ich es klasse finden, einen µC (z.B.
8051 oder auch nen abstrakten, vielleicht kennt einer einen) im MSP430
nachzubilden (sollte nicht so schwer sein). C-Kompiler gibts ja dafür
und man kann prompt das Ding per Laufzeit mit nem C-Programm füttern.
Debuggen auf ASM-Level sollte dann auch kein Problem sein. Ich finde
auch, dass diese Lösung nicht sehr viele Resourcen vergeuden würde.
Vielleicht hat SMALL/PAWN aber auch seine Vorzüge..

USB mäßig wie gesagt LIBUSB (is net Lib, dies für mehrere
Betriebssysteme gibt). Meine Frage is nun, wass du eigentlich mit dem
SMALL/PAWN am µC machen willst?

Vielleicht mach ich über die Sommerferien ein Projektseminar an der UNI
(USB-Oszi mit DSP). Da könnte ich ja einiges einfießen lassen. Aber mal
sehen.

mfg W.K.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Weinga-Unity:
Prima, daß Du die MSP zu gut kennst.

Ich habe nichts gegen den USB per SPI.
Geht vermutlich schneller. :-)
Was meinst Du mit LIBUSB?

Ich kann nicht viel Zeit reinstecken
und mag die 8051-Struktur nicht wirklich.
Daher verspüre ich im Moment nicht den
dringenden Zwang zur Emulation eines 8051
unter MSP, so interessant das später zur
Kostenoptimierung auch sein mag.

Per Laufzeit mit einem C-Programm füttern
klingt sehr interessant. So etwas würde ich
wollen. Mir hat damals die Idee von Conrad
mit dem C-Interpreter auf dem 167 gut gefallen.
Es müsste doch möglich sein so etwas Ähnliches
auch auf dem MSP hinzubekommen.

Zu PAWN habe ich noch keine Erfahrung.
Ich habe es mir mal heruntergeladen.
Quincy heißt die IDE dazu, die beiliegt.

Die Idee war einen C-Interpreter auf dem
PC einzusetzen um damit rasch voranzukommen.
C statt Gambas heißt das Motto. Obwohl ich
gegen Gambas nichts habe. Aber Basic ist eben nicht
zu C durchgängig.

Wenn das Prog. auf dem PC läuft in Kombination mit dem
uC können C-Teile davon schrittweise in den uC
einfließen. Ob PAWN hier eine Hilfe sein
kann vermag ich noch nicht zu sagen.
Es gibt ja heute auch Debugger auf JTAG-Basis.
Es war nur so eine Idee, daß PAWN eine interessante
Lösung sein könnte, vielleicht besser noch auf
dem PC.

Ist Dir damit klar genug, was ich vor habe?

Gruss
   Matthias

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

LIBUSB is ne LIBRARY, mit der man USB ansteuern kann genau so, wie USB
aufgebaut ist. Descriptoren lesen, EP schreiben, lesen... und nicht das
Windows-Konzept, wo alles hinter einen Treiber versteckt wird und nur
über CreateFile usw. kommuniziert wird. In Wirklichkeit ist LIBUSB ein
Universaltreiber, den man für alle USB-Geräte verwenden kann, der aber
die Schnittstelle soweit aufbereitet, dass man das USB-Konzept
Programmseitig zur Verfügung hat. Intern (was mir ja egal ist) wird er
auch wieder mit CreateFile usw. arbeiten.

Vielleicht ist das Konzept mit dem 8051 noch nicht ganz klar geworden
(kann auch AVR oder was anders sein). Man bildet den entsprechenden µC
am MSP430 nach und kann mit den bereits existierenden C-Compiler für
8051 oder AVR C-Programme schreiben, kompilieren und dann in die VM im
MSP430 reinspielen. Somit is es egal, ob man 8051 oder Interpreter. C
ist C und die Interaktion zw. Hardware und C is meineserachtens bei der
8051 Variante gar kein Problem. Debuggen is ja dann auch easy, da man
einfach die VM anzapfen kann und per USB die VM analysieren kann.

Wenns mit PAWN auch schön geht, is es auch gut.

mfg W.K.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Weinga-Unity:
Danke für die Info. Das klingt ja sehr interessant.
Gerne würde ich da mitmachen.
Wäre schön, wenn Du mich ein wenig auf dem
Laufenden halten kannst :-)

Gruss
  Matthias

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Nur um flasche Hoffnungen zu vermeiden, die Thematik beschäftigt mich
schon länger, nur ob ich das je mal konkret so umsetzen werde ist die
Frage da ich es bis jetzt noch nicht wirklich brauche.

Schönes Wochenende noch... der Griller ruft!

mfg W.K.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

na dann grill mal schön :-)
Du weißt ja, wie Du mich erreichen kannst.

Gruss
  Matthias

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo! Tschuldigung, dass ich wieder nen alten Thread hervorkrame, aber
hab was gefunden was hier irgendwie hinpasst (im entferntesten Sinne).

http://atmel.com/dyn/resources/prod_documents/DOC0592.PDF

mfg Weinga-Unity

Autor: -Daniel- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider kann ich dir nix zu den Interpretern sagen,
nach denen du suchst.

Meine Meinung zum ganzen, wenn du in C nichts wichtiges
bisher geschrieben hast, dann wäre die Zeit am besten
investiert erstmal solide C Kenntise aufzubauen.
Es gibt ohne Zweifel bessere Sprachen als C, insbesondere
auf PC (Python, Ruby, auch C++), auf uC als Platform bezweifele
ich stark dass man dort ernsthafte Alternative hat.
Vielleicht könntest Ada einsetzen, schützt dich aber nicht
vor (deinen) logischen Fehler im Program. Und um diese geht's
ja meistens(so meine Erfahrung).

Gruss, Daniel

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Weinga, Daniel: Danke für Eure Beiträge.
Ich habe früher einiges in C programmiert.
Bin aber da kein Profi.

Eine große Menge an positiven Erfahrungen
hatte ich mit HPBASIC. Das war wirklich eine
geniale Sprache. Schade, daß es sowas für
den PC nicht als Freeware gibt. Mit dem
HTBasic kann ich mich nicht so richtig
anfreunden.

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gibt es zu diesem Thema mittlerweile was Neues?

Matthias

Autor: Zwie Blum (zwieblum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm picolisp :-)

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das hört sich echt interessant an !

Matthias

Autor: Ziff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was Neues ? Ja. Die Gerate haben nun ein Webinterface.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mich ja etwas wundert, ist dass bisher noch keiner c# erwähnt hat.

Wenn ich auf dem PC was programmiere, dann nach möglichkeit nur noch 
damit.

*Wird Interpretiert!
*Man kann ändern und weitermachen bei Fehlern.
*Mächtiges Expetionmanagement!
*Direct Command Window nach break.
*C ähnlich
*ok sehr objektorientiert
* GUIs sher einfach
*mit nunit steht ein mächtiges Testingframework identisch JUnit zur 
Verfügung

Gruß
Tom

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ziff:
welche Geräte meinst Du damit?
Kannst Du ein Beispiel geben?

Mir geht es um einen Controller, der in
der Lage ist energiesparend Sensoren abzufragen
dies ggf. in einem FRAM abzulegen, einfache
Berechungen durchzuführen und Ergebnisse
auszugeben auf einen integrierten DAC.

Natürlich gibt es vom großen "C" diese
C-Control-Teile. Die wollte ich jedoch nicht
unbedingt nehmen, obwohl der CC vielleicht
gar nicht so übel ist. Vielleicht könnte ich
den auch auf so einen MSP430 laden.

Picolisp ist halt wieder eine andere Sprache.
Ich bin da offen. Wenn es super geht, einfach
zu verstehen, einfach zu implementieren,
performanter als ein Basic-Interpreter, so
soll mir alles recht sein.

Ob ein Webinterface da groß weiterbringt
vermag ich nicht zu sagen. Da müsste ich ja
Strippen für das Netzwerk ziehen. Der niedrige
Energiebedarf ist dann wohl hin.

Matthias

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart schrieb:
> Was mich ja etwas wundert, ist dass bisher noch keiner c# erwähnt hat.

Danke Tom. Das hört sich doch alles gut an.
Nutzt Du das selbst für Dich?

Da "Ch" schien mir auch nicht übel.
Nur ist das halt Kaufware. Wenn es
bezahlbar ist kann es besser sein zu
kaufen als ewig rumzufrickeln, wenn gratis
Sachen nicht so toll erklärt sind.

Ändern und weitermachen bei Fehlern finde
ich genial, wenn man Dinge ausprobieren
möchte. Das war ja das Schöne an HPBasic
und später Turbo C - daß man da rasch mal
was zum Laufen brachte. Wobei es bei HPBasic
eben keine run time errors gab, deren Ursache
man oft nur erraten konnte.

Matthias

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verwende C# schon ne ganze Weile. Hat übrigens noch so nette 
Features wie Runtime Type Information, d.h. Du kannst vom Programm aus 
informationen über den Typ Deiner Objecte erfahren.

Wenn Du nur C# verwenden willst, gibt es eine abgespeckte Version von 
Visual Studio, die nicht viel kostet.

Meiner Meinung nach ist C# derzeit die effizienteste Art Software für 
den PC zu entwicklen und ich hab daor 10 Jahre MFC unter C++ gemacht.

gruß
Tom

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart schrieb:
> Meiner Meinung nach ist C# derzeit die effizienteste Art Software für
> den PC zu entwicklen

das hört sich für mich sehr gut an.

Aus der freeware Ecke wirds da nichts
vergleichbar brauchbares geben nehme
ich mal an.

Dieses C# wird wohl nicht auf einem
Controller wie dem MSP430 laufen, so nehme
ich an. Für den PC ist es dann eine schöne
Lösung. Dafür kann ich es ins Auge fassen.

Matthias

Autor: Andreas Kanzler (scavanger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Respekt im übrigen einen fast 4(!) Jahre alten Thread wieder zubeleben.


Moment mal,

Zu C#:

> *Wird Interpretiert!
Das stimmt so nicht.

C# (wie alle Sprachen die das .net Framework verwenden, also Visual 
Basic.net, Managed C++, F#,...) sind, ähnlich wie Java, eine Art 
Mittelding zwischen Interpreter und Compiliezter Sprache. .net Programme 
werden in einen optimierten Zwischencode übersetzt, der dann der zur 
Laufzeit von der .net in Maschinencode  übersetzte werden.

> Wenn Du nur C# verwenden willst, gibt es eine abgespeckte Version von
> Visual Studio, die nicht viel kostet.

Die Express Versionen gibt es sogar komplett kostenlos:
http://www.microsoft.com/germany/Express/

Und z.Z. gibt's den Release Candidate für VS 2010 ebenfalls zum 
kostenlosen Download:
http://www.microsoft.com/germany/visualstudio/prod...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias W. schrieb:
> Dieses C# wird wohl nicht auf einem
> Controller wie dem MSP430 laufen, so nehme
> ich an.

Nein, das wird es nie. Übrigens wird es nicht interpretiert, sondern 
in eine Zwischenbinärsprache (CLI) übersetzt, und das ganze setzt auf 
dem .Net-Moloch auf.

Autor: Andreas Kanzler (scavanger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf einem MSP430 läuft das .net Framework soweit ich weiß nicht, aber 
auf einem ARM, genauer auf einem AT91SAM9261:

http://www.aug-electronics.com/ami/Pictures/tabid/...

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kanzler schrieb:
> C# (wie alle Sprachen die das .net Framework verwenden, also Visual
> Basic.net, Managed C++, F#,...) sind, ähnlich wie Java, eine Art
> Mittelding zwischen Interpreter und Compiliezter Sprache. .net Programme
> werden in einen optimierten Zwischencode übersetzt, der dann der zur
> Laufzeit von der .net in Maschinencode  übersetzte werden.

Jain... natürlich erzeugt der Complier erst mal Bytecode. Dieser wird 
aber zur Laufzeit mehr oder weniger interpretiert.

Tom

Autor: Zwie Blum (zwieblum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz wie in alten Tagen, hieß damals "Tokenizing" am C64 ... Ja, echter 
Fortschritt findet sich nur bei M$ :-)

Autor: Andreas Kanzler (scavanger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hof fähig hat das allerdings nicht MS, sondern Sun mit dem Javabytecode.
Ja, MS hat bei .net ganz kräftig bei Java abgeschaut.

Aber Hauptsache auf MS schimpfen.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und MS hat vor allem auch aus den Fehlern on Java gelernt und einiges 
besser gemacht.

Gruß
Tom

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus t. Firefly schrieb:
> und das ganze setzt auf dem .Net-Moloch auf.

Auf so einen Moloch aufsetzen mag ich
natürlich nicht so gerne. Viel lieber sind
mir kleine überschaubare Sachen . . .

Das CC scheint ja nicht so monsterhaft . . .

Das HPBasic passte damals auch noch auf
sehr kleine Festplatten.

Matthias

Autor: Volker Zabe (vza)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Tokenizing" machen sehr viele BASICs. Aber was eine verkürzte 
schreibweise der Schlüsselworte mit Zwischensprachen zu tun haben soll?
Dan schohn eher p-Code vom UCSD-Pascal 
http://de.wikipedia.org/wiki/P-Code
ist noch älter als C64.

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart schrieb:
> Und MS hat vor allem auch aus den Fehlern on Java gelernt und einiges
> besser gemacht.

Lernen aus Fehlern ist ja von Vorteil.
Wenn was Gutes am Ende dabei rauskommt . . .

Ich programmiere momentan eher selten.
Daher sind intuitive Ansätze natürlich zu
bevorzugen.

Matthias

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kanzler schrieb:
> Respekt im übrigen einen fast 4(!) Jahre alten Thread wieder zubeleben.

manchmal ist es gut ein paar Jahre auf neue
Entwicklungen zu warten. Manches wird ja besser.

Wenn es dieses HP Basic für den MSP gäbe
würde ich es sofort einsetzen wollen.
Natürlich hat der MSP nicht so viel Ram
wie damals diese HP-Workstation HP9816S,
die ja auf einem 68000 aufbaute. Statisches
RAM war damals sauteuer.

Matthias

Autor: Ziff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Geraet kann ein Webinterface haben und ein serielles Interface 
benutzen.

Autor: Grrrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann möchte ich doch nochmal FORTH in's Spiel bringen.

Es ist, nach reinem Assembler das schnellste, der Code ist sehr kompakt 
und die umgekehrte polnische Notation ist für den intellektuell normal 
Bemittelten einfach zu verstehen. (Wenn es auch, wie ich einräumen will, 
Gewöhnung erfordert).

Es gibt auch Assembler und ein Scheduling dafür und 
Fliesskommarechnungen gibt es auch. Auch Tracer/Debugger sind vorhanden. 
Gerade wenn ein intuitiver Zugang erforderlich ist, ist FORTH ein 
ernstzunehmender Kandidat. Man baut auf den primitiven Worten seine 
eigene problemorientierte Sprache auf.

Es gibt recht gute online-Texte dazu. Z.B. "Thinking FORTH" von Leo 
Brodie das auch Anfängern der Sprache aber auch des Programmierens 
insgesamt gerecht wird.

Ich habe selbst FORTHs für AVR u.a. implementiert und bin davon 
überzeugt, das es für schnelle effiziente Problemlösungen gut geeignet 
ist.

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ziff schrieb:
> kann ein Webinterface haben und ein serielles Interface

kannst Du das ein wenig näher beleuchten
wo Du da meinst, daß das zum Thema
C-Interpreter zur Steuerung brauchbar wäre?

Matthias

Autor: Frank W. (frankw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Grrrr (Gast)
 > Ich habe selbst FORTHs für AVR u.a. implementiert

Bist Du bereit Deine Forth Implementierung zu veröffentlichen ?
Ich würde sehr gerne mal Forth auf dem AVR ausprobieren.
( Hatte es früher auf nem 8085 und nem Z80 implementiert )

Merci
Frank

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grrrr schrieb:
> Dann möchte ich doch nochmal FORTH in's Spiel bringen.

Gibt denn da Beispiele für gelungene Implementierungen
wo man sehen kann wie das zum Thema
Interpreter zur Steuerung brauchbar wäre?

Matthias

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mich wundert so ein bißchen, daß auf dem
Controller eigentlich immer wieder so vieles
neu gemacht wird.

- Gedanken um ein Minibetriebssystem oder
  eine Ablaufsteuerung
- ADC-Routinen
- DAC-Routinen
- Abfrage/Entprellung Taster
- Registerprogrammierung

All das hält ziemlich auf. Bei den Infineon-
controllern gibt es ja DAVE, der ein wenig
hilft da Struktur ins Programm zu bekommen.

Wer eine Messaufgabe hat möchte sich doch
auf diese Aufgabe konzentrieren und nicht
jedesmal das Rad neu erfinden.

Wenn es da ein Basissystem gäbe auf dem ein
kleiner schlanker Interpreter sitzt, so
ähnlich wie die Debug-Funktionen früher bei
den Motorola 68332.

Bei den Oberflächen hat man ja heute Eclipse,
das mehr und mehr zu einem Standard zu werden
scheint.

Auf dem Controller selbst jedoch vermisse ich
da was . . .

Matthias

Autor: Grrrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank W. schrieb:
> @Grrrr (Gast)
>  > Ich habe selbst FORTHs für AVR u.a. implementiert
>
> Bist Du bereit Deine Forth Implementierung zu veröffentlichen ?

Nein. Ich verkaufe meine Implementierung im Rahmen von Aufträgen. Sie 
läuft auch auf ATMegas mit mehr als 64kB Flash. Es ist zwar auch 
geplant, das FORTH für Hobbyisten und im Quellcode für Gewerbliche 
anzubieten, aber ich darf hier keine Werbung machen.

Aber es gibt auch quelloffene Implementierungen für den AVR.
Hier http://www.mikrocontroller.net/articles/Forth sind einige genannt.

Matthias W. schrieb:
> Gibt denn da Beispiele für gelungene Implementierungen
> wo man sehen kann wie das zum Thema
> Interpreter zur Steuerung brauchbar wäre?

FORTH ist in gewissem Sinne Compiler, Interpreter und OS in einem. Es 
verwendet Threaded-Code (siehe Wikipedia oder eben das Buch).

Wenn Du Dich mit der Sprache ein wenig beschäftigst wirst Du merken, wie 
einfach und intuitiv solch eine Steuerung zu implementieren ist. Eine an 
SPS angelehnte "Sprache" lässt sich in den Grundzügen sicherlich 
innerhalb einer Woche implementieren. Da es so einfach ist solche 
Sprachen zu entwickeln sind sie aber fast immer recht spezialisiert und 
werden auch nicht veröffentlicht, da sie Teil des Lieferumfangs an den 
Kunden und damit sein Eigentum sind.

Autor: Grrrr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um sich echte Codes anzuschauen ist 
http://www.forth.org/fd/contents.html ganz gut geeignet.
Auf Deutsch gibt es auch 
http://www.forth-ev.de/filemgmt/viewcat.php?cid=2

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.