- LiTime Speicher und Akkus         
Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 23

Thema: LunaAVR, neue objektbasierte Programmiersprache für AVR

  1. #1

    LunaAVR, neue objektbasierte Programmiersprache für AVR

    Anzeige

    Powerstation Test
    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

  2. #2
    Erfahrener Benutzer Roboter-Spezialist Avatar von -schumi-
    Registriert seit
    30.12.2009
    Ort
    Wasserburg am Inn / Bayern
    Alter
    30
    Beiträge
    449
    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

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    08.07.2004
    Ort
    Südhessen
    Beiträge
    1.312
    Hallo,

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

    Welche Anforderungen stellst Du an Mitwirkende?

  4. #4
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    61
    Beiträge
    5.799
    Blog-Einträge
    8
    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
    Bild hier  
    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  5. #5
    @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
    Geändert von rgf (06.11.2011 um 19:21 Uhr)

  6. #6
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    08.08.2008
    Ort
    DE
    Beiträge
    523
    Sehe ich das richtig, dass das für Bascom'ler einen Geschwindigkeitsschub bringt, aber für C'ler alles wie beim alten bleibt?

    mfg

  7. #7
    Zitat Zitat von Wsk8 Beitrag anzeigen
    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

  8. #8
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    08.08.2008
    Ort
    DE
    Beiträge
    523
    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

  9. #9
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    08.07.2004
    Ort
    Südhessen
    Beiträge
    1.312
    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.

  10. #10
    Hallo Zusammen,

    den aktuellen Stand der Entwicklung könnt ihr ab sofort auf dieser Seite einsehen.
    Interessierte Tester/Mitwirkende können sich über das dortige Kontaktformular anmelden.

    Gruß, rgf

Seite 1 von 3 123 LetzteLetzte

Ähnliche Themen

  1. programmiersprache
    Von stani im Forum AVR Hardwarethemen
    Antworten: 21
    Letzter Beitrag: 05.11.2008, 20:49
  2. AVR-Programmiersprache
    Von Christoph2 im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 15
    Letzter Beitrag: 03.04.2006, 23:30
  3. Was ist die Programmiersprache
    Von Ganxta2 im Forum Elektronik
    Antworten: 23
    Letzter Beitrag: 22.01.2006, 10:59
  4. Neue Programmiersprache entwickeln
    Von MrQu im Forum AVR Hardwarethemen
    Antworten: 28
    Letzter Beitrag: 15.11.2005, 22:05
  5. Programmiersprache?
    Von Rama-k im Forum AVR Hardwarethemen
    Antworten: 6
    Letzter Beitrag: 07.06.2004, 14:54

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test