Interesse an Alternative zu BASCOM?

Ich bin zwar kein Spezialist, aber ich finds ne schöne Idee. Mit was 
soll das geproggt werden?

Da er scheinbar Objektorientierung und Hochsprache liebt: C++???

Schreib ein paar libs, oder adaptier die libs, die Procyon AVRlib
ist ein Anfang, aber Lizenz beachten.
Basic->C converter (BXC oder BACON als Beispiel), GCC und das Resultat
ist assembler/Hex File das mittels Bootloader nehme ich an runtergeladen
werden kann. Ich habe so ähnlich bestehende PBasic programme auf AVR/ARM 
portiert, ohne was neuzuschreiben. Ich hatte da noch ein Programm vor
dem basic->c converter um ein bisschen die Basic-Syntax zu convertieren,
das ändert aber nichts am Konzept.

Der Charme von BASCOM besteht weniger in der Sprache an sich, sondern 
dass es für die meisten realen Situationen fertige Codebausteine 
mitbringt.

Willst du BASCOM ersetzen, dann bleibt dir nichts anderes übrig, dafür 
einen Ersatz zu schaffen. Und das ist eine Menge Arbeit, wenn das für 
alle möglichen Porzessoren und alle in BASCOM vorhandenen fertigen 
Module gemacht werden soll (und vor allen Dingen richtig gemacht und 
auch dann eine Aktion, wenn der IC die Funktionalität gar nicht kann).

Da du diese Module aber sowieso implementieren musst um BASCOM zu 
verdrängen, kannst du dir auch gleich C-Bibliotheken dafür überlegen(*). 
Wenn die tatsächlich den kompletten Modul-Funktionsumfang von BASCOM 
abdecken, dann könnte es schon sein, dass die dir hier aus der Hand 
gerissen wird und dir dein Gewicht in Gold aufgewogen wird.

Aber: Dazu brauchst du keinen BASIC Compiler entwickeln. Das als C-Lib 
mit allen Schikanen ist völlig ausreichend.

(*)
Noch besser wäre ein Sammlung von C++ Objekten.

Max D. schrieb:
> Ich bin zwar kein Spezialist, aber ich finds ne schöne Idee. Mit was
> soll das geproggt werden?

Christopher schrieb:
> In welcher Sprache willst du Entwickeln??
> Bei der richtigen wäre ich dabei;)


Ist das nicht ein und dieselbe Frage? Darauf war nämlich meine Antwort 
bezogen:

Silvan König schrieb:
> Da er scheinbar Objektorientierung und Hochsprache liebt: C++???

Adrian schrieb:
> Ich würde es in VB realisieren.

Viele Compiler werden in der eigenen Sprache geschrieben, also
C-Compiler in C, Lisp-Compiler in Lisp, Haskell-Compiler in Haskell usw.
Das ist ja auch nachvollziehbar, weil das Ziel des Compiler-Entwicklers
ist, den besten Compiler für die beste Programmiersprache zu schreiben.
Warum sich also bei der Entwicklung des Compilers selbst mit weniger
zufriedengeben?

Wenn das neue Basic VB-ähnlich sein soll, ist es also richtig, VB für
die Entwicklung zu verwenden. Sobald der Compiler fertig ist, sollte er
in der Lage sein (ggf. nach entsprechenden Anpassungen), sich selbst zu
übersetzen, vorausgesetzt natürlich, es gibt auch einen Codegenerator
für PC-Prozessoren.

Viel Erfolg damit!

Edit:

Falls kein Codegenerator für PC-Prozessoren vorgehen ist: Was spricht
dagegen, den Compiler auf einem AVR laufen zu lassen? Cool wäre doch ein
Dongle mit einem AVR und einem FTDI drauf, der über USB den Quellcode
empfängt und ihn compiliert wieder zurückschickt. Man erspart sich
dadurch die Installation einer Entwicklungsumgebung auf dem PC und kann
auf jedem Rechner mit USB unabhängig vom Betriebssystem AVR-Software
entwickeln.

Nur mal so dahergesponnen :)

Yalu X. schrieb:
> Cool wäre doch ein
> Dongle mit einem AVR und einem FTDI drauf, der über USB den Quellcode
> empfängt und ihn compiliert wieder zurückschickt.

Warum zurückschicken? Direkt den Ziel-AVR am anderen Ende dranhängen und 
flashen ;-)

Andreas

Andreas Ferber schrieb:
> Yalu X. schrieb:
>> Cool wäre doch ein
>> Dongle mit einem AVR und einem FTDI drauf, der über USB den Quellcode
>> empfängt und ihn compiliert wieder zurückschickt.
>
> Warum zurückschicken? Direkt den Ziel-AVR am anderen Ende dranhängen und
> flashen ;-)

Auch das ist natürlich eine interessante Möglichkeit, aber oft will man
eben auch einen anderen AVR, der zu tiny für den Compiler ist, oder
einen bereits in einer Schaltung verbauten AVR damit programmieren.

Aber jetzt, wo du das ansprichst: Man könnte natürlich gleich den
Programmieradapter mit auf den Dongle packen. Es fehlt ja nur noch der
Steckverbinder und die Software. Statt Toolchain installieren, Compiler
und Programmiertool aufrufen, bräuchte man also nur noch

  cat quellcode.bas >/dev/ttyUSB0

bzw.

  type quellcode.bas >com8:

eingeben oder im Explorer "Senden an" im Kontextmenü der Quelldatei
anklicken und der AVR ist programmiert, entweder der im Dongle oder der
über ISP damit verbundene :)


Egon schrieb:
> Dein Plan ist absolut unnötig, hoffentlich finden sich nicht auch noch
> Leute denen du Zeit klaust. Sinnlos triffs vielleicht auch.

Klar, Hobbys sind unnötig und sinnlos :)

Ein ganz großes AHA! würde das Projekt verdienen, wenn es konsequent 
plattformunabhängig programmiert werden könnte. Also für Windows, Linux 
und Mac!
Dann müsste man das in Java, Javascript oder RealBasic machen ... ich 
glaube nicht, dass Geschwindigkeit ein besonders wichtiges Kriterium bei 
einem Compiler für AVR ist.

Frank

