Habe den neuen Arduino UNO R4 zu programmieren versucht und bin nur unter Linux erfolgeich. Obwohl die Arduino-IDE unter Win10(64) dieselbe Version von dfu-util verwendet (0.11-arduino4) wie unter Linux, wird das Board unter WIN10 nicht erkannt. Bevor ich jetzt herumsuche, wie man bei dfu-util ein Ticket aufmacht (habe sowas noch nie gebraucht), möchte ich erstmal nachfragen, wie es Anderen mit dem Board ergeht umd ob ich eventuell der Einzige bin, der sich irgendwo zu dumm anstellt. Gruß Klaus (der soundsovielte) 64-bit Win10 Pro Vers. 22H2 Arduino IDE 1.8.19 R4-Libraries von heute zugehörige virtuelle COM-Ports werde in der IDE und im Gerätemanager immer angezeigt.
Klaus S. schrieb: > wie es Anderen mit dem Board ergeht umd ob ich > eventuell der Einzige bin, der sich irgendwo zu dumm anstellt. Bei mir hat es Treiber installiert! ......\packages\arduino\hardware\renesas_uno\1.0.1\drivers Und da die richtige EXE aufrufen. Da ich keine passende Hardware habe: Ohne Gewähr.
Angehängte Dateien:
-
UNO_R4.PNG
70 KB
Arduino F. schrieb: > Bei mir hat es Treiber installiert! Bei mir auch. > Und da die richtige EXE aufrufen. Seit wann macht die Arduino-IDE das nicht selbst? In der Datei post-install.bat wird dpinst-amd64.exe viermal mit %ARGS% aufgerufen, das sieht nicht so aus, als müßte man es nochmal manuell aufrufen. Falls sich jemand genauer mit dem DFU-Protokoll auskennt, habe ich die Fehlermeldung von dfu-util und den erweiterten Teil von usbview in die Textdatei UNO_R4.txt gepackt. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Seit wann macht die Arduino-IDE das nicht selbst? Macht sie, wenn man sie lässt. Es ist allerdings auch eine manuelle Installation von Hardware Definitionen und zugehörigen Compilern möglich. Dann gibts den Automatismus nicht und die Treiber liegen ungenutzt auf der Platte rum. Leider hast du dich nicht über deine Installationsmethode ausgelassen.
:
Bearbeitet durch User
Arduino F. schrieb: > Es ist allerdings auch eine manuelle Installation von Hardware > Definitionen und zugehörigen Compilern möglich. > Dann gibts den Automatismus nicht und die Treiber liegen ungenutzt auf > der Platte rum. > > Leider hast du dich nicht über deine Installationsmethode ausgelassen. Das überrascht mich jetzt. Habe noch nie von manueller Installation gehört oder gelesen. Ich kenne nur den Unterschied zwischen fester und portabler Installation (die Letztere nutze ich). Dabei wird aber bei erstmaligem Start der IDE alles automatisch eingerichtet, ist also nicht manuell. Das hat bisher für viereinhalb verschiedene CPU-Familien ohne größere Aussetzer geklappt (die einzige Ausnahme war eine race-condition in Dan Drowns/Roger Clarkes STM32-Installation). Könntest Du das etwas näher erläutern? Nach meinen bisherigen Erfahrungen werden die Treiber für ein Board in dem Moment eingerichtet, in dem die dazugehörigen Programme und Libraries im Boardverwalter aus dem Internet geladen werden. Gruß Klaus (der soundsovielte) P.S. Die angehängte Textdatei zeigt den Unterschied von dfu-util unter Linux mit und ohne die nötigen Zugriffsrechte. Der Text für die Situation ohne Zugriffsrechte sieht genauso aus, wie die Textausgabe unter Win10. Deswegen ist meine bisherige Vermutung: Rechteproblem!
Klaus S. schrieb: > Könntest Du das etwas näher erläutern? Manche Hardwaredefinitionen sind nicht über den Boardmanager erreichbar. z.B. Manche erstellt man selber, oder Kumpels, oder dümpeln frei im Netz rum, z.B. bei Github In deinem stetchbook Ordner gibt es einen Ordner namens hardware. Genau der ist für die manuelle Installation gedacht. Zudem ist der Ordner gegen Updates geschützt. Es macht also sogar manchmal Sinn, Hardware Definitionen händisch da rein zu werfen, selbst wenn sie über den Boardmanager erreichbar wären. Libraries kann man anders vor Updates schützen, Board Definitionen nur so. ---- Zu deinem eigentlichen Problem kann ich nichts sagen, da ich weder die Hardware habe und nur oberflächliche Kenntnisse zu den Win USB Gedönse.
Klaus S. schrieb: > Fehlermeldung von dfu-util und den erweiterten Teil von usbview in die > Textdatei UNO_R4.txt gepackt nö hast du nicht in die txt soltest du alles was usbtreeview ausgibt reinpacken. Was ich erkennen kann ist ein Compound Device aus CDC + irgendwas Arduino F. schrieb: > Zu deinem eigentlichen Problem kann ich nichts sagen, da ich weder die > Hardware habe und nur oberflächliche Kenntnisse zu den Win USB Gedönse. Win USB ist im Prinzip das gleiche wie libusb unter linux. Die funktionierende linux version verwendet ja libusb. Ich würde jetzt mal vermuten dass dies unter Win auch so sein sollte, weil man ja sonst 2 apps machen müsste eine für linux mit libusb und eine für Win mit WinUsb. @Klaus zeige den kompletten output als txtfile.
Thomas Z. schrieb: > @Klaus zeige den kompletten output als txtfile. Dann habe ich irgendwas falsch verstanden. Ich habe aus den WindowsKit\10\Debuggers\amd64\usbview.exe aufgerufen. Dann wird in der linken Spalte das ganze USB-Geraffel untereinander aufgetragen und wenn ich dann den Port für meinen Arduino lokalisiert habe und den anwähle, taucht in der rechten Spalte die Information zu diesem einen Anschluß auf. Dieser Text taucht zum Teil im Bild auf, der gesamte Text steht in der Datei UNO_R4.txt hinter der Ausgabe von dfu-util und dem Doppelstrich ====================. Was sollte anders laufen? Gruß Klaus (der soundsovielte)
Arduino F. schrieb: > Manche Hardwaredefinitionen sind nicht über den Boardmanager erreichbar. > z.B. Manche erstellt man selber, oder Kumpels, oder dümpeln frei im Netz > rum, z.B. bei Github Okay, wieder was dazugelernt. Danke für die Erläuterung, jetzt weiß ich, wovor ich mich hüten sollte. Ich benutze die Arduino-IDE nur als "Idiotenhügel", wie man wohl bei den Skifahrern sagt. Wenn es ganz ernst wird, mutiere ich zum Assemblerfan mit bare-metal Vorliebe :-)) Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Dann habe ich irgendwas falsch verstanden. Ich habe aus den > WindowsKit\10\Debuggers\amd64\usbview.exe aufgerufen. nicht das MS Tool benutzen! Das ist buggy und unvollständig. Benutze UsbTreeView von Uwe Sieber https://www.uwe-sieber.de/usbtreeview_e.html
Klaus S. schrieb: > jetzt weiß ich, wovor ich mich hüten sollte. Wieso? Welche Probleme siehst du da? Das ist einer der vorgesehenen Wege. Vielleicht nicht der "übliche", aber doch voll im Plan.
Arduino F. schrieb: > Wieso? > Welche Probleme siehst du da? Keine. Aber jeder hat andere Vorstellungen und Wünsche, ich bin einfach nur Minimalist. Für mich ist ein Entwicklungstool erfreulich, wenn es nicht größer als 1MByte ist. Bei 10 MByte gehts grad noch so und alles darüber ist mir erstmal suspekt. Schon mal Rebol als Programmiersprache versucht? Ein MByte. Arduino ist weit drüber, hat aber aus meiner Sicht den Vorteil, daß es nach ganz kurzer Eingewöhnzeit stinkensimpel zu bedienen ist und ganz unkompliziert einfach funktioniert. Irgendwelche Klimmzüge damit zu machen, wäre einfach nicht meins. Die mach ich dann lieber "bare metal" und in Assembler, hat selbst beim Raspi gut geklappt. Das darf ja erfreulicherweise jeder für sich entscheiden. Schon Platform-I/O ist mir im Moment viel zu kompliziert, solange ich keine besseren Beschreibungen finde. Ein Tool wie dfu-util ist gerade noch in der Größe, daß es mir Vergnügen macht, mich in eine Fehlersuche reinzuhängen. GCC? Käme mir gar nicht in den Sinn. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Ich kenne nur den Unterschied zwischen fester und > portabler Installation (die Letztere nutze ich). Damit hat jeder normal denkenden Mensch die Erklärung: Eine portable Version hat nicht von sich aus auf dem System herunzusauen, da ist die manuelle Treiberinstallation durchaus konsequent.
Manfred P. schrieb: > da ist die > manuelle Treiberinstallation durchaus konsequent. Wenn man den Boardsmanager nutzt, werden die Treiber automatisch installiert. Ihm fragt nach Erlaubnis. Man kann da also "versehentlich" auf nein drücken.
Angehängte Dateien:
-
UNO_R4.PNG
140 KB
Thomas Z. schrieb: > Benutze UsbTreeView von Uwe Sieber > https://www.uwe-sieber.de/usbtreeview_e.html Da bin ich wohl auf die ähnlich klingenden Namen reingefallen, genau dort war der Verweis auf usbview ganz am Anfang, und dem war ich gefolgt. Hier also mit usbtreeview (von ganz unten auf der Seite). Gruß Klaus (der soundsovielte)
1 | Child Device 2 : DFU-RT Port |
2 | Device ID : USB\VID_2341&PID_0069&MI_02\6&FFEEF30&0&0002 |
3 | Location : 0000.0014.0000.007.000.000.000.000.000 |
4 | LocationPaths : PCIROOT(0)#PCI(1400)#USBROOT(0)#USB(7)#USBMI(2)... |
5 | Problem : 28 (CM_PROB_FAILED_INSTALL) |
Für das 2. Device das DFU device ist kein Treiber installiert. (Fehlercode 28) Ich würde ja vermuten dass da libusb ran muss. Also Treiber installieren und alles wird gut:-) Edit: dieses Szenario wäre übrigens der ideale Kandidat für BOS DesKriptoren. Beitrag "Usb BOS descriptor" Damit könnte Win ohne weiteres Zutun den Treiber automatisch laden. Das wäre mit etwa 200 Byte code im Bootloader zu machen.
:
Bearbeitet durch User
Thomas Z. schrieb: > Also Treiber installieren und alles wird gut:-) Knapp vorbei ist auch daneben. Habe mit Zadigs Hilfe libUSB installiert. Jetzt meldet zumindest "dfu-util -l" die Boarddaten, kleiner Schritt vorwärts. Der Updatevorgang kommt ebenfalls einen Schritt weiter, das Board wird erkannt, "detach and reattach" wird ausgeführt, das Board geht in den Bootloadermodus und dann verliert dfu-util den Kontakt zum Board. Ist im 32-bit-Win10 genauso wie im 64-bit-Win10. Gruß Klaus (der soundsovielte) P.S. Den Bootloadermode erkennt man schön an der auf- und abschwellenden Helligkeit der "LED-BUILTIN".
Klaus S. schrieb: > Und das sagt usbtreeview zum Zustand im Bootloadermodus. Du hast mit zadig libusb auf das komplette device installiert d.h der Comport ist verschwunden das ist falsch. Deinstalier das wieder. Du hast ein Compount device. Das bedeutet auf unterschiedlichen Interfaces werden unterschiedliche Treiber verwendet. - Interface 0 + 1 CDC - Interface 2 DFU Zadig kann das auch.
:
Bearbeitet durch User
Klaus S. schrieb: > Habe mit Zadigs Hilfe libUSB installiert Du kannst auch statt dem libusb Treiber den WinUSB Treiber installieren. Das geht mit Zadig oder auch über den Gerätemanager. Sofern das dfu-util eine moderne libusb-Version nutzt (ggf. einfach die DLL austauschen), kommt die auch mit dem WinUSB-Treiber klar. Das könnte eventuell stabiler sein als der libusb-Treiber und braucht eben nur den Windows-eigenen WinUSB-Treiber. Klaus S. schrieb: > GCC? Käme mir gar nicht in den Sinn. Der ist aber bei Arduino mit dabei...
Thomas Z. schrieb: > Du hast mit zadig libusb auf das komplette device installiert d.h der > Comport ist verschwunden das ist falsch. Deinstalier das wieder. 1. Der Comport ist schon vor der Zadig-Aktion im Booloadermodus nicht vorhanden gewesen, er verschwindet regelmäßig, wenn man in den Bootloadermodus wechselt (was durch zweimaliges Drücken der Resettaste aus meiner Sicht sehr praxisnah gelöst ist). 2. Die Zadig-Aktion war eine Husch-Husch-Aktion, die ich normalerweise zu vermeiden trachte. Ich mußte aber zu einer Reparatur und daher etwas in Eile. Ich habe nichtmal richtig verstanden, was ich da mache und weiß schon gar nicht, wie ich das wieder rückgängig mache. Normalerweise würde ich jetzt tief Luft holen, zwei Schritte zurücktreten, die letzte Backupdatei herholen und alles Neue wegbügeln. Hättest Du einen Tip, wie es einfacher geht? Mit VCPs kenne ich mich einigermaßen aus, alles Andere ist "terra incognita". Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Hättest Du einen Tip, wie es einfacher geht? Das Gerät im Gerätemanager löschen, neu anstecken und von vorne anfangen.
Niklas G. schrieb: > Du kannst auch statt dem libusb Treiber den WinUSB Treiber installieren. > Das geht mit Zadig oder auch über den Gerätemanager. Da bin ich erst dabei, das Handling solcher Situationen zu lernen. Hatte ich bisher nie gebraucht. Tips für ein Tutorial (außer Youtube)? > Klaus S. schrieb: >> GCC? Käme mir gar nicht in den Sinn. > Der ist aber bei Arduino mit dabei... Gemeint war die Verbesserung oder Fehlersuche, nicht die Benutzung. (Bin seit Jahren in der tcc-Mailingliste :-)) Gruß Klaus (der soundsovielte)
Niklas G. schrieb: > Das Gerät im Gerätemanager löschen Scheibchenweise werden die Infos rausgegeben, danke erstmal. Nächste Scheibe: Wo da? Unter USB-Geräte? Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Tips für ein Tutorial (außer Youtube)? Klaus S. schrieb: > Scheibchenweise werden die Infos rausgegeben, danke erstmal. Ach komm, der Gerätemanager ist ein grafisches Tool, da kann man sich durchklicken bis man es findet. Da braucht man kein Tutorial für. Ist ungefähr so kompliziert wie eine Datei zu löschen.
Niklas G. schrieb: > Ach komm, der Gerätemanager ist ein grafisches Tool, da kann man sich > durchklicken bis man es findet. Da braucht man kein Tutorial für. Ist > ungefähr so kompliziert wie eine Datei zu löschen. Also dann im Klartext: Der Gerätemanager ist nur die Oberfläche, die Windows dem unbedarften Bediener zeigt, um sich notdürftig zu helfen. Mich interessiert, wo Windows Dateien zu Treiberzwecken hinschreibt, in welchen Dateien es sich Treiberinformationen merkt und wie man verhindern kann, daß Windows irgendwelche Treiberdateien thesauriert und bei Gelegenheit wieder hervorholt. Sowas passiert gemäß Lebenserfahrung immer genau in dem Moment, in dem man es am wenigsten brauchen kann (Prinzip der maximalen Gemeinheit). Das wären die nächsten 3 Scheibchen gewesen. Die sind alle genau so leicht, wie das Löschen einer Datei, weil sie das Löschen einer Datei sind. Die notwendige Info wäre eben: welche Datei. Mein universelles Brutalmittel System-Backup löst alle diese Probleme (wie auch viele andere). Ich hätte aber vielleicht gern eine Prozedur, die spezifischer ist und der ich mehr vertraue, als dem Gerätemanager. Dem System-Backup vertraue ich :-)) Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Mich interessiert, wo Windows Dateien zu Treiberzwecken hinschreibt, in > welchen Dateien es sich Treiberinformationen merkt und wie man > verhindern kann, daß Windows irgendwelche Treiberdateien thesauriert und > bei Gelegenheit wieder hervorholt. Das mag Dich interessieren, Windows aber schützt sich vor oberschlauen im-Dateisystem-Herumpfuschern. Man kann den Gerätemanager dazu bekommen, auch im Moment nicht installierte Geräte anzuzeigen, und bei denen lässt sich dann auch der Treiber deinstallieren. Da das eine ziemliche Klickorgie ist, sind hier die Tools von Uwe Sieber zu empfehlen.
Klaus S. schrieb: > Mich interessiert, wo Windows Dateien zu Treiberzwecken hinschreibt Irgendwo nach C:\Windows. Klaus S. schrieb: > Die notwendige Info wäre eben: > welche Datei. Das ist nicht einfach nur eine Datei. Da sind noch diverse Registry-Keys, die man selbst als Admin nicht löschen kann. Das ist also ein relativ komplexer Vorgang. Der wird vom Kernel durchgeführt. Unter laufendem Windows kann man das vermutlich sowieso nicht nachbilden, dazu müsste man wohl von einem Live-Linux aus drauf zugreifen. Der Geräte-Manager ist lediglich ein dünner Wrapper um die Win32-API-Funktionen, die den Kernel zur Treiber-Installation/Deinstallation veranlassen. Du möchtest also deinen eigenen Gerätemanager implementieren? Grad ging's noch um Arduinos? Jedenfalls hatte ich solche Probleme noch nie, selbst mit eigen-entwickelten Geräten. Daher hab ich da auch keinen Überblick, was da Windows-Intern alles passiert. Warum auch. Man kann im Gerätemanager alles machen was man dafür braucht (wobei die eigentliche Datenverwaltung im Kernel passiert), wie eben Geräte löschen. Du kannst die entsprechende Win32-API-Funktion selbst aufrufen wenn du deinen eigenen Geräte-Manager implementierst: https://learn.microsoft.com/en-us/windows/win32/api/newdev/nf-newdev-diuninstalldevice Macht dann halt das Gleiche wie der normale Geräte-Manager, die eigentliche Arbeit macht der Kernel. Klaus S. schrieb: > Also dann im Klartext: Der Gerätemanager ist nur die Oberfläche, die > Windows dem unbedarften Bediener zeigt, um sich notdürftig zu helfen. Der ist eher für Admins und Entwickler gedacht. Als unprivilegierter User kann man dort eh nur gucken, aber nichts ändern, dazu braucht es Admin-Rechte. Der zeigt auch viele gute Detail-Infos an. Einziges Manko (neben der altbackenen Benutzerführung): Er kann bei USB-Geräten die String-Deskriptoren nicht anzeigen...
:
Bearbeitet durch User
@Niklas @Harald Ich danke Euch für Eure Hilfsbereitschaft. Ihr habt mir zwar nichts erzählt, was ich nicht schon selbst praktiziert oder woanders gehört hatte, aber Euer Insistieren auf den hervorragenden Eigenschaften des Gerätemanagers hat mich zu ein paar Experimenten angeregt. Und tatsächlich, nachdem ich aus der Geräteklasse "libusb-win32" das zweite und letzte Gerät deinstallieren wollte, hat mir der Gerätemanager ein Kontrollkästchen zum Anwählen von "Treibersoftware löschen" angeboten. Das finde ich doch schonmal ein vertrauenerweckendes Angebot. Jetzt muß ich nur noch rausfinden, ob es auch stimmt. Gruß Klaus (der soundsovielte) P.S. Tut mir leid, daß ich so mäkelig bin. Aber mir fehlt das den meisten Menschen innewohnende Gen zum "Glauben". Ich wills immer wissen (Wissen = durch wiederholte Erfahrung gewonnene Erkenntnis).
alles was mit USB zu tun hast findest du unter HKLM\SYSTEM\CurrentControlSet\Enum\USB es gibt einige Kopien davon unter anderen Pfaden. wenn du dort eine VID / PID kombo löschst ist das entsprechende Device weg. im Windows Systemordner gibts *.pnf Dateien. Das sind kompilierte Versionen der verwendeten inf Dateien. Wenn man die passend entfernt erzwingt man einen neuen Treiber Dialog. In jedem Fall sollte man sehr genau wissen was man tut sonst ist das System kaputt.
Klaus S. schrieb: > Ich wills immer wissen > (Wissen = durch wiederholte Erfahrung gewonnene Erkenntnis). Na dann kannst du dich ja durch die Windows-Dokumentation wühlen. Für Arduino-Nutzung braucht das jedenfalls sonst keiner, und wie gesagt, selbst USB-Geräte-Entwickler nicht. Weißt du bei jeder Windows-Funktion wie sie intern funktioniert? Hast du den Windows-Quellcode studiert? Den Microcode deiner CPU? Klaus S. schrieb: > Ich danke Euch für Eure Hilfsbereitschaft. Ihr habt mir zwar nichts > erzählt, was ich nicht schon selbst praktiziert oder woanders gehört > hatte, Wieso fragst du dann nach den Dateien, die du löschen musst, wenn du schon weißt, dass es damit nicht getan ist? Klaus S. schrieb: > hervorragenden Eigenschaften des > Gerätemanagers Der Gerätemanager ist ziemlich simpel. Die Magie passiert im Windows-Kernel. Und die willst du nachbilden? Die Treiberdateien sind in C:\Windows\System32\DriverStore\FileRepository . Aber mit Löschen oder Hineinkopieren ist es wie gesagt nicht getan (was unter laufendem Windows wie gesagt sowieso nicht geht). Thomas Z. schrieb: > alles was mit USB zu tun hast findest du unter > HKLM\SYSTEM\CurrentControlSet\Enum\USB Es gibt auch noch HKLM\SYSTEM\CurrentControlSet\Control\usbflags
:
Bearbeitet durch User
Niklas G. schrieb: > Na dann kannst du dich ja durch die Windows-Dokumentation wühlen. Ja, wenn es notwendig ist. Meine einzige "Großtat" in Windows war bisher eine DLL für einen IPC-Mechanismus über "shared memory" und dabei mußte ich mich tatsächlich durch die Windows-Dokumentation wühlen. Ansonsten schreibe ich für Windows bisher nur 08/15-Gebrauchssoftware und das so simpel wie eben möglich. Ansonsten kann ich Deinen Fragen nur entnehmen, daß wir uns gründlich mißverstehen. Ich will weder Dateien löschen noch den Kernel nachbilden. Ich möchte, daß Windows die einmal installierten Treiber wieder vollständig vergisst. Nur ist das Tool, das ich dafür habe, im Moment für mich gerade unpassend, weil zu zeitraubend. Daher meine Frage nach einer einfacheren Lösung. Das Problem scheint nur zu sein, daß ich nicht alles blind glaube, daß Du das aber gern hättest. Tut mir leid, klappt nicht, mir fehlt das Gen dazu. Man kann mich aber überzeugen durch gescheite Angaben, die mir einleuchten und die ich reproduzierbar nachvollziehen kann. Schau einfach mal bei Thomas nach, der hat erheblich mehr Ahnung von USB als ich und immer zielgerichtete Vorschläge. Die leuchten mir ein und die vollziehe ich nach und danach entscheidet sich, wie es weitergeht. Gruß Klaus (der soundsovielte)
Angehängte Dateien:
-
Geraet_Deinstallieren.png
160 KB
Klaus S. schrieb: > Daher meine Frage nach > einer einfacheren Lösung Die 3 Klicks im Geräte-Manager sind nicht einfach genug? Was könnte einfacher sein? Bestimmt nicht den PC herunterzufahren und manuell in der Registry und dem Driver Store herumzuwühlen. Klaus S. schrieb: > Ich möchte, daß Windows die einmal installierten Treiber wieder > vollständig vergisst. Ah, also nicht nur für das Gerät, sondern komplett? Das geht so: https://learn.microsoft.com/de-de/windows-hardware/drivers/install/using-device-manager-to-uninstall-devices-and-driver-packages Klaus S. schrieb: > as Problem scheint nur zu sein, daß ich nicht > alles blind glaube, Probier es einfach aus. Es funktioniert. Was brauchst du noch? Die genaue Auflistung was der Kernel da intern macht?
:
Bearbeitet durch User
Thomas Z. schrieb: > In jedem Fall sollte man sehr > genau wissen was man tut sonst ist das System kaputt Weswegen ich Backup-Fetischist bin. Ohne Acronis True Image wäre ich verloren :-) Gruß Klaus (der soundsovielte)
Harald K. schrieb: > https://www.uwe-sieber.de/misc_tools_e.html#devicecleanup Das macht aber letztendlich exakt das gleiche wie der Geräte-Manager. Es hat nur eine praktischere Benutzerführung weil man mehrere Geräte auf einmal löschen kann. Das ist für einen einzelnen Arduino aber unerheblich. Und ein zusätzliches Tool zu installieren ist für mich nicht "einfacher".
Niklas G. schrieb: > Es hat nur eine praktischere Benutzerführung weil man mehrere > Geräte auf einmal löschen kann. Richtig, man klickt sich nicht einen Wolf, wenn man das auf einen PC loslässt, mit dem schon 'ne Weile gearbeitet wurde. Gerade das ist beim Gerätemanager nervig; könnte man dort mehrere ausgeblendete Geräte markieren und gemeinsam löschen, wäre vieles einfacher. Niklas G. schrieb: > Und ein zusätzliches Tool zu installieren ist für mich > nicht "einfacher". Da wird nichts installiert, das ruft man einfach nur auf. Wie auch den USB Device Tree Viewer.
Also ich verliere langsam die Lust, damit weiterzumachen. Das Installieren und Deinstallieren der Treiber klappt jetzt prima, Gerätemanager und Zadig arbeiten synchron und ohne Widersprüche. Windows "findet" nichts wieder, wenn im Gerätemanager die Software auch gelöscht und nicht nur das Gerät deinstalliert wird. Insoweit bin ich mit Windows (und mit mir :-))) zufrieden, aber natürlich nicht mit Arduino. Auf den Seiten von Arduino finde ich nur Werbung, aber keine Mailingliste für User oder sowas, also halt ich erstmal still, bis auch andere User sich mit ähnlichem Problem melden und kümmere mich um meine USB-Kenntnisse, die ja noch ganz am Anfang stehen. Gruß Klaus (der soundsovielte) P.S. Mit Zadig habe ich außerdem die "WinUSB" durch "libUSBk" ersetzt, aber das brachte nur einen anderen Wortlaut des Nichterkennens als der Betrieb ohne Treiber.
Klaus S. schrieb: > P.S. Mit Zadig habe ich außerdem die "WinUSB" durch "libUSBk" ersetzt, > aber das brachte nur einen anderen Wortlaut des Nichterkennens als der > Betrieb ohne Treiber. hast du denn libusb oder auch Winusb wirklich nur für Interface 2 installiert? USB und Betrieb ohne Treiber geht nicht. Jedes Usb Gerät braucht Treiber. Die können wie im Falle von CDC vom OS kommen (Klassentreiber) oder eben von einer Installation.
Klaus S. schrieb: > Auf den > Seiten von Arduino finde ich nur Werbung, https://support.arduino.cc/hc/en-us/articles/9398559565340-Problems-uploading-to-UNO-R4-WiFi-on-Windows Keine 1 Minute brauchte ich um das zu finden.....
Thomas Z. schrieb: > hast du denn libusb oder auch Winusb wirklich nur für Interface 2 > installiert? Erwischt. Natürlich nicht. Ich sagte doch, daß meine USB-Kenntnisse Zuwachs brauchen. Das CompoundDevice und die Endpoints brauchen noch Klärung in meinem Kopf. Ich kümmer mich drum, danke. Arduino F. schrieb: > https://support.arduino.cc/hc/en-us/articles/9398559565340-Problems-uploading-to-UNO-R4-WiFi-on-Windows > Keine 1 Minute brauchte ich um das zu finden..... Ich wußte doch, daß Fähigkeiten ungleich verteilt sind und hoffte, daß jemand Anderes darin besser ist als ich. Ich hatte nach einer halben Minute die Schnauze so voll von der ganzen Werbung ... Ebenfalls danke. Gruß Klaus (der soundsovielte)
Habe für Interface2 WinUSB installiert. Danach war der COMport nicht mehr da. Konnte für Interface0 usbserial nachinstallieren, dann war er als COM5 wieder sichtbar. Arduino lud wieder bis "detach und reattach" und fand im Bootloadermodus keinen COMport. In diesem Bootloadermodus konnte ich mit Zadig wieder einen Treiber für "Santiago DFU" laden (was hat heilige Jakob mit DFU zu tun?). Ich habs mal mit usbserial versucht, aber der bekam COM7 zugeteilt. Der wurde aber in der Arduino-IDE nicht, im Gerätemanager sehr wohl angezeigt. Dementsprechen klappte das Flashen natürlich weiterhin nicht. die fehlende COMport-Verbindung wurde angemeckert. Wenn man es nun schaffen könnte, beiden Treibern dieselbe COMportnummer zu verpassen? Es gibt da was zum renumerieren der COMports, fällt mir nur gerade nicht ein. Werde danach suchen. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Habe für Interface2 WinUSB installiert. Danach war der COMport > nicht > mehr da. Konnte für Interface0 usbserial nachinstallieren, dann war er > als COM5 wieder sichtbar. scmeiss noch mal alles raus COM3 + COM5 + WinUsb Danach anstecken. CDC kommt automatisch ab Win10. -> da sollte dann auch dein COM3 erscheinen. Wenn das durchgelaufen ist auf Interface 2 WinUsb mit Zadig installieren. Danach sollte alles korrekt funktionieren
Thomas Z. schrieb: > scmeiss noch mal alles raus COM3 + COM5 + WinUsb > Danach anstecken. CDC kommt automatisch ab Win10. -> da sollte dann auch > dein COM3 erscheinen. Ganz so einfach ist es leider nicht. Am Desktop mit 64bit-Win10 erscheint kein COMport und unter "Andere Geräte" der DFU-RT-Port. Am Laptop mit der 32-bit-Version erscheint dagegen der COMport und ganz unten im GM der DFU-RT-Port in einer separaten Zeile "USB-Controller". Der UNO sendet alle Sekunde einen String und das kann ich auf dem Laptop unter Win10 und Linux verifizieren. Zadig bietet mir an, für CDC Port (Interface 0) oder für DFU-RT Port (Interface 2) was zu installieren. Nach meiner Interpretation der Sachlage wäre jetzt USBserial für den CDCport nötig. Richtig? Habe mal die Ausgabe von usbtreeview in der Textdatei angehängt GrußKlaus (der soundsovielte)
War neugierig und habs gleich gemacht. Ergebnis leider wie immer. Gruß Klaus (der soundsovielte)
Die Treiber scheinen damit aber richtig eingerichtet. Mit "dfu-util -l" wird das Gerät wie in Linux angezeigt. Schaltet man in den Bootloadermodus, so erscheint im Gerätemanager "Santiago DFU" und man kann wiederum mit Zadig WinUSB als Treiber dafür laden. Danach ist möglich, mit "dfu-util -a 1 -U <filename>" den Codespeicher auszulesen. Allerdings bricht das Auslesen nicht ab, wenn die angewählte Anzahl Bytes erreicht ist. Dieser Fehler tritt aber auch unter Linux auf. Da ist wohl noch ein wenig Feinschliff nötig. Ich werde hier abbrechen und unter Linux mein Forth aufspielen, damit kann ich dann weiter experimentieren. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Zadig bietet mir an, für CDC Port (Interface 0) oder für DFU-RT Port > (Interface 2) was zu installieren. Nach meiner Interpretation der > Sachlage wäre jetzt USBserial für den CDCport nötig. Richtig? Das CDC Device beteht aus 2 Interfaces Interface0 ist control Interface1 ist das DatenInterface Interface2 ist das DFU device. Aus dem UsbTreeview geht hervor dass das der Treiber für das DFU Device nicht gestartet werden kann (code 28 für Childdevice #2) Wie gesagt CDC auf Interface 0 per Zadig ist definitiv falsch. Du must es irgendwie schaffen alles für dein Teil zu deinstallieren. Dann kommt der CDC automatisch (unter W10). dann auf dein Interface2 winusb mit Zadig. Schalte in Zadig den erweiterten mode ein. Ich hab dir mal ein Beispiel vom wch-link angehängt. Da sind die Deskriptoren auch nicht 100% ok Das Ding funktioniert aber Interface0 DAP -> winusb Interface2 -> CDC daten Interface3 -> CDC Control
:
Bearbeitet durch User
Thomas Z. schrieb: > Du must es irgendwie schaffen alles für dein Teil zu deinstallieren. Das scheint noch nicht ganz zu klappen. Wenn ich alles deinstalliere, was mit dem Board zusammenhähgt, erscheint im Gerätemanager das Board als "DFU-RT Port" unter "Andere Geräte" und ein Treiber ist angeblich nicht verfügbar. In Zadig aber erscheint normalerweise "NONE" im Feld für den vorhandenen Treiber, wenn alles deinstalliert wurde. Für das Interface0 steht dort aber "libusbK". Ist das die Win10-default-Einstellung? > Dann kommt der CDC automatisch (unter W10). Wenn damit die "CommunicationDeviceClass" gemeint ist, ein COMport erscheint definitiv nicht. Gruß Klaus (der soundsovielte)
Endlich Zeit gefunden, System Backup zurückzuspielen. COMport ist da, Zadig sagt für Interface0: "usbser (v10.0.19041.2130)" Für Interface2 WinUSB installiert, danach mit Arduino dasselbe Spiel wie immer: Opening DFU capable USB device... Device ID 2341:0069 Run-Time device DFU version 0101 Claiming USB DFU (Run-Time) Interface... Setting Alternate Interface zero... Determining device status... DFU state(0) = appIDLE, status(0) = No error condition is present Device really in Run-Time Mode, send DFU detach request... Device will detach and reattach... Cannot open DFU device 2341:0369 found on devnum 6 (LIBUSB_ERROR_NOT_SUPPORTED) Lost device after RESET? Der ausgewählte serielle Port Lost device after RESET? ist nicht vorhanden oder das Board ist nicht angeschlossen "dfu-util -l" manuell gestatert sagt: Cannot open DFU device 2341:0369 found on devnum 6 (LIBUSB_ERROR_NOT_SUPPORTED) Zadig sagt über den Treiber des im Bootloadermodus aktiven "Santiago DFU": NONE. Lade ich als Treiber WinUSB, dann kann ich mit "dfu-util -l" zwar zwei DFU-Kanäle sehen: Found DFU: [2341:0369] ver=0100, devnum=7, cfg=1, intf=0, path="2-3", alt=0, name="@CodeFlash /0x00000000/8*2Ka,120*2Kg", serial="370D280D58313330D23A33324B572D98" Found DFU: [2341:0369] ver=0100, devnum=7, cfg=1, intf=0, path="2-3", alt=1, name="@DataFlash /0x08000000/8*1Kg", serial="370D280D58313330D23A33324B572D98" ein COMport ist aber nicht mehr vorhanden. Es fehlt also aus meiner vorläufigen Sicht der richtige Treiber für "Santiago DFU". Werde morgen nachmittag mal versuchen, Arduino unportabel zu installieren. Jetzt ist erstmal die Familie dran. Gruß Klaus (der soundsovielte)
bei der usb.org gibts eine Class Spec zum DFU mode. MS unterstützt bis heute keinen Klassentreiber für DFU. Das ist also etwas frickelig. Soweit mir bekannt ist wird beim Aktivieren des DFU modes ein Replug ausgelöst, und es kommt ein DFU Device mit anderen IDs hoch (dein Santiago DFU). Dieses braucht logischerweise auch Treiber. Das deckt sich ja mit deiner Aussage, dass der Comport verschwindet. Kannst du posten was für IDs da kommen (UsbTreeView oder im Gerätemanager nachschauen). Ev muss dafür noch mal libusb zugeordnet werden.
Thomas Z. schrieb: > Kannst du posten was für IDs da kommen (UsbTreeView oder im > Gerätemanager nachschauen). Das hatte ich schon in meinem Posting vom "04.07.2023 09:40" angehängt. > Ev muss dafür noch mal libusb zugeordnet werden. Das habe ich doch mit Zadig gemacht. Muß das anders laufen? Gruß Klaus (der soundsovielte) P.S. Verwendung der installierten Version statt der portablen Version von Arduino 1.8.19 bringt keinen Unterschied.
mm so langsam glaube ich dass bei deinem System kein libusb vorhanden ist. Benutzte mal winusb das ist bei jedem Windows seit Vista dabei. lt der Homepage von dfu-util gehen alle Varianten "We offer binaries for Microsoft Windows and some other platforms. dfu-util uses libusb 1.0 to access your device, so on Windows you have to register the device with the WinUSB driver (alternatively libusb-win32 or libusbK), please see the libusb wiki for more details." Instalier winusb für das device VID_2341 / PID_0369 und auch für Interface2 vom Compountdevice VID_2341 / PID_0069
:
Bearbeitet durch User
Thomas Z. schrieb: > mm so langsam glaube ich dass bei deinem System kein libusb vorhanden > ist. Woher auch? > Benutzte mal winusb das ist bei jedem Windows seit Vista dabei. > lt der Homepage von dfu-util gehen alle Varianten Die nehm ich doch schon die ganze Zeit, die schlägt Zadig mir doch vor. Der letzte Schritt zum Erfolg (endlich!!) war das Starten der Arduino-IDE als Administrator, jetzt funktioniert das Flashen. Danke für Deine Ausdauer, allein hätte ich es nicht hinbekommen. Ich mach nochmal ein paar Experimente und poste dann eine Zusammenfassung. Gruß Klaus (der soundsovielte) P.S. libusb habe ich aus Neugier mal heruntergeladen, die Versionen für Windows liegen in 2 Ausgaben vor: Cygwin und Mingw. Wie ich sie in Programme einbinde, die mit Cygwin oder Mingw compiliert werden, ist mir klar (ob statisch oder dynamisch). Wie ich sie ins Windows-System integriere, damit Zadig sie findet, ist mir aber noch schleierhaft. Einfach dahin kopieren, wo sich die anderen DLLs tummeln und Windows defaultmäßig nachschaut? Schaut Zadig da auch nach?
Klaus S. schrieb: > Ich mach nochmal ein paar Experimente und poste dann eine > Zusammenfassung. Das Problem hat sich erledigt. Wenn die Software für den UNO R4 geladen wird, kommt jetzt am Ende noch ein Treiber hinterher. Damit funktioniert das Programmieren ohne Probleme, COMiport und Renesas Flash Programmierer müssen anwählt werden. Getestet wurde auf einem komplett neu eingerichteten Windows10/64 ohne Vorbehandlung (nicht mal die Gerätetreiber für den Laptop waren installiert).
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.