Hallo! Wollte mal vorsichtig was anfragen. BASCOM ist ja in aller Munde. Natürlich auch die Beschränkung bzw. die Kosten. Die Syntax finde ich nicht gerade konform und auch die Objektorientiertheit fehlt. Gäbe es Interessenten und Mitwirkende an einer Alternative mit einer besseren Basic Syntax und Objektorientierung? Unter der Haube sollte der Basic-Code dann nach Assembler übersetzt werden. Hochsprachen beherrsche ich, Assembler bin ich zur Zeit noch am einlernen. Was sagen die Assembler-Spezialisten dazu? Gruß Adrian
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.
Versuche es! Das hat sicher eine Menge Aha-Effekte und enormen Wissenszuwachs zur Folge. Trotzdem. BASCOM AVR kostet in der Anschaffung zur Zeit etwa 90 Euro. Was Du beim "Selbermachen" sparst, wirst Du potenziert an Zeit "verheizen". Ob es sich lohnt, mußt Du selber wissen.
Danke erstmal für das viele Feedback! :-) Silvan König: Es wird eine Basic-Alternative.... daher kein C++. Ich finde, dass die GCC werkzeuge schon recht gut sind. Die Syntax wird VB bzw VBA. Ich hab da schon spontan ganz viele Ideen. Chris: Ich will keinen Umweg über C gehen. Basic nach Assembler, also ein Codegenerator. Sollte anschließend kein Problem sein das Assemblerfile bzw Hex-File zu kompillieren und dann über ein anderes Programm in den Flash laden. Karl heinz Buchegger: Die Codebausteine müssen natürlich auch erstellt werden. Alles jedoch nach und nach. Geplant ist das die Assemblerschnipsel je nach Plattform und Prozessor immer passend erstellt werden. Die Definitionen werden offen als XML verfügbar sein und durch Helfer erweitert werden. Und ich will BASCOM nicht verdrängen :-) Nummernschalter (Gast): Klar ist es interessant so ein Projekt zu realisieren. Ich würde die 90 Euro auch investieren wenn ich regelmäßig flashen würde und ich jetzt ein Lösung bräuchte. Darum geht es abern nicht. Ich mache es für die Community.
In welcher Sprache willst du Entwickeln?? Bei der richtigen wäre ich dabei;) MFG
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++???
Auch ich habe bisher nur wenige Projekte in BASCOM AVR realisiert, aber es ging alles ziemlich flott. Und dafür haben sich die paar Öcken auf jeden Fall gelohnt. Mittlerweile benutze ich vorwiegend Linux und bin damit "gezwungen", avr-gcc zu nutzen. Funktioniert auch, ... weitestgehend (abhängig von der eingesetzten Distribution). Leider sehen sich die Jungs aus Holland nicht in Lage, eine Lösung für Linux "nachzuschieben". Ich wäre bereit bis zu 100 Euro dafür zu zahlen. Und ich denke, das geht den meisten Linux-Nutzern mit "AVR/8051-Ambitionen" so. Also mach' Dich ran ;-)
bascom mag angeblich wine (ich hab ermangels linux-pc keine praxiserfahrung, aber elektor hat des ma geschrieben)
Windows-Programme unter Linux laufen zu lassen ist (meiner Meinung nach) "Mist"! Ein großer Vordenker aus Dresden (UZ) äußert sich sinngemäß: "Emulatoren zu benutzen ist wie Porsche im Simulator fahren". Und damit hat er vollkommen recht. Auch wenn sich diese Aussage auf einen anderen Kontext bezog.
Nabend Ich würde es in VB realisieren. Ist meine Muttersprache. Die kompletten definitionen wären jedoch extern in XML-Dateien. Mein Prog würde sie interpretieren und als Objekte anbieten. Gruß Adrian
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
Oje oje oje oje oje! Schwachsinnige Idee hoch zehn! Kann ja garnix werden, und selbst wenn es nach hunderten Stunden Arbeit tatsächlich mal funktionieren würde, gäb es kein einzigen Anwender der es nutzen würde außer dir selbst. Dein Plan ist absolut unnötig, hoffentlich finden sich nicht auch noch Leute denen du Zeit klaust. Sinnlos triffs vielleicht auch. Gruß Egon
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.
Die Graphische Sache ist da echt interessant! Ein netter Ansatz ist z.b. MircoSPS von CadSoft http://www.cadsoft.de/microsps/index.htm Jedoch ist das auch nicht wirklcih umfangreich, und auch nicht das allerschnellste. Ne feine Sache wär einfache Regelungen graphisch entwerfen zu können (wie in Simulink) und daraus Code zu generieren. Speziell denk ich dabei an Regelsysteme mit einer gewissen Anzahl analoger Eingänge und einem analogen Ausgang. Damit könnte man wunderschön Zustandsregler oder klassische PID Regler etc. erstellen ohne groß sich mit der Software rumzuärgern die ja eigetnlich nur die Regelung die man eh schon entworfen hat implemenentiert! Oder gibts da schon irgendwas? Also irgendwas für das man nicht 1000e für ne DSP Umgebung hinblättern muss.
Also es sollte ein Codegenerator werden. Das hat ziemlich garnichts mit einem Compiler zu tun. Und es ist wohl völlig egal mit welcher Software im Prinzip eine Textdatei generiert wird. VB ist meine Muttersprache und grafische Oberflächen sind blitz schnell erstellt. Die meisten die es für langsam halten wissen nicht mal wovon sie sprechen. Naja Egon, ich glaube die meisten hier auf mc.net machen das alles hobbymäßig. Du anscheinend nicht. Zusätzlich als Schaltplan die Steuerung zu erstellen ist natürlich auch ne gute Idee! Wäre schön mal zur Abwechslung was Konstruktives zu hören als von jedem seine persönliche Meinung über dies und das! Und nochmal zum merken: ================================================================== ES WIRD KEIN COMPILER SONDERN EIN CODEGENERATOR (VB -> ASSEMBLER)! ==================================================================
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)
Moin! Ich habe bereits eine Scriptsprache erstellt die wirklich alles Parst. Ohne Hilfsmittel wie andere es gerne nutzen. Nagut, dann ist ein Codegeneratot eben ein Teil eines Compilers. Jedoch soll das Programm dann nicht die Binaries bzw. Hexfiles erstellen. 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. Daher ging dieser Thread auch mehr an die Assembler-Profis. Denn in Assembler lese ich mich zur Zeit noch ein.
Kurz und schmerzlos: Interesse an sauberen, durchdachten und gut dokumentierten Bibliotheken: Ja, auf jeden Fall. Am liebsten in C. Interesse an Basic: Nö.
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.
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.
Es gibt doch schon Arduino und Processing, wozu dann noch Basic?
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.
Krach, Knack, Knirsch, Ächts... (Das war die Lanze, die ich gerade für BASCOM gebrochen habe) ;-) Man muß sich auch vor Augen halten, daß der "Bascom-Mann" ja von seiner Arbeit leben muß. Es ist schon aller Ehren wert, daß er eine Demoversion anbietet, mit deren Codegröße viele Leute auskommen. Was die Bedienober- fläche anbetrifft, so finde ich sie "handlicher" als die vom AVR-Studio. Man kann die vorgefertigten Routinen benutzen, aber auch direkt Assemblerbefehle in den Quelltext einfügen, wenn man meint, diese Aufgabe selbst besser lösen zu können. (Nein, ich kenne den Hersteler nicht persönlich und bekomme auch keine Provision für diesen Text) MfG Paul
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 :)
... Wenn Time-to-Market ein Kriterium ist: Die englische Originalversion ist einbändig und geht schon in 4 Monaten :) ... I find it hard to believe That all the pain that we are feeling Has some meaning in this world It's so hard to believe That everything you see is different From the things that you've been told [Eraserheads ]
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. ;)
Die Sache scheint nicht einfach zu sein. Auf diese Seite schaue ich schon erwartungsvoll seit Anfang des Jahres: http://www.avrtools.no/ Zumindest kann es als Anregung dienen.
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.
Mega schrieb: > Die Graphische Sache ist da echt interessant! > > Ein netter Ansatz ist z.b. MircoSPS von CadSoft > http://www.cadsoft.de/microsps/index.htm Von der MicroSPS gibt es auch eine Neuentwicklung. http://www.microsps.net/
Sven P.: Wenn du eh kein Interesse an einer Alternative zu BASCOM hast dann spar dir die Kommentare. Hier geht es um eine Basic alternative. >Karl heinz Buchegger: >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. Ich habe eben erst einen Syntaxparser geschrieben. Bin noch nicht beim fünften angelangt. Somit wird mein zweiter auch selbst gemacht. Schön das es third-party-Produkte auch können. >Karl heinz Buchegger: >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? Ganz einfach und zum 1000sten mal: Ein VB-Programm generiert Assembler-Anweisungen. Also verschone mich mit Unterstellungen ich wollte die Runtime in den AVR laden wollen!!!! >print ( 3 + 5 ) * 8 Wenn meine Scriptsprache das von alleine parsen kann dann wird es auch ein Assembler-Proggi tun. Nur das man sich um mehr Gedanken machen muss. >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. Wo habe ich behauptet das mir 90 € zu viel wären? Es geht immer noch um Hobby und die verbundene "Zeitverschwendung" >Es gibt doch schon Arduino und Processing, wozu dann noch Basic? Es gibt doch Mercedes. Wozu dann noch Opel? Detlev T.: Danke! Endlich mal Anregungen und Ideen. Wenn hier jedoch zu 90% kein Interesse besteht sondern nur Zweifel und fehlendes Verständnis lasse ich es doch sein. Ich hab noch mehr als genug andere Projekte für meine verschwendete Hobbyzeit.
Hallo Adrian, das, was du tun willst, ist schon ein richtiger Compiler - ein Compiler übersetzt eine Eingabesprache (z.B. Basic) in eine andere (z.B. Assembler). Mir haben vor vielen Jahren mal die Crenshaw Texte (http://compilers.iecc.com/crenshaw/ ) geholfen, da da sehr wenig Wert auf theoretische Informatik gelegt wird. Das "Drachenbuch" von Aho, Sethi, Ullman verlangt da deutlich mehr - mehr als ich damals als 16-jähriger verstanden habe. Allerdings konnte ich den ab S. 31 der deutschen Ausgabe (Kapitel 2) beschriebenen Ein-Pass-Compiler verstehen und erweitern - ein bischen C sollte man aber schon können. Crenshaw verwendet dagegen Pascal als Syntax. Ein anderes, kleines, nettes Büchlein ist Nikolaus Wirths "Compilerbau". Dort ist ebenfalls mit wenig theoretischer Informatik ein kompletter Compiler beschrieben. Alle Ansätze haben aber den Nachteil, das der entstehende 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. Dazu braucht man die ganze Prozedur, wie es. z.B. im Drachenbuch ab S. 100/Kapitel 3 beschrieben wird. Da ist die Lernkurve dann wesentlich steiler und insg. arbeitsintensiver. Einen kleinen Compiler selbst zu schreiben kann wirklich Spass machen. Ihn aber gut / konkurenzfähig hinzukriegen, ist ein hartes Stück Arbeit und macht irgendwann u.U. keinen Spass mehr. Das Problem ist nun, dass man grad für AVR einen kompakten Code braucht, da sonst der kleine Speicher zu schnell voll ist. Also, lass dir nicht den Spass verderben und fang' an! Allerdings wird es wohl ein langer, steiniger Weg, bis du wirklich eine brauchbare Alternative zu bascom hast. Wenn das forschen / programmieren im Vordergrund steht, probiers. Wenn du nur auf das Ergebnis zielst - kauf dir lieber den bascom. Just my two cents, Klaus
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.