LunaAVR, neue objektbasierte Programmiersprache für AVR

[rgf]

Projektvorstellung: Objektbasierte Programmiersprache LunaAVR

Zur Bereicherung der Auswahl an existierenden Entwicklungswerkzeugen, habe ich mich entschlossen mein bisher inoffizielles Projekt hier vorzustellen (nach Absprache mit Frank). Ziel ist es, interessierte Anwender und/oder Entwickler zu finden, die an diesem Projekt mitwirken wollen.

Für eine Kurzübersicht findet ihr im RN-Wissen einen Artikel, welcher gerne durch Helfer anhand der Originaldokumentation erweitert werden darf.
Die ständig gepflegte Originaldokumentation findet ihr unter folgendem Link:
Originaldokumentation LunaAVR

Projekt-Status

• Es existiert ein funktionierender Compiler in einer alpha-Version, welcher avrasm2-Kompatiblen Assembler-Sourcecode produziert. An einem integrierten Assembler wird nach Abschluss der grundlegenden Compilerfunktionalität gearbeitet. Weiterhin sind alle grundlegenden Funktionsbibliotheken (geschrieben in Assembler) einsatzbereit.
• Zusätzlich existiert ein angepasster (eigener) Editor mit Syntax-Highlighting, Syntaxstrukturierung für den LunaAVR-Compiler, es kann jedoch jeder eigene Texteditor freier Wahl für die Programmentwicklung benutzt werden.
• Eine IDE, die später die speziellen objektbasierten Besonderheiten und Möglichkeiten der Programmiersprache ausnutzt, ist in Planung und wird nach Abschluss der ersten Betaversion des Compilers begonnen.

Portierte Sourcen
Ich konnte sämtliche meiner Sourcen erfolgreich portieren, zum Teil mit erheblichem Performancegewinn. Darunter befinden sich KFZ-Zünd und Motorsteuerungen, Anzeigeinstrumente und sonstige Steuerungen. Die meisten meiner Projekte haben einen KFZ-Bezug, da ich mich in der Oldtimer- und Custombike-Szene bewege (weltweit) und Diese dort für Freunde aus der Szene konstruiere, programmiere und anfertige.

Anwender mit anderen Themengebieten sind daher sehr willkommen zu testen ob sie ihre Sourcen auf LunaAVR portieren wollen, um die noch sicher vorhandenen Schwächen und Fehler auszuloten.

Entwickler sind willkommen die Funktionsbibliotheken mit weiteren tollen Funktionen zu erweitern (AVR-Assembler).

Derzeit wünsche ich mir einen Diskussionsthread, in dem ich anstehende Fragen beantworten möchte und ob es überhaupt Interessenten für dieses Projekt gibt.

Gruß, rgf

[-schumi-]

WOW, Respekt!

Der einzige größere Brocken der noch fehlt ist ja anscheinend nur noch I2C...

Ich würde den Compiler wirklich sehr gerne mal ausprobieren
Wo kann man den runterladen? Im Downloadbereich der Hompage ist ja leider noch nichts...

Und in welcher Sprache ist der Compiler eigentlich geschrieben?

Viele Grüße
-schumi-

PS: Herzlich willkommen im RN :-D

[thewulf00]

Hallo,

das klingt sehr interessant. Ich würde mich da gern mal einarbeiten und das Ganze austesten.

Welche Anforderungen stellst Du an Mitwirkende?

[radbruch]

Hallo

Das erzeugte Binary ist von der Größe her vergleichbar mit existierenden Hochsprachen wie C/C++. Die Geschwindigkeit liegt auf dem Level von C/C++ und ist damit bis zu 10x schneller als vergleichbarer Code aus BASCOM®.

Ein gewaltiges Projekt. Aber brauchen wir das wirklich? Ich sehe den Bedarf nicht. Und das kann übrigends jeder behaupten, denn alle anderen, die das schon ewig machen, sind doof.

Ich konnte sämtliche meiner Sourcen erfolgreich portieren, zum Teil mit erheblichem Performancegewinn. Darunter befinden sich KFZ-Zünd und Motorsteuerungen, Anzeigeinstrumente und sonstige Steuerungen.

Wie kann man sich diesen Performancegewinn vorstellen? Höheren Motordrehzahlen möglich oder kompliziertere Instrumente? Gibt es schon ein Tool das Bascom- oder C-Quellen portieren kann?

Nachdem ich mich nun durch die Wiki- und die Projektseite gearbeitet habe, fühle ich mich irgendwie um das Demo betrogen.

Gruß

mic

[rgf]

@schumi:
Was man sehen kann sind die Hardware-Abbildungen der AVR-Controller, es fehlt aber noch Einiges. Ich denke da an Software-SPI und Software-UART um ein paar Beispiele zu nennen. Ich entwickle Software in verschiedenen Sprachen, von Assembler bis Java. Der Compiler selbst wird mit RealStudio entwickelt, was die Möglichkeit für zusätzliche Linux und Apple-Binarys eröffnet.

