LunaAVR 2012.r7.2.build3697

Danke für den Hinweis, Uwe,
Die Oberfläche macht einen sehr aufgeräumten und bedienerfreundlichen Eindruck. Tolle Dokumentation in Deutsch.

Klasse.

73, Günter

Moin,

danke an DO5PI für den heißen Tip!

Ich habe kein großes Talent zum Programmieren und bin froh, kleinere Sachen mit Bascom hinzubekommen. Allerdings nervt mich, dass es das nicht für Linux gibt (unter Wine läuft es mehr schlecht als recht).

Habe darum ein paar Anläufe mit C bzw. mit dem Arduino-Dialekt gemacht, aber in C kann ich nur minimal herumfummeln; zurecht komme ich damit nicht.

Eigentlich habe ich 'ne richtige Aversion gegen C; das geht schon mit den Semikolons am Zeilenende und den geschweiften Klammern los, für die man sich auf der deutschen Tastatur die Finger verrenkt.

Und dann die Syntax - statt englischsprachiger Operatoren wie "AND" oder "OR" gibts irgendwelche zweckentfremdeten Mathezeichen, statt "Shift" oder "Rotate" gibts irgenwelche LSD-lastigen Konstrukte mit vielen "<<<<" drin..... eigentlich bin ich ständig am Fluchen, wenn ich versuche, da durchzusteigen.

Die "Krönung" sind die Fehlermeldungen des C- Compilers - der erkennt keine Syntaxfehler, sondern rennt so lange weiter, bis er an irgendeinem Folgeproblem hängenbleibt, das er dann bemäkelt (mit etwas Glück stimmt wenigstens die Zeilennummer...).

Luna habe ich angeguckt und gedacht: "hey, das ist ja so übersichtlich und verständlich wie Bascom". Im Detail ist dann doch vieles anders, aber es ist lesbar und dank der englischen Schlüsselworte leichter merkbar.

Aufgrund der Objektorientierung sind die Befehle sogar übersichtlicher und logischer als bei Bascom.

Ich versuche gerade, einen AVR- Morsetutor, den ich mal in Bascom zusammengestoppelt hatte, nach Luna zu portieren, indem ich den Bascom- Code einfach mal in die Luna-IDE geladen habe und die Fehlermeldungen abarbeite.

Da fliegt mir zwar in jeder 3. Zeile irgendwas um die Ohren, weil in Luna vieles im Detail anders ist als unter Bascom, aber noch sage ich: "aha, so ist das also unter Luna", statt wie bei C über irgendwelche hahnebüchenen Konstrukte rumzufluchen.

Mal sehen, ob die gute Laune bleibt. Fehlerfrei übersetzter Code heisst ja noch lange nicht, dass er auch wie erwartet funktioniert

Eine gewisse Sorge ist allerdings, dass Luna von nur 1 - 2 Leuten programmiert und dokumentiert wird. Wenn die mal keine Lust mehr haben, weil es nicht geung Interesse an Luna gibt, wird das Ding verwaisen, wie so viele andere kleine OpenSource-Projekte.

Aber ich finde es absolut erstaunlich, was die auf die Beine gestellt haben - sogar eine umfangreiche Doku (zu der die meisten Coder ja keine große Lust haben). Allerdings beschreibt sie überwiegend die Befehle; was etwas kurz kommt, sind Beispiele, wie man gängige Probleme löst.

73,
Ralf

"Also dann mal ran, und schreibe bitte nicht das Projekt ab, sondern lege dir eigene funktionale Klasse für ein Teilproblem an."

Das habe ich nicht so ganz verstanden, ich nehme an, Du warnst davor, Bascom- Code 1:1 nach Luna übernehmen zu wollen, weil man dadurch die eleganteren Möglichkeiten von Luna verpaßt (oder einige Sachen gar nicht 1:1 umsetzbar sind).

Im Prinzip ist mir das bewußt - ich will aber erst mal versuchen, Chrash-Kurs-mäßig herauszufinden, wie die von Bascom her gewohnten Sachen unter Luna funktionieren - aber mit dem Ziel, mir dann die "Bascom- Denke" abzugewöhnen.

Da es aber im Moment an ziemlich vielen Stellen kracht (obwohl der (Bascom)-Binärcode nicht mal 2 kB umfaßt), muß ich vielleicht einen Schritt zurück machen und erst mal mit etwas noch einfacherem beginnen.