Naja, so teuer ist BASCOM nun auch wieder nicht.

Was mir im Freeware-Bereich eher fehlt ist eine grafische 
Programmierumgebung a'la Labview, wenn es schon OOP sein soll. 
Tendenziell wohl eher "nur" ein grafischer Editor, der am Ende 
C++-Quelltext für den gcc-Compiler ausspuckt.

Darf ich was fragen?

Wieviel Erfahrung hast du denn in diesem Bereich?

Wenn ich mir solche Dinge ansehe
> Und nochmal zum merken:
> ==================================================================
> ES WIRD KEIN COMPILER SONDERN EIN CODEGENERATOR (VB -> ASSEMBLER)!
> ==================================================================
dann zweifle ich doch sehr daran, dass du weißt was du tust.

Du schreibst einen Compiler! Ein Codegenerator ist Teil eines Compilers, 
der sich die im Compiler erzeugte Zwischenrepräsentierung hernimmt und 
daraus dann den echten Maschinencode erzeugt.
Und wenn du darauf spekulierst, dass du bei Visual Basics in die 
Internals reinkommst, so dass du von dort den Expression Tree bekommst: 
Träum weiter.

Oder verwechselt hier wieder mal jemand IDE und Compiler?

Vielleicht hab ich ja auch was übersehen. Also: wie genau stellst du dir 
deinen Codegenerator vor? Welche Schritte macht er? Wie ist seine 
Arbeitsweise?


Ich seh das wie Egon: Eine Totgeburt noch ehe es losgegangen ist.

(Und ehe du fragst: Ja, ich hab schon Sprachen entworfen und Compiler 
dafür geschrieben)

sausix schrieb:

> Ich habe bereits eine Scriptsprache erstellt die wirklich alles Parst.
> Ohne Hilfsmittel wie andere es gerne nutzen.

Schön. Dann hast du deine Zeit verplempert.

Den ersten Syntax Parser schreibt man selber um zu wissen wie das geht. 
Aber spätestens beim 5.ten ist es nur noch Zeitverschwendung den 
Syntaxparser mit der Hand zu schreiben. Das kann ein Tool genausogut.

> Was meinst du mit Internals von VB? Die Auflösung der Logik von
> Ausdrücken usw? Halt mich mal nicht für nen Anfänger. Ich kenne den
> Unterschied zwischen IDE und Compiler. VB mache ich seit 95. Sogar
> beruflich. Ich habe gutes technisches Wissen in den Bereichen die ich
> mache.


Was soll konkret aus deinem Machwerk hinten rauskommen und wie stellst 
du dir vor, dass du VB da mitbenutzen kannst?

Deine Scriptsprachen in allen Ehren, aber auch du wirst es nicht 
schaffen, die Scripting Runtim auf einem AVR zum laufen zu bekommen. 
Also muss dein Machwerk wohl oder übel Assembler erzeugen. Nur wie 
machst du das?

Wie erzeugt dein Kongolmerat aus einer Eingabedatei

  print ( 3 + 5 ) * 8

die entsprechenden Assembler Anweisungen. Und zwar ohne dass du einen 
kompletten Compiler schreibst.

Die Frage ist doch so schwer auch wieder nicht.

Hallo,

man könnte zB. damit anfangen, eine Erweiterung für eclipse zu 
schreiben, um darin Bascom programmieren zu können, denn das schlimmste 
am Bascom ist diese IDE
:)

Dann wäre die erste hürde schon genommen, da ist der umstieg auf eine 
andere Sprache nicht mehr weit, und es läuft auf allen möglichen 
Betriebssystemen.

Nur um nicht misverstanden zu werden.
Ich will dich keineswegs aufhalten.
Ich möchte nur eine realistische Einschätzung gewinnen können, ob dieses 
Projekt realisierbar ist.

Es sagt sich leicht: 90 Euro ist mir zuviel, na dann schreib ich mir das 
halt selber. Und ach ja, objektorientiert soll es auch noch sein.

In den meisten Fällen hat derjenige, der das sagt noch keine Vorstellung 
davon, was da auf ihn zukommt.

Und den Punkt hätte ich vorab gerne geklärt.

Mega schrieb:
> Ein netter Ansatz ist z.b. MircoSPS von CadSoft

Dieses Konzept kannte ich schon. Überzeugt hat es mich aber nicht. Erst 
einmal ist der Umweg über EAGLE umständlich, aber damit könnte man wohl 
noch leben. Als Interpreter ist das aber eher langsam und da wird es 
schon eng. Inakzeptabel ist aber für mich, dass man das System nicht 
erweitern kann. Objekte, die der Interpreter nicht kennt, die kennt er 
halt nicht.

Meine Vorstellung (wenn auch leicht OT, weil es hier ja eher um 
Skriptsprachen geht):

Eine GUI erlaubt das Platzieren von Objekten und die Verbindung von Aus- 
zu Eingängen von Objekten. Daraus wird C++-Code generiert und 
(automatisch?) in avr-g++ eingespeist. Dieser Quellcode würde aus den 
Klassen der benutzten Objekten bestehen. main() erzeugt die benötigten 
Instanzen und "verbindet" die Datenleitungen, auf denen Datenobjekte 
laufen. Wahrscheinlich braucht man dann noch einen Scheduler mit einer 
Liste aller Objekte sowie eine Nachrichten-Queue.

Zur Erweiterung müsste man dann ein grafisches Sysmbol erstellen und 
eine neue Klasse programmieren. Von dem Ur-Objekt erbt es die 
Funktionen, die für den Betrieb nötig sind. Das wäre wohl vor allem der 
Empfang und das Senden von Datenobjekten und die Möglichkeit, vom 
Scheduler regelmäßig angestoßen zu werden. (Da stellt sich schon die 
Frage, ob avr-gcc überhaupt virtuelle Funktionen unterstützt)

Für alle Zwecke wäre das sicher nicht geeignet - und klein wäre so ein 
Projekt auch nicht. Ich will das gar nicht erst anfangen, deshalb kann 
ich auch nicht erwarten, dass es ein anderer tut. Ist nur eine Idee.

Detlev T. schrieb:

> Eine GUI erlaubt das Platzieren von Objekten und die Verbindung von Aus-
> zu Eingängen von Objekten.

