Probleme beim Compillieren von LUFA Projekten (USB für AVR)

[Barny F. (barny)]

Guten Tag

Ich wollte mich jetzt einmal an AVR mit USB (ATmega32U4) heranwagen.
Da die Beispiele auf Microchip dafür eher suboptimal sind (Schreibfehler 
-> O statt 0, Backslashes über den gesammten Quellcode wild verteilt 
usw.) hatte ich gedacht dass ich mir LUFA 
anschaue.(https://github.com/abcminiuser/lufa)

Also Zip heruntergeladen und versucht ein Beispielprojekt zu 
kompilieren.

Ich habe aber das Problem dass keines der Beispielprojecte kompillieren 
will.
Weder mittels WinAVR + Kommandozeile noch über Microchip Studio.

Kann mir bitte jemand verraten was ich da falsch gemacht habe?
Das ist die Konsolenausgabe:

C:\AVR\LUFA\lufa-master\Projects\USBtoSerial>make
      0 [main] sh 6840 sync_with_child: child 7044(0x208) died before initialization with status code 0xC0000142
     84 [main] sh 6840 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
      0 [main] sh 3048 sync_with_child: child 10232(0x214) died before initialization with status code 0xC0000142
     80 [main] sh 3048 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
      0 [main] sh 5188 sync_with_child: child 8140(0x214) died before initialization with status code 0xC0000142
     70 [main] sh 5188 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
 [INFO]    : Begin compilation of project "USBtoSerial"...

avr-gcc (WinAVR 20100110) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 [OBJCPY]  : Extracting EEP file data from "USBtoSerial.elf"
avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings USBtoSerial.elf USBtoSerial.eep || exit 0
      0 [main] sh 2116 sync_with_child: child 4092(0x200) died before initialization with status code 0xC0000142
     83 [main] sh 2116 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
make: *** [USBtoSerial.eep] Error 128

C:\AVR\LUFA\lufa-master\Projects\USBtoSerial>

Hex und elf werden generiert, aber ich würde trotzdem gerne wissen was 
da einen Fehler wirft.

[Barny F. (barny)]

Der Fehler bei Microchipstudio ist identisch, nur die Ausgabe ist etwas 
länger

[Dergute W. (derguteweka)]

Moin,

Weiss nicht, obs viel hilft, aber ich hab' mir den Kram grad mal unter 
Linux runtergeladen und USBtoSerial ge"make"ed. Hat erstaunlicherweise 
auf Anhieb geklappt. Werden auch keine toten Kinder erwaehnt.
Wird wohl eher was windows-spezifisches sein.

Gruss
WK

[Barny F. (barny)]

Hmmm.
Ich habe Mint angeschmissen und da läufts.
Ubuntu auch.

Wie kann ich Windows überreden dass es da auch funktioniert?

[Axel S. (a-za-z0-9)]

Barny F. schrieb:
> Hmmm.
> Ich habe Mint angeschmissen und da läufts.
> Ubuntu auch.
>
> Wie kann ich Windows überreden dass es da auch funktioniert?

Hmm. Die Fehler sind im wesentlichen die zwei

[main] sh 6840 sync_with_child: child 7044(0x208) died before initialization with status code 0xC0000142
[main] sh 6840 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable

Irgendein Shellscript läuft da Amok. Und da es unter Windows weder eine 
native (Bourne) Shell noch einen Systemruf fork() gibt, braucht das eine 
mehr oder weniger gelungene Implementierung dieser UNIX-Infrastruktur 
für Windows (Windows Services For UNIX? [1]). So wie es aussieht, liegt 
das Problem da. Was spricht denn dagegen, unter UNIX [2] zu entwickeln?


[1] https://de.wikipedia.org/wiki/Microsoft_Windows_Services_for_UNIX
[2] Muß ja nicht Linux sein, xBSD geht auch. Oder MacOS.

[Barny F. (barny)]

Ich kann gerne auf Windows verzichten.
Das Problem ist das ich da nicht alleine dran bastle und die zweite 
Person noch nicht so ganz Bereit ist auf die dunkle Seite des Pinguins 
zu wechseln.

Deswegen wollte ich das Ganze eigentlich Plattformunabhängig halten.

[Dieter S. (ds1)]

Man könnte einfach mal nach "child state waiting for longjmp" suchen, da 
kommen viele Treffer inklusive Lösungsvorschläge...

[Ein T. (ein_typ)]

Barny F. schrieb:
> avr-gcc (WinAVR 20100110) 4.3.3

Januar 2010...

Davon abgesehen hat Dein armer Windows-Kumpel heutzutage doch nun 
wirklich viele Möglichkeiten:

- Windows Subsystem for Linux (WSL)
- Docker
- Virtualbox  VmWare  Hyper-V

Eventuell würde sogar Cygwin funktionieren, käme auf einen Versuch an.

[Barny F. (barny)]

Ein T. schrieb:
> Barny F. schrieb:
>> avr-gcc (WinAVR 20100110) 4.3.3
>
> Januar 2010...
Das war nur der Verzweiflungsversuch nachdem Microchip Studio 7
nicht funktioniert hat.
Ich habe den Output von WinAVR gepostet da der wesentlich kürzer ist. 
Microchip Studio hat das Gleiche, nur dreimal so lange gesagt.

Übrigens ist die GCC Version für AVR unter Linux auch nicht soooooo viel 
neuer.


Wie geschrieben arbeite ich normalerweise unter Linux.
Ich wollte eigentlich nur das Ganze auch unter Windows lauffähig machen 
damit auch die Windows-Nutzer deren Anpassungen machen können ohne das 
ich jedes mal die Änderungen machen muss.

Ich danke für die Vorschläge mit den vielen Wegen Linux einzusetzen.
Ich wollte eigentlich nur wissen ob es einen Weg gibt das unter Windows 
Läuft.
Aber ich habe keine Hoffnung Leute die sich absolut gegen Linux sträuben 
auf Dinge wie VM, Docker,... einsteigen.

Es ging mir hauptsächlich darum dass die Alten "Das habe ich immer schon 
so gemacht" Leute daran arbeiten können ohne dass ich für sie 
compilieren muss.

[Nemopuk (nemopuk)]

Barny F. schrieb:
> Übrigens ist die GCC Version für AVR unter Linux auch nicht soooooo viel
> neuer.

Debian 13 (trixie, stable) hat avr-gcc Version 14.2.0 von 2024.

[Harald K. (kirnbichler)]

Wenn nicht Schlaufüchse ganz tolle nichtportable Dinge in Makefiles 
veranstalten würden, müsste man nicht versuchen, das Verhalten von Linux 
unter Windows nachzubilden.

Wer Shellskripte in einem Makefile aufruft, der ist so ein Schlaufuchs.

[Nemopuk (nemopuk)]

Harald K. schrieb:
> Wenn nicht Schlaufüchse ganz tolle nichtportable Dinge in Makefiles
> veranstalten würden

Schon das Bereinigen (löschen) alter Dateien erfordert 
Betriebssystem-Spezifische Befehle. Aus gutem Grund liefert mingw einige 
der üblichen Shell Kommandos gleich mit.

[Ein T. (ein_typ)]

Barny F. schrieb:
> Übrigens ist die GCC Version für AVR unter Linux auch nicht soooooo viel
> neuer.

Find' ich schon:

ein@typ:~# cat /etc/os-release
PRETTY_NAME="Ubuntu 25.04"
ein@typ:~# avr-gcc --version
avr-gcc (GCC) 14.2.0

[Micha (nichtgast)]

Was bei mir geholfen hatte, war msys2 zu installieren und den Pfad auf 
das bin Verzeichnis zu setzten. Damit kann man im normalen cmd diverse 
Bash Befehle verwenden. Das reicht fürs makefile.