Ich sehe, gibt's was neues von Jörg --> AVRDUDE 5.11 vielen Dank! Gibt's auch bald neue Version von WINAVR? Gruß Martin
Martin e. C. schrieb: > Gibt's auch bald neue Version von WINAVR? Soweit ich weiß, plant Eric eine für den Herbst, ja.
Mir würde eine Win kompilierte Version vom neuen avrdude schon sehr helfen. Hoffe auf vermeiden des unnötigen 0xFF brennen mit der neuen Version. Selber auf Win compilieren ohne in dem GNU tohuwabohu fit zu sein ist ein steiniges Feld - das kann Tage dauern ... obwohl eigentlich alle tools da sein sollten: Beitrag "avrdude: doofes 0xFF schreiben unterdrücken? (beim Bootloader brennen)" aber weiß der Teufel warum er sogar flex, bison, awk und wer weiß was alles braucht. dude ist doch kein Compiler.. oder kann jemand angeben "dies und das funktionierende Gnu Toolset von Downloadadresse so und so installieren, dann gehts mit erhöhter Wahrscheinlichkeit .." ;-)
kxr schrieb: > Mir würde eine Win kompilierte Version vom neuen avrdude schon sehr > helfen. Hoffe auf vermeiden des unnötigen 0xFF brennen mit der neuen > Version. Da hoffst du wohl leider vergeblich. Mein Zeitvorrat ist auch nur endlich, und den habe ich in den letzten 14 Tagen vorrangig dafür verwendet, diverse Bugs zu reparieren. > Selber auf Win compilieren ohne in dem GNU tohuwabohu fit zu sein ist > ein steiniges Feld - das kann Tage dauern ... "fit sein" muss man da nicht, aber man muss halt sehen, wo man den ganzen Krempel her bekommt, den man bei Linux, *BSD, MacOS X oder dergleichen über eins der gängigen Paketierungssysteme frei Haus geliefert bekommt. > aber weiß der Teufel warum er sogar flex, bison, awk und wer weiß was > alles braucht. dude ist doch kein Compiler.. awk scheint von autoconf/automake intern benötigt zu werden, AVRDUDE braucht das selbst nicht. lex und yacc haben doch nicht zwingend etwas mit "Compiler" zu tun. Sie werden hier benutzt, um die das avrdude.conf zu parsen. Würde man wohl heute eher mit XML machen, aber dann braucht man auch wieder eine plattformunabhängige XML-Bibliothek als externe Abhängigkeit, und naja, ob das wirklich schneller ist? Das Parsen des mittlerweile über 500 KiB großen avrdude.conf passiert in Nullkommanix. > oder kann jemand angeben "dies und das funktionierende Gnu Toolset von > Downloadadresse so und so installieren, dann gehts mit erhöhter > Wahrscheinlichkeit .." ;-) Linux oder FreeBSD installieren, dann geht's mit 100%iger Sicherheit. ;-) Was glaubst du, warum die meisten dieser Programme unter unixoiden Betriebssystemen entwickelt werden? Weil das für die Entwickler einfach mal bequemer ist.
Jörg Wunsch schrieb: > kxr schrieb: >> Mir würde eine Win kompilierte Version vom neuen avrdude schon sehr >> helfen. Hoffe auf vermeiden des unnötigen 0xFF brennen mit der neuen >> Version. > > Da hoffst du wohl leider vergeblich. Mein Zeitvorrat ist auch nur > endlich, und den habe ich in den letzten 14 Tagen vorrangig dafür > verwendet, diverse Bugs zu reparieren. dann war die geheimnisvolle Andeutung von "B.A." im anderen Thread wohl eine Ente. danke für den Hinweis. > >> oder kann jemand angeben "dies und das funktionierende Gnu Toolset von >> Downloadadresse so und so installieren, dann gehts mit erhöhter >> Wahrscheinlichkeit .." ;-) > > Linux oder FreeBSD installieren, dann geht's mit 100%iger Sicherheit. > ;-) Was glaubst du, warum die meisten dieser Programme unter > unixoiden Betriebssystemen entwickelt werden? Weil das für die > Entwickler einfach mal bequemer ist. kann man mit den üblichen Installs von Debian & Co einigmaßen einfach für Windows cross-kompilieren - z.B. auf meinem Server? das wär vielleicht ein einfacherer Weg. oder war eine komplette Umgewöhnung auf Linux gemeint? das wär ein bischen heftig für mich ;-) hier: Linux=alle Server, Windows=User/UI
kxr schrieb: > dann war die geheimnisvolle Andeutung von "B.A." im anderen Thread wohl > eine Ente. Ja, vermutlich. Ich wüsste nicht, wer dieser B. A. sein sollte, um eine autoritative Aussage treffen zu können. > kann man mit den üblichen Installs von Debian & Co einigmaßen einfach > für Windows cross-kompilieren - z.B. auf meinem Server? Habe ich selbst noch nicht gemacht, aber das sollte gehen. Ich weiß nur nicht, wie Dinge wie libusb dann in das Schema reinpassen, der reine Compiler/Binutils wäre nicht das große Problem. Einen alternativen als den Default-Compiler gibt man einfach beim configure an mit:
1 | env CC=gcc-mingw32 ./configure |
(mal in der Annahme, dass der Cross-Compiler "gcc-mingw32" heißen würde) > oder war eine komplette Umgewöhnung auf Linux gemeint? das wär ein > bischen heftig für mich ;-) Meinst du, man braucht so lange, bis man von ständigen Pattern- Updates des Virenscanners entwöhnt ist? ;-) OK, andauernd security patches für Firefox oder dergleichen sind dort leider genauso gang und gäbe wie in der Windowswelt. :-(
> Meinst du, man braucht so lange, bis man von ständigen Pattern- > Updates des Virenscanners entwöhnt ist? ;-) OK, andauernd security > patches für Firefox oder dergleichen sind dort leider genauso gang > und gäbe wie in der Windowswelt. :-( Auch bei Ubuntu gibt es alle paar Tage irgenwelche Updates und Patches.
Jörg Wunsch schrieb: > "fit sein" muss man da nicht, aber man muss halt sehen, wo man den > ganzen Krempel her bekommt, den man bei Linux, *BSD, MacOS X oder > dergleichen über eins der gängigen Paketierungssysteme frei Haus > geliefert bekommt. die GNU/mingw Teile sind ziemlich alle im WinAVR.../utils/bin schon drin. nur leider gehen viele nicht richtig. Grade eben am Beispiel "egrep" gesehen. ein make hier streikte bei einem egrep weil die WinAVR version (im PATH weit vorn) von egrep zickt. umbenannt, damit das egrep aus meiner älteren gnubin sammlung genommen wird -> geht wieder. also nochmal avrdude kompilieren probiert: gawk, flex und bison aus anderer Sammlung. configure läuft durch. checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking target system type... i686-pc-mingw32 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for bison... bison -y checking for flex... flex checking lex output file root... lex.yy checking lex library... none needed checking whether yytext is a pointer... no checking for ranlib... ranlib checking whether gcc and cc understand -c and -o together... yes checking for tputs in -ltermcap... no checking for tputs in -lncurses... no checking for readline in -lreadline... no checking for library containing gethostent... no checking for library containing setsockopt... no checking for usb_get_string_simple in -lusb... no checking for libusb_init in -lusb-1.0... no checking for libusb_init in -lusb... no checking for ftdi_init in -lftdi... no checking limits.h usability... yes checking limits.h presence... no checking for limits.h... yes checking stdlib.h usability... yes checking stdlib.h presence... no checking for stdlib.h... yes checking string.h usability... yes checking string.h presence... no checking for string.h... yes checking fcntl.h usability... yes checking fcntl.h presence... no checking for fcntl.h... yes checking sys/ioctl.h usability... no checking sys/ioctl.h presence... no checking for sys/ioctl.h... no checking sys/time.h usability... yes checking sys/time.h presence... no checking for sys/time.h... yes checking termios.h usability... no checking termios.h presence... no checking for termios.h... no checking unistd.h usability... yes checking unistd.h presence... no checking for unistd.h... yes checking for ddk/hidsdi.h... yes checking for an ANSI C-conforming const... yes checking whether time.h and sys/time.h may both be included... yes checking for memset... yes checking for select... no checking for strcasecmp... yes checking for strdup... yes checking for strerror... yes checking for strncasecmp... yes checking for strtol... yes checking for strtoul... yes checking for gettimeofday... yes checking for usleep... yes checking for a Win32 HID libray... yes checking for uint_t... no checking for ulong_t... no checking for parallel device... lpt1 checking for serial device... com1 checking if gcc accepts -Wno-pointer-sign ... no checking if gcc accepts -mno-cygwin... yes checking if linker accepts -static... yes configure: creating ./config.status config.status: creating doc/Makefile config.status: creating windows/Makefile config.status: creating avrdude.spec config.status: creating Makefile config.status: creating avrdude.conf.tmp config.status: creating ac_cfg.h config.status: executing depfiles commands nächster Schritt im breakdance, es bleibt make gleich am Anfang hängen ... C:\temp\avrdude-5.11>make C:/Programme/WinAVR-20100110/utils/bin/sh.exe ./ylwrap config_gram.y y.tab.c con fig_gram.c y.tab.h config_gram.h y.output config_gram.output -- bison -y -d C:\Programme\WinAVR-20100110\utils\bin\bison.exe: no grammar file given make: *** [config_gram.c] Error 1 anderes sh, anderer Fehler: C:/bin/sh.exe ./ylwrap config_gram.y y.tab.c config_gram.c y.tab.h config_gram.h y.output config_gram.output -- bison -y -d c:\Programme\WinAVR-20100110\utils\bin\bison.exe: /cygdrive/c/temp/avrdude-5.11/ config_gram.y: No such file or directory make: *** [config_gram.c] Error 1 das ist so typisch der Anfang des steinigen Wegs ... man hofft daß um die nächste Ecke ... ;-) (ich schaffe so etwa 50% der gnu-Sachen zu kompilieren. Aber mit sachen wie autoconf,automake wie hier, "--" etc da gehen bei mir schon die Warnleuchten an...
Hallo, wenn es nicht pressiert kann ich heute abend ein AVRDUDE "für Windows" kompilieren, ich hatte mal irgendwo (hier im Forum) ein Anleitung geschrieben wie man es für Windows (unter eine Windows Maschine) kompiliert. Gruß Martin
kxr schrieb: > checking for usb_get_string_simple in -lusb... no > checking for libusb_init in -lusb-1.0... no > checking for libusb_init in -lusb... no Ich hoffe mal, du willst dann keine nur über USB ansprechbaren programmer benutzen. > C:/Programme/WinAVR-20100110/utils/bin/sh.exe ./ylwrap config_gram.y > y.tab.c con > fig_gram.c y.tab.h config_gram.h y.output config_gram.output -- bison -y > -d > C:\Programme\WinAVR-20100110\utils\bin\bison.exe: no grammar file given > make: *** [config_gram.c] Error 1 Schreib mal in den Script ganz oben (3. Zeile) ein
1 | set -x |
rein. Dann kann man verfolgen, warum dem Script das nicht gefällt. > C:/bin/sh.exe ./ylwrap config_gram.y y.tab.c config_gram.c y.tab.h > config_gram.h > y.output config_gram.output -- bison -y -d > c:\Programme\WinAVR-20100110\utils\bin\bison.exe: > /cygdrive/c/temp/avrdude-5.11/ > config_gram.y: No such file or directory Sieht so aus, als würdest du hier versuchen, die Tools von Cygwin und MinGW zu mischen. Das passt nicht. Die Übersetzung der Namen wie /cygdrive/c/temp/... in die tatsächlichen Windows-Namen ist Bestandteil der Cygwin-Bibliothek und wird folglich nur von den Cygwin-Tools verstanden; du versuchst jedoch, ein WinAVR- (also MinGW-) bison damit zu füttern. Am besten ist es, den Pfad zu den Cygwin-Utilities nie in den %PATH% in Windows aufzunehmen, sondern Cygwin ausschließlich über das Fenster mit der Cygwin-Shell zu starten. Da drin sollte sich AVRDUDE eigentlich ordentlich compilieren lassen, und das Compilat sollte dann auch keine cygwin1.dll benötigen.
Der Treiber für die FTDI 2232 ist drin, super! Ich hatte den ja schon bei mir reingepatcht und den "Device busy" Fehler selbst gehabt und behoben… Aber konnte das nicht gleich auf savannah kommentieren ohne einzuloggen und dann hab ich es vergessen. An der Patch-Diskussion sehe ich, dass ja doch noch alles gut gegangen ist. Ich habe hier auch das OpenOCD USB, fürn ARM gekauft, und mit einem selbstgebauten Adapter von 20 Pin ARM JTAG auf AVR ISP 10 und 6 Pin flutscht das so richtig wenn man mal die Frequenz auf mehrere MHz einstellt.
So, hier ist die neue Version AVRDUDE 5.11 für Windows kompiliert: Beitrag "Re: AVRDUDE für Windows kompilieren - Anleitung !"
Martin e. C. schrieb: > So, > hier ist die neue Version AVRDUDE 5.11 für Windows kompiliert: > > Beitrag "Re: AVRDUDE für Windows kompilieren - Anleitung !" danke für exe und Anleitung. vielleicht geh ich demnächst mal an die 0xFF Optimierung ... steht aber noch nicht fest, falls jemand es noch eiliger hat ;-)
jetzt hab ich das neueste MingW mit dem neuen Autoget-Tool nochmal drüberinstalliert, dabei Developertools(incl. MSYS) markiert (!) und dann C:\MinGW\msys\1.0\bin;C:\MinGW\bin vorn in den PATH rein. sonst nix. Dann lief .\configure und make problemlos im ersten Rutsch durch - samt libusb. Das Problem waren v.a. die bogus gnu/sys tools aus den WinAVR/util Verzeichnissen und der dann folgende Mischmasch...
Jörg Wunsch schrieb: >> checking for usb_get_string_simple in -lusb... no >> checking for libusb_init in -lusb-1.0... no >> checking for libusb_init in -lusb... no > > Ich hoffe mal, du willst dann keine nur über USB ansprechbaren > programmer benutzen. hast du das berücksichtigt? sonst hast du kein USB Support! also die neue LibUSB runterladen und einbinden wie im Anleitung dann fuktioniert.
kxr schrieb: > vielleicht geh ich demnächst mal an die 0xFF Optimierung ... steht aber > noch nicht fest, falls jemand es noch eiliger hat ;-) Laut Info von Jörg ist es im SVN bereits drin: Beitrag "Re: avrdude: doofes 0xFF schreiben unterdrücken? (beim Bootloader brennen)"
Hallo Jörg, da hier über die Kompilierung gesprochen würde, frage ich hier weiter paar Sachen. Mich würde interessieren wie kann ich AVRDUDE kompilieren wenn ich die ganze Dateien von SVN hole. Wenn ich AVRDUDE von eine "Release Version" kompiliere gibt es kein problem: ./configure usw. alles läuft. Ich habe die Dateien von SVN geholt und damit versucht nun da ist kein Datei "configure" dabei sondern "configure.ac und makefile.am". Frage: wie erzeuge ich die configure Datei? Google sagt dass es mit autoconf gehen sollte oder? klappt aber bei mir leider nich! Gruß
Als Fehlermeldung bekomme ich:
1 | $ autoconf |
2 | /c/MinGW/bin/autoconf-2.67: line 493: /mingw/bin/autom4te-2.67: No such file or directory |
3 | /c/MinGW/bin/autoconf-2.67: line 493: exec /mingw/bin/autom4te-2.67: cannot execute: No such file or directory |
ein automake spuck:
1 | $ autoconf |
2 | /c/MinGW/bin/automake: /c/MinGW/bin/automake-1.11: bin/perl: bad interpreter: No such file or directory |
3 | /c/MinGW/bin/automake: line 156: /c/MinGW/bin/automake-1.11: error 0 |
und da ist bei mir das Licht aus!
Martin e. C. schrieb: > Mich würde interessieren wie kann ich AVRDUDE kompilieren wenn ich die > ganze Dateien von SVN hole. Du brauchst dafür noch die "auto"-Tools, also autoconf und automake. Dann startest du den Script ./bootstrap, dieser ruft die Auto-Tools in der richtigen Reihenfolge auf. Im Ergebnis bekommst du dann den configure-Script (und noch ein paar andere Dateien).
YES!
autoconf istalliert dann,
Jörg Wunsch schrieb :
> Dann startest du den Script ./bootstrap,
und was sehe ich da? es funktioniert, glaube ich es selber nicht ;-)
MIL GRACIAS !
Saludos
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.