[rest gesnippt]

Das wäre etwas, was mich auch interessieren würde.
Ich hab so etwas bisher auch nur als Interpreter realisiert, bei dem man 
das 'Programm' einem Standardinterpreter in Form von Beschreibungsdaten 
vorsetzt. Mit allen Nachteilen, die weiter oben schon angesprochen 
wurden.

> laufen. Wahrscheinlich braucht man dann noch einen Scheduler mit einer
> Liste aller Objekte sowie eine Nachrichten-Queue.

Und genau da fängt die Sache dann an interessant zu werden. Ist es 
möglich, aus der Verschaltung eine 'optimale' Abarbeitungsreihenfolge 
der Objekte zu generieren oder lebt man damit, einfach alle Objekte 
Round-Robin mässig durchzuhacheln, selbst wenn sich an den Eingängen 
dieser Objekte nichts verändert hat.

Wenn ich dich richtig verstanden habe, dann stellst du dir vor, dass ein 
Ausgang beim Schalten so etwas wie eine Nachricht in die Queue stellt, 
die nacheinander abgearbeitet wird. Ist eine Möglichkeit. Interessante 
Frage: Was bedeutet das für die Laufzeit?

Welche anderen Konzepte gibt es?

> Für alle Zwecke wäre das sicher nicht geeignet - und klein wäre so ein
> Projekt auch nicht. Ich will das gar nicht erst anfangen, deshalb kann
> ich auch nicht erwarten, dass es ein anderer tut. Ist nur eine Idee.

Ich hatte mal ein Spielsystem programmiert um damit Logik-Schaltungen zu 
simulieren.

Einzelne Objekte wurden mittels Kabel-Objekten miteinander verbunden. 
Das Kabel-Objekt stellte die Verbindung von Ausgang zum nächsten Eingang 
her. Änderte ein Objekt seinen Ausgang, dann benachrichtigte es das an 
diesem Ausgang hängende Kabel-Objekt, welches wiederrum den Eingang des 
nächsten Objektes von der Veränderung informierte. Änderungen an 
Eingängen wurden nicht gleich in die Objektlogik mit einbezogen, sondern 
es gab so etwas wie einen Eingangspuffer, der die Änderung 
zwischenspeicherte. Erst nachdem alle Objekte einen Durchgang komplett 
hinter sich gebracht haben, kam dann der große Sync-Puls und alle 
Objekte übernahmen die Eingangspuffer in ihre interne Logik.

Der Teufel steckte im Detail. Nach ein wenig spielen und experimentieren 
hab ich das aber wieder einschlafen lassen. Beruflich hatten sich andere 
Prioritäten ergeben.

(Allerdings sind wir jetzt schon weit Off-topic. Wir sollten dem TO 
nicht seinen Thread zerstören.)

Martin schrieb:
> Kauf dir das Drachenbuch (Compilerbau, Aho, Sethi, Ullman) in der
> deutschen Übersetzung (2 Teile), arbeite es vollständig durch (6 Monate,
> vielleicht länger), danach melde dich wieder.

Wenn Time-to-Market ein Kriterium ist: Die englische Originalversion ist
einbändig und geht schon in 4 Monaten :)

Yalu X. schrieb:
> Martin schrieb:
>> Kauf dir das Drachenbuch (Compilerbau, Aho, Sethi, Ullman) in der
>> deutschen Übersetzung (2 Teile), arbeite es vollständig durch (6 Monate,
>> vielleicht länger), danach melde dich wieder.
>
> Wenn Time-to-Market ein Kriterium ist: Die englische Originalversion ist
> einbändig und geht schon in 4 Monaten :)

Du meinst: die erste Lesung :-)

Karl heinz Buchegger schrieb:
> Und genau da fängt die Sache dann an interessant zu werden. Ist es
> möglich, aus der Verschaltung eine 'optimale' Abarbeitungsreihenfolge
> der Objekte zu generieren oder lebt man damit, einfach alle Objekte
> Round-Robin mässig durchzuhacheln, selbst wenn sich an den Eingängen
> dieser Objekte nichts verändert hat.

Vorbelastet bin ich mit HP-Vee (so eine Art primitives Labview) und der 
QT-Bibliothek. Daraus ziehe ich meine Ideen.

Die Nachrichten-Queue wäre ein FIFO, das heißt die ältesten Nachrichten 
werden als erstes abgearbeitet. Wenn ein Ausgang auf mehrere Eingänge 
geht, gibt es keine Vorgabe, in welcher Reihenfolge die Objekte 
aufgerufen werden. Zeitkritische Dinge müsste man in ISRs (und C) 
programmieren, auf dessen "volatile"-Daten dann ein entsprechendes 
Objekt zugreift.

Objekte würden erst einmal nur dann aufgerufen, wenn es eine Nachricht 
an sie gibt. Allerdings muss es auch Objekte geben, die eine solche 
Kette von Nachrichten initieren können, sonst passiert ja gar nichts. 
Also ein z.B. "Pin-Change-Objekt", das eine Nachricht erzeugt, wenn sich 
am Eingang etwas tut. Ein "RS232-Objekt", das eine Nachricht aussendet, 
wenn ein Zeichen empfangen wurde usw. Diese warten auf keine Nachricht 
eines anderen Objektes, müssten also auf andere Weise angestoßen werden. 
Ob der Scheduler "weiß", welche Objekte regelmäßig einen Tritt brauchen 
oder ob die entsprechende Methoden der anderen Objekte einfach leer 
sind, das müsste man noch überlegen.

Was Laufzeit, Speicherverbrauch etc. betrifft, wäre das verglichen mit 
handoptimierten C oder gar Assembler natürlich grottenschlecht. 
Echtzeitanwendungen kann man da getrost vergessen, soweit man das nicht 
in einer ISR erledigen kann. ABER viele Projekte sind ja gar nicht so 
kritisch.

