CDK4AVR -- new AVR Cross Development Kit

Schöne deutsche Aroganz. Wer es nicht braucht der soll es auch nicht 
bekommen. Aus dem angelsächsischen Sprachraum habe ich für meine 
"freiwillige Arbeit" !!! nur Lob geerntet; und was ist die erste 
DEUTSCHE Antwort ? -- Beleidigung wegen Formfehler


Hurra Deutschland


Ach, für alle die jetzt denken sie müssten mir Antworten schicken -- 
Vergesst es einfach :-)

@Peter: Ich verstehe deine Kritik nicht so ganz. Du gibst in deinen 
Antworten doch oft auch Links zu deinen in englisch verfaßten Seiten.

> Und: Keine Antwort ist auch eine Antwort
Ich hab das eher als eine Bekanntmachung verstanden, denn als "Ich will 
jetzt wissen, was ihr dazu meint". Und für diesen Fall halte ich ein 
englisches Posting eigentlich noch ok. Für eine Diskussion auf Englisch 
wäre hier kein Platz?!

@Stephan: Wieso spielst du die beleidigte Leberwurst? Nur weil du nicht 
sofort Lob, wie von den "angelsächsischen" Kollegen geerntet hast? Nimm 
das doch lockerer, meist ist das doch alles garnicht so ernst gemeint.

Ansonsten: Interessantes Projekt, erstes Posting kein Angeber-Posting, 
informativ.

Schmittchen.

Sorry Leute -- bin nicht beleidigt, ehr erhaben. Ich erinnerte mich bei 
dieser Antwort nur an ein schon lange zurück liegendes posting von 
simplem Quellcode zum AVR-Ctrl, über den dann locker dahergezogen wurde. 
Allein eine solche Missachtung der Arbeit anderer hat man doch nicht 
verdient, oder?

Ich möchte nochmal alle dazu Aufrufen, CDK4AVR zu testen. Es sollte 
problemlos mit existierenden AVR Tool Chains zusammenarbeiten, da es 
selbst nur im Verzeichnis /opt/cdk4avr lebt. Voraussetzung dafür ist die 
richtige Reihenfolge der Suchpfade.


Sollte sich jemand mit dem Objektformat von AVR Studio auskennen, den 
bitte ich um Hilfe. Siehe Bugreport 639607:

http://sourceforge.net/tracker/?group_id=66481&atid=514651

Wenn wir schon mal dabei sind:

Das Englisch ist recht lausig. Da solltest Du mal dran arbeiten anstatt 
von deutscher Arroganz zu reden...
Wenn ich in einem deutschen Forum schon Englisch lesen soll, dann bitte 
auch richtiges. Da rollen sich einem ja die Fussnägel hoch...

@georg: warum regst du dich über anderer leute englisch auf. wenn er es 
halt nicht kann
wenn ich mein projekt woanders schon in "schlechtem"englisch woanders 
präsentioert habe, dann würde ich auch nur den ttext hier reinkopieren, 
ohne ihn nochmal zu übersetzten. wer zwingt dich denn dazu es zu lesen

ich hoffe, dass das teil gut läuft, da mein einziges
!"Achtung, nicht für Windows-Benutzer !"
windows x-windows ist.

Na prima! Wie ich sehe, hat sich seit meinem letzten Besuch in diesem 
Forum nicht viel verändert.

@Stephan

Mach Dir nichts draus, das ist halt die deutsche Oberlehrer-Mentalität. 
Ich hatte mit einigen Herren hier auch schon heftige Diskussionen, die 
meinen, nur wenn sie Mitglied in irgendwelchen selbsternannten 
"Expertenkreisen" sind, gelten ihre Meinungen hier als neue Gesetze.

Da kann man nichts machen.

