Erfahrungen zu LunaAVR

[harryk]

Hallo Forum,

ich wurde gebeten meine Erfahrungen zur Programmiersprache Luna für AVR Mikrocontroller zu teilen, was ich mit diesem Thema gerne tun möchte.
Wie ich bei meiner Vorstellung schon geschrieben habe, konnte ich schon einiges an Erfahrungen sammeln und beantworte auch gerne Fragen dazu (soweit es mein Wissen zulässt). Dieses Thema soll keinen Sprachenkrieg anzetteln, er ist von mir ausschließlich dazu gedacht Interessierten einen Einblick zu gewähren und darüber zu diskutieren.

Worum gehts?

Es gibt da eine recht neue Programmiersprache namens Luna, die sich sprachlich an Basic, Pascal und C orientiert.
Sie ist aus meiner Sicht Basic/Pascal-ähnlich und kombiniert erfolgreich die objektorientierte Programmierung mit der klassischen Programmierung.

Webseite: http://avr.myluna.de
Screenshot: Bild von der aktuellen Version

Verfügbar für: Windows, Linux und Mac OS
Preis: kostenlos
Lizenz: Freeware/Quelloffen

Meine Erfahrungen

Was ich zuerst begrüße ist die Tatsache, dass die Entwicklungsumgebung für alle drei großen Betriebssysteme verfügbar ist. Ich benutze im Keller einen Linux-PC und im Arbeitszimmer der Wohnung einen Windows-PC. Hier muss ich also keine Umstellungen vornehmen und kann an beiden Rechnern arbeiten. Ich habe viele Jahre ausschließlich Assembler programmiert und bezüglich Hochsprachen habe ich Erfahrungen in Pascal (jedoch nicht auf Mikrocontrollern). Da ich damit sozusagen mich recht entspannt und unvoreingenommen nach einer Hochsprache für Mikrocontroller umsehen konnte, jedoch mit C syntaktisch irgendwie auf Kriegsfuß stehe, habe ich mich mit Bascom und auch Luna gleichermaßen beschäftigt. Schlussendlich bin ich dann bei Luna geblieben. Hier nun meine Erfahrungen an kleinen Beispielen, warum es sich lohnt sich damit auseinanderzusetzen.

1. Die IDE
   In meinem Alter möchte ich nicht mehr mit einem Standardeditor arbeiten, ich wollte schon etwas modernes was mir die Arbeit der ordentlichen Strukturierung eines Codes abnimmt. Die IDE und der Editor sind da so wie ich es mir vorgestellt habe. Man hat farbliche Hervorhebungen, automatisches strukturieren des Codes, man kann Codebereiche ein- und ausklappen, es gibt eine Autovervollständigen-Funktion und viele hilfreiche Werkzeuge die man bei der Programmierung benötigt. Einige davon sind z.Bsp. die direkt erreichbaren Datenblätter der Mikrocontroller, die ganzen Adressen und Konstanten der Mikrocontroller, Editoren für Zeichensätze und Bilder für grafische Displays, sogar ein Disassembler ist seit der neuesten Version integriert. Das Arbeiten mit der IDE macht Spaß und im Vergleich wirkt die Bascom-IDE auf mich wie ein Notepad mit farbigen Buchstaben.

• Die Sprache
  Die Sprache geht schon mehr in Richtung Basic/Pascal. Eine direkte Benennung kann ich hier aber gar nicht vornehmen, sie ist kein einfaches Basic, kein Pascal und schon gar kein C, enthält aber viele nützliche Elemente aus allen drei Sprachen, es ist halt Luna. Sie bietet sprachlich eine Mischung aus Objektorientierung und Standardprogrammierung. Die Dokumentation (PDF) ist sehr umfangreich und enthält zu jedem Befehl immer ein kleines Beispiel. Hier kommt man schnell dahinter wie etwas funktioniert.

