Wenn man "make clean" macht, kann es zudem passieren, daß das .dep-File
verschwindet und WinAVR dann deshalb rummeckert.
Kapier ich nich.
Der alte WinAVR-20100110 ist auf Version 4.8.0 geupdated und ist
normalerweise ganz friedlich und brav. Nur, wenn man über ein
Netzlaufwerk Dateien kompiliert oder Win10 ein Update macht, kann es
passieren, daß o.a. Fehler auftauchen.
Man kann sie manchmal beheben, indem man die msys-1.0.dll (im
Verzeichnis von WinAVR-20100110/utils/bin)gegen eine andere Version
tauscht. Das ist von früher bekannt.
Ich habe zwei Versionen (im Anhang, die mit msys-1.0y.dll funktioniert
derzeit nicht, aber je nach Laune halt doch). Tritt der Fehler auf,
tausche ich diese dll gegen die jeweils andere, starte den Rechner neu
und meistens klappt es so. Manchmal reicht das aber nicht, und man muß
WinAVR deinstallieren und neu installieren.
Ich wäre nicht so genervt, wenn es in letzter Zeit nicht häufiger
aufgetreten wäre. Weiß das Forum, wie man das ultimativ lösen kann?
Und ich meine damit, ohne die Software gegen eine neuere/andere zu
tauschen :)
Jürgen S. schrieb:> Und ich meine damit, ohne die Software gegen eine neuere/andere zu> tauschen :)
Je nun, wer leiden will, muß leiden.
Was genau brauchst du denn aus dem Steinzeit-Paket WinAVR, daß du nicht
darauf verzichten kannst? Den Compiler hast du ja anscheinend schon
geupdated.
Oliver
Ich muß ja zum Glück auf gar nichts verzichten, wenn ich den WinAVR
nehme. Eigentlich wollte ich es geheim halten, aber der erzeugt aus
C-Code ein Hexfile, das man in den AVR flashen kann. Und dann rennt der
AVR los. Wie durch Zauberhand. Mehr braucht ich nicht.
Es wird nur dann nervig, wenn die o.a. Probleme auftauchen.
Jeder, wie er will. WinAVR besteht aus notepad++, der toolchain, make,
und einem einzigen kleinen Plugin für notepad, das das für dich
unverständliche „Zauberwunder“ auf Knopfdruck startet.
Dazu noch mfile, um makefiles zu erstellen.
Als das gibt es auch als aktuelle Versionen, du musst es nur einmal
verstehen.
Oliver
> Als das gibt es auch als aktuelle Versionen, du musst es nur einmal> verstehen.
Ok. Immerhin versuchst Du einem nicht Eclipse, Arduino, Platformio,
Visual- oder AtmelStudio unterzujubeln.
Ich schau mir mal Zaks avr-gcc an. Es gibt da ein paar Foldernamen, die
auch in WinAVR auftauchen, z.B. libexec,share,avr etc.. Wie durch
Zauberhand sind die ähnlich ;)
Bei Zak fehlt vermutlich noch mfile, und ein Editor, und und und. Aber
vielleicht wurschtel ich mir das zusammen.
(Für die AVRs will ich nicht mehr groß umlernen, der WinAVR hat mir
immer gut gefallen und für die kleinen Sachen, die man mit dem AVR in
nativem C macht, taugt er noch immer).
Mal zur Info: Tatsächlich habe ich jetzt erstmal
MS Visual Code installiert und der gcc4.8.0 läuft nach Einrichten der
Tasks wie im guten alten Notepad mit den 2 Optionen 'Make all' und
'Make Clean' (Programmieren erledige ich nach wie vor über AVR Studio).
Aber das ist schon cool, man kann jetzt fast wie in Coocox schnell zu
Prozeduren springen und z.B. feststellen, wo die überall verwendet
werden.
Nur ein bißchen bunt ist die Sache, der schwarze Hintergrund
gewöhnungsbedürftig und automatisch formatieren/einrücken der C-Texte
geht wohl nicht oder ich habe es noch nicht gefunden.
Mit diesem Video ging es ganz einfach
https://www.youtube.com/watch?v=LE7-uzhlGVM&feature=emb_logo
Allerdings weiß ich nicht, ob damit das ursprüngliche
msys-1.0.dll-Problem gelöst ist - eher nicht, weil ja das gleiche
avrgcc.exe verwendet wird...
Jürgen S. schrieb:> MS Visual Code installiert und der gcc4.8.0 läuft nach Einrichten der> Tasks wie im guten alten Notepad mit den 2 Optionen 'Make all' und> 'Make Clean' (Programmieren erledige ich nach wie vor über AVR Studio).
Warum startest Du die Builds aus Notepad++ (bzw. jetzt VS Code), wenn Du
ansonsten mit AVR Studio arbeitest?
Jürgen S. schrieb:> Ok. Immerhin versuchst Du einem nicht Eclipse, Arduino, Platformio,> Visual- oder AtmelStudio unterzujubeln.Jürgen S. schrieb:> Aber das ist schon cool, man kann jetzt fast wie in Coocox schnell zu> Prozeduren springen und z.B. feststellen, wo die überall verwendet> werden.
Irgendwann kommt halt doch jeder dahinter, daß ein anständiger Editor
oder auch eine IDE einfach unverzichtbar ist.
Oliver
Hmmm schrieb:> Warum startest Du die Builds aus Notepad++ (bzw. jetzt VS Code), wenn Du> ansonsten mit AVR Studio arbeitest?AVR Studio 4.19 Build 730 bietet nicht wirklich große Extras ;)
Ich habe mal 6 und 7 probiert, gefällt mir aber nicht, außerdem sind die
teils auch buggy.
VS Code scheint schlank zu sein, das ist ein Vorteil - allerdings
befürchte ich, daß das msys-1.0.dll-Problem auch da wieder auftaucht.
Oliver S. schrieb:> Irgendwann kommt halt doch jeder dahinter, daß ein anständiger Editor> oder auch eine IDE einfach unverzichtbar ist.
Für die kleinen AVR-Sachen braucht man das nicht wirklich. Mit Coocox
arbeite ich seit 2014 und hatte trotzdem beim AVR bisher nicht das
Bedürfnis, auf Eclipse umzusteigen.
Außerdem löst das Verwenden von VS Code wahrscheinlich nicht das
msys-1.0.dll-Gezicke.
Jürgen S. schrieb:> AVR Studio 4.19 Build 730 bietet nicht wirklich große Extras ;)
Ach, Missverständnis. Ich war beim Wort "Programmieren" vom
Code-Schreiben ausgegangen, während Du das Flashen meintest.
Jürgen S. schrieb:> VS Code scheint schlank zu sein
Das täuscht. VS Code basiert auf Electron, im Endeffekt ist das
JavaScript-Code, der auf einer Chromium-Engine läuft.
Jürgen S. schrieb:> Mit Coocox> arbeite ich seit 2014 und hatte trotzdem beim AVR bisher nicht das> Bedürfnis, auf Eclipse umzusteigen.
Alles mit derselben IDE zu machen, hat den Vorteil, dass Du Dich nicht
immer wieder an wechselnde Shortcuts und andere Unterschiede gewöhnen
musst.
Aber das ist Geschmackssache, für Kleinkram reicht auch oft ein nackter
vi.
Hmmm schrieb:> Ach, Missverständnis. Ich war beim Wort "Programmieren" vom> Code-Schreiben ausgegangen, während Du das Flashen meintest.
Ja, mein Fehler.
> Alles mit derselben IDE zu machen, hat den Vorteil, dass Du Dich nicht> immer wieder an wechselnde Shortcuts und andere Unterschiede gewöhnen> musst.
Der Aspekt hat schon was für sich.
Ich wäre auch nicht so zickig, wenn ich nicht beim Versuch, von Coocox
auf AC6 umzusteigen, totalfrustriert geworden wäre. Ein Blinky hatte
funktioniert, aber als ich dann testweise das target wechseln wollte,
brach die Hölle los. Als Bestrafung wurde AC6 sofort wieder
deinstalliert, aber die Schmach sitzt noch tief.
Wann kapieren die IDE-Hersteller endlich, daß sie exakt eine Setup.exe
herstellen sollen, auf die man draufklickt, dann "AVR","STM32" oder "PC"
eingibt und es läuft einfach. Beim WinAVR hat das doch auch so
funktioniert (g).
Jürgen S. schrieb:> Wann kapieren die IDE-Hersteller endlich, daß sie exakt eine Setup.exe> herstellen sollen, auf die man draufklickt, dann "AVR","STM32" oder "PC"> eingibt und es läuft einfach. Beim WinAVR hat das doch auch so> funktioniert (g).
Es dürfte schwierig sein, eine IDE zu entwickeln, die von Haus aus alles
abdeckt, was Entwickler brauchen könnten. Du nennst drei gängige
Plattformen, der nächste vermisst vielleicht den Amiga-Cross-Compiler.
Also sind IDEs eher eine Grundlage, die Du einmalig an Deine Bedürfnisse
anpassen musst. Das ist zwar erstmal Aufwand, aber dafür hast Du danach
genau die Umgebung, die Du brauchst.
Meistens ist der Umzug auf eine neue IDE auch kein Drama. Wenn etwas
trotz gleicher Toolchain nicht funktioniert, einfach die Build-Logs
vergleichen.
Hmmm schrieb:> Es dürfte schwierig sein, eine IDE zu entwickeln, die von Haus aus alles> abdeckt, was Entwickler brauchen könnten. Du nennst drei gängige> Plattformen, der nächste vermisst vielleicht den Amiga-Cross-Compiler.
Schon klar, das war ein bißchen selbstironisches Gejammer von mir.
Inziwschen habe ich nochmal Eclipse für c/c++-Developer installiert,
dazu das AVR-Plugin. Und bin kurz vorm Speihen. Die Fehlertoleranz bei
der IDE ist minimal; wenn man ein Projekt angelegt hat, kann man die
Einzelheiten kaum rückgängig machen. Oder man löscht das Projekt, dann
verschwinden auch die main.c und alles Andere. Na toll.
Außerdem gelingt es zwar, ein Projekt in dem Ordner, in dem die main.c
liegt, anzulegen und zu kompilieren (mit makefile). Aber was trotz
1h(!)Suche nicht gelingt, ist, die Dateien aus meiner AVR Library als
Source- und Incudefiles in das Projekt aufzunehmen. D.h.. ich kann die
nur aufrufen, indem ich auf den Includepfad einer anderen Datei klicke,
in dem diese Datei eingebunden wird.
Dazu kommen ungefähr 95% aller Buttons, Menüeinträge und Kontextmenüs
beziehen sich auf Zeug, das ich nicht brauche bzw. was vielleicht für
Profis relevant ist, aber unglaublich viel Zeit kostet, um es als
'unbedeutend für meine Zwecke' einzustufen.
Die ganze Logik von dem Eclipse-Zeug ist mit meiner Denke nicht
kompatibel.
Wenn es als Paket funktioniert wie z.B. in Coocox, ist es sehr hilfreich
und gut, man gewöhnt sich dran und hat keine gravierend falschen
Einstellungen drin, die alle Bemühungen verhunzen.
Es sollte für verschiedene Platformen Templates geben, die einem die
Mühe erleichtern.
Genug geklagt :). Ich werde mal ein Project mit Eclipse anlegen, dann
über Netzlaufwerk kompilieren und sehen, ob es wieder ein Problem mit
der msys-1.0.dll gibt. Wenn nicht, kriegt die IDE noch ein zweite
Chance.
Bin am Ende :)
Zwar habe ich es zwecks Übung und Einarbeitung bei Eclipse + AVR-Plugin
geschafft, ein Projekt, das als 'New C-Projekt' angelegt war,
zurückzuhampeln auf ein 'Makefile-Projekt', und das funktioniert auch
mit clean und make so, wie es soll. Das gibt Zuversicht.
Allerdings stimmt was mit den defines für die AVR-CPU nicht. Soweit ich
weiß, ist z.B. _AVR_ATmega324P__ oder __AVR_ATmega168P_ im avr-gcc
hinterlegt.
Compilieren tut es auch richtig, also wenn ich im makefile 'atmega324p'
oder 'atmega168p' wähle, compiliert es auch für den entsprechenden
Prozessor.
Aber Eclipse erkennt die CPU symbolisch im Editor nicht. Das ist
verwirrend.
Ich habe im Anhang das Problem gezeigt. Im makefile ist ein atmega324p
ausgewählt, er compiliert auch dafür, aber im Editor ist der falsche
Zweig grau unterlegt
Kurz und bündig die Frage:
#if defined(_AVR_ATmega324P_)||defined(_AVR_ATmega324PA_) ist
richtig erkannt fürs compilieren, aber der Editor zeigt falsch an.
Woran kann das liegen?
Edit: Die <avr/io.h> ist eingebunden, das sieht man nicht auf dem
Ausschnitt. Auch dort ist bei
#elif defined (_AVR_ATmega324P_) || defined (_AVR_ATmega324A_)
# include <avr/iom324.h>
das include grau unterlegt.
Jürgen S. schrieb:> Ich habe im Anhang das Problem gezeigt. Im makefile ist ein atmega324p> ausgewählt, er compiliert auch dafür, aber im Editor ist der falsche> Zweig grau unterlegt
Damit das funktioniert, müsste Eclipse das Makefile parsen können.
Vermutlich kannst Du irgendwo in Eclipse eigene Variablen definieren und
(z.B. per Environment) an make übergeben, um sie nicht immer an zwei
Stellen ändern zu müssen.
Hmmm schrieb:> Damit das funktioniert, müsste Eclipse das Makefile parsen können.
Logisch. Da habe ich tatsächlich den Baum vor lauter Wäldern nicht
gesehen. Bei Coocox mußte ich da für den F429 auch extra einrichten.
Ach herrjeh. Und ich hatte gehofft, das mit dem Präprozessorzeug geht
ganz von selbst.
Wieviel kann ein Mann ertragen, wenn er das auch noch berücksichtigen
muß ... jammer und zeter...dabei war die IDE ja sooo teuer :)
Hmmm schrieb:> Damit das funktioniert, müsste Eclipse das Makefile parsen können.
Es funktioniert tatsächlich anders. Die _AVR_ATmegaXXXP_ Definitionen
liest Eclipse über ein *.xml-File ein und kennt sie auch.
> Vermutlich kannst Du irgendwo in Eclipse eigene Variablen definieren und> (z.B. per Environment) an make übergeben, um sie nicht immer an zwei> Stellen ändern zu müssen.
Habe ich versucht und z.B. MCU und F_CPU vom makefile in entsprechend
benannte Environmentvariablen in Eclipse verfrachtet. Hat auch
funktioniert (mit den kleingeschriebenen Definitionen -> MCU mit
Variable atmega324p z.B.). So habe ich das auch mal kennengelernt.
Und jetzt allerdings reicht's mir schon wieder mit der SCHEISSE. Der
Präprozessor funktioniert nämlich so wie gedacht, wenn man den
_AVR_ATmega16_ nimmt. Denn das ist der Defaulttyp, der in Eclipse AVR
eingestellt ist. Und das Ausgrauen funktioniert, wenn man dann auf einen
anderen AVR umstellt.
Ich bin wieder zurück auf das C-Projekt ohne vorgefertigtes makefile (so
wie es auch später mal sein soll, wenn man die IDE benutzt, ohne
zusätzlich im makefile rumpfuschen zu müssen), und habe festgestellt,
daß man diesen Defaulttyp nicht einfach ändern kann - das ist einer von
diesen bescheuerten Bugs. Kann man nachlesen, wenn man in
http://avr-eclipse.sourceforge.net/wiki/index.php/Known_Issues blättert.
Ich will aber für das Projekt mit 3 verschiedenen AVRs gleichzeitig
rumwurschteln, und habe dafür mehrere Boards.
3h habe ich mir mit dem Dreck jetzt um die Ohren gehauen, *.sc-files
gelöscht, Environment-Variablen von System-Build auf User:Config und
wieder zurückgestellt, und Zeit verdaddelt, um irgendwelchen doofen
Einstellungen auszuprobieren. Und bei jedem Build kommt
'../main.c:507:5: warning: 'PCINT1_vect' appears to be a misspelled
signal handler [enabled by default]'. Logisch, weil der Mega16 keinen
PCINT hat.
Wenn jemand eine IDE will, die exakt einen einzigen Prozessor - nämlich
den Mega16 - compilieren kann, dann empfehle ich diesen
AVR-Eclipsenquark gerne weiter. Was für ein blöder Käse.
Thread beobachten
Seitenaufteilung abschalten