Wobei mir im Moment auch noch nicht klar ist, ob die beschränkteren Möglichkeiten von Bascom nicht auch ein Vorteil sind - ich verheddere mich schnell in komplexeren Projekten und habe aus der Not eine Tugend gemacht: kleine Sachen auf kleinen AVRs zu realisieren, z.B. AtTiny13, AtTiny45 und AtTiny24/44.

73,
Ralf

Moin,

Zitat von DK5BU

Eigentlich habe ich 'ne richtige Aversion gegen C; das geht schon mit den Semikolons am Zeilenende und den geschweiften Klammern los, für die man sich auf der deutschen Tastatur die Finger verrenkt.

Naja, ob ich nun ALT-GR oder SHIFT drücke, um die geschweiften Klammern zu erreichen ist ziemlich egal. Die sind also auf US-Tastaturen auch nicht besser zu erreichen.

Zitat von DK5BU

Und dann die Syntax - statt englischsprachiger Operatoren wie "AND" oder "OR" gibts irgendwelche zweckentfremdeten Mathezeichen, statt "Shift" oder "Rotate" gibts irgenwelche LSD-lastigen Konstrukte mit vielen "<<<<" drin..... eigentlich bin ich ständig am Fluchen, wenn ich versuche, da durchzusteigen.

#define AND &
#define OR |
#define begin {
#define end }
#define SHL <<
#define SHR >>

SCNR

Zitat von DK5BU

Die "Krönung" sind die Fehlermeldungen des C- Compilers - der erkennt keine Syntaxfehler, sondern rennt so lange weiter, bis er an irgendeinem Folgeproblem hängenbleibt, das er dann bemäkelt (mit etwas Glück stimmt wenigstens die Zeilennummer...).

-Wfatal-errors beim gcc zwingt den Compiler zu einem sofortigen Stop. Das der gcc keine Syntaxfehler erkennt, ist mir nun aber ganz neu. Das die Fehlermeldungen manchmal etwas viele sind, ist eine Einstellungssache.

Zitat von DK5BU

Eine gewisse Sorge ist allerdings, dass Luna von nur 1 - 2 Leuten programmiert und dokumentiert wird. Wenn die mal keine Lust mehr haben, weil es nicht geung Interesse an Luna gibt, wird das Ding verwaisen, wie so viele andere kleine OpenSource-Projekte.

Das muss bei OSS kein Grund sein, etwas nicht zu verwenden. Sieht ja auch nicht übel aus.

Mich machen da eher die Einschränkungen in der Beschreibung stutzig, auf die nicht weiter eingegangen wird: "Luna ist in Teilen quelloffen und kostenlos". Es wird auf der Site nirgends erwähnt, unter welcher Lizenz das Paket veröffentlicht wird, wie es sich mit den Bibliotheken verhält und was daran nicht quelloffen ist. Oder habe ich das nur übersehen?

73, Tom

Hallo Tom,

ich bin wohl zui sehr Grobmotoriker, um mich mit der AltGr-Taste anzufreunden. Bin aber wohl nicht der einzige, denn so mancher Coder benutzt aus dem gleichen Grunde eine US- Tastatur.

Was die Möglichkeit betrifft, eigene defines anzulegen: die Logikoperatoren sollten nur ein Beispiel sein. Da müsste ich die halbe Sprache umbauen

Macht auch wenig Sinn, weil der wesentliche Vorteil von "C" für mich wäre, anderer Leute Code und Libs verwenden zu können; und den muss man ja dann wenigstens ansatzweise verstehen. Von daher macht es auch wenig Sinn, nur eine Teilmenge der C-Syntax zu lernen und einzusetzen - in anderer Leute Code kriegt man dann doch die volle Breitseite ab.

Was die Lizenz von LunaAVR angeht: da gibt es in der Tat Widersprüche - der Splash- Screen spricht von Freeware, unter der Hilfe gibts eine Eula, aber dem Binärpaket ist die GPL V2 beigefügt. Da habe ich mir gedanklich das rausgesucht, was mir am liebsten ist, die GPL...

Die "manpower", die hinter dem Projekt steht, finde ich schon wichtig: die OpenSource-Welt ist voll von verwaisten Projekten.

73,
Ralf

Moin Ralf,

Zitat von DK5BU