• Die Objektorientierung
  Bei Luna ist alles in Klassen oder Objekte zusammengefasst. Das bedeutet für den Programmierer, z.T. etwas mehr Schreibarbeit. Man wird aber mit einer wirklich guten Übersichtlichkeit belohnt. Die Objektorientierung sieht praktisch angewendet so aus, dass man wahlweise mit normalen Prozeduren und Funktionen arbeiten kann und zusätzlich die Möglichkeit hat solche mächtigen Bestandteile wie Klassen und Strukturen zu verwenden.
  
  Wie muss man sich das vorstellen? Auf der Webseite gibts dazu ein wirklich passendes Beispiel:
  

  Die Zugriffe und Schreibweisen der objektorientierten Programmierung sind der realen Welt nachempfunden. Zum Verständnis ein vereinfachtes Beispiel zu den Begriffen „Klasse“, „Objekt“, „Methode“ und „Eigenschaft“:
  
  Wir haben ein Haus, in dem Haus befindet sich ein Schrank. Der Schrank hat Schubfächer und in den Schubfächern liegen Dokumente. In der Analogie zur objektorientierten Programmierung in Luna repräsentiert das Haus eine Klasse. Der Schrank der sich im Haus befindet ist ein Objekt. Möchte man nun ein Dokument aus dem Schrank im Haus holen, betritt man das Haus, geht zum Schrank, öffnet eine gewünschte Schublade und nimmt sich das Dokument. Eine Methode vom Objekt Schrank wäre hierfür öffneSchublade oder nimmDokument. Eine Eigenschaft wäre AnzahlSchubfächer.
  
  Die Einzelnen Schritte unterteilt man durch einen Punkt, sodass der Aufruf aus obigem Beispiel so aussieht:
  
  Ermitteln der Anzahl der Schubfächer vom Schrank:
  
  Anzahl = Haus.Schrank.anzahlSchubfächer
  
  Holen eines Dokumentes:
  
  Haus.Schrank.nimmDokument( SchubfachNummer )

Beispiele

Ein einfaches "Hallo Welt" in Luna sieht so aus (aus den mitgelieferten Beispielen):

avr.device = attiny2313
avr.clock = 20000000         ' Quarzfrequenz
avr.stack = 4                ' Bytes Programmstack (Vorgabe: 16)

uart.baud = 19200            ' Baudrate
uart.Recv.enable             ' Senden aktivieren
uart.Send.enable             ' Empfangen aktivieren

print "Hallo Welt"

Do
Loop

Erläuterung: "avr" ist die sogenannte Basisklasse in Luna. Das ist mehr oder weniger der Controller selbst. Wie in der objektorientierten Notation üblich, unterteilt man Zugriffe auf solche Klassen oder Objekte mit einem Punkt. In der Dokumentation ist dann immer beschrieben welche Eigenschaften (Zahlenwerte oder Variablen) oder Methoden (Funktionen die man verwenden kann) ein solches Objekt oder eine solche Klasse hat. Es gibt viele solcher eingebauten Objekte oder Schnittstellen, die jeweils ihre entsprechenden Bestandteile zur Verfügung stellen. Zum Konfigurieren der seriellen Schnittstelle beispielsweise "uart".

Bitmanipulationen und Ausdrücke:
Man kann wie bei C oder Pascal beliebig lange Ausdrücke bauen und auch z.Bsp. das Schieben von Bits und Verknüpfungen direkt im Ausdruck vornehmen:

a = (a * b / c + (d << 2)) or 0b11101000

Das "d << 2" schiebt die Bits der variable "d" beispielsweise um zwei Bits nach Links.

Tabellen:
In Bascom kann man ja auf einen "Data-Bereich" mit setzen eines Zeigers zugreifen, in Luna ist das etwas eleganter, denn man fast hier z.Bsp. eine Tabelle in einem sogenannten Objekt zusammen, dem man dann einen Namen vergibt:

data meineTabelle
  .dw 0xa1b2
  .db "hallo ich bin ein Text",0
enddata

Wenn man dann darauf zugreifen will kann man das mit den praktischen Objektfunktionen von einem solchen Datenobjekt vornehmen:

print "Größe der Tabelle in Bytes: ";str(meineTabelle.SizeOf)
print meineTabelle.CString(2)
print str(meineTabelle.WordValue(0))

So das war erstmal ein kleiner Einblick von meiner Seite. Mein Fazit hierzu ist, dass es sich durchaus lohnt sich damit auseinanderzusetzen und einen Blick zu wagen. Wenn man einmal verstanden hat wie es funktioniert (so wie ich), dann will man irgendwie nicht mehr davon weg.

