Archiv verlassen und diese Seite im Standarddesign anzeigen : Produktvorstellung LunaAVR, neue objektbasierte Programmiersprache für AVR
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 (http://www.rn-wissen.de/index.php/LunaAVR), welcher gerne durch Helfer anhand der Originaldokumentation erweitert werden darf.
Die ständig gepflegte Originaldokumentation findet ihr unter folgendem Link:
Originaldokumentation LunaAVR (http://avr.myluna.de/doku.php)
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-
06.11.2011, 09:30
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
06.11.2011, 11:17
Hallo,
das klingt sehr interessant. Ich würde mich da gern mal einarbeiten und das Ganze austesten.
Welche Anforderungen stellst Du an Mitwirkende?
radbruch
06.11.2011, 11:34
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
@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
Sehe ich das richtig, dass das für Bascom'ler einen Geschwindigkeitsschub bringt, aber für C'ler alles wie beim alten bleibt?
mfg
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
Ich möchte die Diskussion ungern auf die Geschwindigkeit reduzieren. Jede Sprache hat sicher ihre Vor- und Nachteile in bestimmten Anwendungsgebieten.
Das will ich auch nicht unbedingt, ich will auch nicht darüber diskutieren ob deine Sprache jetzt sinnvoll ist oder nicht, aber ich programmiere die AVRs in C und wenn bei dieser Sprache prinzipiell keine Vorteile gegenüber C rausspringen was performance und so betrifft, sehe ich keinen Sinn darin wieder eine neue Sprache zu lernen.
Bei Neueinsteigern ist die Situation natürlich wieder anders, diese können sich aussuchen was ihnen besser liegt.
mfg
thewulf00
06.11.2011, 20:29
Die Vorteile von neuen Sprachen kristallisieren sich erst mit der Zeit heraus. Für Einsteiger wird es eine einfachere und bequemere Art zu programmieren sein. Wer unbedingt Performance braucht, wird sowieso auf ASM oder andere Controller ausweichen.
Aber wenn man das Ganze objektorientiert benutzen kann, und der Compiler/die IDE bereits einiges an Grundobjekten mitbringt, dann lohnt sich ein Blick auf jeden Fall. Wer aber nicht mitentwickeln will, sollte sich noch gedulden, da die Entwicklung ja noch nicht abgeschlossen ist.
Hallo Zusammen,
den aktuellen Stand der Entwicklung könnt ihr ab sofort auf dieser Seite (http://avr.myluna.de/doku.php?id=de:entwicklungsstand) einsehen.
Interessierte Tester/Mitwirkende können sich über das dortige Kontaktformular anmelden.
Gruß, rgf
Nach einem Gespräch mit den aktiven Testern, sind wir größtenteils der Meinung das die Testversion einen Stand erreicht hat, bei dem sie der allgemeinen Öffentlichkeit durchaus zugänglich gemacht werden kann. Sie kann also ab sofort auch von nicht angemeldeten Testern heruntergeladen werden.
Ich bitte dazu zu bedenken, das es sich nachwievor um eine reine Testversion und nicht um die Endversion handelt. Sie kann in gewissem Umfang sicher problemlos als Entwicklungswerkzeug genutzt werden, dient aber vornehmlich als Version zur Fehlersuche und Weiterentwicklung. Dazu bitte auch die Hinweise in der readme lesen.
Rückmeldungen können über die im readme enthaltene Mailadresse, hier im Forum oder auf der Dokumentationsseite (http://avr.myluna.de)erfolgen.
Download aktuelle Testversion (http://avr.myluna.de/doku.php?id=de:download)
Gruß, rgf
Letzte Version: 0.2.45 alpha
Download (http://avr.myluna.de/doku.php?id=de:version_0.2.45_alpha)
Notizen:
* fix: (lavrc) Fehler in Variablenzugriff behoben (danke Irkan)
* fix: (lavrc) Fehler in MemoryBlock-Zugriff behoben (danke Irkan)
* fix: (lavrc) Fehler in Bedingungen (IF..Else, Select..Case) behoben (danke Micha)
* fix: (lavrc) Fehler in Exceptions behoben
* fix: (lavrc) Fehlerhafte Berechnung behoben
* fix: (lavrc) Bibliotheksfunktionen wurden z.T. nicht implementiert
* fix: (lavrc) Fehler in Variablenzugriff behoben
* fix: (lavrc) Fehler in Schleifen behoben
* add: (lavrc) Neue Examples hinzugefügt (danke Dirk)
-schumi-
19.11.2011, 14:29
Hi rgf,
leider sind ja in deinem Downloadpaket nur Windows-Binarys enthalten.. Könntest du auch ein Paket für Linux dazulegen? Währe echt cool :-D
(Sollte laut dem ersten Screenshot hier http://www.realsoftware.com/realstudio/gallery/ nicht gerade kompliziert sein)
Und es muss garnicht die ganze IDE sein, der Compiler alleine würde mir schon genügen :-)
Viele Grüße
-schumi-
moin schumi,
nuja, ganz so einfach ist das nicht. Man muss schon, genau wie bei Projekten in C, entsprechende Systemfunktionen differenzieren. Ich setze mich aber mal ran, kein Problem. Großer Aufwand dürfte es insgesamt nicht sein. Ich teste es dann mit openSuse.
Hallo Zusammen,
ich habe heute die Version 0.3.5 beta zum Download bereit gestellt.
Integriert im Compiler ist nun auch der eigene Assembler lavra, zudem ist nun auch eine Linux-Version von Editor und Compiler verfügbar.
Für die Englisch-Übersetzung der Wiki-Artikel werden noch Helfer benötigt. Anmeldung im Wiki möglich.
have fun! :)
http://avr.myluna.de/doku.php
-schumi-
14.12.2011, 19:07
Hi rgf,
ich hätte jetzt endlich mal Zeit gehabt um deinen Compiler auszuprobieren, aber Fehlanzeige:
simon ~/Downloads/lunaavr_0.3.61_beta_linux$ ls
Examples lavrc.db LICENSE.TXT Lizenz.txt LunaAVR LunaAVR Libs README.TXT
lavrc lavrc Libs LIESMICH.TXT LIZENZ.TXT LunaAVR.cfg LunaAVR.log Resources
simon ~/Downloads/lunaavr_0.3.61_beta_linux$ chmod +x ./lavrc
simon ~/Downloads/lunaavr_0.3.61_beta_linux$ ./lavrc
bash: ./lavrc: Datei oder Verzeichnis nicht gefunden
simon ~/Downloads/lunaavr_0.3.61_beta_linux$ uname -a
Linux laptop_simon 3.1.4-1-ARCH #1 SMP PREEMPT Tue Nov 29 08:55:45 CET 2011 x86_64 Pentium(R) Dual-Core CPU T4500 @ 2.30GHz GenuineIntel GNU/Linux
simon ~/Downloads/lunaavr_0.3.61_beta_linux$
Ich schätze mal dein Compiler wird eine 32-Bit Version sein?
Leider findet pacman das Paket "lib32-glibc" nicht, so dass ich dein 32-Programm nicht auf meinem 64-Bit OS starten kann :(
Viele Grüße
-schumi-
Moin Simon,
Hi rgf,
ich hätte jetzt endlich mal Zeit gehabt um deinen Compiler auszuprobieren, aber Fehlanzeige:
simon ~/Downloads/lunaavr_0.3.61_beta_linux$ ls
Examples lavrc.db LICENSE.TXT Lizenz.txt LunaAVR LunaAVR Libs README.TXT
lavrc lavrc Libs LIESMICH.TXT LIZENZ.TXT LunaAVR.cfg LunaAVR.log Resources
simon ~/Downloads/lunaavr_0.3.61_beta_linux$ chmod +x ./lavrc
simon ~/Downloads/lunaavr_0.3.61_beta_linux$ ./lavrc
bash: ./lavrc: Datei oder Verzeichnis nicht gefunden
simon ~/Downloads/lunaavr_0.3.61_beta_linux$ uname -a
Linux laptop_simon 3.1.4-1-ARCH #1 SMP PREEMPT Tue Nov 29 08:55:45 CET 2011 x86_64 Pentium(R) Dual-Core CPU T4500 @ 2.30GHz GenuineIntel GNU/Linux
simon ~/Downloads/lunaavr_0.3.61_beta_linux$
Ich schätze mal dein Compiler wird eine 32-Bit Version sein?
Leider findet pacman das Paket "lib32-glibc" nicht, so dass ich dein 32-Programm nicht auf meinem 64-Bit OS starten kann :(
Viele Grüße
-schumi-
Ja, 32 Bit. Schau mal hier, das sollte weiterhelfen: https://github.com/nullkey/glc/wiki/Install
Gruß, rgf
thewulf00
15.12.2011, 10:36
In Debian-Derivaten kann man mittels eines Paketes die 32bit-Libraries nachrüsten:
http://www.debian-administration.org/articles/534
-schumi-
15.12.2011, 18:53
So, habs jetz endlich hinbekommen :-D
(Arch32-light aus AUR installiert -> erstellt eine VM in die man sich einloggen kann)
Allerdings check ich nicht, wie ich jetzt eine luna-Datei übersetze:
[root@laptop_simon lunaavr_0.3.61_beta_linux]# ls
Examples LIESMICH.TXT Lizenz.txt LunaAVR LunaAVR.cfg README.TXT lavrc lavrc.db
LICENSE.TXT LIZENZ.TXT Loops.luna LunaAVR Libs LunaAVR.log Resources lavrc Libs lavrc.log
[root@laptop_simon lunaavr_0.3.61_beta_linux]# ./lavrc Loops.luna
lavrc: luna avr compiler v0.3.61 beta
Copyright (c) 2011 rgf software
[root@laptop_simon lunaavr_0.3.61_beta_linux]# ls
Examples LIESMICH.TXT Lizenz.txt LunaAVR LunaAVR.cfg README.TXT lavrc lavrc.db
LICENSE.TXT LIZENZ.TXT Loops.luna LunaAVR Libs LunaAVR.log Resources lavrc Libs lavrc.log
So, wo ist jetz die Hex?
Auch "./lavrc Loops.luna -o Loops.hex" tuts nicht :confused:
(Einen Parameter ala "-help" "-?" o.ä. um die Parameter zu erfahren konnte ich nicht herausfinden - immer nur "file not found")
Kannst du mal kurz schreiben wie man den Compiler bedient?
Viele Grüße
-schumi-
hilfe erscheint bei option "-h"
Beispiel:
./lavrc -v -ohbelr Loops.luna
erzeugt hex, binary, eeprom-file, asm-listing und report
controller wird im source definiert, entsprechend anpassen.
Nutzt du dein Linux nicht grafisch? du kannst es einfacher haben indem du einfach den Editor startest und den Compilerpfad passend einstellst.
-schumi-
15.12.2011, 22:56
Oh mann, auf "-h" hätt ich auch kommen können^^
So funktioniert das Compilieren ja schon prächtig :-D
Nutzt du dein Linux nicht grafisch? du kannst es einfacher haben indem du einfach den Editor startest und den Compilerpfad passend einstellst.
Ja, Arch32 ist eine minimal-VM, ohne X11, per default ist da noch nicht mal pacman drauf.
(Normalerweise nutze ich zur Zeit Gnome3 mit Gnome-Shell als grafische Oberfläche :) )
Richtig auf der Hardware ausprobieren muss ich es aber erst noch..
Es ist eine neue Version online.
Download (http://avr.myluna.de/doku.php?id=de:version_0.3.74_beta)
Einige kleinere Bugs gefunden und behoben.
Es gibt eine neue erwähnbare Version:
Version 0.8.35_beta
Download:
lunaavr-0.8.35_beta.zip (http://avr.myluna.de/lib/exe/fetch.php?media=lunaavr-0.8.35_beta.zip) (6.87 MiB) (Windows ab XP SP3)
lunaavr_0.8.35_beta_linux.tar.gz (http://avr.myluna.de/lib/exe/fetch.php?media=lunaavr_0.8.35_beta_linux.tar.gz) (6.72 MiB) (Linux from Kernel 2.6.x, Gtk 2.x)
Windows-Version getestet unter: Windows 7 Professional
Linux-Version getestet unter: openSUSE 10.3
Änderungen:
(lavrc) Datenbankstruktur geändert.
(lavrc) Neue Implementierungsstruktur des Compilers, Anzeige in der Ausgabe. Dadurch effizientere Einbindung benötigter Funktionen.
(lavrc) Fehlerhafte Timereinstellungen behoben.
(lavrc) Fehlerhafte Print-Bearbeitung behoben.
(lavrc) Neu: Ausgabe kompletter Arrays als Block mit Print: „print c()“
(lavrc) Fehler im ExpressionParser behoben.
(lavrc) Verbesserte Controller-Unterstützung.
(lavrc) Bibliotheks-Funktionen Geschwindigkeits- und Speicheroptimiert.
(lavrc) Manche fehlerhaften Ausdrücke wurden nicht als Solche erkannt.
(lavrc) Uart.Flush hinzugefügt
(lavrc) Timer3, Timer4, Timer5 und CompareC hinzugefügt (Atmega1280,..)
(ide) Anpassungen an den neuen Compiler vorgenommen.
(ide) Datasheets der Controller direkt aufrufbar
(ide) Vorbereitung für Projektmanagement (noch nicht anwählbar).
Beispielanwendung zur implementierten Klassen-Funktionalität in der nicht erwähnten vorherigen Version (0.7.x):
http://www.youtube.com/watch?v=--RYjqpsONI
Dargestellt sind:
1. Video play
2. blinkendes Picture (zu schnell für die Kamera)
3. Random Text
4. Echtzeitberechnung und Darstellung von verschiedenen sich bewegenden geometrischen Objekten: Punkt, Linien, Kreis, Rechteck, proportionaler Text und Polygon (zu schnell für das Display: schliert)
Die Wiederholrate liegt inklusive aller Echtzeitberechnungen bei 23 FPS
Das dogm-demo ist nur als Demonstration gedacht und erfüllt keinen weiteren Zweck.
Gruß, rgf
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.