Was die Möglichkeit betrifft, eigene defines anzulegen: die Logikoperatoren sollten nur ein Beispiel sein. Da müsste ich die halbe Sprache umbauen

Das geht doch schnell, sind dann doch nur 16 Schlüsselwörter und eine paar Operatoren

Zitat von DK5BU

Macht auch wenig Sinn, weil der wesentliche Vorteil von "C" für mich wäre, anderer Leute Code und Libs verwenden zu können; und den muss man ja dann wenigstens ansatzweise verstehen. Von daher macht es auch wenig Sinn, nur eine Teilmenge der C-Syntax zu lernen und einzusetzen - in anderer Leute Code kriegt man dann doch die volle Breitseite ab.

C ist da wirklich simpel, durch den begrenzten Umfang der Sprache. Der Aufwand an sich liegt nicht bei den syntaktischen Eigenarten der Sprache, sondern beim Verständnis der Libs, API, GUI Umgebung oder eben auch bei einem neuen Mikrocontroller. Auch bei LunaAVR muss man sich wie bei Arduino mit den vereinfachten Schnittstellen vertraut machen. Das mag auf den ersten Blick verführerisch und für viele kleine Anwendungen auf den AVR auch ausreichend sein.

Ich persönlich mag das nicht, ich bevorzuge den Controller pur, schon aus dem Grunde, dass man bei einem Fehler weniger Möglichkeiten hat, wo dieser liegen könnte. Aber gut, ich verwende als "IDE" auch den vi und make, früher gar emacs. Bin also sicher kein Maßstab

Zitat von DK5BU

Die "manpower", die hinter dem Projekt steht, finde ich schon wichtig: die OpenSource-Welt ist voll von verwaisten Projekten.

Da hast Du sicher recht! Oftmals weil die Projekte aber auch keinen größeren Sinn oder sich selbst überlebt haben. Bei den guten und erfolgreichen Projekten, egal wie viel "manpower", findet sich auch ein Nachfolger, bzw. meist werden es während der Entwicklungszeit schon von alleine mehr, siehe z.B. fldigi.

73, Tom

Hallo Uwe,

danke für den Hinweis:

Zitat

Compiler/IDE sind Freeware, die enthaltene Lizenzvereinbarung in der IDE beinhaltet nur eine genauere Definition der Freewarelizenz. Die Luna-Sourcen und die Datenbank-Sourcen sind GPL/CC.

- Compiler/IDE: Freeware
- Beispielquelltexte: GPL/CC
- Datenbank-Sourcen: GPL/CC

Die mitgelieferten Programme AVRdude und Burn-O-Mat hat er zu erwähnen vergessen, die sind auch GPL.

Das Freeware-Lizenzmodell gefällt mir nicht sonderlich, weil es danach aussieht, dass die Community helfen soll, LunaAVR fortzuentwickeln, und wenn es dann fertig ist, soll es wohl Geld einbringen.

Dagegen ist zwar nichts einzuwenden (selbst wenn die teuer wird; eine eingeschränkte Freeware-Version ist ja bei solchen IDEs marktüblich), vergrößert aber das Risiko, dass die Softwareentwicklung mangels kommerziellem Erfolg eingestellt wird.

In Ponyhof-Notation: wir dürfen das Pony streicheln und füttern, aber wenn es dann mal groß ist und keiner fürs Reiten zahlen will, geht es möglicherweise zum Abdecker und nicht auf den OpenSource-Gnadenhof

Aber egal, LunaAVR macht mir trotzdem Spaß, und ich werde wohl auch ein LunAtic werden....

Ich habe meinen als Einstieg gewählten Bascom-Code (Morse-Tutor) erst mal nicht portieren können, weil die LunaAVR- Rnd() - Funktion keinen wählbaren Maximalwert liefert, sondern nur 0-255. Die Funktion brauche ich mehrfach und mit wechselnden Maximalwerten.

Aber ich habe erfolgreich zwei Morsebaken portiert (eine mit Festtext und eine mit freier Programmiermöglichkeit über einen Software- Uart). .

Die Binaries sind etwas größer als bei BASCOM, das erste Programm passt in einen AtTiny13, das zweite leider nicht mehr, läuft aber auf einem AtTiny25.

Jetzt habt ihr mich animiert auch mal erste Schritte in Luna zu machen und habe da - beim Vergleichen mit Bascom - einige Fragen.