Die Software dieses Forums scheint auch nur Mickysoft-kompatibel zu sein 
:-(

Hi Stephan,

Ich verstehe die Aufregung um eine allgemeine Information
ueber ein Stueck Software auch nicht so richtig. Gut, das
sich jemand Arbeit macht und das Ergebniss dann auch noch
der Allgemeinheit zur Verfuegung stellt. Weiter so. Alle,
die es aus welchen Gruenden auch immer nicht interessiert,
sollten einfach darueber hinweglesen.

Jens

@Jens & Notker

Schön, daß es noch Gleichgesinnte gibt. Ich bin überrascht, daß dieser 
Thread noch einmal zum Leben erweckt wurde.


@all

In den nächsten Tagen werde ich wieder aktuelle Pakete bei Sourceforge 
einspielen (binutils 2.13.2.1 + objcopy für coff-(ext)-avr, gcc 3.3 und 
einige weitere upgrades). Hierfür suche ich Testuser, speziell auch für 
die Interoperation mit anderen Linux Distributionen als das von mir 
benutzte Mandrake. Es scheint da Probleme zu geben :-(

Von einigen Leuten wurde ich zu Dokumentationen über CDK4AVR gefragt. 
Nun, leider fehlt mir dazu die Zeit und da es sich bei SF.net um eine 
internationale Platform handelt, sollte diese auch in Englisch 
geschrieben sein .... :-) Ich suche daher Mitstreiter für eine solche 
Aufgabe. Als wichtigster Punkt wäre da eine FAQ und ein INSTALL guide.

Wer also Lust verspürt --> bitte melden.


Stephan

@Andreas: kannst Du nicht eine MD5-Summe über den Beitrag gegen
die des vorherigen Beitrages vergleichen?  Damit solltest Du
doch die Doppelklicker (oder 5mal-Klicker) abfangen können.

@Stephan: bitte veröffentliche den derzeitigen Betatest für die
GNU binutils nicht ohne ausdrücklichen Hinweis, daß es sich um
einen solchen handelt (einschließlich meines READMEs).  Es gibt
mittlerweile wenigstens einen schwerwiegenden bekannten Bug darin
(der noch nicht im alten README erwähnt ist), daher möchte ich
ausdrücklich nicht, daß die derart gepatchten Binutils ohne
weitere Hinweise so in der Welt kursieren.

@Joerg

Danke für den Hinweis. Es wird sich um ein separates Paket handeln, das 
speziell für das Erstellen von COFF Objekten benutzt werden kann. Dem 
Paket liegt das bisherige "objtool" als auch ein gepatchtes avr-objcopy 
aus den Binutils bei. Letzteres werde ich avr-coff-objcopy benennen, um 
es vom regulären avr-objcopy zu unterscheiden. Das sprengt zwar die 
Namenskonvention, aber es sollte nur für kurze Zeit so bleiben. Früher 
oder später wird es Bestandteil der binutils.

Sowohl "objtool" als auch die BETA Version von "avr-coff-objcopy" sind 
bis jetzt noch nicht productiva. Daher werde ich das Paket als 
ABSOLUTLELY BETA kennzeichnen. Deine README ist ebenfalls enthalten.

Um was für einen Bug handelt es sich eigentlich. Wurde dieser in 
avr-gcc-list besprochen (ich habe lange nicht mehr darin gelesen, 
sorry). Schreibe mir doch bitte ein Kurzinfo an mich direkt -- Danke.


Stephan

Na ja, wenn es sowieso nur für die Erstellung von COFF gedacht
ist, dann ist es natürlich witzlose, das zu trennen.  Das war
mir jetzt nicht klar.

Hatte mich nur gewundert, daß jemand, der mir bislang nirgends
übern Weg gelaufen ist, einfach so ,,mein'' Beta irgendwo mit
ausspucken will.  Wenn es jedem Konsumenten klar ist, daß das
Beta ist (und wohin die Bugreports zu schicken sind), dann ist
das für mich OK.

Der Bug tritt beim Redefinieren von struct zutage, und nach
einer Konsultation mit Ian Lance Taylor (das ist der vom
Taylor-UUCP, wer es noch kennt und/oder gar noch benutzt), der
große Teile der Binutils geschrieben hat, weiß ich nun, daß ich
da einiges neu schreiben muß. :-(  Die Hitze der letzten Tage
war wenig angetan, eine solche Arbeit zu beginnen...

Ein typischer Fall ist, daß eine Include-Datei sowas enthält:

typedef struct foo foobar;
struct foo {
     foobar *next;
     ...
};

und dann von mehr als einer Quelldatei included wird.  Dabei
ist der typedef eigentlich eine forward declaration, wird
aber beim zweiten Mal nicht als solche erkannt (da es ja schon
eine bekannte struct foo gibt), so daß eine Referenz auf altes
Zeug drin stehenbleibt.  Wenn dann das Feld "next" umgesetzt
werden soll, wird auf Speicherbereiche zugegriffen, die bereits
gefree()t worden sind.

Workaround ist:

struct foo {
     struct foo *next;
     ...
};
typedef struct foo foobar;

Jörg> "... jemand, der mir bislang nirgends übern Weg
Jörg>  gelaufen ist ..."

Naja, meine Arbeiten an CDK4AVR sind ehr zufällig nebenbei in meiner 
Freizeit entstanden. Ich habe mit dem AVRCtrl Bord meine ersten und z.Z. 
leider einzigen Erfahrungen mit AVR's gesammelt. Ich baue an einer 
kleinen Bibliothek für dieses Board (KEYPAD, LED, LCD, OW, Temp.-, 
IR-Sensor). Da ich hierbei noch nie Probleme hatte, mußte ich auch nie 
jemanden hier oder bei avr-gcc-list fragen.

Bei den Arbeiten an der Bibliothek ist mir aufgefallen, daß es für 
Windows mit WinAVR eine fundierte Entwicklungsumgebung gibt. Für Linux 
gab es bis dato keine fertigen Install-Pakete -- auch für die 
Übersetzung benötigt man doch schon ein wenig mehr Wissen/Zeit. Auch 
heute exitieren nur Snapshots von binutils, gcc, und libc. Da ich 
ausschließlich unter Linux arbeite, wollte ich das mit CDK4AVR ändern. 
Im laufe des letzten Jahres habe ich nach und nach alle im Internet 
verfügbaren Entwicklungswerkzeuge für AVR unter Linux (Unix) gesammelt, 
angesehen, übersetzt und in CDK4AVR eingepflegt. Es soll ein Startpunkt 
für Entickler unter Linux sein.


Jörg> "... forward declaration ..."

Soetwas vermeide ich lieber besser. Daher habe ich mit diesem Bug keine 
Probleme gehabt. Momentan versuche ich mit meinem alten AVR Studio 3 
unter Linux/WINE ein erzeugtes COFF aus einer kurzen Assemblerquelle zu 
verarbeiten. Dabei stoße ich leider auf das Problem der verschiedenen 
Filenamen unter Windows und Linux, da ich unter Linux mit native tools 
assembliere und konvertiere (avr-as, avr-coff-objcopy) und unter WINE, 
also Windows, versuche das COFF zu laden. Die Referenz zum Quellfile ist 
dann nicht richtig.

Hat da jemand einen Lösungsansatz?


Stephan

Naja, die Snapshots sind schon die Installationspakete für
Linux.  Was anderes baust Du ja letztlich auch nicht (vom
coff-avr-patch bzw. objtool mal abgesehen).  Für FreeBSD pflege
ich die offiziellen Ports, so daß das auch soweit abgedeckt ist.

Zusätzlich zu den Snapshots sollte es wohl jeweils noch eine
Version der letzten stabilen Version dort geben, sofern das Sinn
hat.  Für avr-lib hat das derzeit keinen Sinn, für avr-gcc auch
erst, seitdem 3.3 offiziell raus ist.

AVR Studio 3 ist ein ziemliches Auslaufmodell.  Vor allem für
das Problem der fehlenden Initialisierung für .data wirst Du dort
keine Lösung mehr bekommen (während sie für AVR Studio 4 zumindest
in Atmels Quellen bereits existiert).  Siehe Beta-README (ganz
am Ende).

AVR Studio 4 läuft nicht unter Wine.  Abhilfe wäre VMLAB, aber
das kostet paar Euro (meiner Meinung nach aber gut investierte,
wenn man auf so eine Form von GUI-Werkzeugen steht).

Zum Konvertieren der Dateinamen gibt es die beiden Optionen
--change-pathname und --basename.  Die habe ich im README
nicht weiter dokumentiert, da ich die Win-User damit nicht
überfordern wollte :), die brauchen das eher sowieso nicht.
Für Unix/Wine dagegen sind sie hilfreich.  Die Doku in der
objcopy-Manpage dafür ist aktuell.  Mail mir, wenn Du damit
nicht klarkommst.

Da AS3 sich aber über jede noch so kleine Ungereimtheit komplett
erbricht, solltest Du wohl dasselbe tun, was auch WinAVR tut:
avr-strip -g auf alle .o und .a Dateien, die zur Bibliothek
gehören (libc.a, libgcc.a, libm.a, gcrt1.o, jeweils mehrere
Exemplare davon).  Das verhindert, daß die Pfadnamen aus den
Bibliotheken in den Debuginformationen auftauchen.
--change-pathname brauchst Du dann nur noch für Dein eigentliches
Projekt oder --basename, aber das ist beim Format coff-avr
ohnehin die einzige Möglichkeit, und für AS3 solltest Du auf
jeden Fall coff-avr benutzen.

Hmm, die Sache mit --change-pathname und --basename werde ich mir am WE 
mal ansehen. Das mit AS3 ist eine Spielerei vom letzten Jahr. Mich hat 
es einfach nur interessiert, ob dieses Win32 Programm wirklich unter 
WINE läuft -- daher existiert das Paket. Ich benutze AS3 nicht wirklich, 
und daß es bereits durch die besseren Merkmale von AS4 überholt ist tut 
sein übriges. Ich werde die Untersuchen zu AS3 wohl bald komplett 
einstellen und ehr versuchen, ob AS4 mitlerweile mit den letzten WINE 
Quellen zur Arbeit zu überreden ist.

Muß ich eigentlich auch für AS4 alle Bibliotheken und Objekte strippen? 
Ich denke ja, denn die Debuginformationen mit Referenzen zu den 
Quellfiles sind ja auch für AS4 unter WINE fehlerhaft.

Der Hinweis mit VMLAB ist für mich selber mal irgendwann von interesse, 
danke. In CDK4AVR sollen aber ausschließlich frei erhältliche und 
uneingeschränkt benutzbare Werkzeuge enthalten sein.


Stephan

AS4 ist mit Wine derzeit wohl nicht zum Laufen zu bekommen.
Man sagt, daß es mit win4lin lauffähig wäre, das kann ich aber
mangels Linux nicht testen (und win4lin bringt eigene Kerneltreiber
mit, die ich nicht auf die Schnell mal nach FreeBSD portiert
bekomme).  Da es außerdem Kommerzware ist, wird Dich das wohl
auch nicht weiter interessieren.

AS4 erbricht sich nicht über nicht auffindbare Quelldateien,
sonder erlaubt es wohl, deren Namen einzugeben (bzw. kann auch
so einfach weiterarbeiten -- VMLAB ebenso).

In CKD4AVR würde ich weder das eine noch das andere direkt
reinpacken.  AVR Studio darfst Du schließlich auch nur im
Komplettpaket weitergeben (,,uneingeschränkt benutzbar''?),
ich habe das unter Wine auch nie zum Installieren bekommen.