Den Overhead durch C++ kann man vielleicht sogar noch stark reduzieren, 
weil ja schon der Code-Generator "weiß" welche Objekte es gibt und diese 
auch von Anfang an existieren. Dynamische Erzeugung mit "new" und 
"delete", was beim avr-gcc sowieso nicht geht, wird daher gar nicht 
gebraucht. Auch virtuelle Funktionen könnte man ggf. vermeiden. 
Eventuell kommt man sogar mit einer C-Erweiterung aus wie zu Urzeiten 
von C++ aus, indem man den Funktionen einen Zeiger "this" auf die 
eigenen Daten übergibt. Das weiß man aber erst, wenn man die 
Anforderungen genau formuliert hat.

Den so erzeugten Code darf man sich dann wohl nicht ansehen, wenn man 
gerade etwas gegessen hat - muss man ja aber auch nicht. ;)

hp-freund schrieb:
> Die Sache scheint nicht einfach zu sein.
> Auf diese Seite schaue ich schon erwartungsvoll seit Anfang des Jahres:

Genau das meine ich:
Enthusiastisch losgelegt - und dann stellt sich alles als nicht ganz so 
einfach dar, wie ursprünglich angedacht.


> http://www.avrtools.no/
>
> Zumindest kann es als Anregung dienen.

Ob das ein Web-Fehler ist?
[quote]
Frequency counter Max 10 Hz
[/quote]

Da fehlen zb viele Dinge, die man mit Timer machen kann.

@hp-freund
Zu viel vorgenommen und daran gescheitert, schätze ich einmal. Das 
Bedürfnis nach dieser Art von Programmierung ist offenbar nicht nur bei 
mir da. Aber ein kommerzielles Projekt hat natürlich zwei große 
Probleme. Man muss erstens gleich am Anfang viel bieten und dann laufen 
einem zweitens die Kosten davon, weil man alles selbst machen muss.

Meine Vorstellung ist eher ein Framework, wo die Objektklassen erst nach 
und nach entstehen. Das kann man natürlich so nicht verkaufen. Da muss 
erst einmal eine Community entstehen, die diese Module frei tauscht. 
Vielleicht macht auch einer den Codegenerator und ein anderer 
programmiert die GUI-IDE dazu. Opensource macht vieles möglich, was 
kommerziell nicht geht. Und wenn erst einmal nur ein bestimmter 
Controller unterstützt wird? Who cares. Wäre doch zumindest ein Anfang.

Karl heinz Buchegger schrieb:

> Genau das meine ich:
> Enthusiastisch losgelegt - und dann stellt sich alles als nicht ganz so
> einfach dar, wie ursprünglich angedacht.

Das ist bei Programmiersprachen auch nicht anders.
So eine Entwicklung steht und fällt damit, ob man BASCOM Paroli bieten 
kann oder nicht. Und dazu benötigt man wiederrum diese vorgefertigten 
Plug/Play Module.
Ansonsten sagt sich jeder: OK, noch ein BASIC; aber was hab ich für 
einen Mehrwert gegenüber zb. C? Das bischen andere Syntax beeindruckt 
mich nicht wirklich und mit WinAVR oder IAR gibt es genügend ausgereifte 
Pakete, die man auch industriell einsetzen kann ohne sich mit 
Kinderkrankheiten rumschlagen zu müssen.

Kein Mehrwert -> kaum praktischer Einsatz -> kaum Weiterentwicklung.

Ich hab einfach schon zu viele Projekte gesehen, die zwar als 
Labormuster toll ausgesehen haben, aber alle vor der praktischen 
Einsetzbarkeit eingeschlafen sind. Und da nehme ich durchaus meine 
eigenen Projekte nicht aus.

Nach meinem Ausflug in die grafische Programmierung zurück zum 
ursprünglichen Thema.

Ich denke nicht, dass es unbedingt noch einen neuen Basic, C oder sonst 
was Compiler braucht. BASCOM hat aus meiner Sicht einige Mängel, 
insbesondere dass man nur eine Rechenoperation pro Zeile ausführen kann 
und fehlerträchtig mit Hilfsvariablen operieren muss, sowie das massive 
Vertrödeln von Rechenzeit. Offenbar ist das aber für viele nicht 
gravierend, sonst würden sie diesen Compiler ja nicht nutzen.

Vorschlag für einen anderen Ansatz: Abgesehen von Spezialanwendungen 
(Würfel, Lottozahlengenerator) soll das Verhalten eines Controllers 
nicht zufällig, causal und deterministisch sein. Auf deutsch: Der 
Zustand eines Ausgangs muss eine Funktion der Zustände aller Eingänge 
sein, die sie seit dem Einschalten hatten. Würde man also die Zustände 
aller Eingänge seit dem Einschalten mitloggen, könnte man den Zustand 
des Ausgangs aus diesen Daten berechnen.

Technisch ist der direkte Weg natürlich nicht zu realisieren, weil man 
dazu praktisch unendlich viel Speicher zur Verfügung haben müsste und 
die Auswertung auch praktisch unendlich lange dauern würde. Man muss 
also von vornherein wissen, was geloggt werden muss.

Ich komme auf die Idee der objektorientierten Programmierung zurück. 
Nehmen wir an, man definiert einen Strauß "Watcher". Das sind Objekte, 
die einen (oder mehrere) Eingänge beobachten und nur das, was 
"interessant" ist, protokollieren. Ein Watcher könnte zum Beispiel 
protokollieren, ob eine Signalflanke aufgetreten ist. Ein anderer, ob 
ein Impuls aufgetreten ist und seine zeitliche Länge protokollieren. Ein 
dritter protokolliert die letzten n Messungen eines ADC-Wandlers usw.

Die Steuerung der Ausgänge übernehmen andere Objekte, die dazu auf das 
"Wissen" der Watcher zurückgreifen, nennen wir sie "Worker". 
Wahrscheinlich wird man dazwischen noch andere Objekte schalten können 
müssen, die Daten verarbeiten können, damit die Zahl der Objekte nicht 
ins unendliche steigt. Nennen wir diese dritte Gruppe "Thinker".

Mit diesen "Bausteinen" beschreibt man dann seine Anwendung. Als erstes 
beschreibt man alle Objekte, die man nutzen will und gibt ihnen Namen. 
Dann beschreibt man die Nachrichten-"Ketten", das heißt zu jedem 
"Worker" gibt man an, welches andere Objekt er "fragen" muss um den 
gewünschten Zustand des Ausgangs zu berechnen. Das geht also faktisch 
den umgekehrten Weg wie in der oben beschriebenen grafischen Lösung, wo 
quasi die "Watcher" die Aktionen starten.