Gruß vom Harry

 

[Cassio]

Hallo Harry!

Schönen Dank, für deine ersten Zeilen zur Hochsprache LUNA.

Einiges hatte ich zwar schon in der recht umfangreichen PDF-Doku gelesen, aber trotzdem finde ich den Auftakt sehr gelungen.


Lobenswert finde ich auch diese Aussage von dir:

Dieses Thema soll keinen Sprachenkrieg anzetteln,.....

Dann solltest du diese subjektiven Eindrücke, Kommentare, oder persönliche Meinungen dazu aber auch unterlassen!

......im Vergleich wirkt die Bascom-IDE auf mich wie ein Notepad mit farbigen Buchstaben.

Wie dem aber auch sei....
Ich werde beim Thema LUNA jedenfalls mit am Ball bleiben,
auch wenn ich erst mal mit BASCOM weiter arbeite.


Grüße,
Cassio

 

[harryk]

Hallo Cassio,

ich bin hier als Anwender recht unvoreingenommen herangegangen, da passiert es manchmal das persönliche Eindrücke einfließen. Das kennst du sicher selbst. Es war natürlich nicht meine Absicht jemandem auf den Schlips zu treten, entschuldige. Ich hätte zum Artikel noch mehr schreiben können, jedoch lässt meine Konzentration nach einer gewissen Zeit nach.

Gruß vom Harry

 

[Cassio]

Hallo Harry!

Es war ja auch nur zur Vorsicht, damit hier nicht doch ein "Für und Wieder" der Programmiersprachen losgebrochen wird.


Ich finde ein unschlagbar genialer Pluspunkt für LUNA ist die Möglichkeit der freien Betriebssystemwahl.
Momentan habe ich mir nur erst mal die Windows-Variante geladen, um es parallel mit BASCOM laufen lassen zu können.
Da ich aber seit geraumer Zeit schon wieder nach meinem geliebten Linux schiele, wäre LUNA für mich das perfekte Entwicklungstool.

Na mal sehen....
ich muss nur mal etwas Zeit finden und dann erste kleine Testprogramme schreiben.
Vielleicht etwas mit Bitmanipulation, serielle Verbindung und dann noch LCD.
Wie es aber mit GLCD`s aussieht weiß ich noch nicht. Irgendwie habe ich dazu noch nicht mal Beispiele gefunden.


Grüße,
Cassio

 

[harryk]

Die freie Wahl des Betriebssystems war auch bei mir ein tragender Grund. Wie ich schon schrieb nutze ich mehrere PCs, jeweils mit Linux und Windows. Mit grafischen Displays habe ich außer ein paar Tests selbst weniger gemacht, aber hier ist die Unterstützung schon recht umfangreich. Schau mal bei den Beispiel-Sourcen unter "dogm-Grafikklasse". Im Video wird etwas gesagt von 23 fps bei Echtzeitzeichnungen auf das Display, bei meinen eigenen Versuchen war das sogar noch schneller. Das beiliegende Demo lief bei mir mit ca. 37 fps, womöglich weil der Compiler seit der damaligen Vorstellung verbessert wurde. Die IDE bietet dafür einen Font-Editor mit dem man dann eigene Fonts bearbeiten/erstellen kann. Ansonsten kann man mit der Klasse frei auf dem Display zeichnen.

Bei den Beispielen ist auch ein Webserver der mehrere Verbindungen gleichzeitig und auch mehrere Dienste gleichzeitig verwalten kann, das ist schon recht überzeugend was die Funktionsfähigkeit betrifft. Ich muss mir mal das Pollin-Net-IO-Board kommen lassen, das wollte ich auch noch mal probieren.

Gruß, Harry

 

[Pirx]

Hallo Harry,

Luna ... hmm ... nicht uninteressant. Danke für die Einführung.

Strukturell erinnert mich das sehr an Excel-VBA, mit dem ich beruflich viel unterwegs bin. Hier macht es die enorme Menge an Objekten gelegentlich sehr schwer, das gewünschte ausfindig zu machen und gerät die sonst sehr schön strukturierte Art der Programmierung mitunter zum Problem. Aber ich vermute mal, dass sich das bei Luna in Grenzen hält, denn soviel steckt in einem AVR ja nicht drin.

Gruß
Pirx

 

[Cassio]

Hallo zusammen!

Das DOGM-Beispiel habe ich auch gesehen, aber sonst irgendwie nichts für GLCD`s.
Nicht mal für den KS0108 oder dem T6963.
Da wird man wohl noch selber Hand anlegen müssen, um eine Class zu schreiben.

