Forum: Compiler & IDEs Win10, WinAVR-20100110 und msys-1.0.dll


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jürgen S. (avus)


Angehängte Dateien:

Lesenswert?

Moin,
ein steinaltes Problem im WinAVR mit Notepad (pn.exe), das aber noch 
immer nervt, wenn es mal passiert, ist z.B. so eine Meldung
1
> "make.exe" all
2
      0 [main] sh 3008 sync_with_child: child 2712(0x1C0) died before initialization with status code 0xC0000142
3
  32812 [main] sh 3008 sync_with_child: *** child state waiting for longjmp
4
/usr/bin/sh: fork: Resource temporarily unavailable
5
      0 [main] sh 3324 sync_with_child: child 9844(0x1C0) died before initialization with status code 0xC0000142
6
  57216 [main] sh 3324 sync_with_child: *** child state waiting for longjmp
7
/usr/bin/sh: fork: Resource temporarily unavailable
8
9
-------- begin --------
10
avr-gcc (GCC) 4.8.0 20130306 (experimental)
11
Copyright (C) 2013 Free Software Foundation, Inc.
12
This is free software; see the source for copying conditions.  There is NO
13
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
14
15
16
Size before:
17
      0 [main] sh 10112 sync_with_child: child 964(0x1B8) died before initialization with status code 0xC0000142
18
  45667 [main] sh 10112 sync_with_child: *** child state waiting for longjmp
19
/usr/bin/sh: fork: Resource temporarily unavailable
20
make.exe: *** [sizebefore] Error 128
21
22
> Process Exit Code: 2
23
> Time Taken: 00:01

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 :)

von Oliver S. (oliverso)


Lesenswert?

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

von Jürgen S. (avus)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

: Bearbeitet durch User
von Jürgen S. (avus)


Lesenswert?

> 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).

von Jürgen S. (avus)


Lesenswert?

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...

von Hmmm (Gast)


Lesenswert?

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?

von Oliver S. (oliverso)


Lesenswert?

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

: Bearbeitet durch User
von Jürgen S. (avus)


Lesenswert?

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.

: Bearbeitet durch User
von Hmmm (Gast)


Lesenswert?

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.

von Jürgen S. (avus)


Lesenswert?

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).

von Hmmm (Gast)


Lesenswert?

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.

von Jürgen S. (avus)


Lesenswert?

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.

von Jürgen S. (avus)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Hmmm (Gast)


Lesenswert?

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.

von Jürgen S. (avus)


Lesenswert?

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 :)

von Jürgen S. (avus)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.