Beispiel Monoflop:
An PD7 soll ein 100µs langer Impuls erscheinen, wenn an PD1 (=INT0) eine 
FLanke detektiert wird.   Ich brauche: Einen Worker "Impuls" und einen 
Watcher "Flanke". Der Ausgangszustand (Impuls oder kein Impuls) hängt 
vom Wert des Watchers ab: Flanke seit der letzten Frage oder nicht. Das 
könnte vielleicht so aussehen:

1

worker_puls Impuls(PD7,100);

2

watcher_slope Flanke(PD1, negative);

3

4

Impuls <= Flanke;

Beispiel PID-Regler:
Ein PWM-Ausgang soll etwas steuern, Messwerte kommen über ADC0 herein. 
Jede 10ms soll gemessen werden und die letzten 8 Werte gespeichert 
werden. Die Parameter des Reglers soll durch Daten aus der 
RS232-Schnittstelle verändert werden können.

1

watcher_adc adc(ADC0, 10000, 8);

2

thinker_pid pid(23,7,4);

3

worker_pwm pwm(PWM0);

4

interface_rs232 control(UART0, 9600, 8, 1, N);

5

6

pwm<=pid;

7

pid<=(adc , control);

Der PID-Regler "fragt" also den ADC-Wandler nach neuen Werten und die 
RS232-Schnittstelle nach neuen Parametern.

Ich hoffe es wird klar, was mir da vorschwebt.

Detlev T. schrieb:

> Ich hoffe es wird klar, was mir da vorschwebt.

Die Idee ist schon klar.
Du willst Standardbauelemente, die über Standardfunktionalität verfügen. 
Ähnlich wie eine mathematische Funktionen ein ganz bestimmtes Verhalten 
hat wenn man sie nach dem Funkionswert für eine Variablenbelegung 
befragt. Und ähnlich wie bei anderen Ansätzen, lautet für jedes Objekt 
die Frage: "Wie komme ich zu meinen Eingangswerten" und nicht wie im 
klassischen Ansatz "Ich hab da einen Wert was tu ich damit"

Der entscheidende Punkt ist für mich: Wieviel Funktionalität stopfst du 
in ein Objekt. Im Moment hast du extreme High-Level Objekte, die 
wahsinnig intelligent sind. Hinter

   pid<=(adc , control);

(mir gehts jetzt zb nur um die UART) steckt schon eine Menge Know How 
über UART Übertragung. Soll ein
   watcher_adc adc(ADC0, 10000, 8);
watcher_adc wirklich über eine Queue verfügen, oder war das nicht besser 
eine Sache für ein
   thinker_queue queue( 8 );
   queue <= adc;
   pid <= queue;

(wobei mir gerade der Gaedanke kommt, dass das ja keine Queue im 
klassischen Sinne ist, sonder ein äh 'last recently values' Objekt. 
Egal, du weißt was ich meine)

Aber alles in allem eine interessante Idee.

Adrian schrieb:
> Ganz einfach und zum 1000sten mal:
> Ein VB-Programm generiert Assembler-Anweisungen.

Klaus schrieb:
> Ein-Pass-Compiler nur einen sauschlechten Code generiert. Man kann dem
> mit etwas Mühe ein bischen Abhilfe schaffen, ist dann aber immer noch
> Lichtjahre von dem kompakten Code weg, den z.B. der gcc generiert.

genau aus dem grund würde ich an deiner Stelle einen VB->C compiler 
bauen.
Das hat den riesen Vorteil, dass du dich 'nur' um die Codegenerierung 
und die Objekte kümmern musst.
Die optimierung und größtenteils auch die Anpassung an verschiedenen 
AVRs kriegst du kostenlos von der avr-libc

Adrian schrieb:

>>print ( 3 + 5 ) * 8
>
> Wenn meine Scriptsprache das von alleine parsen kann dann wird es auch
> ein Assembler-Proggi tun.

Siehst du.
Genau an dieser Stelle kommt bei mir schon wieder das Problem hoch, dass 
diese Antwort die Frage nicht beantwortet. Ein Assembler-Proggi parst 
diese Programmzeile nicht, sie implementiert sie. Das ist nichts mehr 
mit parsen. Das Parsen ist zu diesem Zeitpunkt schon längst erledigt, 
das geht das Assembler Programm nichts mehr an. Es sei denn du baust 
einen Interpreter. Dann reden wir aber von etwas ganz anderem, als dem 
wovon im Eröffnungsposting bzw. im ganzen Thread implizit die Rede war.


Auch deine Verwendung des Terminus "Skript" verwirrt micht. Ein Skript 
ist üblicherweise etwas was tatäschlich interpretierend abgearbeitet 
wird. Es gibt eine Runtime, die sich den Quellcode vornimmt, diesen 
parst und jede Anweisung sofort nach dem Parsen ausführt. Typische 
Anwendungen davon sind Command-Line Parser bzw. deren 
Programmiersprache. Bei einem Compiler ist die Sache aber völlig anders. 
Der muss sich mit Problemen rumschlagen, die ein Interpreter so 
normalerweise gar nicht hat, wie zb. Register-Allocation oder 
Life-span-Analysis. Dafür holt man aber mit einem Compiler den vollen 
Speed aus der CPU heraus, getoppt nur noch von einem guten 
Assembler-Programmierer. Warum? Weil ein Compiler ein Programm, 
zumindest aber eine Funktion, in seiner Gesamtheit betrachtet und sich 
nicht nur 1 Programmzeile nach der nächsten vornimmt.

Und genau an dieser Stelle widersprechen sich deine Aussagen immer 
wieder. Zeitweilig sieht es so aus, als ob du tatsächlich einen Compiler 
bauen willst, andere Aussagen hingegen gehen wieder mehr in Richtung 
Interpreter. Und genau aus diesem Grund hab ich konkret nachgefragt, wie 
genau du dir das Behandeln der Eingabe

   print ( 3 + 5 ) * 8