Ansonsten ist aber alles wichtige für mich dabei.....
I2C/TWI, 1Wire, Hard-SPI und Soft-SPI.

Ich muss wohl wirklich mal anfangen und einfach etwas schreiben.
Dann komme ich vermutlich auch schneller hinter die "Eigenarten" der Sprache.
Momentan "kämpfe" ich in den Beispielen noch mit den Anweisungen.
Auf den ersten Blick ist manchmal nicht ersichtlich ob es sich um Standardanweisungen von LUNA handelt, oder ob etwas durch eine Class hinzugeladen wird.
Das macht das Ganze aber gleichzeitig auch spannend und interessant.
Es wirkt daher sehr flexibel und was es nicht gibt, kann man über eine Class hinzufügen.


Was ich allerdings noch nicht gefunden habe ist ein Tool zum Einstellen der FUSES am AVR und einen kleinen Simulator.


Grüße,
Cassio

 

[dino03]

Hallo Harry,

das mit der Betriebssystemunabhängigkeit ist echt interessant da ich wohl Win7, ... nicht mitmachen werde. Es wird bei mir beim WinXP bleiben und ich werde wohl wieder (wie schonmal vor einigen Jahren) auf die Linux-Schiene schwenken.

Die objektorientierten Zeilen erinnern mich doch ein wenig an Java p o Graus ). Aber die Sprache ist dadurch natürlich gut erweiterbar.

Das Hauptproblem das ich mit Bascom habe ist eigentlich der aufgeblähte Code. In Assembler habe ich Code der bei gleicher Funktionalität bei 25-50% der Größe liegt. Das ist mir schmerzlich bei zwei Projekten aufgefallen. Bei einem Tiny2313 hat man zB nicht wirklich viel Luft.

Zur IDE: Syntax Highlighting hat man bei Bascom ja auch. Was micht ein wenig nervt ist die automatische Anordnung der Kommentare hinter einer Befehlszeile. Das sieht oft nach ziemlichem Zickzack und etwas zerrissen aus. Es wird dadurch ein wenig unübersichtlich und unstrukturiert. Automatische Einrückung kenne ich bereits von anderen Sprachen. Da sieht man dann sofort was innerhalb einer Bedingung oder Schleife liegt.

Zu den Sprachen ... es ist viel mit Gefühl verbunden welche Sprache man lieber verwendet. Bei Assembler schätze ich die Einfachheit und direkte Zugriffsmöglichkeit auf die Hardware. Man erhält sehr schnellen und kompakten Code. Bei Bascom hat man dafür sehr einfach zu erlernende Befehle und Abläufe. Die IDE in Bascom ist auch sehr einfach gehalten was auch Anfängern sehr entgegenkommt. Wenn ich das mit Eclipse bei Java vergleiche ist das ein riesiger Unterschied. Bei Eclipse benötigt man schon ne ganze Zeit um nur mit der IDE warm zu werden.

Auf jeden Fall erstmal besten Dank für deinen Erfahrungsbericht zu Luna.

Gruß
Dino

 

[harryk]

Hallo Cassio, Dino,