@thewulf:
Mitwirkende sind Willkommen. Ausgetestet werden soll inwieweit Designfehler innerhalb der Sprache existieren und ob eigene Projekte portiert werden können. Der Themenbereich meiner Projekte ist auf meine eigenen Anforderungen eingeschränkt. Andere Entwickler haben auch andere Schwerpunkte. Hier sollen die sicher noch vorhandenen Schwächen aufgezeigt werden. Fehlersuche natürlich ebenso.

Ein gewaltiges Projekt. Aber brauchen wir das wirklich? Ich sehe den Bedarf nicht.

Ich habe auch keinen wirklichen "Bedarf" gesehen. Wenn man aber so herangeht, müsste man ehrlich sein und sagen, dass es für das iPhone eigentlich auch nie wirklich einen "Bedarf" gab, es gab zu damaliger Zeit ja genügend Nokias in ausreichender Größe, Form und Farbe.

Das Projekt ist entstanden, weil ich es einfach machen wollte: Eine eigene Programmiersprache mit bestimmten Ideen die ich für die Programmierung nützlich erachte (Beispiel: Objektbasierung). Im Verhältnis ist der Aufwand für Mikrocontroller vergleichsweise gering. Jetzt stelle ich das Projekt hier vor, nicht mehr und nicht weniger. Einfach um zu schauen, ob es Andere interessant finden und ihnen als Werkzeug nützlich wäre.

Auch stelle ich das Projekt absichtlich in seiner Entstehungsphase vor, damit interessierte Anwender oder Entwickler die Möglichkeit haben frühzeitig an der Gestaltungsrichtung teilzuhaben. Es mag in seinem momentanen propritären Zustand für meine Zwecke und meine Schwerpunkte ausreichen, wird es aber sicher nicht für Andere. Ich werde in naher Zukunft eine Testversion zusammenstellen, die es den einzelnen ernsthaft Interessierten erlaubt sich ein Bild zu machen, Fehler aufzuzeigen, Richtungsempfehlungen zu äußern oder selbst z.Bsp. an dem Bibliothekscode mitzuwirken. Die bis dahin anstehenden wichtigen Fragen die sich vorab stellen, möchte ich jedoch im Vorfeld klären, nicht erst wenn viele Stunden möglicherweise sinnloser Arbeit Mehrerer investiert sind.

Wie kann man sich diesen Performancegewinn vorstellen? Höheren Motordrehzahlen möglich oder kompliziertere Instrumente?

Das sind kürzere Bearbeitungszeiten von Routinen und wirkt sich beispielsweise auf umfangreiche Berechnungen die in gewissen Programmbereichen in Echtzeit erfolgen müssen oder in Interrupt-Serviceroutinen aus.

Dazu ein Beispiel:

Die ersten Versionen einer programmierbaren Zündsteuerung habe ich in Bascom geschrieben. Nun muss man wissen, dass hier neben der einfachen Timerei, der Echtzeitberechnung von bestimmten Werten auch weitere Sensorik dazu kam wie Temperatur und Lastzustand usw. Zusätzlich noch die Echtzeitkommunikation mit der PC-Software, Anzeige und Modifikation aktueller Werte. Hier musste ich feststellen, dass bei der Ausgabe über UART Variablen durch die Interruptroutinen überschrieben wurden und auch die parallele Kommunikation während des Betriebs instabil war. Hier kam man technisch einfach an die Grenzen, egal wie man optimiert hat.

Schlussendlich hab ich das Ganze verworfen und alles in Assembler geschrieben. Ab diesem Zeitpunkt ist die Echtzeitberechnung verbliebener Werte (Vorberechnung mit Tabellen fand schon statt) in seiner Dauer von 300 µs auf 30-68 µs pro Signal geschrumpft, die Echtzeitkommunikation stört die Timer nicht mehr und Variablen werden nicht mehr überschrieben. Da Assembler mächtig tipparbeit ist und ich schon eine eigene große Funktionsbibliothek erstellt hatte, dachte ich man könne das Ganze ja auch einfacher haben und eine eigene Sprache schreiben. Der Code ist aus LunaAVR ist dadurch prinzipiell derselbe wie in meinen Assemblerversionen. ..und ja, dadurch sind auch höhere Drehzahlen möglich.

Gruß, rgf

[Wsk8]

Sehe ich das richtig, dass das für Bascom'ler einen Geschwindigkeitsschub bringt, aber für C'ler alles wie beim alten bleibt?

mfg

[rgf]

Sehe ich das richtig, dass das für Bascom'ler einen Geschwindigkeitsschub bringt, aber für C'ler alles wie beim alten bleibt?

mfg

Ich möchte die Diskussion ungern auf die Geschwindigkeit reduzieren. Jede Sprache hat sicher ihre Vor- und Nachteile in bestimmten Anwendungsgebieten.
Mein Anliegen ist vielmehr, die Objektidee in eine AVR-Programmiersprache zu übernehmen und möglichst sinnvoll auszunutzen, gleichzeitig jedoch den direkten Hardwarezugriff nicht zu stark zu abstrahieren bei einer gleichzeitig leicht verständlichen Semantik auch für Anfänger. Es ist nicht das Ziel Andere Werkzeuge zu ersetzen. Wenn wie in diesem Fall ein Geschwindigkeitsvorteil herauskommt, bin ich darüber natürlich nicht betrübt.

Gruß, rgf