vorstellst (wobei ich besser eine der Konstanten durch eine Variable 
ersetzt hätte). Und deine ausweichende Antwort befriedigt mich ehrlich 
gesagt nicht wirklich. Ich weiß immer noch nicht: baust du jetzt einen 
Compiler, oder wird es doch ein Interpreter, oder vielleicht ein 
Mittelding ala P-Code mit einer virtuellen CPU?

Mir kommt auch vor du bist der Ansicht, du brauchst da nur einen Parser 
(den du anscheinen schon hast?) und dann hinten nach noch ein wenig 
Bytewurschteln und fertig ist die Sache. Für einen Compiler ist das aber 
völlig falsch. Das Syntaxparsen ist für einen Compiler der einfachste 
Teil der Übung, der auch noch am schnellsten und problemlosesten zu 
erledigen ist. Erst die Teile nach dem Syntaxparsen sind die 
aufwändigen, die interessanten und die anspruchsvollen. Vom Syntaxparsen 
bis zur Generierung des eigentlichen Assembler-Codes der dem 
Eingabeprogramm entspricht, ist es ein weiter Weg.

Vielleicht kannst du diesen Punkt vorab dann doch noch zufriedenstellend 
klären. Wenn du Mitstreiter für das Projekt suchst, wäre es IMHO schon 
ganz gut, wenn sie vorab schon wenigstens in groben Zügen wüssten wohin 
die Reise gehen soll und womit die Strecke zurückgelegt wird.

Ev. wäre es ganz gut, wenn du erst mal vorstellst, welche Teile du schon 
hast und wie man die weiterbenutzen könnte. Zwischen den Zeilen klingt 
immer wieder an, dass du einen Parser zur Verfügung hast. Also: Was 
kommt da hinten raus? Was macht der Parser? Wie könnte man den in deinem 
neuen Projekt einsetzen?

> Ein VB-Programm generiert Assembler-Anweisungen.

Ein Schachprogramm spielt Schach.
Weiß ich deswegen wie es das macht? Nein. Nach welchen Prinzipien macht 
es das? Fehlanzeige.
Man kann die Arbeitsweise eines Schachprogramms durchaus beschreiben, 
ohne sich gleich in Programmierdetails zu verlieren.

In deiner Aussage steckt mir einfach zuwenig konkret verwertbare 
Information. Das ist mir persönlich alles (noch) zu wischi-waschi als 
das ich sagen würde: paaaaast, ich könnte den und den Teil übernehmen.

Und es tut mir leid. Aber solche Aussagen ....

> Sollte anschließend kein Problem sein das Assemblerfile
> bzw Hex-File zu kompillieren und dann über ein anderes Programm
> in den Flash laden.

> Geplant ist das die Assemblerschnipsel je nach Plattform und
> Prozessor immer passend erstellt werden.

> Also es sollte ein Codegenerator werden. Das hat ziemlich gar
> nichts mit einem Compiler zu tun.

> Und nochmal zum merken:
> ==================================================================
> ES WIRD KEIN COMPILER SONDERN EIN CODEGENERATOR (VB -> ASSEMBLER)!
> ==================================================================

... in ihrer Gesamtheit gesehen stärken nun mal mitnichten mein 
Vertrauen darin, dass du weißt was da auf dich zukommt. Ein Programm von 
einer Hochsprache auf Assembler zu übersetzen ist ein klein wenig 
komplizierter als vorgefertigte Assembler-Codestückchen 
aneinanderzureihen.

Karl heinz Buchegger schrieb:
> Der entscheidende Punkt ist für mich: Wieviel Funktionalität stopfst du
> in ein Objekt. Im Moment hast du extreme High-Level Objekte, die
> wahsinnig intelligent sind.
Das ist Absicht. Kleinen Kindern gibt man große Bauklötze. Es ist nicht 
das Ziel, die eierlegende Wollmilchsau der Controller-Programmierung zu 
erfinden. Es wird immer wieder Aufgaben geben, die damit nicht 
realisierbar sind.

Karl heinz Buchegger schrieb:
> (mir gehts jetzt zb nur um die UART) steckt schon eine Menge Know How
> über UART Übertragung.
Das verstehe ich nicht ganz. Im Endeffekt muss der Host am anderen Ende 
der Leitung eine Nachricht schicken, die der Worker adc verstehen kann. 
Oder man schaltet einen Thinker "Extractor" dazwischen, der die 
Nachricht vom Host für den Worker adc verdaulich macht.

Wie schon oben bei der "grafischen" Lösung muss das System aber 
natürlich offen sein. Das heißt, der Nutzer muss eigene Objektklassen 
programmieren können, vielleicht in etwas, das wie C aussieht. ;) Könnte 
man z.B. aus irgendeinem Grund das Programm auf dem Host nicht ändern, 
müsste man ggf. eine neue Thinker-Klasse programmieren - Aber eben auch 
nur die.

Karl heinz Buchegger schrieb:
> Soll ein
>    watcher_adc adc(ADC0, 10000, 8);
> watcher_adc wirklich über eine Queue verfügen, oder war das nicht besser
> eine Sache für ein
>    thinker_queue queue( 8 );
>    queue <= adc;
>    pid <= queue;
Äh, nee, eher nicht. Erstens muss eine solcher "Thinker" (nennen wir ihn 
Collector) ja jede Form von Daten sammeln können, ggf auch Kollektionen 
von anderen Thinkern seiner Art. Das ist ineffizient und gibt sicher 
schnell Probleme.

Schwerwiegender ist aber der Bruch im Konzept. Ich denke ja von den 
Workern her. Ein Thinker wird nur dann "gefragt", wenn ein Worker etwas 
wissen will. Bei deiner Idee müsste der Thinker Collector von sich aus 
den adc regelmäßig abfragen. Mein Bauchgefühl sagt mir, dass das 
Nachteile hat.

Noch ein Programmbeispiel. Was macht es?

1

worker_pwm pwm(PWM0);

2

thinker_pid pid(23,7,4);

3

thinker_add add;

4

thinker_const offset(0.4);

5

watcher_adc adc(ADC0, 10000, 8);

6

watcher_rs232 control(UART0, 9600, 8, 1, N);

7

8

pwm <= add;

9

add <= (pid , offset);

10

pid <= (adc , control);