Data Direction Register: Luna erlaubt offensichtlich nur einen Port komplett als Aus- Oder Eingang zu setzen oder nur einzeln bitweise.
Der in Bascom mögliche Befehl um z.B. bei Port B drei Ports als Ausgang und 5 Ports als Eingang zu deklarieren mündet in eine Fehlermeldung: portb.&b00000111.mode = Output

Auch bei den Bedingungen ist mir ein Unterschied aufgefallen:

Bei if - else -elseif ist als Vergleichsooperand ein Ausdruck erlaubt. Beim im Grunde ähnlichen Select - case darf als case Vergleichsoperand nur eine Konstante stehen.
case 10 geht (Konstante)
case >10 <20 (Ausdruck) gibt eine Fehlermeldung, Bascom kann das.

Seh ich da was falsch?

73, Günter

Zitat

dafür sind wir doch Programmierer und nicht nur Nutzer?

Kennst Du Kongrument oder den Modulo-Operator ?

Zitat
a = b mod c

Ja, ist schon klar, dass man das "zu Fuß" mit einer eigenen Funktion erschlagen könnte. Für mein Einstiegsobjekt war mir die Hürde erst mal zu hoch; da bin ich dann lieber auf ein noch kleineres Beispiel umgestiegen.

Kongrument sagt mir nix, aber Modulo habe ich schon öfter verwendet.

Zum Thema prozedural vs. objektorientiert (ich schwafele mal etwas rum, weil die Frage vielleicht auch die Mitleser interessiert): ich habe nur eine grobe Vorstellung was "objektorientiert" bedeutet, und dass Objektorientierung umso hilfreicher wird, je größer das Projekt wird.

Ich habe mich auf kleine Projekte und kleine Controller (Attiny13/45, AtTiny24/44) "eingeschossen" und schon gemerkt, dass der Luna- Binärcode etwas größer wird als vergleichbarer Bascom- Binärcode. Ist das Overhead, der durch die Objektorientierung erforderlich ist oder ist Bascom - weil älter - nur gründlicher optimiert?

Ist zwar nicht tragisch, aber schmälert etwas den Einsatzbereich für meinen "Lieblingscontroller" Attiny13...

Ob ich mir eine objektorientierte Herangehensweise angewöhnen kann, weiss ich auch noch nicht. Ich wurschtel' beim Programmieren immer drauflos wie eine Hausfrau, die bei Kochen zwischendurch drei mal in den Supermarkt um die Ecke rennen muß

Da das vermutlich die Vorgenensweise vieler Bascom-Programmierer ist, stellt sich die Frage, ob das nur Gewohnheit oder mentalitätsbedingt ist. Vielleicht können wir das einfach nicht besser; es sind ja nicht alle Menschen gleich.... damit verschenkt man dann zwar die Potentiale, die Luna bietet, aber kommt auch irgendwie zum Ziel.

Früher gab es mal den Spruch: a real programmer con program fortran in every language. Das Gegenteil geht vielleicht auch mit Luna: a bad programmer can program bascom in every language

Die objektorientierte Luna-Syntax finde ich schon mal intuitiver und übersichtlicher als die von Bascom, auch wenn sie etwas mehr Schreibarbeit bedeutet:

Bascom:


Config Timer0 = Counter , Prescale = 8 , Compare A = Toggle , Clear Timer = 1
Ocr0a = Tonhoehe


Luna:


Timer0.clock = 8
Timer0.CmpA.mode = Toggle , Clear Timer = 1
Timer0.cmpA.clear.enable
Timer0.cmpA.value = Tonhoehe

Wechselt man zu einem anderen Hardware- Objekt, ist die Syntax dann sehr änlich (unter Bascom ist das nicht so logisch)

73,
Ralf

Danke für das Beispiel Uwe,

was mir an Luna gefällt ist die wirklich intuitiv zu erfassende Syntax.

Wie in allen Sprachen (nicht nur in Programmiersprachen) kann man sich ungelenk und plump ausdrücken, oder eloquent und virtuos. Bei normaler Sprache lernt man gute Ausdrucksfähigkeit durch Lesen von guter Literatur. Bei der Programmiersprache genauso, in dem man sich an Beispielen von erfahrenen Programmierern orientiert. Insofern hoffe ich auf eine breite Nutzerbasis von Luna, so dass es bald viele gute Beispiele im Web gibt, von denen man profitieren kann.

vy73, Günter