Hier ist ein selbstgebastelter usbtiny Programmieradapter (Bus 001 Device 004: ID 1781:0c9f Multiple Vendors USBtiny), der frueher auch schon im Einsatz war und ein recht frisch zusammenkompiliertes BLFS-12.2.
Jetzt wollte ich mir da einen avrdude-8.0 bauen. Das hat mit dem fiesen build.sh script prinzipiell geklappt, es fiel auch ein avrdude hinten raus. Nur mosert der:
1
avrdude -c usbtiny -pt13 -U flash:w:bla.hex
2
Error: no usb support; please compile again with libusb installed
3
Error: unable to open port usb for programmer usbtiny
4
5
Avrdude done. Thank you.
Ich hab irgendwas im Hinterkopf, dass aeltere avrdudes nicht nur die libusb-1.0.x sondern auch noch die libusb-0.1.x brauchten
Ist das immernoch so?
Die libusb-1.0.27 hab' ich, die libusb-0.1.12 laesst sich mit dem gcc-14.2.0 von BLFS12 nicht bauen, alldieweilen er diverse "Sauereien" nicht mehr durchgehen laesst:
1
linux.c:377:27: error: '%s' directive output may be truncated writing up to 4096 bytes into a region of size 1006 [-Werror=format-truncation=]
Danke fuer die Tipps. Insbesondere den beiden Stephanenden, wo sofort klar ist, dass sie die eigentliche Problematik messerscharf erkannt haben.
OK, avrdude-8.0 braucht also unter Linux libusb-1.x und libusb-0.y.
Ist nur die libusb1.x da und keine libusb-0.y kommt halt die Fehlermeldung: no usb support; please compile again with libusb installed
-> Vielleicht da mal ueber eine kleine Texterweiterung nachsinnen?
Anbei ein fieser patch, der die Gscheidhaferligkeit des gcc14 durch sinnlos vergroesserte Buffer umgeht. Damit kompiliert die libusb-0.1.12, in Folge tut dann auch der avrdude.
OK, avrdude-8.0 braucht also unter Linux libusb-1.x und libusb-0.y.
Hat nichts mit Linux zu tun. Das liegt einfach daran, auf welchem der APIs die jeweiligen Implementierungen aufsetzen. Die meisten setzen auf dem 0.1 API auf (hat sich halt nie jemand gefunden, der sie hätte neu schreiben wollen), lediglich CH341 wurde für das 1.0 API geschrieben, USBasp kommt wahlweise mit 0.1 oder 1.0 aus, und FT245 kann entweder libusb 1.0 oder libftdi nehmen.
Anbei ein fieser patch
Ziemlich wirr. Einfach wahllos Puffer vergrößert, mal 2 * PATH_MAX, ein andermal 3 *, dann 4 *, und eine völlig aus der Luft gegriffene Zahl für einen globalen Puffer.
Was ist denn eigentlich genau das Problem beim Compilieren? Den größeren Puffer für den error string kann ich mir vorstellen, wenngleich gewiss niemand 10 Kilobyte braucht, aber bei den Dateinamen verstehe ich das gar nicht. So lang können die nicht sein, die sind doch irgendwo unter sysfs bei Linux.
Dem Compiler sollte das sowieso egal sein, aber kann natürlich sein, dass der Laufzeittest auf überlaufende Puffer (mal wieder) fehlt.
Ziemlich wirr. Einfach wahllos Puffer vergrößert, mal 2 * PATH_MAX, ein
andermal 3 *, dann 4 *, und eine völlig aus der Luft gegriffene Zahl für
einen globalen Puffer.
Der Faktor haengt damit zusammen, wieviele strings im snprintf zu einem neuen verwurstet werden.
Ich sag' ja: Ein fieser patch.
Nur grad soviel, dass make durchlaeuft und ich dann sicher weiss, ob tatsaechlich die libusb-0.x die Sache fixt. Haett' ich den patch hier nicht angepappt, sondern nur geschrieben: "Prima, jetzt gehts" haette sich sicherlich mindestens wieder einer auf den Schlips getreten gefuehlt.
Was ist denn eigentlich genau das Problem beim Compilieren?
Steht im 1. Post, hier noch mal deutlich: make bricht beim bauen der libusb-0.1.12 ab, weil gcc(14.2.0) mit einer Fehlermeldung (siehe 1. Post) abbricht.
So wie ich das sehe, hat gcc "Angst", dass strings abgeschnitten werden. Pufferueberlaeufe wirds da auf den ersten Blick eher nicht geben.
Die gcc-Konstrukteure haben da jetzt ein paar Sachen fest eingebaut, mit denen sich gcc standardmaessig so verhaelt, wie wenn er "frueher" mit -Werror gestartet worden waere. (Und wo ich mich tlw. wundere, wie lange gcc das einfach so mitgemacht hat; das stringverarbeitungsgedoens hier gehoert nicht dazu)
Noch besser waere es ohnehin, nicht mehr in altem Code rumzuruehren, den
seit >18 Jahren keiner mehr angefasst hat, weil's eine neue lib gibt.
Das hilft nichts, wenn das neue API halt vollständig inkompatibel mit dem vorherigen ist und die Leute da schon eine Menge Arbeit reingesteckt haben.
Aus gutem Grund liefert die (OS-eigene) libusb bei FreeBSD sowohl das 0.1 als auch das 1.0 API (und noch ein weiteres, FreeBSD-eigenes, das sie 2.0 getauft haben). Der Code, der 0.1 verwendet, schreibt sich halt nicht von selbst um, und bloßes Umschreiben von Code, nur weil jemand ein schickeres API gemacht hat, ohne dass dabei sonst ein Mehrwert entstünde, gehört nicht unbedingt zu den Tätigkeiten, bei denen die Freiwilligen sofort alle nach vorn stürmen würden …
Kleiner Nachtrag: bei den diversen Pfadnamen wäre es auch völlig
legitim, snprintf() zu benutzen, um so den sich ergebenden String zu
limitieren.
Ja, das wird dort auch genauso gemacht. Hab' grad nochmal druebergeschaut: Es liegt nicht am picky gcc14, sondern es liegt daran, dass die libusb-0 Entwickler das Ding mit -Werror kompilieren. Was ja nun in der release nicht unbedingt clever ist, weils genau solche Probleme mit immer schlauer werdenden Compilern triggert.
Man kann das -Werror auch aus dem Makefile[,.am] rausbauen, dann laeufts auch ohne meinen fiesen Patch.
Dem gcc faellt nur auf, dass bei der snprintf() Operation was abgeschnitten werden kann. Also nix mit bufferoverflow oder so.
Aber egal was: Irgendwas muss an der ollen libusb-0 angefasst werden, damit das mit aktuellem gcc tut.
es liegt daran, dass die libusb-0 Entwickler das Ding mit -Werror
kompilieren
Das dürfte dann eine Zeile über dem von dir zitierten Text gestanden haben. ;-) "Warnings treated as errors" oder sowas.
Aber egal was: Irgendwas muss an der ollen libusb-0 angefasst werden,
damit das mit aktuellem gcc tut.
Angesichts dessen, dass das 0.1er API halt nach wie vor eine Bedeutung hat, könnten sie auch mal eine neue Version davon veröffentlichen, die genau das korrigiert. Man kann sich ja gern wünschen, dass alle auf die 1.0 aufspringen, aber wie wir sehen, passiert das davon allein eben nicht.
Angesichts dessen, dass das 0.1er API halt nach wie vor eine Bedeutung
hat, könnten sie auch mal eine neue Version davon veröffentlichen, die
genau das korrigiert.
Das koennte man machen. Hast du spontan ein Projekt ausser avrdude im Kopf, was die libusb-0 noch braucht?
Ich bau' ja dann und wann gerne mal ein BLFS und da ist die libusb-0 nach BLFS-6.3 (August2008) aus "dem Buch" rausgeflogen. Und mir faellt's eben erst jetzt auf, dass die aktuell noch wer braucht...
Hast du spontan ein Projekt ausser avrdude im Kopf, was die libusb-0
noch braucht?
Nö, kann ich auch schlecht testen, weil es bei den FreeBSD-Ports ja nie als Abhängigkeit auftaucht, da das API vom OS bereitgestellt wird. (Dort kann ich nur Abhängigkeiten von 3rd-Party-Software verfolgen.)
Aber letztlich jeder, der mal irgendwann irgendwas für 0.1 geschrieben hat, was dann "einfach so läuft". Never change a running system und so … Klar ist das 1.0er API besser (durchdacht), aber wenn man irgendwas hat, was mit 0.1 bereits funktioniert, hat das andere API keinerlei Mehrwert.
Hast du spontan ein Projekt ausser avrdude im Kopf, was die libusb-0
noch braucht?
Nö, kann ich auch schlecht testen, weil es bei den FreeBSD-Ports ja nie
als Abhängigkeit auftaucht, da das API vom OS bereitgestellt wird. (Dort
kann ich nur Abhängigkeiten von 3rd-Party-Software verfolgen.)
Ich hänge mich da mal rein weil ich gerade avrdude mit winusb als Treiber teste. Die alte v6.3 arbeitet nicht mit winusb die v8 schon. Andere Versionen hab ich nicht probiert. Avrdude6.3 habe ich sowohl mit libusbk.sys als auch mit libusb0.sys benutzen können.
"Please note that libusb-win32 and libusbK are separate projects. libusb-win32 is a Windows-only project which provides a libusb-0.1 API compatible library for Windows and the associated kernel driver libusb0.sys."
Generell finde ich es schwierig bei libusb die Versionen auseinander zu halten (unter Windows). Kann es sein dass unter win die 0.1 API notwendig ist wenn winusb verwendet wird?
nun winusb ist seit W7 fester Bestandteil von Windows. Es gibt wohl sogar backports auf XP. Ich benutze winusb deshalb sehr gerne weil man den Treiber automatisch laden kann (ohne inf, ohne Zertifizierung), genauso wie es bei Klassentreiber üblich ist. Dazu muss man nur etwas Arbeit in die FW stecken. Viele neuere Geräte arbeiten inzwischen so. Man sieht ja auch hier dass User damit überfordert sind einen Usbtreiber zu installieren.
Man sieht ja auch hier dass User damit überfordert sind einen Usbtreiber
zu installieren.
Für User ist es ohne ordentliche Doku schwer zu erkennen, welche Treiber zum Gerät passen und welche Software zu welchem Treiber passt. Beide Voraussetzungen müssen gleichzeitig erfüllt werden. Wenn nicht, bekommt der Anwender oft unverständliche Fehlermeldungen angezeigt.
Erschwerend kommt dazu, dass die meisten Programmieradapter ohne Treiber und ohne Software verschickt werden. Der Anwender muss selbst heraus finden, welche Software zum Gerät passt und welcher Treiber zu Software + Gerät passt.
Selbst Atmel und Microchip halten sich mit der entsprechenden Dokumentation sehr zurück. Man findet lediglich Kompatibilitätslisten zwischen deren IDE und Programmieradapter (ohne Hinweise zu Treibern), die jedoch stets unvollständig sind.
Die unterschiedliche gepatchten Versionen avrdude haben ebenfalls zur Verwirrung beigetragen. Das es so etwas wie das Zadig Tool überhaupt gibt, ist schon ein Unding. Es sollte in einer heilen IT Welt völlig unnötig sein.
Ich denke, die Hauptschuld liegt hier bei Microsoft, die nach libusb0 (libusb-win32) gleich zwei inkompatible Treiber auf den Markt geworfen haben. Aber so sind wir es ja von MS gewohnt.
Ich denke, die Hauptschuld liegt hier bei Microsoft, die nach libusb0
(libusb-win32) gleich zwei inkompatible Treiber auf den Markt geworfen
haben. Aber so sind wir es ja von MS gewohnt.
Seit wann kommt denn LibUSB von Microsoft? Also die machen ja vieles seltsames, aber doch keine LibUSB.
Von MS kommt WinUSB und der Treiber klappt seit Jahren bestens.
So habe ich das nicht gemeint. libusb0 (libusb-win32) war der erste Treiber dieser Art. Von Microsoft gab es bis dato noch keinen.
Danach hat Microsoft libusbK und danach winusb zum Windows hinzugefügt. Beide implementieren das "missing Feature", aber auf inkompatible Art zum jeweiligen Vorgänger.
LibusbK ist doch aber auch nicht von Microsoft. Auch wenn es sich da installieren lässt und ein Winusb kompatibles API hat.
Oder wie meinst du das?
WinUSB ist natürlich nicht plattformunabhängig, ich glaub das war nicht das Ziel von MS dabei. Man muss ja schon froh sein, dass sie sowas überhaupt auf die Reihe bekommen haben.
muss es gar nicht sein. So wie ich das sehe wurde die Kompatibitätsschicht in libusb eingezogen Stefan hat die Stellen weiter oben gezeigt: libusb 1.0.09 bzw libusb 1.0.13.
Deswegen kann ich AvrDude 8.0 auch mit allen drei Treibern benutzen. Weil ich mir das nicht so recht erklären konnte hab ich mich in diesem Thread gemeldet.
Ich habe übrigens mit dem usbASP Backend getestet.
Leider hat bekomme ich die Zadig Installation jetzt nicht mehr aus dem System raus. Aber ich wusste vorher schon dass Zadig potentiell gefährlich ist.
Mein Ziel ist ein Compound Device Interface 0 auf winusb Interface 1+2 auf CDC. Das soll automatisch passieren und funktioniert auch mit einer frischen VID PID Combo. Nur mit der Original VID/PID von Fischl klappt das nicht mehr. Da muss wohl noch ein Registry Eintrag vorhanden sein den ich übersehe.
Nur mit der Original VID/PID von Fischl klappt
das nicht mehr
so ich hab es hinbekommen. Es funktioniert nun wie erwartet. Es gibt nur zwei kleine Einschränkungen:
wegen dem Compount device muss ich die mingw Variante von avrdude verwenden
AvrDude muss auf usbasp-clone stehen
Da ich bei meinem Device die Seriennummer vergeben habe ist auch ein abwechselnder Betrieb mit einem Fischl Device möglich. Die Installationen stören sich nicht. usbasp-clone ist notwendig da sich mein Device nicht mit www.fischl.de meldet. Das ist notwendig um die Lizenzbedingung bezüglich VID/PID zu erfüllen.
In allen Fällen wird winusb als Treiber verwendet.