Und was mir noch einfällt: Wenn das Konzept so erst einmal funzen 
sollte, könnte man sich an eine GUI machen. :D

PS: Was mir gerade noch einfällt. Parameter der Objekte wären 
(teilweise) optional. "watcher_adc adc(ADC0);" wäre zum Beispiel ein 
Objekt, dass keine Daten sammelt und nur den aktuell gemessenen Wert 
zurückgibt. "watcher_adc adc(ADC0,10000);" würde auch nicht sammeln, 
aber automatisch alle 10ms messen usw.

Detlev T. schrieb:
> Karl heinz Buchegger schrieb:
>> Der entscheidende Punkt ist für mich: Wieviel Funktionalität stopfst du
>> in ein Objekt. Im Moment hast du extreme High-Level Objekte, die
>> wahsinnig intelligent sind.
> Das ist Absicht. Kleinen Kindern gibt man große Bauklötze.

OK.
Mein Einwand geht dann auch mehr in die Richtung, die ich das 
Lego-Syndrom nennen möchte: Für jeden Sch... einen eigenen Baustein.
(Gemeint ist: Früher(tm) gab es von Lego eine Handvoll Grundbausteine, 
mit denen man das meiste erledigen konnte. Mach heute eine 
Lego-Schachtel auf und du findest da drinnen haufenweise Spezialteile, 
die nur bei diesem einen Modell einsetzbar sind. Die Einfachheit des 
Systems von früher wurde irgendwann aufgegeben)

Klar muss es Spezialitäten geben. Da wird man nicht drumherum kommen. 
Die Frage ist nur, wo hört man auf, die Objekte mit immer mehr 
Funktionalität vollzustopfen.

>> (mir gehts jetzt zb nur um die UART) steckt schon eine Menge Know How
>> über UART Übertragung.
> Das verstehe ich nicht ganz. Im Endeffekt muss der Host am anderen Ende
> der Leitung eine Nachricht schicken, die der Worker adc verstehen kann.

D.h. ich muss den Host an das ADC Objekt anpassen. Ich bin nicht mehr 
frei in meiner Entscheidung wie genau ich die Übertragung machen will.

> Oder man schaltet einen Thinker "Extractor" dazwischen, der die
> Nachricht vom Host für den Worker adc verdaulich macht.

Das klingt für mich schon besser.

> Wie schon oben bei der "grafischen" Lösung muss das System aber
> natürlich offen sein. Das heißt, der Nutzer muss eigene Objektklassen
> programmieren können, vielleicht in etwas, das wie C aussieht.

Davon geh ich sowieso aus

>> Soll ein
>>    watcher_adc adc(ADC0, 10000, 8);
>> watcher_adc wirklich über eine Queue verfügen, oder war das nicht besser
>> eine Sache für ein
>>    thinker_queue queue( 8 );
>>    queue <= adc;
>>    pid <= queue;
> Äh, nee, eher nicht. Erstens muss eine solcher "Thinker" (nennen wir ihn
> Collector) ja jede Form von Daten sammeln können, ggf auch Kollektionen
> von anderen Thinkern seiner Art. Das ist ineffizient und gibt sicher
> schnell Probleme.
>
> Schwerwiegender ist aber der Bruch im Konzept. Ich denke ja von den
> Workern her. Ein Thinker wird nur dann "gefragt", wenn ein Worker etwas
> wissen will. Bei deiner Idee müsste der Thinker Collector von sich aus
> den adc regelmäßig abfragen.

Hast du nicht denselben Bruch auch in einem PID Regler bzw. in allen 
Thinkern, die es sich nicht leisten können nur dann Arbeit zu 
verrichten, wenn sie von einem Worker nach Werten gefragt werden? Was 
ist mit dem Extractor Objekt von weiter oben, das du postuliert hast um 
eine Protokollschicht in die UART zu bekommen? Ist das nicht im Prinzip 
genau dasselbe Problem?
Vielleicht könnte eine Lösung darin bestehen, dass ein Watcher sich auch 
auf andere Watcher beziehen kann. Dann wäre das Queue Objekt oder der 
Extractor oder PID Regler auch nichts anderes als ein Watcher. Sie 
überwachen dann keine Hardware sondern eben andere Watcher. Das würde 
die Thinker-Schicht in dem Sinne von eigenständig notwendiger Arbeit 
freihalten wie dir das vorschwebt.

Karl heinz Buchegger schrieb:
> Hast du nicht denselben Bruch auch in einem PID Regler bzw. in allen
> Thinkern, die es sich nicht leisten können nur dann Arbeit zu
> verrichten, wenn sie von einem Worker nach Werten gefragt werden?

Ich denke, dass du Unrecht hast. Von der Definition her sind Thinker ja 
gerade Objekte, die nur etwas berechnen, wenn sie gefragt werden und 
sich die dafür notwendigen Daten verschaffen. Wenn ein Objekt 
eigenständig etwas tut, ist das nach meiner Philosophie ein "Watcher".

Du denkst meiner Ansicht auch noch in die falsche Richtung. Ein Regler 
ist für dich ein (aktives) Element, das regelt. Das stimmt in diesem 
Konzept aber nicht. Hier ist ein Regler ein Objekt, dass eine Stellwert 
aus Ist-Wert und Soll-Wert berechnet, also ein Thinker. Dabei muss man 
für eine PID-Regler auch die Ist-Werte der Vergangenheit kennen. (Nennt 
man die dann War-Werte? ;-) ) Die liefert der Watcher adc.

Ich merke auch gerade, dass ich bei PID-Regler den Sollwert vergessen 
habe. (Naja, Alpha-Version. ;) )

OK. 2. Versuch

1

worker_pwm pwm(PWM0);

2

thinker_pid pid();

3

thinker_textextractor p("P=",24);

4

thinker_textextractor i("I=",7);

5

thinker_textextractor d("D=",4);

6

thinker_textextractor soll("SOLL=",0);

7

watcher_rs232 interface(UART0, 9600, 8, 1, N);

8

watcher_adc(ADC0, 10000, 8);

9

10

pwm  <= pid;

11

pid  <= (adc, soll, p, i, d);

12

p    <= interface;

13

i    <= interface;