Hallo zusammen!]
Das DOGM-Beispiel habe ich auch gesehen, aber sonst irgendwie nichts für GLCD`s.
Nicht mal für den KS0108 oder dem T6963.
Da wird man wohl noch selber Hand anlegen müssen, um eine Class zu schreiben.

Die Entwickler sind da nach meiner Erfahrung aufgeschlossen. Wenn ich eine Frage hatte wurde mir immer geholfen. Bei einfachen Sachen soll man aber lieber im Forum nachhaken. Was solche Hardware betrifft kann mir auch vorstellen, das eine Nachfrage zur Implementierung erfolg hat, wenn man die Hardware sponsort. Also z.Bsp. mit einem KS0108/HD61202 Display. Aber die Ansteuerung ist ja nicht wirklich schwierig und man kann beispielsweise die vorhandenen Tools zur Font und Grafikbearbeitung mit verwenden. Das Portieren von C-Quelltexten ist übrigens recht einfach durch die mächtigen Fähigkeiten. Ich stehe zwar mit der C-Syntax auf Kriegsfuß, verstehe aber durchaus größtenteils den Code und für C gibt es ja wirklich umfangreiche Sourcen.

Das Hauptproblem das ich mit Bascom habe ist eigentlich der aufgeblähte Code. In Assembler habe ich Code der bei gleicher Funktionalität bei 25-50% der Größe liegt. Das ist mir schmerzlich bei zwei Projekten aufgefallen. Bei einem Tiny2313 hat man zB nicht wirklich viel Luft.

Also einen Tiny13, Tiny25 o.Ä. programmiere ich z.Bsp. nicht mit einer Hochsprache. Die sind dafür einfach zu spartanisch ausgerüstet. Bei einer Hochsprache hat man immer einen größeren Overhead. Auch muss man wissen welche Befehle man verwenden kann. Manche Funktionen blähen den Code stark auf, z.Bsp. Fließkommaberechnung oder Stringfunktionen. Beim RFID-Beispiel mit LCD finde ich ist das ganz geschickt gelöst. Die LCD-Funktionen besitzen Ausgabemöglichkeiten für Texte die nur als Konstanten, wie z.Bsp. "hallo", geschrieben sind und auch Zahlenwerte/Hex, ohne dass man mit Strings hantieren muss. So reichen die Ressourcen des tiny2313 dicke aus und es ist sogar noch Platz für weiteren Code. Ansonsten stimme ich dir zu, Assembler ist dabei die bessere Wahl.

Ich habe aktuell mal nachgefragt, was so an Neuerungen für eine nächste Version zu erwarten ist:

- GUI fürs setzen der Fusebits usw.
- Build-in Hexeditor
- Der ValueConverter ist mit eingebaut
- Datenobjekte kann man optional fest an bestimmte Adressen setzen

Ob ein Simulator in Luna implementiert wird konnte ich nicht herausfinden,hat mir persönlich jetzt aber nicht gefehlt. Die Projekte sind viel zu unterschiedlich und die Hardware die man am Controller betreibt ist zumeist nicht simulierbar. Da man sich den erzeugten Assemblercode anschauen kann, fehlt mir da erstmal nichts.

Bascom ist auch sehr einfach gehalten was auch Anfängern sehr entgegenkommt.

Ja das sehe ich auch so. Leute die kleinere Ansprüche haben können hier nicht viel falsch machen, die erlaubten Ausdrücke die man schreiben kann sind recht simpel und es gibt auch nicht solche Konstrukte wie Klassen, Strukturen oder Objektfunktionen. Das ist zum Verständnis für für Anfänger und einfachere Programmierer wesentlich besser geeignet. Luna ist da wohl für Programmierer die einen sprachlich höheren Anspruch haben. Ich finde es jedenfalls prima das es solche Leute gibt die uns gute Werkzeuge zur Verfügung stellen und wir die Wahl haben!

Gruß vom Harry und angenehme Feiertage!

 

[TommyB]

*push* (ganz ohne pop )

Jupp, der Thread ist was älter.
Ich hab jetzt so langsam auch mal angefangen mich in LunaAVR einzuarbeiten.

Ich erinner mich noch an die Bascom IDE (zugegeben eine ältere Version). Verglichen mit dem Visual Studio womit ich sonst arbeite (und auch das Atmel Studio drauf aufbaut) war das für mich immer etwas wie gewollt und nicht gekonnt. Die Oberfläche von LunaAVR gefällt mir sehr gut. Auch wenn es erstmal etwas ungewohnt ist dass der Tabulator nur n Leerzeichen erstellt...
Was mir auch noch fehlt wäre wenn man mit mehreren Dateien arbeitet (hab ich in Assembler häufig gemacht) auf eben diese schnell zuzugreifen. Wie im VS:

Sehr schön ist auch dass man, wie im VS auch, den Code ein- und aufklappen kann. Das konnte die Bascom Version die ich früher genutzt hatte nicht.

Von der Sprache ist es wirklich ein bisschen Pascal, ein bisschen Basic (Bascom). Da ich ASM und VB.Net gewöhnt bin finde ich mich da recht schnell zurecht. Auch wenn Dinos (entschuldige das Wortspiel ;P) damit etwas Probleme haben finde ich es super dass man mit Klassen arbeiten kann. Das macht vieles leichter, grade wenn man "Treiber" braucht, beispielsweise für LCD Module die eben nicht über 4bit angesteuert werden sondern via SPI. Man hat halt nicht einfach 100 Blätter auf dem Schreibtisch und muss sich so zurecht finden sondern man bekommt Ordner gestellt

Schade ist nur dass (selbstverständlich) debugWire nicht unterstützt wird (außer zum Flashen scheinbar) und dass es generell keinen Simulator gibt. Aber was solls, Kleinfieh kann man ja auch in Bascom simulieren. Oder (das hab ich aber noch nicht getestet) in der .s Datei sollte der vollständige Quelltext (in ASM) drin liegen sobald man das Projekt kompiliert hat. Das sollte man ja im Atmel Studio laden können und damit machen was man will. Augenscheinlich ist das auch gut kommentiert (Luna Quelltext als Kommentar über den Befehlen).

So viel zu meinem ersten Eindruck
Es hat definitiv Potential und ist einen Blick wert. Genaueres kann ich aber erst sagen wenn mein erstes Projekt damit fertig ist

 

[TommyB]

So der zweite Eindruck ist da

Ich habe jetzt etwas mit LunaAVR gearbeitet und es hat sich einiges gezeigt.
Damit hab ich mein Projekt Mini Labor-(Schalt-)Netzteil realisiert und jetzt in der Mache ist LiIO / LiPO Kapazität messen.

Die Sprache gefällt mir sehr gut (und das obwohl ich immer noch fälschlicherweise Sub statt Procedure schreib, Macht der Gewohnheit), die IDE im großen und ganzen auch, auch wenn sie ein paar kleine Schönheitsfehler hat (Cursorposition ändert sich teilweise beim Zeilenwechsel), aber die Vorteile überwiegen.

Aber man sollte schon Assemblerkenntnisse haben. Leider gibt es hier und da in den Libraries (ADC, LCD, ...) Probleme. So musste ich, da ich ein 16x2 OLED statt ein LCD verwende mir eine eigene Library dafür schreiben (eher die existierende LCD4 kopieren und umprogrammieren) da die Initialisierung etwas anders ist. Displays über SPI werden scheinbar noch garnicht unterstützt. Natürlich sind die trotzdem brauchbar, man muss nur alles selber machen. Wenn man jetzt einen "exotischen" Chip hat wie den Tiny861 denn ist man mit der ADC Klasse gekniffen, die ist für den zugegebenermaßen etwas speziellen Chip kaum brauchbar, da muss man denn schon direkt auf die Register zugreifen. Das AVRdude was zum Flashen verwendet wird mag mich auch nicht so wirklich. So im Durchschnitt jedes 5. Mal flashen schlägt fehl (hängt fest).

Was wirklich grausam ist ist die Dokumentation. Dort besteht ein gewaltiges Optimierungspotential. Die englischen Seiten sind teilweise deutsch und manche Seiten sind veraltet und dessen Codebeispiele auf neuen Versionen von Luna garnicht mehr lauffähig; man muss also selber in die Library schaun wie der was erwartet.

Die Community ist überwiegend freundlich und hilfsbereit. Ich hab dort bisher nur einen "RTFM"-Schreiber erlebt. (was ja irgendwie lustig ist. Ich soll also das f***ing manual lesen. Ja das hab ich vor dem Post auch getan. Und hab noch weniger verstanden als davor...)


Also schlussendlich: Trotz diverser Unstimmigkeiten ist es definitiv angenehm damit zu arbeiten, werde ich bei größeren Projekten auch weiterhin machen.

 

[Grandpa]

Hallo Thomas,

hab mich auch für LunaAVR entschieden und grad installiert. Der AVRISPMKII war auch sofort im Linux und als zu verwendender Programmer im Luna erkannt. Nur - wie es scheint, zickt Avrdude rum, siehe Anhang. Im Luna-Forum hat sich noch niemand dazu geäußert. Hast Du vielleicht eine Idee dazu? usblib ist auch installiert. Ein Linux- Spezialist bin ich aber immer noch nicht...

Gruß,
Michael

 

[TommyB]

Puh, da muss ich leider passen. Den MKII habe ich nicht, ich bleibe noch meinem Drachen treu. Und Linux läuft bei mir nur zwangsweise in einer VM, meine Kenntnisse darin sind so ungefähr = 0.

Aber es gibt hier ja noch andere Linuxer. @dino03 war glaub ich auch einer.
Für mich als Laien sieht es so aus alsob das Ziel falsch ist. Windows war es meine ich egal, da kann man so usb angeben, unter Linux / MacOS war das glaub ich irgendwas mit /dev/???. Aber das ist jetzt nur eine Vermutung.

Edit: Schuss ins Blaue: http://stackoverflow.com/questions/5412727/avrisp-mkii-doesnt-work-with-avrdude-on-linux

 

[Grandpa]

Ok, danke...das probier ich mal.

Und sonst? LunaAVR ist ja noch top bei Dir...Ich hab die aktuelle 2016.r1.

Klingt alles vielversprechend; besonders die Parameterübergabe/ Rückgabe. Ich lass mich überraschen.
Wenn ich gar nicht klarkomme, bau ich mir nochmal einen rechner mit LPT- Port undf verqwende meinen Selbstbau- Progger, der bis jetzt viele Jahre gut funktioniert hat.
Nur hat die neue, schnelle Kiste keinen LPT- Port. Aber wenigstens kann ich noch einen Com- Port On . Board über einen Blech- Anschluß rausführen...

 

[TommyB]

Ich selbst nutze entweder ASM für kleinere Projekte, oder eben Luna für größere, vor allem wenn es dann auch noch um Fließkomma Operationen geht was die AVR's ja nicht können (hardwareseitig). Aber in letzter Zeit hab ich kaum mehr was mit den kleinen Käfern gemacht, weil wegen Zeitmangel.

 

[Grandpa]

Ja, das Zeit- Problem...Das muß ich auch irgendwie regeln...

Übrigens - dank Deiner Hilfe bin ich einen Schritt weiter. Jetzt findet avrdude das USB- Gerät nicht, obwohl der Programmer ordentlich im System eingebunden ist; die grüne Led leuchtet auch...

Das bekomm ich aber hin. Morgen gehts weiter. Nochmals Danke und einen guten Rutsch.


Gruß,
Michael

 

[TommyB]

Wünsch ich dir auch

 

[dino03]

Hi,

die Gerätedateien findet man unter Linux im Verzeichnis /dev (Devices).
Die physikalischen seriellen sind sowas wie ttyS0 , ttyS1 , ...
die seriellen per USB sind dann sowas wie usbttyS0 , usbttys1 , ...
Eigentlich erklären sich die Namen relativ von alleine. Zum Beispiel "random", "video0", "rtc0", ...
Es gilt aber wie in anderen Verzeichnis unter Linux ... die Zugriffsrechte müssen passen.
Sonst wird man die Datei (das Gerät) nicht ansprechen können.
Bei Linux ist alles eine Datei. Egal ob es Hardware, Speicherbereiche, Programme, ... ist.

Gruß
Dino

 

[Grandpa]

Ich hab's...Den Ordner rules.d habe ich um die Datei für den Programmer erweitert; die Rechte waren eh schon gesetzt.
jetzt sagt mir avrdude, "Mosi und SCK failed". Da habe ich wohl irgendwo einen Kabelbruch...Ist aber merkwürdig, da ich bisher mit dem LPT- Programmer mit BASCOM keine Schwierigkeiten hatte.

Ok - dieses Jahr nicht mehr...

Dann mal alles Gute!

 

[Grandpa]

Frohes Neues - Allet is' juut... Ein ATmega8 war defekt und der Zweite war nicht richtig gesteckt.

Also - auf zur ersten Mondlandung...