Moin,
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=]
Dergute W. schrieb:> Ich hab irgendwas im Hinterkopf, dass aeltere avrdudes nicht nur die> libusb-1.0.x sondern auch noch die libusb-0.1.x brauchten
Ältere Versionen werden sich bestimmt nicht von selbst verändern. Wenn
das damals stimmte (was ich annehme), dann wird das wohl immer noch so
sein.
Kannst du nicht einfach das Paket libusb-dev (0.1.x) installieren? Dann
musst du sie nicht "bauen", denn das hat schon der Linux Distributor
erledigt.
Sherlock 🕵🏽♂️ schrieb:> Kannst du nicht einfach das Paket libusb-dev (0.1.x) installieren? Dann> musst du sie nicht "bauen", denn das hat schon der Linux Distributor> erledigt.
Sowohl bei Debian als auch Ubuntu sind libusb-1.0-0 und libusb-0.1-4 in
den Paketquellen enthalten.
Moin,
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.
Gruss
WK
Dergute W. schrieb:> 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.
Moin,
Jörg W. schrieb:> 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)
Gruss
WK
Dergute W. schrieb:> Steht im 1. Post,
OK, nochmal gelesen (vorher nur auf dem Handy geguckt und nicht alles so
überblickt).
Damit hätte es aber genügen sollen, diesen error-String auf 4096
aufzuweiten.
Besser wäre es ohnehin, die Größe dynamisch zu machen, aber das ist 'n
anderer Punkt.
Moin,
Jörg W. schrieb:> Besser wäre es ohnehin, die Größe dynamisch zu machen, aber das ist 'n> anderer Punkt.
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.
Jörg W. schrieb:> (hat sich halt nie jemand gefunden, der sie hätte neu> schreiben wollen)
Jaa, ich kenne die Problematik... :-)
Gruss
WK
Dergute W. schrieb:> 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 …
Jörg W. schrieb:> Dergute W. schrieb:>> Steht im 1. Post,>> OK, nochmal gelesen (vorher nur auf dem Handy geguckt und nicht alles so> überblickt).>> Damit hätte es aber genügen sollen, diesen error-String auf 4096> aufzuweiten.
Kleiner Nachtrag: bei den diversen Pfadnamen wäre es auch völlig
legitim, snprintf() zu benutzen, um so den sich ergebenden String zu
limitieren.
Moin,
Jörg W. schrieb:> 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.
Gruss
WK
Dergute W. schrieb:> 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.
Moin,
Jörg W. schrieb:> Das dürfte dann eine Zeile über dem von dir zitierten Text gestanden> haben. ;-) "Warnings treated as errors" oder sowas.
Nee, ganz so einfach - bzw. ganz so blind bin ich/war es nicht.
Jörg W. schrieb:> 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...
Gruss
WK
Dergute W. schrieb:> 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.
Jörg W. schrieb:> Dergute W. schrieb:>> 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.
unter https://github.com/libusb/libusb/wiki/Windows habe ich nun
folgendes gesehen:
"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?
Thomas Z. schrieb:> Kann es sein dass unter win die 0.1 API> notwendig ist wenn winusb verwendet wird?
Als ich diesbezüglich mal Nachforschungen anstellte, kam ich zu diesem
Schluss:
libusb-win32 ist offenbar das kompatible Pendant zur libusb von Linux.
Dann führte Microsoft den winusb Treiber ein. Programme, die mit libusb
ab v1.0.9 compiliert wurden unterstützen den winusb Treiber.
(https://github.com/libusb/libusb/blob/master/ChangeLog#L272)
Programme, die mit libusb ab v1.0.13 compiliert wurden, unterstützen die
Treiber winusb, libusb-win32 und libusbK.
(https://github.com/libusb/libusb/blob/master/ChangeLog#L234)
LibusbK kannte ich noch nicht, habe ich gerade zum ersten mal von
gelesen.
Sherlock 🕵🏽♂️ schrieb:> Dann führte Microsoft den winusb Treiber ein.
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.
Thomas Z. schrieb:> 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.
Thomas Z. schrieb:> Kann es sein dass unter win die 0.1 API notwendig ist
Die meisten der Backends in Avrdude sind für 0.1 geschrieben, und es hat
sich nie jemand gefunden, sie auf 1.0 anzupassen.
Das ist unabhängig vom OS.
Sherlock 🕵🏽♂️ schrieb:> 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.
Christian R. schrieb:> Seit wann kommt denn LibUSB von Microsoft?
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.
Christian R. schrieb:> 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?
Ich meinte, dass LibusbK von Microsoft kommt. Kann sein, dass ich damit
falsch liege.
Jörg W. schrieb:> … und insbesondere nicht plattformunabhängig.
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.
Das hab ich benutzt:
Beitrag "Usb BOS descriptor"
Im Anhang mein UsbTreeView Output
Thomas Z. schrieb:> 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.
Thread beobachten
Seitenaufteilung abschalten