14

d    <= interface;

15

soll <= interface;

Und fertig ist der PID-Regler mit RS232-Schnittstelle. :D

Detlev T. schrieb:

> Ich denke, dass du Unrecht hast. Von der Definition her sind Thinker ja
> gerade Objekte, die nur etwas berechnen, wenn sie gefragt werden und
> sich die dafür notwendigen Daten verschaffen. Wenn ein Objekt
> eigenständig etwas tut, ist das nach meiner Philosophie ein "Watcher".

Nein, nein. Das hab ich schon so verstanden.
Daher hab ich ja auch im vorhergehenden Posting noch den Vorschlag 
gemacht, dass Watcher sich auch auf andere Watcher beziehen könnten um 
sie auf Veränderungen zu 'überwachen'.

Karl heinz Buchegger schrieb:
> Daher hab ich ja auch im vorhergehenden Posting noch den Vorschlag
> gemacht, dass Watcher sich auch auf andere Watcher beziehen könnten um
> sie auf Veränderungen zu 'überwachen'.

Eigentlich sollte das ja der erste Watcher schon tun.

Das größte Problem bei meinem Konzept sehe ich bei bidirektionalen 
Elementen. Das geht bei der RS232 ja schon los. Empfang geht ja noch als 
"Watcher". Aber wie passt der Ausgang ins Konzept? Soll man das als 
Worker implementieren, der die anderen Objekte dauernd mit der Frage 
nervt, ob es etwas zu senden gibt?

Gut das ginge vielleicht auch noch. Hohe Performance steht ja nicht im 
Pflichtenheft. ;-) Mit der SPI-Schnittstelle wird es schon schwieriger. 
Das ist ja Ein- und Ausgabe gleichzeitig und das wird bei manchen ICs 
auch genutzt. Wahrscheinlich wird man die Kommunikation zwischen den 
Objekten auch bidirektional auslegen müssen. Also dass die "Antwort" 
auch von der "Frage" abhängen kann. Die Frage könnte dann auch sein 
"gibt es etwas Neues, und wenn ja, was?" womit dann wohl auch keine 
"Watcher für Watcher" nötig wären.

Vielleicht kommt am Ende sogar heraus, dass diese strenge 
Klassifizierung "Worker", "Thinker" und "Watcher" gar nicht 
durchzuhalten ist und man kommt am Ende wieder bei der "grafischen" 
Lösung heraus. Also einfach Objekte, die Datenobjekte senden und 
empfangen.

Aber auch das wäre ja nicht unbedingt schlecht. Wäre vielleicht ein 
Anfang, dem man später eine GUI überstülpen kann.

Ich hatte gerade noch so eine Idee.

Es gibt hier um Forum ein paar Threads, die sich mit einem 
Basic-Interpreter beschäftigen. Ich musste da an meine Anfangszeit mit 
Computern (Ich gehöre zur C64-Generation) denken. Der große Vorteil war 
da, dass man Dinge einfach und schnell ausprobieren konnte. Also 
Basic-Befehle einfach eingeben und gucken, was passiert. Danach konnte 
man die Befehle 1:1 auch in einem Programm verwenden. Die Rechenleistung 
dieser Interpreter war natürlich grottenschlecht, "Syntax-" und "Type 
Mismatch-" Fehler wurden erst zur Laufzeit entdeckt, aber die 
Einstiegsschwelle für Anfänger war sehr niedrig.

Danach kamen Basic-Compiler auf. Dort konnte man dann den zuvor 
erstellten Interpreter-"Sourcecode" direkt in ein lauffähiges Programm 
compilieren, das dann natürlich viel schneller ausgeführt wurde.

So etwas fehlt aus meiner Sicht noch bei den Mikrocontrollern. Nicht 
eine zweite, eierlegende Wollmilchsau wie BASCOM, womit man praktisch 
alle denkbaren Projekte mit erstellen könnte. Sondern ein interaktives 
Entwicklungssystem für zeitunkritische Applikationen und Einsteiger.

Vorstellen könnte ich mir da ein Entwicklungssystem auf Basis des 
ATMEGA1284p. Der hat 16kiB SRAM, die man für den Interpreter nutzen 
könnte. Angesteuert würd er über U(S)ART1 und ein Terminalprogramm auf 
dem PC. Dort speichert man auch die Programme im Klartext, Übertragung 
z.B. über YMODEM.

Das Zielsystem für das Compilat könnte dann aber auch ein "kleinerer" 
ATMEGA sein. Ports, Timer, USART0, ADC, SPI und TWI können die ja alle. 
(ATTINY würde ich weglassen) Eventuell könnte man den üppigen 
Flash-Speicher des MEGA1284 auch dazu nutzen, ein Basicprogramm 
abzuspeichern, das dann beim Start automatisch ins SRAM kopiert und 
ausgeführt wird. So wäre der Weg zu einer funktionierenden Applikation 
noch flacher als z.B. beim Arduino Projekt.

Die damit erstellten Programme wären natürlich bei weitem nicht so 
leistungsfähig als wenn man sie mit BASCOM erstellt hätte. Aber das wäre 
ja auch nicht das Ziel.

Nur einmal so als Idee.

Detlev T. schrieb:

> So etwas fehlt aus meiner Sicht noch bei den Mikrocontrollern. Nicht
> eine zweite, eierlegende Wollmilchsau wie BASCOM, womit man praktisch
> alle denkbaren Projekte mit erstellen könnte. Sondern ein interaktives
> Entwicklungssystem für zeitunkritische Applikationen und Einsteiger.

Gibt es IMHO. Nennt sich Shell. Für AVRs schau mal unter Betriebssysteme 
& Co.  im Artikel Linksammlung

Hallo Stefan,

ich habe mir die Sachen einmal angesehen. Die meisten sind offenbar 
wirklich nicht mehr als eine Shell, also eine Art Kommandozeile. 
Allenfalls Bitlash erlaubt ein bisschen Programmierung über die Makros. 
Das ist weniger, als an was ich gedacht habe. Und die Syntax ist beinahe 
so kryptisch wie Forth, wo es mit amforth wohl schon ein ganz 
brauchbares und leistungsfähigeres  System gibt.

Gruß, DetlevT