Hallo AVR-Gemeinde, nachdem ich bisher unter AVRStudio gearbeitet habe, möchte ich auf Eclipse umsteigen. Kompilieren mit Hexoutput funktioniert schon. Ich würde auch gerne Debuggen in Eclipse und habe versucht, AVARICE zu nutzen. Bin ganz einfach angefangen und habe ein Kommandozeilenfenster aufgemacht. Aktive Directory ist "C:\Programme\WinAVR-20070525\bin\". Habe AVARICE eingegeben und es passiert nichts. Es erscheint 2 Zeilen tiefer wieder der Eingabeprompt. Ansonsten kommt keine Meldung. Habe dann verschiedene Parameter angegeben, es tut ssich auch nichts. Dann habe ich verschiedene andere Programme iM DOS-Fenster probiert. Bei AVRDUDE ist es genauso. SIMULAVR meldet ohne Parameter: main.c:411: WARNING: Device not supported: simulavr was mir sinnvoll erscheint. Der Compiler u.s.w. läuft auch. Was kann ich tun? Ach ja: Ich nutze WindowsXP mit SP2 und alle Patches. Ich habe keine CYGWIN Installation, aber soweit ich weiß, sollte es auch ohne funktionieren (CYGWIN1.DLL). Und bitte keine Diskussion wegen Linux oder Windows. ;-) WinAVR ist die Version WinAVR-20070525. Danke für Hilfe. Joachim PS. Vielleicht hat Jörg einen Tip?
Hans-joachim Borchers wrote: > Habe AVARICE eingegeben und es passiert nichts. Es erscheint > 2 Zeilen tiefer wieder der Eingabeprompt. Ansonsten kommt > keine Meldung. > ... Bei AVRDUDE ist es genauso. Irgendwas ist da bei dir kaputt. Beide Programme sollten beim Start ohne Argumente mittelmäßig gesprächig reagieren, etwa so:
1 | $ avarice |
2 | AVaRICE version 2.6.20070217, Feb 21 2007 20:38:03 |
3 | |
4 | Defaulting JTAG bitrate to 1 MHz. Make sure that the target |
5 | frequency is at least 4 MHz or you will likely encounter failures |
6 | controlling the target. |
7 | |
8 | Failed to open /dev/avrjtag: No such file or directory |
1 | $ avrdude |
2 | Usage: avrdude [options] |
3 | Options: |
4 | -p <partno> Required. Specify AVR device. |
5 | -b <baudrate> Override RS-232 baud rate. |
6 | -B <bitclock> Specify JTAG/STK500v2 bit clock period (us). |
7 | -C <config-file> Specify location of configuration file. |
8 | -c <programmer> Specify programmer type. |
9 | -D Disable auto erase for flash memory |
10 | -i <delay> ISP Clock Delay [in microseconds] |
11 | -P <port> Specify connection port. |
12 | -F Override invalid signature check. |
13 | -e Perform a chip erase. |
14 | -O Perform RC oscillator calibration (see AVR053). |
15 | -U <memtype>:r|w|v:<filename>[:format] |
16 | Memory operation specification. |
17 | Multiple -U options are allowed, each request |
18 | is performed in the order specified. |
19 | -n Do not write anything to the device. |
20 | -V Do not verify. |
21 | -u Disable safemode, default when running from a script. |
22 | -s Silent safemode operation, will not ask you if |
23 | fuses should be changed back. |
24 | -t Enter terminal mode. |
25 | -E <exitspec>[,<exitspec>] List programmer exit specifications. |
26 | -y Count # erase cycles in EEPROM. |
27 | -Y <number> Initialize erase cycle # in EEPROM. |
28 | -v Verbose output. -v -v for more. |
29 | -q Quell progress output. -q -q for less. |
30 | -? Display this usage. |
31 | |
32 | avrdude project: <URL:http://savannah.nongnu.org/projects/avrdude> |
Wenn das bei dir alles gar nicht passiert, musst du einen Windows-Guru befragen, wie man das debuggt. Unter Unix würde ich mit truss/ktrace/ strace und/oder einem Debugger weitergucken. Irgendwas wie einen Syscall-Tracer sollte es auch für Windows geben.
Hallo Jörg, danke, dass Du antwortest. > > Irgendwas ist da bei dir kaputt. Beide Programme sollten beim > Start ohne Argumente mittelmäßig gesprächig reagieren, etwa so: Das hatte ich auch erwartet. > Wenn das bei dir alles gar nicht passiert, musst du einen Windows-Guru > befragen, wie man das debuggt. Unter Unix würde ich mit truss/ktrace/ > strace und/oder einem Debugger weitergucken. Irgendwas wie einen > Syscall-Tracer sollte es auch für Windows geben. Ich kann das versuchen. Aber mein Windows ist gerade neu installiert wegen neuem Rechner. Also selbst bei Windows fällt es mir schwer, dass dann da schon was kaputt ist :-) Aber ein paar Fragen hab ich noch. Eben habe ich WinAVR nochmal neu installiert. Hat aber nicht geholfen. :-( Fragen: 1) Kann es nicht an der CYGWIN1.DLL liegen? Habe gelesen, dass AVARICE gegen die kompiliert werden muß, das aber manchmal nicht so geschieht. räusper 2) Hilft vielleicht eine CYGWIN-Installation? Ich will das nicht einfach auf meinen Rechner installieren. Unnützt mit Zeugs belasten will ich ihn ja nicht. Und die meisten Deinstallationen hinterlassen leider fast immer "Reste". 3) Könnte ich evtl. noch andere Tests machen? Habe nebenbei auch mal nach evtl. woanders vorhandene CYGWIN1.DLLs gesucht. Ist aber nur die eine vom WINAVR vorhanden. Ich hatte ml ein Problem, da eine falsche CYGWIN-DLL genutzt wurde, weil deren Pfad im Suchpfad vorher eingetragen war. Ich werde auch mal nach einem geeigneten Debugger suchen. Der MS-Debugger vom Studio, da wird man im Assemblecode wohl kaum was wiedererkennen. Vielen Dank für Deine Hilfe. Joachim
Hans-joachim Borchers wrote: > Fragen: > 1) Kann es nicht an der CYGWIN1.DLL liegen? Habe gelesen, dass > AVARICE gegen die kompiliert werden muß, das aber manchmal > nicht so geschieht. *räusper* Avrdude ist eine reine Win32-API-Applikation, die braucht keine CYGWIN1.DLL. Laut Aussage von Eric Weddington selbst dann nicht, wenn man sie mit Cygwin baut (was er wohl tut). Ich habe aber keine Ahnung, wie man unter Win32 rausfindet, welche DLLs alle von einem Programm benutzt werden. Unter Unix würde ich "ldd `which avrdude`" tippen... AVaRICE benötigt dagegen in der Tat Cygwin, da es auf dem Posix-API aufsetzt. Eigentlich sollte aber WinAVR die passende CYGWIN1.DLL mitbringen. Lediglich mit dem Nichtfunktionieren der mitgebrachten USB-Bibliothek ist mir hier was bekannt.
> > Avrdude ist eine reine Win32-API-Applikation, die braucht keine > CYGWIN1.DLL. Laut Aussage von Eric Weddington selbst dann nicht, > wenn man sie mit Cygwin baut (was er wohl tut). Oh mann, das verstehe ich dann überhaupt nicht, warum AVRDUDE nicht läuft. > > Ich habe aber keine Ahnung, wie man unter Win32 rausfindet, welche > DLLs alle von einem Programm benutzt werden. Unter Unix würde > ich "ldd `which avrdude`" tippen... Bin leider kein LINUX/UNIX Guru :-( > > AVaRICE benötigt dagegen in der Tat Cygwin, da es auf dem Posix-API > aufsetzt. Eigentlich sollte aber WinAVR die passende CYGWIN1.DLL > mitbringen. Ist auch so. In der BIN-Directory ist sie drin, daa wo auch AVaRICE drin ist. Lediglich mit dem Nichtfunktionieren der mitgebrachten > USB-Bibliothek ist mir hier was bekannt. Was ist denn da faul. Ich wollte Dragon oder AVR ICE MKII benutzen. Geht das dann sowieso nicht? Ansonsten werde ich mal einen Debugger organisieren. Danke nochmal. Joachim
Hans-joachim Borchers wrote: > Oh mann, das verstehe ich dann überhaupt nicht, warum AVRDUDE > nicht läuft. Zumindest lassen die Anzeichen vermuten, dass es kein Cygwin- Problem ist. Guck dich mal um mit syscall-Tracern. Ich hatte mir letztens ein strace-Äquivalent für Win32 mal beschafft, kann dir aber nicht mehr recht sagen, woher ich es habe. (Das heißt auch Strace und scheint von einer Firma namens BindView zu sein.) So ein Teil produziert zwar Unmengen an Ausgabetext, aber den kann man sich in eine Datei schreiben lassen und dann versuchen zu verstehen, bis wohin die Applikation ungefähr gelaufen ist und was sie veranlasst haben könnte, die Hufe zu strecken. >> Lediglich mit dem Nichtfunktionieren der mitgebrachten >> USB-Bibliothek ist mir hier was bekannt. > Was ist denn da faul. Eric Weddington hat die libusb0.dll aus dem libusb-win32 (von SourceForge.net) wohl einfach mit ins WinAVR reingepackt. Irgendwie scheint das Teil aber nur zu funktionieren, wenn es über den richtigen Installer von libusb-win32 ins System gebracht wird. > Ich wollte Dragon oder AVR ICE MKII benutzen. > Geht das dann sowieso nicht? Die Lösung ist, die libusb0.dll von WinAVR zu entsorgen und sich den originalen Installer von sourceforge.net zu holen. Nachdem dieser dann ,,seine'' libusb0.dll installiert hat, funktioniert alles -- so zumindest haben es mir schon mehrere Leute bestätigt. > Ansonsten werde ich mal einen Debugger organisieren. Kannst dir ja erstmal den genannten dependencywalker und ggf. strace angucken. Für einge grobe Abschätzung, warum irgendwas nicht richtig startet, ziehe ich derartige Tools zumindest unter Unix einem ,,richtigen'' Debugger erstmal vor, insbesondere dann, wenn ich nicht vor habe, die Applikation aus den Quellen sowieso neu zu zimmern.
Hallo, @ Uhu Uhuhu Dependencywalker schient mir ein Tool zu sein, welches nur abhängigkeiten aufzeigt. Damit stelle ich dann aber nicht fest, wann sich ein Programm verabschieded?!?! Aber ich muß mich noch genauer drum kümmern. Danke für den Tip. @ Jörg Vielen Dank nochmal für die Tips. Die Tips zu der USB-Lib sind auch viel Wert, wenn denn AVaRICE erstmal nicht mehr bockig ist. Ich habe gestern noch ein Tool gefunden "Debuggy", mit dem scheint man auch soetwas untersuchen zu können. Habe es mal gestartet und kurz mit "gespielt", konnte aber noch nichts entdecken. Werde es die Tage abends mal mit mehr Zeit intensiver untersuchen. Außerdem hab ich hier einen Kollegen, der in solchen Fragen auch oft weiter weiß. Den werd ich auch gleich mal interviewen. Ich melde mich, sobald ich nicht weiterweiß oder etwas neues weiß :-) Habt einen schönen Tag. Hier in Bremen gießt es gerade Bindfäden. Joachim
Hallo, so ich bin weiter. Habe mit einem Tool namens strace für Windows gesehen, dass AVaRICE nach usblib.dll verlangt, danach war Schluß. Nun gut, habe nach Deiner (Jörg) Anleitung verfahren und LIBUSB von Sourceforge geholt und installiert. Danach hat sich AVaRICE auch wie oben von Jörg beschrieben gemeldet. Über USB habe ich aber den Dragon z.B. nicht zum Laufen bekommen. Er hat den Dragon gefunden und hat dann irgendein USB bulk read error gemeldet und dann stand wieder das DOS-Prompt dort. Mein Rechner bootet auch nicht mit installierter USBLIB. Ich mußte die letzte bekannte lauffähige Version von Windows starten. Danach lief USBLIB natürlich nicht mehr. Erst deinstalliert, dann wieder installiert und Rechner bootet nicht mehr. Er kommt nicht mal zu dem "schwarzen" Startschirm, wo dieser blaue Balken hin und her wandert. So ein Mist. Hat dazu einer eine Idee? Weiter wurde der Dragon nur gefunden (auch mit dem Testtool der USBLIB), wenn dieser direkt am PC hängt und nicht an einem USB-Hub. Damit könnte man ja noch leben. Vielleicht kann man das aber auch beheben. Ja ich habe noch einen Nachbau eines JTAG ICE MK1 (Evertool-Nachbau) und der läuft über die COM-Schnittstelle scheinbar. Da gab es keine Zicken. Allerdings bin ich noch nicht zum Debuggen gekommen. Folgendes habe ich hinbekommen: ---snip c:\Programme\WinAVR-20070525\bin>avarice --jtag /dev/com3 :4242 AVaRICE version 2.6, May 15 2007 17:07:24 Defaulting JTAG bitrate to 1 MHz. Make sure that the target frequency is at least 4 MHz or you will likely encounter failures controlling the target. JTAG config starting. Hardware Version: 0xc1 Software Version: 0x80 Reported JTAG device ID: 0x9502 Configured for device ID: 0x9502 atmega32 JTAG config complete. Preparing the target device for On Chip Debugging. Disabling lock bits: LockBits -> 0xff Enabling on-chip debugging: Extended Fuse byte -> 0x3f High Fuse byte -> 0x1b Low Fuse byte -> 0x3f Waiting for connection on port 4242. ---snap GDB gestartet in einer zweiten Konsole, dann target remote :4242 eingegeben und es kam: ---snip (gdb) target remote :4242 Remote debugging using :4242 0x00000000 in ?? () (gdb) -snap Also zusammengefaßt: 1) Rechner bootet mit installierter USBLIB nicht mehr. 2) Wenn USBLIB installiert ist, findet er den DRAGON nur, wenn er nicht am Hub hängt. 3) Wenn der Dragon gefunden wird, gibt es einen USB bulk-read-error. Wenn einer zu den 3 Punkten etwas weiß, dann bitte schreiben. Ich will natürlich den Dragon nutzen.) Einen ICE MKII kann ich auch probieren, habe ich aber noch nicht. Vielen Vielen Dank für die Hilfe. Joachim
Hans-joachim Borchers wrote: > so ich bin weiter. Habe mit einem Tool namens strace für Windows > gesehen, dass AVaRICE nach usblib.dll verlangt, danach war Schluß. Seltsam, dass es da nichtmal 'ne Ausschrift gibt, wenn die nicht gefunden wird. > Ja ich habe noch einen Nachbau eines JTAG ICE MK1 (Evertool-Nachbau) > und der läuft über die COM-Schnittstelle scheinbar. Ja, das ist 'ne andere Kategorie. > (gdb) target remote :4242 > Remote debugging using :4242 > 0x00000000 in ?? () Das ist erstmal prinzipiell OK. > 1) Rechner bootet mit installierter USBLIB nicht mehr. Das wäre auf jeden Fall wert, auf der Liste der libusb-win32 mal nachzufragen. Letztlich sind wir hier nur deren Nutzer. > 2) Wenn USBLIB installiert ist, findet er den DRAGON nur, > wenn er nicht am Hub hängt. > 3) Wenn der Dragon gefunden wird, gibt es einen USB bulk-read-error. Wären auch beides Fragen, die man dort mal probieren könnte los zu werden. Leider ist mir auch schon aufgefallen, dass es beliebig viel Schrott bei USB gibt, gerade im Bereich der Hubs. Zu Hause habe ich noch Glück, aber auf Arbeit passiert es auch immer mal, dass man den Hub komplett neu stöpseln muss. > Einen ICE MKII kann ich > auch probieren, habe ich aber noch nicht. Den wirst du via RS-232 genaus schön und sofort benutzen können wie den mkI-Clone, über USB wird er sich ziemlich genauso wie der Dragon verhalten. Hast du 'ne Chance, das an einem anderen USB-Controller zu testen?
Jörg Wunsch wrote: > Seltsam, dass es da nichtmal 'ne Ausschrift gibt, wenn die nicht > gefunden wird. Ja ja, so sind sie die Softies ;-) >> 1) Rechner bootet mit installierter USBLIB nicht mehr. > > Das wäre auf jeden Fall wert, auf der Liste der libusb-win32 mal > nachzufragen. Letztlich sind wir hier nur deren Nutzer. Werd ich mal tun. Heute aber nicht mehr schnarch > >> 2) Wenn USBLIB installiert ist, findet er den DRAGON nur, >> wenn er nicht am Hub hängt. >> 3) Wenn der Dragon gefunden wird, gibt es einen USB bulk-read-error. > > Wären auch beides Fragen, die man dort mal probieren könnte los zu > werden. Leider ist mir auch schon aufgefallen, dass es beliebig viel > Schrott bei USB gibt, gerade im Bereich der Hubs. Ja leider ist das so. grummel >> Einen ICE MKII kann ich >> auch probieren, habe ich aber noch nicht. > > Den wirst du via RS-232 genaus schön und sofort benutzen können wie > den mkI-Clone, über USB wird er sich ziemlich genauso wie der Dragon > verhalten. Dann ist er aber langsam. Aber auch besser als garnichts. > > Hast du 'ne Chance, das an einem anderen USB-Controller zu testen? Wenn ich mal Zeit habe ja. Dann werde ich das mal testen. Benutze hier jetzt einen Apple MAC MINI mit "Intel Inside" ;-) Jetzt bekomme ich bestimmt prügel, darauf Windows laufen zu lassen. Das Windows läuft daruf native, nicht das einer denkt, ich habe es in einer VM laufen. Na dann, vielen Dank nochmal. Wenn ich dann wieder was habe, schreibe ich es hier. Zu Eclipse und GDB wird es bestimmt auch Fragen geben. Und danke Jörg, dass Du geholfen hast. Gute Nacht Joachim
Hans-joachim Borchers wrote: >> Seltsam, dass es da nichtmal 'ne Ausschrift gibt, wenn die nicht >> gefunden wird. > Ja ja, so sind sie die Softies ;-) Nö, Winzigweich lässt grüßen. Der dynamische Linker unter Unix sagt sehr wohl, was ihm fehlt. >> Den wirst du via RS-232 genaus schön und sofort benutzen können wie >> den mkI-Clone, über USB wird er sich ziemlich genauso wie der >> Dragon verhalten. > Dann ist er aber langsam. Ungefähr halb so schnell wie mit USB. >> Hast du 'ne Chance, das an einem anderen USB-Controller zu testen? > Wenn ich mal Zeit habe ja. Dann werde ich das mal testen. > Benutze hier jetzt einen Apple MAC MINI mit "Intel Inside" ;-) Tja, unter OS X hättest du diese Probleme nicht. ;-) Vermutlich aber andere. Wenngleich, was ich in letzter Zeit so mitbekommen habe, scheint die libusb da mittlerweile brauchbar stabil zu sein.
Jörg Wunsch wrote: > Hans-joachim Borchers wrote: > >>> Seltsam, dass es da nichtmal 'ne Ausschrift gibt, wenn die nicht >>> gefunden wird. > >> Ja ja, so sind sie die Softies ;-) > > Nö, Winzigweich lässt grüßen. Der dynamische Linker unter Unix sagt > sehr wohl, was ihm fehlt. Ja so können die Softies auch sein :-) Aber wenn ich ein Programm für ein Betriebssystem schreibe, dann muß ich dessen Schwächen auch berücksichtigen. schulterzuck > >>> Den wirst du via RS-232 genaus schön und sofort benutzen können wie >>> den mkI-Clone, über USB wird er sich ziemlich genauso wie der >>> Dragon verhalten. > >> Dann ist er aber langsam. > > Ungefähr halb so schnell wie mit USB. Mir viel ein, daß es vielleicht gaarnicht langsamer ist? Oft wird bei USB ja doch nur ein Wandler zu einem UART eingesetzt und läuft dann genauso langsam, hat aber USB. Kann auf UART kann schneller, muß aber nicht. Na aber ich werde es erleben. > >>> Hast du 'ne Chance, das an einem anderen USB-Controller zu testen? > >> Wenn ich mal Zeit habe ja. Dann werde ich das mal testen. >> Benutze hier jetzt einen Apple MAC MINI mit "Intel Inside" ;-) > > Tja, unter OS X hättest du diese Probleme nicht. ;-) Vermutlich aber > andere. Wenngleich, was ich in letzter Zeit so mitbekommen habe, > scheint die libusb da mittlerweile brauchbar stabil zu sein. Unter OS X habe ich Eclipse mit der AVR Toolchain nicht zum laufen bekommen. Eclipse schon, aber die den nicht. Allerdings habe ich auch nur einen kurzen Versuch gemacht. Der Reiz es hinzubekommen ist schon da. Ich kenn mich nur unter Linux (oder OS X) so gut wie nicht aus. Aber OS X ist schon fein. Kann hier beides booten, es besteht also die Chance, dass ich es doch noch lerne :-) Wir werden sehen. Ich habe soviele andere Projekte, die ich gerne erledigen würde...... gähn Einen schönen Tag noch. Joachim
Hans-joachim Borchers wrote: >> Nö, Winzigweich lässt grüßen. Der dynamische Linker unter Unix >> sagt sehr wohl, was ihm fehlt. > Ja so können die Softies auch sein :-) Aber wenn ich ein Programm > für ein Betriebssystem schreibe, dann muß ich dessen Schwächen auch > berücksichtigen. Geht nicht: Henne-und-Ei-Problem. Das Programm startet ja gar nicht, weil ihm die shared lib fehlt, also kann sich das Programm auch nicht selbst drum kümmern. Das muss mehr oder minder der dynamic loader tun. (Technisch ist der bei Unix mit in die Applikation gelinkt, aber logisch ist er natürlich ein Bestandteil des Betriebssystems. Weiß nicht, wie das bei Win32 organisiert ist.) (JTAG ICE via RS-232) >> Ungefähr halb so schnell wie mit USB. > Mir viel ein, daß es vielleicht gaarnicht langsamer ist? Oft wird > bei USB ja doch nur ein Wandler zu einem UART eingesetzt und läuft > dann genauso langsam, hat aber USB. Nee, es ist hier kein RS-232-Wandler, es ist schon ein echter USB-Interface-Chip. Aber es ist eben auch keine Größenordnung schneller, die RS-232 wird bei den Atmel-Geräten (JTAG ICE, STK500) ohnehin immer mit 115200 Bd benutzt. Bei USB vertrödelt man einiges mit Paketierungs-Overhead und Latenzen.
Jörg Wunsch wrote: > Hans-joachim Borchers wrote: > >>> Nö, Winzigweich lässt grüßen. Der dynamische Linker unter Unix >>> sagt sehr wohl, was ihm fehlt. > >> Ja so können die Softies auch sein :-) Aber wenn ich ein Programm >> für ein Betriebssystem schreibe, dann muß ich dessen Schwächen auch >> berücksichtigen. > > Geht nicht: Henne-und-Ei-Problem. Das Programm startet ja gar nicht, > weil ihm die shared lib fehlt, also kann sich das Programm auch nicht > selbst drum kümmern. Das muss mehr oder minder der dynamic loader > tun. (Technisch ist der bei Unix mit in die Applikation gelinkt, aber > logisch ist er natürlich ein Bestandteil des Betriebssystems. Weiß > nicht, wie das bei Win32 organisiert ist.) Da muß ich Dir doch mal widersprechen. Ganz genau weiß ich das auch nicht. Aber man kann das Vorhandensein der Lib prüfen und auch ob sie geladen werden kann. Und dann wüßte man, ob man MIT FEHLERMELDUNG abbrechen soll. Ganz so blöd ist Windows nun doch nicht. Ich weiß aus eigener Erfahrung, das Programme auch Fehler melden, wenn ihnen eine DLL fehlt. > > (JTAG ICE via RS-232) > >>> Ungefähr halb so schnell wie mit USB. > >> Mir viel ein, daß es vielleicht gaarnicht langsamer ist? Oft wird >> bei USB ja doch nur ein Wandler zu einem UART eingesetzt und läuft >> dann genauso langsam, hat aber USB. > > Nee, es ist hier kein RS-232-Wandler, es ist schon ein echter > USB-Interface-Chip. Gut, die Info habe ich nicht. > Aber es ist eben auch keine Größenordnung > schneller, die RS-232 wird bei den Atmel-Geräten (JTAG ICE, STK500) > ohnehin immer mit 115200 Bd benutzt. Bei USB vertrödelt man einiges > mit Paketierungs-Overhead und Latenzen. Ja so ist das mit dem neumodischen Krams ;-) Joachim
Hans-joachim Borchers wrote: > Ganz genau weiß ich das auch nicht. Aber man kann das Vorhandensein der > Lib > prüfen und auch ob sie geladen werden kann. Und dann wüßte man, > ob man MIT FEHLERMELDUNG abbrechen soll. Ganz so blöd ist Windows > nun doch nicht. Ich möchte aber nicht den dynamischen Linker in der Applikation nachbauen, nur weil die Betriebssystemimplementierung zu blöd ist dazu. Aber wenn dafür einer einen Patch für avrdude schreiben will: nur zu. Ich hab' keine Ahnung von Windows (und will es auch nicht benutzen müssen). Bei AVaRICE ist die Sache noch ein wenig anders, da das alles auf Cygwin aufsetzt. AVaRICE selbst hat praktisch keine Ahnung davon, dass sein Posix-API in Wirklichkeit eine Emulation unter Win32 ist. Hier müsste es also, wenn schon, dann Cygwin erledigen, das zu vermelden.
Jörg Wunsch wrote: > > Ich möchte aber nicht den dynamischen Linker in der Applikation > nachbauen, nur weil die Betriebssystemimplementierung zu blöd ist > dazu. Brauchst Du auch nicht. Du sollst ja auch nur den Return-Code der entsprechenden Funktion auswerten. 2 Zeilen Code :-) Man kann das ohne Problem und OHNE VIEL AUFWAND handeln. Unter Windows kann man statisch und auch dynamisch linken. Und bei beiden gibt es Fehlercodes ob das geklappt hat und man kann dann den Anwender mt einer Fehlermeldung darauf hinweisen. Windows schmeißt in einigen Fällen auch automatisch eine Meldung. Nun es kommt halt ganz auf den Anwendungsfall an, aber die Diskussion wird zu lang und wird dann auch OT :-) räusper Höre ich da eine starke Abneigung gegen Windows ;-) Wobei ich kein Windows-Fan bin, nur so schlecht ist es nun doch nicht. Oft ist eher Unwissenheit der Linux-User über Windows die sehr stark dagengegen sind. > > Aber wenn dafür einer einen Patch für avrdude schreiben will: nur zu. > Ich hab' keine Ahnung von Windows (und will es auch nicht benutzen > müssen). :-) siehe oben :-) > Hier müsste es also, wenn schon, dann Cygwin erledigen, das zu > vermelden. Könnte man so machen.
Hans-joachim Borchers wrote: > Brauchst Du auch nicht. Du sollst ja auch nur den Return-Code > der entsprechenden Funktion auswerten. Welchen Return-Code? Ich mache hier nichts explizit. Die DLLs sind vom Linker so vorgekaut, wenn main() aufgerufen wird, müssen sie schon im VM-Adressraum präsent sein. Alles davor geht mich aus Sicht der Applikation nüscht an, da habe ich keinen Einfluss drauf. Was du meinst, wäre ein explizites dlopen() bzw. dessen Äquivalent unter Win32, aber das macht avrdude nicht. Daher schrob ich ja, dass ich diesen Anteil der Arbeit vom runtime loader erwarten würde. (So ist es unter Unix jedenfalls, der macht nämlich auch weiter nichts als dlopen() für die einzelnen Bibliotheken, deren Namen der Linker im ELF hinterlassen hat.)
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.