Hallo Mikrocontroller-Gemeinde, ich hoffe der Betrag ist hier richtig einsortiert ist. Oder gehört er mehr nach ? Ich bin auf der Suche nach eine Umgebung die ich bei uns in die Fertigung integrieren kann, um uController (hauptsächlich ATMega 328) im roduktionsprozess bzw. im Prüfprozess zu ISP zu programmieren. Das heißt: Ich will kein keine IDE installieren, wo der Benutzer irgendwelche Fenster aufmachen muss und viele Einstellungen klicken muss. Bisher verwende ich STK500.exe aus AVRStudio, das ich aus einer Batchdatei heraus aufrufe. Diese Batchdatei wird entweder von einem automatischen Testsystem aufgerufen oder von einer eigens entwickelten Fertigungsmitarbeiter gerechten Oberfläche. Auf anderen Systemen (Win7 32 Bit) habe ich ähnliches am Laufen aber mit AVRDude. Jetzt sollen alle PCs in der Fertigung auf Windows 10, 64-Bit und 32_Bit, umgestellt werden. In diesem Zuge sollte alles vereinheitlicht werden. AVRStudio auf allen System zu installieren, macht meines Erachtens keinen Sinn mehr. Ich weiß dass auch ATMELStudio ein Kommandozeilen-Tool(ATProgramm.exe) zum Programmieren an Board hat, aber es wiederstrebt mir 1GB Software zu installieren um eine 4,4MB Software zu nutzen. (OK - wahrscheinlich nutzt Atprogramm auch ein paar andere Module mit). Das System sollte wartbar bleiben, auch durch unsere IT und durch unsere Fertigung. Die andere Alternative ist natürlich AVR-Dude: Hier benötige ich aber den LIB-USB-Treiber und die Installation dieses behagt mir nicht. Man muss dazu Windows veranlassen beim Installieren "nicht signierte Treiber" bei der Installation zuzulassen. (eine der vielen Anleitungen im www: http://stefanfrings.de/avr_tools/libusb.html) und das macht, für mich gesehen, das System "für Laien" schlecht wartbar. Kennt jemand von auch eine Software, ggf. auch einen Programmer dazu der evtl. mit einer kleinen GUI zum Testen und vor allem mit einer Kommandozeilenversion der Software kommt, die meinen Anforderungen entsprechen würde? Oder hat jemand eine Idee das mit den oben genannten Tools EINFACH zu lösen. Im voraus schon mal besten Dank Gruß Robert
:
Verschoben durch Moderator
Wenn Du kein WinOS magst, dann nimm bitte Linux. Unter Debian kann Avrdude und andere Tools einfach installiert werden. Ein Rasp. Pi kann auch Linux (Debian) und hat ein Monitorausgang und auch ein 100 MBit/s Lan-Interface. Überträgt bei uns im Netz ~125 kByte/s.
Robert H. schrieb: > ich hoffe der Betrag ist hier richtig einsortiert ist. Nö, eher nich ... ISP-Programmierung hat nichts mit Compiler zu tun. Robert H. schrieb: > Oder gehört er mehr nach ? Wird der Mod schon verschieben.
Hallo Karl, danke für die schnelle Antwort. Leider geht das nicht so einfach. Ich muss das ganze von unseren (alten) Incircuittestern (Windows 32-Bit) aus steueren können. Auf den anderen Arbeitsplätzen in der Elektronikfertigung läuft "nur" Windows und die Programme die hier erstellt und verwendet werden sind "auch nur Windows". Alles andere ist hier nicht durchfürbar. Danke nochmal Gruß Robert
Robert H. schrieb: > Leider geht das nicht so einfach. Ich muss das ganze von unseren (alten) > Incircuittestern (Windows 32-Bit) aus steueren können. Hallo, in meiner "Welt" geht das schon, so ein Raspberry Pi (ab B), kann man per Putty (WinOS) als über SSH und der Commandozeile (bash) steuern. Das ist dann für dich ein Remote-System. Wenn man will setzt mach noch einen Apache mit einem Webfrontend für die korrekte Anwendung auf und jeder DAU, kann über den Webservice dann "Dinge" anstoßen. Man muss es nur wollen.
Robert H. schrieb: > Auf den anderen Arbeitsplätzen in der Elektronikfertigung läuft "nur" > Windows und die Programme die hier erstellt und verwendet werden sind > "auch nur Windows". Im meinen Augen schränkt man sich so sehr ein, nicht effiziente und zuverlässige (Linux)-System zu nutzen. Dann kann man Dir nur noch viel Spaß beim Supporten der User/ Anwender wünschen.
Robert H. schrieb: > Oder hat jemand eine Idee das mit den oben genannten Tools EINFACH zu > lösen. Kenne mich mit Windows zu wenig aus. Die aktuellen Tools von Atmel basieren ja auf HID *), da müsstest du eigentlich ohne spezielle Treiber auskommen – auch mit AVRDUDE. Das wäre zum Beispiel beim ATATMELICE der Fall. Leider sind diese Geräte etwas fragiler (vor allem die dünnen Kabel) als das gute alte AVRISPmkII, bei dem man ganz starken Wert auf Robustheit für industriellen Einsatz gelegt hat. *) Alles ist halt ein "human interface", denn das ist so ziemlich das Einzige, wofür Windows schon immer einen generischen Treiber dabei hatte – würde sich ja dumm machen, wenn du zum Installieren von Maus und Tastatur erst einen Treiber installieren müsstest. ;-)
:
Bearbeitet durch Moderator
Ich habe mir jetzt nicht alles durchgelesen, aber für die Produktion verwenden wir Programmer von halec. So kleine Dinger mit SD-Karte und einigen LED. Schau Dir die mal an. Tip top Teile und 1a Support.
Robert H. schrieb: > Hier benötige ich aber den LIB-USB-Treiber und die Installation dieses > behagt mir nicht. Man muss dazu Windows veranlassen beim Installieren > "nicht signierte Treiber" bei der Installation zuzulassen. Wieso das denn? Ich bin zwar auch kein Freund von libusb aber mit zadig kann man libusb problemlos mit zertifizierten Treiber installieren. Das Treiber Problem bekommst du immer wenn USB im Spiel ist. Der einzige Ausweg ist HID das wie schon erwähnt seit W95 funktioniert. Thomas
Hallo Dennis, vielen Dank für die Info. Diese Module passen für uns nicht: * Die Firmware wird bei uns immer von Server gezogen (wegen Änderungen) * Außerdem kreieren wir eingene Seriennummern und es müssen bei jedem Prüfling auch Daten in das Hex-File gepatcht werden. Aber trotzdem ein interesannte Gerät Gruß Robert
Hallo Jörg, das mit einem HID-Programmer hört sich gut an. Da lasse ich mir mal bei der nächsten Bestellung einen mitkommen. Die Batchdateien für das Programming mit AVR-Dude existieren schon. Das ist der geringste und wartungsfreundlichste Aufwand. Danke Gruß Robert
Kannst dir natürlich zuvor mal diese Zadig-Geschichte angucken. Da habe ich keine Ahnung davon, aber wenn du damit die libusb anstandslos auf deine Windows10s bekommst, könntest du die existierende Lösung weiter benutzen. Wie gesagt, an Robustheit ist das AVRISPmkII kaum zu übertreffen.
Hallo Thomas, ich bekomme dännächst eine Win10 32-Bit Testmaschine für die Produktion. Da werde ich das mit ZADIG nochmal testen. Habe vor Jahren schon mal damit gearbeitet führte damals aber nicht zum gewünschten Erfolg. Danke Gruß Robert
:
Bearbeitet durch User
Damals habe ich es versucht an meinem Entwicklungsplatz AVR-Studio mit Jungo-Treiber und AVR-Dude mit Lib-USB-Treiber unter 64-Bit Windows und bin damals gescheitert. Habe zwar dann den einen Filter-Treiber installiert und habe die 64-Bit Lib-USB-Treiber mit einem Tool selbst zertifiziert. Wenn ich mich richitg erinnere musste man aber dann den PC immer ein einen Modus starten, dass er mit den selbst zertifzierten Treibern lief. Diese ganze Konstellation hätte das ganz für unsere IT (die, die Rechner nur neu installiert wenn es ein PRoblem gibt) udn auch für die Kollegen die sich noch nicht damit befasst haben nicht Support-Bar gemacht. Danke euch Robert
Es gibt in zadig zwei verschiedene libusb Varianten. Ich benutze libusbk. Das funzt auf mehren w10 64 Bit Maschinen ohne Probleme. Eine Alternative könnte auch WinUsb sein sofern du einen Programmer findest der WinUsb kann. Thomas
Thomas Z. schrieb: > Eine Alternative könnte auch WinUsb sein Vielleicht hat ja mal jemand Lust, eine WinUsb-Schicht für AVRDUDE zu bauen … allerdings müsste diejenige dann wohl auch in der Lage sein, Release-Binaries später dafür zu liefern, denn ich fürchte, die bekomme ich mit dem MinGW32-Crosscompiler nicht fabriziert.
Robert H. schrieb: > Jetzt sollen alle PCs in der Fertigung auf Windows 10, 64-Bit und > 32_Bit, umgestellt werden. Bei uns wurden in der Produktion alle auf Xubuntu umgestellt. Bis auf die Maschinen die ihren eigenen Windows-PC dabei haben wie zum Beispiel Bestückautomat, da kann man eh nicht viel machen. Die sollen dort weder Powerpoints erstellen noch Egoshooter spielen, und auch keine Viren verbreiten, also für welchen Zweck sollten die dann überhaupt Windows brauchen auf nem Rechner auf dem genau 2 oder 3 selbstgeschriebene Anwendungen laufen? Nach Beantwortung dieser Frage war klar: Da kommt Linux drauf, da muss man nicht ohne Not immer wieder neue Windows-Fässer aufmachen, die existierenden die man nicht wegbekommt sind schon ärgerlich genug, da müssen nicht auch noch neue hinzu ohne Grund.
:
Bearbeitet durch User
Jörg W. schrieb: > Vielleicht hat ja mal jemand Lust, eine WinUsb-Schicht für AVRDUDE zu > bauen … allerdings müsste diejenige dann wohl auch in der Lage sein, > Release-Binaries später dafür zu liefern, denn ich fürchte, die bekomme > ich mit dem MinGW32-Crosscompiler nicht fabriziert. So einfach ist das nicht. Damit WinUsb direkt im OS ohne inf Geraffter automatisch funktioniert muss das Usbdevice passente Deskriptoren liefern können. Danach kann man im userspace machen was man will. Das Prinzip ist dann ähnlich wie libusb. MS hat dafür diese OS Aware Requests erfunden. Thomas
Thomas Z. schrieb: > So einfach ist das nicht. Damit WinUsb direkt im OS ohne inf Geraffter > automatisch funktioniert muss das Usbdevice passente Deskriptoren > liefern können. Naja gut, das war's dann dafür. Ich dachte schon, sie hätten mal was richtig gemacht. ;-) Der Dreh von libusb ist ja eben genau, dass man jedes Device da dran hängen kann. Das geht unter Linux, MacOS, *BSD, Solaris out of the box, ggf. nachdem man sich halt die nötigen Zugriffsrechte organisiert hat.
:
Bearbeitet durch Moderator
> Leider geht das nicht so einfach. Ich muss das ganze von unseren (alten) > Incircuittestern (Windows 32-Bit) aus steueren können. Darf man fragen, was das für Tester sind? Ggf. kann man das mit dem Tester selbst erledigen, auch mehrere Devices parallel. Jörg
Jörg W. schrieb: > Naja gut, das war's dann dafür. Ich dachte schon, sie hätte mal was > richtig gemacht. ;-) Der Dreh von libusb ist ja eben genau, dass man > jedes Device da dran hängen kann. Das geht unter Linux, MacOS, *BSD, > Solaris out of the box, ggf. nachdem man sich halt die nötigen > Zugriffsrechte organisiert hat Das Problem sind die Inf Dateien unter win. Wenn man daran dreht gehen schnell mal die Treiberzertifikate verloren.(w10) Das ist auch der Grund warum libusb unter win bei weitem nicht so problemlos ist wie unter Linux. Libusb und WinUsb sind vom Funktionsumfang ziemlich idendisch. Im Prinzip hat MS das schon richtig gemacht. Wenn diese OS Deskriptoren da sind wird WinUsb automatisch benutzt genau wie es auch bei HID oder Audio mit den Klassentreibern funktioniert. Kein Inf notwendig. In allen anderen Fällen muss man mit einem INF nachhelfen. Zatig kann auf Wunsch übrigens auch mit WinUsb benutzt werden. Thomas
Thomas Z. schrieb: > Libusb und WinUsb sind vom Funktionsumfang ziemlich idendisch. Im > Prinzip hat MS das schon richtig gemacht. Naja, nee. libusb (und die OS-Treiber, auf denen diese aufsetzt) sind halt komplett unabhängig von irgendwelchen spezifischen Vorkehrungen im Gerät. Ich kann damit also potenziell jedes Gerät ansprechen, unabhängig davon, wie das USB-Gerät aufgebaut ist und/oder ob es vielleicht noch weitere Treiber dafür im System gibt oder nicht. Einzige Voraussetzung ist, dass der entsprechende Prozess ein Zugriffsrecht dafür hat (und natürlich, dass noch niemand sonst drauf zugreift, egal ob über libusb und die zugrunde liegenden Treiber, oder vielleicht über einen Klassentreiber). Die Rechteproblematik ist auch nicht wirklich vergleichbar mit einem INF-File, denn letzteres muss (darum geht's ja gerade hier) erst einmal die Runde über ein Zertifikat drehen, während die Rechtevergabe unter unixoiden Systemen rein Policy des lokalen Admins ist.
doch Jörg WinUsb und libusb sind vom Funktionsumfang im wesentlichen gleich. Lediglich ISO Transfers fehlen meines Wissens in WinUsb. Beide Treiber sind dazu gedacht vom Usermode beliebige Usbfunktionen auszulösen. Ich finde also schon das dies vergleichbar ist. Auch unter Linux funktioniert libusb nicht von alleine. Ich muss dort ev sogar das richtige libusb draufhaben oder eben nachinstallieren, wobei das bei den Distros schon dabei sein dürfte. Ist das auf dem Mac auch so? WinUsb ist seit WinVista im OS mit Backport auf XP. Seit W7 funktioniert die automatische Erkennung via OS Deskriptoren zuverlässig. Ich kann also ein USB Device bauen was sofort unter Win erkannt wird und ohne Anwender Treiberinstallation funktioniert. Ich halte das für einen großen Fortschritt. Ich brauche dafür auch keine extra Rechte oder eine spezielle Inf. Echtes Plug&Play was Bill Gates ja ursprünglich mit W98 versprochen hatte. Thomas
Thomas Z. schrieb: > doch Jörg WinUsb und libusb sind vom Funktionsumfang im wesentlichen > gleich. Da habe ich keinen Zweifel geäußert. Die zugrunde liegenden Treiber bzw. INF-Files sind halt das, was einem das Leben schwer macht (sonst hätten wir diesen Thread hier nicht). > Auch unter > Linux funktioniert libusb nicht von alleine. Ich muss dort ev sogar das > richtige libusb draufhaben oder eben nachinstallieren, wobei das bei den > Distros schon dabei sein dürfte. Ist das auf dem Mac auch so? Die Bibliothek muss man ggf. installieren, aber die generischen OS-Treiber sind inhärent auf den unixoiden Systemen ab Haus dabei, und damit kann man ausnahmslos alle USB-Geräte ansprechen. > Seit W7 funktioniert > die automatische Erkennung via OS Deskriptoren zuverlässig. Das ist der Knackpunkt: "OS Deskriptoren", es geht dann eben nicht mit jedem beliebigen Gerät aus der Dose raus. Deshalb habe ich es als halbe Sache bezeichnet. > Echtes Plug&Play was Bill Gates ja ursprünglich mit W98 versprochen > hatte. Und selbst das eben nur nicht universell, und auch ansonsten (siehe CDC, erst seit Windows 10 als Klassentreiber vorhanden) haben seine Jungs mehr als 15 Jahre gebraucht, um halbwegs da anzukommen, wo alle anderen schon immer waren, seit sie überhaupt USB gemacht haben. Dafür, dass Microsoft meiner Erinnerung nach federführend an USB mitgewirkt haben, fand ich das immer beschämend. Sie hätten die ersten sein können, bei denen einfach mal „alles klappt“.
Jörg W. schrieb: > Das ist der Knackpunkt: "OS Deskriptoren", es geht dann eben nicht mit > jedem beliebigen Gerät aus der Dose raus. Deshalb habe ich es als halbe > Sache bezeichnet. das stimmt wohl, wobei da ursprünglich wohl auch Sicherheitsbedenken eine Rolle gespielt haben. Nur noch mal zum Verständnis: Diese OS Deskriptoren sind nur bei automatischer Kennung notwendig Wenn mit einer Inf gearbeitet wird geht WinUsb seit XP. Das gleiche gilt auch CDC mit Inf geht's seit XP. Außerdem kostet es mich nichts diese OS Deskriptoren zu implemtieren. Linux macht damit ja nichts und unter Win habe ich weniger Support zu leisten. Man sieht das ja auch hier. Mindestens 1mal pro Woche kommt die Frage nach irgend welchen Treiber Installationen. Libusb funktioniert unter Win auch nicht besser. Da merkt man deutlich dass die ursprüngliche Entwicklung aus der Linux Ecke kommt. Thomas
Thomas Z. schrieb: > Außerdem kostet es mich nichts diese OS Deskriptoren zu implemtieren. Doch: du kannst sie eben bspw. in einem AVRISPmkII nicht (nachträglich) implementieren, dafür wärst du auf den Support des Herstellers angewiesen. Die haben stattdessen drauf verzichtet, und standardisieren nun diesen Quatsch, bei dem alles ein HID ist (CMSIS-DAP ist von Keil für ARM genau so standardisiert worden). Das ist der wesentliche Unterschied zwischen diesem Ansatz und dem der unixoiden Systeme. Die haben jeweils einen generischen Treiber, der auf alles zugreifen darf. (Der libusb obliegt das Verdienst, diese verschiedenen Treiber zu abstrahieren auf ein gemeinsames API.) Damit brauchst du dann eben doch wieder extra Klimmzüge, und die sind das, was das Leben damit schwer macht – siehe aktueller Thread. > wobei da ursprünglich wohl auch Sicherheitsbedenken eine Rolle gespielt > haben Dafür hätte es genügt, dass man (analog zur Rechtevergabe in den Unixen) dem lokalen Admin das Recht erteilt, die entsprechenden Geräte zuzulassen. Sonst wird ja auch für alles Mögliche nachgefragt. Genau das hätte man doch hier auch tun können: wenn ein Gerät dieser Art (USB-Geräteklasse + VID/PID) das erste Mal angesteckt wird, einfach nachfragen, ob der WinUsb darauf zugreifen dürfen soll, und ob er das auch künftig für alle derartigen Geräte können soll. Damit wäre die Sache völlig unbürokratisch erledigt gewesen.
:
Bearbeitet durch Moderator
Hallo zusammen, entschuldigt, dass ich schon eine ganze Zeit nicht mehr online war, es war viel zu tun und ich hatte Urlaub. :-) @Matthias: Danke für den Link auf "e-lab Programmer", ich kann mich nicht mehr erinnern auf die Teile schon mal gestoßen zu sein, aber vom AVRco-Pascal habe ich schon mal gehört. Ich habe mal ein paar mehr Infos von e-lab angefordert. @Jörg DIe Testsystem sind uralte Marconi 505/5200 (zuletzt Cobham/VAVI) Testsysteme. Die habe keine Möglichkeit für ISP Programmierung. Marconi5200: https://www.viavisolutions.com/de-de/node/59993 Von einer uralten "505" finde ich gar kein Bild mehr. Zum Thema "Arbeitsplätze" unter Linux: Unsere (Uralt-)Testsystem laufen alle unter Windows, von dieser Umgebung muß dass Flashen angestoßen werden können. Auch die Funktionstestplätze und die reinen Programmierplätze laufen unter Windows. Somit ist unsere ganze Firma "Windows" inkl. der EDV/IT-Abteilung. Plötzlich Rechner mit Linux in die Produktion zu stellen würde uns nie genehmigt und es wäre bis auf eine halbe Hand voll Entwickler niemand im Haus die diese System warten und supporten können. Ansonsten bedanke ich mich noch für euere rege Diskussion über LibUSB, WinUSB. INF-Files und USB-Treiber-Programmierung. Aber hier bin ich ausgestiegen - auch aufgrund meines urspünglichen Problems. (nichts für ungut) Gruß Robert
:
Bearbeitet durch User
Guck dir mal dir Produkte der Firma Conitec an, die haben solche System.
Hallo Robert, wir benutzen die Presto von Asix, die sind per Kommandozeile steuerbar. https://www.asix.net/prg_presto.htm Nachteil: Die Teile sind sehr langsam (Faktor 2), gegenüber z.B. einem AVRISP MKII. Vorteil: Eine breite Palette an Controllern wird unterstützt. Evtl. gibt es da in letzter Zeit Verbesserungen, unsere Geräte sind schon ein paar Jahre alt. Marian.
Hallo Marian, Danke für dne Link. Auf diese Teile bin ich bei meiner Rechene auch nicht gestoßen. Nach was habe ich eigentlich gesucht? ;-) Habt ihr dir PRESTO oder die FORTE. Bei den FORTE wird ja damit geworben, dass die Aufgrund des verbauten Cntroller-In-a-FPGA schneller sind. In der Artieklbeschreibung finde ich jetzt nichts über Kommandozeile, aber da lese ich einfach weiter. Werde mir das ganz noch näher anschauen. Danke und Gruß Robert
Robert H. schrieb: > Habt ihr dir PRESTO oder die FORTE. Bei den FORTE wird ja damit Wir haben mehrere Presto und programmieren damit 8Bit PIC und AVR. > In der Artieklbeschreibung finde ich jetzt nichts über Kommandozeile, http://asix.tech/_programmers/presto_en.pdf Kapitel 5.6 Seite 63 Das UP ist die Bedienoberfläche für die Geräte. Marian.
Zur allgemeine Info als Rückmeldung: Habe Kontakt zu e-lab aufgenommen. Die Programmer von denen sind sogar über eine DLL steuerbar. D.h. Ich müsste nicht jedesmal eine Shell von meiner Anwendung aus öffen um eine Kommandozeile auszuführen sondern könnte das ganze gleich in meine "GANG-Programmer-Oberfläche" impelmentieren. Nur e-lab schreibt: "Die Steuerung über die DLL ist nur bei den "teuerem" UPP1-X möglich." Mit dem Typ ISP3-X (der ja als ISP-Programmer eingentlich für sowas ausgelegt sein sollte) geht es per DLL nicht. Gruß Robert
Hallo Marian, danke für den Link auf die Anleitung. Bist mir zuvorgekommen. Gruß und schönen Tag noch Robert
Hallo Edgar S. Die Galep kenn' ich von früher her, die hatten wir schon: Da war das Problem, dass wenn wir die Programmer an den Testsystemen einsetzten und über Kommadozeile starteten, hatten wir immer ewige Ladezeiten für die GUI und die Initialiiserung des Programmers. Auch der Parameter /quiet hat das ganze meiner Erinnerung nach nicht wesentlich beschleunigt. Wie es mit der GALEP5 Software, die ja bei jedem Programmstart "eine Netzwerk Verbindung zum Programmer über USB aufbaut", das ewig dauert habe ich es dann an den Testsystemen nicht mehr getestet. An reinen Programmierplätzen lief es ohne Probleme. Gruß Robert
Jörg W. schrieb: > Robert H. schrieb: > Kenne mich mit Windows zu wenig aus. Die aktuellen Tools von Atmel > basieren ja auf HID *), da müsstest du eigentlich ohne spezielle Treiber > auskommen – auch mit AVRDUDE. Das wäre zum Beispiel beim ATATMELICE der > Fall. Hallo Jörg, ich habe mitr gleich nach deienm Tipp einen Atmel ICE zugelegt und komme aber leider erst jetzt dazu ihn zu testen. Ich bin gerade dabei die PCs in der Fertigung auf Win10 umzustellen und da wäre es schön wenn ich gleich auf den ATMEL ICE umstellen könnte. Der ATMEL ICE wird vom W10 (32Bit) ohne Probleme erkannt und im Gerätemanger erscheinen bei Eingabegeräte zwei Devices: - HID-konformes, vom Hersteller definiertes Gerät - USB-Eingabegerät Ich habe auch mittlerweile gelesen das der ATMEL ICE erst ab AVRDUDE 6.3 erkannt wird. Beitrag "avrdude & atmel ice problem". 13.01.2017 16:46 (dl8dtl) Ich habe AVRDude 6.3 bereits als .exe in "avrdude-6.3-mingw32.zip" gefunden und muss nicht mehr selebst übersetzen. Aber wenn ich in der Kommandozeile avrdude -c atmelice_isp -P USB eingebe, öffnet sich eine Windowsdialog, dass die Auzsführung des Codes nicht fortgesetzt werden kann, da libusb0.dll nicht gefunden wurde. a) was seltsam ist, dass ein Kommandozeilenprogramm eine Windowsfenster öffnet b) und dass hier libusb0.dll benötigt wird. Ich dachte mit ATMELICE_isp setzt AVRDUDE direkt auf den HIF-Treiber auf. Ich wollte mir nämlich das installieren der libusb geschichte ersparen. Kann mir jemand weiter helfen? Danke an alle Gruß Robert
:
Bearbeitet durch User
Robert H. schrieb: > Plötzlich Rechner mit Linux in die Produktion zu stellen würde uns nie > genehmigt und es wäre bis auf eine halbe Hand voll Entwickler niemand im > Haus die diese System warten und supporten können. Es ist typischerweise billiger, sich ein fertiges Embedded-Linux-System (Industrial oder Hutschienen-PC) von einem Dienstleister zu bestellen, davon 2-3 Ersatzeinheiten zusaetzlich einzukaufen und das ganze per Python ueber's Netzwerk zu programmieren, oder direkt per DLL aus der ICT-Software heraus (fuer Genrad-Tester habe ich das mal gemacht, allerdings nicht fuer AVR). Das ist nachhaltiger als sich alle paar Jahre mit Windows, Updates, WinUSB und Treiber- Unzulaenglichkeiten herumzuschlagen. Dass in dem 'Embedded Programmer' Linux sitzt, muss die IT-Abteilung dann halt so hinnehmen.
Robert H. schrieb: > dass hier libusb0.dll benötigt wird. Für das Atmel-ICE würde sie nicht benötigt werden. Du hast aber eine vorcompilierte Version von AVRDUDE, die alle möglichen Tools bedienen kann, nicht nur dieses ICE, daher wurde sie gegen LibUSB gelinkt. Du hast also zwei Optionen: * AVRDUDE selbst compilieren. Dann kannst du es so compilieren, dass du zwar auf HID zugreifen kannst, aber keine LibUSB brauchst. * Einfache eine LibUSB mit hinlegen. Damit ist der Programmstart trotzdem möglich, benutzt wird sie jedoch nicht weiter (daher müsstest du auch keine weitere Konfiguration der LibUSB vornehmen). Im einfachsten Fall genügt es, wenn du dir die libusb0.dll in das Verzeichnis reinlegst, in dem avrdude.exe liegt.
Hallo Martin, danke für die Hinweise. Dieses Thema gab's in Thread schon mal. Ich habe mir dannauch einige Hersteller von solchen "universellen ISP" Programmern angeschaut. Da lagen dann Preise wenn ich mich richtig erinnere bei 1500-2000€ für das Grundgerät und bei bis zu 1000€ für einen Programmierkopf. Da unsere ICT und FKT Arbeitsplätze einzelne Tische sind, bräuchte ich dafür 5 Grundgeräte und 5 Köpfe und für die "Flash-Arbeitspläte" 2 Grundgeräte und 8 Programmierköpfe. Das ist dann preilich jenseits von Gut und Böse (zumindestens bei uns). PS: Das Linux in den Embedded-Systemen der Programmer wäre sogar der IT egal. Danke nochmal Gruß Robert
Hallo Jörg, auf einem System mit instalieerten libusb0.dll bekomme ich jetzt biem Aufreuf von AVRdude eien Meldung: JTAG_open_common: Cant dind any device mit VID... und PID... Aber genau diese PID und VID har der Programmer. Monentan werde ich es mal so weiter betreiben wie bisher. Mit installierten libusb und altem USBProg. - Momentan muß ich die Rechner in der Produktion auf Win10 umstellen, sonst nimmt die IT am 15.01. vom Netz - Zum selber Compilieren bin ich zu weit weg von der Problematik. Danke und bis bald Robert
Robert H. schrieb: > JTAG_open_common: Cant dind any device mit VID... und PID... Hmm. Dann hat weder libhidapi noch libusb funktioniert. Das entsprechende Stück Code ist:
1 | #if defined(HAVE_LIBHIDAPI)
|
2 | /*
|
3 | * Try HIDAPI first. LibUSB is more generic, but might then cause
|
4 | * troubles for HID-class devices in some OSes (like Windows).
|
5 | */
|
6 | serdev = &usbhid_serdev; |
7 | for (usbpid = lfirst(pgm->usbpid); rv < 0 && usbpid != NULL; usbpid = lnext(usbpid)) { |
8 | pinfo.usbinfo.flags = PINFO_FL_SILENT; |
9 | pinfo.usbinfo.pid = *(int *)(ldata(usbpid)); |
10 | pgm->fd.usb.max_xfer = USBDEV_MAX_XFER_3; |
11 | pgm->fd.usb.rep = USBDEV_BULK_EP_READ_3; |
12 | pgm->fd.usb.wep = USBDEV_BULK_EP_WRITE_3; |
13 | pgm->fd.usb.eep = 0; |
14 | |
15 | strcpy(pgm->port, port); |
16 | rv = serial_open(port, pinfo, &pgm->fd); |
17 | }
|
18 | if (rv < 0) { |
19 | #endif /* HAVE_LIBHIDAPI */ |
20 | #if defined(HAVE_LIBUSB)
|
21 | serdev = &usb_serdev_frame; |
22 | for (usbpid = lfirst(pgm->usbpid); rv < 0 && usbpid != NULL; usbpid = lnext(usbpid)) { |
23 | pinfo.usbinfo.flags = PINFO_FL_SILENT; |
24 | pinfo.usbinfo.pid = *(int *)(ldata(usbpid)); |
25 | pgm->fd.usb.max_xfer = USBDEV_MAX_XFER_3; |
26 | pgm->fd.usb.rep = USBDEV_BULK_EP_READ_3; |
27 | pgm->fd.usb.wep = USBDEV_BULK_EP_WRITE_3; |
28 | pgm->fd.usb.eep = USBDEV_EVT_EP_READ_3; |
29 | |
30 | strcpy(pgm->port, port); |
31 | rv = serial_open(port, pinfo, &pgm->fd); |
32 | }
|
33 | #endif /* HAVE_LIBUSB */ |
34 | #if defined(HAVE_LIBHIDAPI)
|
35 | }
|
36 | #endif
|
37 | if (rv < 0) { |
38 | avrdude_message(MSG_INFO, "%s: jtag3_open_common(): Did not find any device matching VID 0x%04x and PID list: ", |
39 | progname, (unsigned)pinfo.usbinfo.vid); |
Zuerst wird also libhidapi ausprobiert, danach libusb. Bin ich gerade überfragt, warum die libhidapi da nichts findet.
Wie wäre es damit? https://www.mikrocontroller.net/articles/Raspberry_Pi_als_Universalprogrammer Dann noch ein http Interface dazu gebastelt, das dann über Windows incl. Dateitransfer bedient wird. Einmal erstellt und, da keine Updates benötigt werden, nie wieder angefaßt.
Andreas B. schrieb: > Wie wäre es damit? Halte ich nicht für produktionstauglich, wegen der fehlenden Pufferung zwischen dem Pi und dem Target. Falschrum reingesteckt, versehentlich was kurzgeschlossen, … – der Pi ist damit immer irgendwie „mit einem Bein im Knast“. Die von Atmel gelieferten Tools sind in dieser Hinsicht außerordentlich robust aufgebaut (mit Ausnahme des AVR Dragon).
> Raspberry
Mein Gott, warum nicht einfach avrdude installieren und fertig? Da steht
doch anscheinend eh schon ein Windows-Rechner, da muss man doch nicht
noch einen zweiten Rechner daneben stellen.
Außerdem hat er ja geschrieben daß die EDV-Leute in seiner Firma Angst
vor moderner Technik und Arbeitserleichterung haben und deshalb lieber
bei Windows 32Bit Gefrickel bleiben wollen, da kannst Du doch kein
neumodisches Teufelszeug und Hexenwerk mit Arm und Linux vorschlagen!
Bernd K. schrieb: > Mein Gott, warum nicht einfach avrdude installieren und fertig? Thread gelesen? Vermutlich nicht.
Jörg W. schrieb: > Bernd K. schrieb: >> Mein Gott, warum nicht einfach avrdude installieren und fertig? > > Thread gelesen? > > Vermutlich nicht. Doch, hab ich. Und wo ist das Problem? Treiber installieren, avrdude installieren, fertig. Das ist kein Neuland, das haben andere auch schon hinbekommen, sogar unter Windows.
Jörg W. schrieb: > Halte ich nicht für produktionstauglich, wegen der fehlenden Pufferung > zwischen dem Pi und dem Target. Falschrum reingesteckt, versehentlich > was kurzgeschlossen, … – der Pi ist damit immer irgendwie „mit einem > Bein im Knast“. Vertauschsichere Stecker sollte man in der Industrie schon machen. Notfalls macht man halt Optokoppler an die ISP Ausgänge. > Die von Atmel gelieferten Tools sind in dieser Hinsicht außerordentlich > robust aufgebaut (mit Ausnahme des AVR Dragon). Die müssen dann mit jedem Windows upgrade auf dem PC wieder upgedatet werden. Oder man nimmt halt die Atmel HW und steuert die mit dem Raspi via AVRdude an. Auch wieder über ein vom Raspi bereitgestelltes Webinterface.
Bernd K. schrieb: > Treiber installieren Genau die damit einhergehenden Probleme sind im Eröffnungsposting beschrieben.
Andreas B. schrieb: >> Die von Atmel gelieferten Tools sind in dieser Hinsicht außerordentlich >> robust aufgebaut (mit Ausnahme des AVR Dragon). > > Die müssen dann mit jedem Windows upgrade auf dem PC wieder upgedatet > werden. Ich bezog mich hier auf die Hardware (das, was Atmel da "Tool" nennt). Für die Benutzung mit AVRDUDE braucht's da keinerlei Updates, auch nicht auf Windows. Die Firmwareversion interessiert AVRDUDE nicht großartig. Ja, die mit einem RPi anzusteuern wäre wahrscheinlich noch ein sinnvoller Kompromiss. Wenn man auf dem noch ein wenig Python-Bastelei macht, bekommt man es sogar vielleicht hin, an einem GPIO einen "Programmieren!"-Button anzuklemmen und abzufragen. Verteilen der zu flashenden Firmware auf den Pi könnte sich sogar über Samba und Windows filesharing machen lassen.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Verteilen der zu > flashenden Firmware auf den Pi könnte sich sogar über Samba und Windows > filesharing machen lassen. Ich hatte bei dem Webinterface eher daran gedacht, das File mit dem Win PC über die Website zu übertragen und hier auch die Programmierung auszulösen. Der TO wollte ja alles über Win PCs steuern. Alternativ könnte sich der Raspi auch über ein zentrales Repo seine Hex files selbst holen. Da gibt es viele Möglichkeiten.....
:
Bearbeitet durch User
Robert H. schrieb: > Monentan werde ich es mal so weiter betreiben wie bisher. Mit > installierten libusb und altem USBProg. - Momentan muß ich die Rechner > in der Produktion auf Win10 umstellen, sonst nimmt die IT am 15.01. vom > Netz - > > Zum selber Compilieren bin ich zu weit weg von der Problematik. Naja du findest jetzt gerade die diversen Stolperfallen die sich so auftun können. Meine Empfehlung ist immer noch bleib bei deinem Setup das du ja soweit im Griff hast und und installiere unter W10 mit zatig den libusbk für deinen Programmer. Das wird problemlos funktionieren. Ich arbeite jetzt schon eine ganze Weile mit zadig und libusb unter W10. Keinerlei Probleme. Thomas
Robert H. schrieb: > Hallo Martin, > danke für die Hinweise. Dieses Thema gab's in Thread schon mal. Ich habe > mir dannauch einige Hersteller von solchen "universellen ISP" > Programmern angeschaut. Da lagen dann Preise wenn ich mich richtig > erinnere bei 1500-2000€ für das Grundgerät und bei bis zu 1000€ für > einen Programmierkopf. > Das sind leider die ueblichen Preise, das Zeug ist halt keine Massenware. Wenn man aber bereits die 50-100 Kisten fuer einen ICT ausgegeben hat, sollte das nicht mehr so weh tun. > Da unsere ICT und FKT Arbeitsplätze einzelne Tische sind, bräuchte ich > dafür 5 Grundgeräte und 5 Köpfe und für die "Flash-Arbeitspläte" 2 > Grundgeräte und 8 Programmierköpfe. > Das ist dann preilich jenseits von Gut und Böse (zumindestens bei uns). > Bei der Stueckzahl kannst du mit Selberbauen allenfalls/mit Glueck noch konkurrieren. Ich habe einfach einen simplen ARM-Embedded PC mit 4 USB-Schnittstellen genommen, vier robuste FT2232H-Adapter dran und damit die parallele Taktstrasse bestueckt. Vielleicht klappt das auch mit AVRdude. Der groesste Aufwand ist die Software-Anpassung, und wenn das Konstrukt zu hohe Ausfallraten hat (damals bei Windows USB leider der Fall gewesen) wird's sehr nervig/kostspielig, wenn man schon eh genug mit Testzyklen und Datenbankkram usw. genug zu tun hat.
Martin S. schrieb: > vier robuste FT2232H-Adapter dran und damit die parallele Taktstrasse > bestueckt. Vielleicht klappt das auch mit AVRdude. Ja, sollte.
Jörg W. schrieb: > Und selbst das eben nur nicht universell, und auch ansonsten (siehe CDC, > erst seit Windows 10 als Klassentreiber vorhanden) haben seine Jungs > mehr als 15 Jahre gebraucht, um halbwegs da anzukommen, wo alle anderen > schon immer waren, seit sie überhaupt USB gemacht haben. Dafür, dass > Microsoft meiner Erinnerung nach federführend an USB mitgewirkt haben, > fand ich das immer beschämend. Sie hätten die ersten sein können, bei > denen einfach mal „alles klappt“. Jörg, das siehst du schlichtweg falsch. MS hat mit seinem INF und CAT Mechanismus dafür gesorgt, daß man zu einem beliebigen und möglicherweise erst frisch erfundenen USB-Device einen passenden, vom Hersteller des Gerätes gelieferten Treiber in's System einbinden kann. Das klappt auch tatsächlich genau so, wie von MS gedacht. Bedenke dabei, daß USB eigentlich eine geschlossene Gesellschaft ist. Da darf eigentlich nicht ein jeder ein USB-Gerät bauen, es zu einer Geräteklasse zuordnen und fertig ist die Laube. Um eine vid und eine pid haben zu dürfen, muß man in den Verein eintreten und Geld berappen. Genau SO war und ist das gedacht. Systeme wie Linux sind da schlichtweg außen vor - es sei denn, irgend jemand zahlt dafür und irgend jemand ist dafür der juristische Vertragspartner. Jegliche freie Verwendung des USB (per Irgendwas-vid&pid) ist da nicht vorgesehen. Punkt. Wenn unsereiner also für seinen popligen selbstprogrammierten µC ne vid&pid von Winbond verwendet, dann ist das rein rechtlich nur per großzügigiem Augenzudrücken seitens Winbond möglich. Und wenn Linux über eine größere Menge an USB-Treibern verfügt, dann ist (bis auf Ausnahmen) das weder vom Konsortium noch von den betreffenden Geräteherstellern abgesegnet, sondern sowas ähnliches wie Robin Hood. Das ist also eigentlich nicht beschämend für MS, sondern sozusagen ein Abweichen von den zuvor gefaßten Vereins-Grundsätzen, getrieben von den "Straßen"-Zuständen. Das ist genau so wie die Preise für egal was, wo die gängigen Straßenpreise den Markenanbietern das eigentlich geplante Geschäft soweit versauen, bis diese mit ihren Preisen ebenfalls in realistische Gefilde notgedrungen sich herablassen. Oder wie Autodesk nun ne Bündelung macht, um das Geschäft zu erhalten. Nochwas: Wozu eigentlich diese auf dem USB herumhackende Diskussion? Der TO will vermeiden, eine ganze fette IDE mit ihren ganzen Whistles&Bells der Produktion zumuten zu müssen. Das Anliegen ist sehr verständlich. Aber am ehesten löst man das, indem man ein Separat-Programm schreibt, das eben nur das Brennen der Chips abdeckt und das ordentlich auf der ja bereits in der Produktion vorhandenen PC-Basis arbeitet - die eigentlichen Programmier-Algorithmen sollte man kennen, wenn die bisherige Lösung bereits zu alt ist für die vorhandenen PC's. Und wenn die hier vorgeschlagene Brenn-Hardware nicht mehr unterstützt wird, dann kauft man ne neue oder macht man sie selber und benützt eine möglichst verbreitete Verbindung wie z.B. VCP zwischen PC und Brenner. Kein Gefummel mit libusb, zadek und Konsorten, sondern das, was man ohne sowas kriegt - zum Beispiel fertige USB-seriell-Konverter oder nen FTDI-parallel, der ist schneller. Und dafür gibt es die Treiber schon längst. W.S.
W.S. schrieb: > Jörg, das siehst du schlichtweg falsch. Ach ja, weil es Microsoft als einzige richtig gemacht haben? Seltsam nur, sie waren von vornherein bei dem Laden mit dabei (und haben uns allen damit vermutlich so einen Ressourcen-Engpass wie eine 16bittige VID mit eingebrockt – zu einer Zeit, da man um das Ende 32bittiger IP-Adressen schon sehr genau Bescheid wusste), und das war schon immer als "Plug and Play" angepriesen. Microsoft sind aber in mancher Hinsicht die letzten, die das endlich mal geschafft haben, mehr als nur HID (und MSC) als class driver zu implementieren. Alle anderen (und damit meine ich jetzt nicht nur Linux, sondern auch alle anderen kommerziellen Systeme, die Opensource-Systeme sowieso) haben das vorher auf die Reihe bekommen. Sie alle haben es auch vorher schon geschafft, einen generischen USB-Treiber mit im Boot zu haben, auf den man ohne Wenn und Aber (wie ominöse INF-Files, die man am besten noch durch den Hersteller absegnen lassen möge) zurückgreifen kann, wenn es mal keinen vorgefertigten Gerätetreiber gibt. Das ist dahingehend noch on-topic, weil es halt just in den Problemkreis des TE hinein ragt, mit den Schwierigkeiten, die man mit LibUSB hat. Den Zirkus hat man in der Form nur unter Windows. (Bei allen anderen muss man sich höchstens noch um Zugriffsrechte kümmern, damit halt nicht jederfrau alles darf.) Ironischerweise verhindert der ganze Signier-Käse mit Microsoft-Kuckuck keinesfalls einen Missbrauch. Klassentreiber wie HID sind natürlich essenziell (schließlich muss man irgendwie Maus und Keyboard ran bekommen, ohne dass jeder Tastaturhersteller vorher bei Microsoft gebettelt hat), genauso MSC – und damit kann man mit einem unbekannten USB-Stick eben trotzdem noch Malware nach Gutdünken unterbringen. Ausgebremst werden alle die mit exotischen Geräten, die praktisch kaum eine Chance hätten, die Systemsicherheit zu gefährden.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Alle anderen (und damit meine ich jetzt nicht nur Linux, sondern auch > alle anderen kommerziellen Systeme, die Opensource-Systeme sowieso) > haben das vorher auf die Reihe bekommen. Manchmal ist es schwer, dir etwas beizubringen. Das ganze Verfahren ist von Anfang an NICHT dazu gemacht, um dir oder mir das Benützen zu erleichtern, sondern um den Kreis der Hersteller einzuschränken, alle anderen sowohl technisch als auch juristisch auszugrenzen und dabei möglichst viel Geld herauszuholen. Ohne dieses wäre das Einführen von vid&pid herzlich überflüssig und das Zuordnen eines Gerätes zu einer Geräteklasse hätte völlig ausgereicht. Aber eben genau DAS sollte strikt vermieden werden. So herum tickt das Ganze. Das Konsortium mit MS und Intel an der Spitze wollte möglichst lange wie Fafnir auf dem Goldschatz sitzen. Die ganze Industrie ist voll von sowas. Denke doch nur an Kopierschutzmaßnahmen bei DVD's, selbst bei Audio-CD's haben sie es versucht. All diese Welt ist nicht dein Freund. Kannste dir merken. Wünschen würde ich mir was Anderes, du wohl auch - aber das ist ein anderes Thema. W.S.
W.S. schrieb: > Ohne dieses wäre das Einführen von vid&pid herzlich überflüssig und das > Zuordnen eines Gerätes zu einer Geräteklasse hätte völlig ausgereicht. Sehe ich nicht so, eine Herstellerkennung gibt's auch woanders (MAC-Adressen bspw.). Dass man für spezielle Hardware (und darunter zähle ich durchaus einen ISP-Programmer, um mal zurück zum Thema zu kommen) spezielle Protokolle erfinden kann, finde ich durchaus sinnvoll, und VID/PID gestatten es dann, dass man eine eindeutige Zuordnung eines solchen speziellen Protokolls zu einem Gerät findet. Es ist das Verdienst Microsofts, einerseits das Konzept des Klassentreibers zum Teil (bspw. eben für serielle Geräte) jahrelang ignoriert zu haben, und andererseits den ganzen Zirkus dabei so umständlich aufgebläht zu haben, dass am Ende die Hersteller auch noch davon abgegangen sind, ihre Gerätetreiber über VID/PID-Zuordnung anzubinden, sondern stattdessen sagen: "Wenn Microsoft als (nahezu) einzigen Treiber halt immer HID dabei hat, dann sind wir eben jetzt ein HID." Nochmal für dich: nur bei Microsoft mit so einem Zirkus. Nicht bei Sun, nicht bei Mac, nicht bei *BSD, nicht bei Linux. Es ist also unbillig, nur wegen Microsofts Unwillen hier alle über einen Kamm scheren zu wollen.
:
Bearbeitet durch Moderator
W.S. schrieb: > Das ganze Verfahren ist > von Anfang an NICHT dazu gemacht, um dir oder mir das Benützen zu > erleichtern Naja, dann werden sie halt eben nicht benutzt wenn das absichtlich schwer zu benutzen gemacht wurde. Ist doch nicht mein Problem. Ein Grund mehr darauf komplett zu verzichten. Bei uns stehen jetzt 6 nagelneue Xubuntu-Boxen unten in der Produktion mit Programmieradapter, Prüfadapter, eigener Software. Konfiguration und Softwareausstattung lege ich hier oben schriftlich fest und mit einem Tastendruck rauscht die per ansible/ssh nach unten und manifestiert sich dort auf allen 6 Rechnern gleichzeitig. Ohne meinen Hintern aus dem Sessel zu erheben. Das ist so entspannend und befriedigend dem allem beim reibungslosen Funktionieren zuzuschauen, ich kann mich gar nicht davon losreißen.
Jörg W. schrieb: > Es ist das Verdienst Microsofts, einerseits das Konzept des > Klassentreibers zum Teil (bspw. eben für serielle Geräte) jahrelang > ignoriert zu haben, und andererseits den ganzen Zirkus dabei so > umständlich aufgebläht zu haben, dass am Ende die Hersteller auch noch > davon abgegangen sind, ihre Gerätetreiber über VID/PID-Zuordnung > anzubinden, sondern stattdessen sagen: "Wenn Microsoft als (nahezu) > einzigen Treiber halt immer HID dabei hat, dann sind wir eben jetzt ein > HID." Jörg du siehst das ganze nur mit deiner Linux Brille. Schon im 98DDK gab es einen USB Comporttreiber der sog POS Treiber. Zu diesem Zeitpunkt hat es noch gar keine CDC Spec. gegeben. Ebenso war dort schon ein Treiber für SDC drin. Auch wenn die Qualität der Beispiele nicht immer produktiv Niveau hatte konnte man daraus durchaus was bauen. Nur die Hersteller von spez. Hardware waren zu faul das auch umzusetzen. Es hat schon einen Grund warum FTDI mit ihren Chips so erfolgreich waren. Nicht ohne Grund waren viele Treiber ziemlich instabil. Es gab aber damals schon eine Fa Thesycon die kommerziell einen Universaltreiber angeboten hat nur die meisten haben halt selbst was gebastelt. Es gab da auch noch diese kaputten Jungo Treiber. Ich geb dir Recht diese inf Geschichte ist ziemlich verkorkst. Das hätte man besser lösen können. Ich bin aber schon der Meinung dass nicht MS sondern der HW Hersteller geeignete Treiber bereitstellen muss. Wenn er das nicht kann muss er halt mit HID arbeiten. Das WinUsb nicht so richtig zum Zuge kommt kann man jetzt auch nicht MS vorwerfen. Das läuft stabil und ist gut dokumentiert. Wenn man es richtig macht kommt das auch ohne Inf aus man muss das nur wollen. Thomas
Hi, die Microchip IPE unterstützt mittlerweile mit dem PicKit4 auch Atmel Controller. Die IPE bietet ebenfalls ein Kommandozeilentool mit an. Wird bei uns in der Fertigung auch in automatisierten Testsystemen eingesetzt. Evtl. ist das ja was für euch. Gruß
Thomas Z. schrieb: > Jörg du siehst das ganze nur mit deiner Linux Brille. Mit Linux habe ich eher wenig am Hut. ;-) Meine Wurzeln liegen eher im FreeBSD, aber mit USB muss ich mich vor allem im Zusammenhang mit AVRDUDE & Co. rumärgern. > Schon im 98DDK gab > es einen USB Comporttreiber der sog POS Treiber. Zu diesem Zeitpunkt hat > es noch gar keine CDC Spec. gegeben. Dennoch wette ich, dass sie zu der Zeit bereits in Vorbereitung war. Sie ist im Januar 1999 als Version 1.1 verabschiedet worden, und wer solche Standardisierungsgremien kennt weiß, dass die nicht von heute auf morgen arbeiten. (Möglicherweise gab es intern sogar eine 1.0, die nur nie veröffentlicht worden ist?) Außerdem ist das keine Ausrede dafür, dass man nicht nach erfolgter Standardisierung einen Klassentreiber nachgelegt hat, wie man es ja für HID und MSD getan hat. Ganz ehrlich, zu Windows-98-Zeiten wurde USB ohnehin üblicherweise noch als “Useless Serial Bus” übersetzt, weil die gesamte OS-Unterstützung und Anbieterwelt noch reichlich „grün“ war. Das hat sich erst in den Jahren danach dann allmählich gesetzt. > Ich geb dir Recht diese inf Geschichte ist ziemlich verkorkst. Das hätte > man besser lösen können. Ich bin aber schon der Meinung dass nicht MS > sondern der HW Hersteller geeignete Treiber bereitstellen muss. Das ist die typische Windows-Sichtweise: „sollen die mal machen“. Wenn dann ein Linux installiert wird und nicht alles gleich aus der Dose raus funktioniert, wird über den „Mist“ gemeckert … ;-) > Wenn er > das nicht kann muss er halt mit HID arbeiten. Ein Programmierdongle als “human interface” ist einfach pervers. > Das WinUsb nicht so > richtig zum Zuge kommt kann man jetzt auch nicht MS vorwerfen. Das läuft > stabil und ist gut dokumentiert. Warum zum Geier™ wird es dann nicht benutzt? Schreib mir eine Anpassung für AVRDUDE, mit der man das benutzen kann, und ich veröffentliche sie sofort mit. Ich glaube mich zu erinnern, mir das mal rudimentär angesehen zu haben, und es war dann wohl doch nicht ganz so einfach … einen Programmierdongle einerseits mit dem von dir geforderten Herstellertreiber unter Atmel Studio aber alternativ mit WinUsb zu betreiben, damit man auch mit AVRDUDE drauf zugreifen kann, geht wohl nicht so ohne weiteres. (Korrigier mich, wenn das nicht richtig ist.) Auch so Dinge wie in einem FT2232 den ersten Kanal mittels generischem Treiber für die Programmierung (MPSSE) zu benutzen und den zweitem dem normalen ttyUSB-Treiber zu überlassen, gestaltet sich in Windows deutlich schwieriger als unter allen anderen OSes.
Thomas Z. schrieb: > Ich bin aber schon der Meinung dass nicht MS > sondern der HW Hersteller geeignete Treiber bereitstellen muss. Gilt das auch für Tastaturen, Mäuse und USB-Sticks? Wenn ja dann gute Nacht, wenn nein dann warum Standardtreiber nicht auch für die anderen generischen Geräteklassen? Wenn ein Hersteller meint er könne einen besseren Treiber liefern für seine Tastatur oder seine Maus oder für seinen RS232-Adapter als der generische Windows-Treiber und den Anwender dann damit nerven will den Treiber-Installationstanz für sein spezielles Gerät aufzuführen dann kann er das doch immer noch machen. Aber die Grundfunktionen aus der Geräteklasse kann ein generischer Klassentreiber für Windows doch problemlos machen. Anderswo geht das doch auch. Und genau dafür war es ja auch gedacht, sonst bräuchte man doch überhaupt keine Geräteklassen in denen die Grundfunktionen definiert sind die mit allen Geräten dieser Klasse kompatibel sind!
Jörg W. schrieb: >> Wenn er >> das nicht kann muss er halt mit HID arbeiten. > > Ein Programmierdongle als “human interface” ist einfach pervers. Definiere einfach die Abkürzung um: "Has [already] Installed Driver" und schon ist es nicht mehr pervers. Es sind einfach nur 3 Buchstaben, Schall und Rauch, Microsoft hat es dazu gemacht weil es jahrelang die einzige von Windows unterstützte Geräteklasse war. Man braucht dafür auch keine zusätzlichen Libs mehr, libhidapi ist auf Windows einfach nur ein ganz dünner Wrapper den man genausogut hätte weglassen können, einfach CreateFileA, WriteFile, ReadFile, CloseHandle im Windows API und fertig ist die Kommunikation mit dem HID-Device.
:
Bearbeitet durch User
Ich weiß. Macht es trotzdem nicht weniger idiotisch, führt die Geräteklassen in USB ad absurdum. Wie schon geschrieben, bringt der ganze Zirkus halt nicht einmal einen Sicherheitsgewinn, mit dem man das hätte begründen können. Emotet und Konsorten kommen sowieso auf ganz anderen Wegen daher, und STUXnet hat auch nicht erst Microsoft nach einer Zertifizierung gefragt …
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Wie schon geschrieben, bringt der ganze Zirkus halt nicht einmal einen > Sicherheitsgewinn Der überall zunehmende Zertifikatszirkus dient dazu die Anwender davon abzuhalten an strategisch wichtigen Positionen selbergeschriebene Software einzusetzen. Sonst könnte man ja Bluray-Filme rippen oder sowas, Gott bewahre! Mit Sicherheit für den Anwender hat das alles nichts zu tun sondern es geht um die Sicherheit für die Hersteller vor den rechtlichen Konsequenzen möglicher Aktionen der Endanwender. Rechtliche Rahmenbedingungen bei Urheberrechten haben den Nährboden gelegt für die Notwendigkeit dieser perversen technischen Selbstkastration und damit einhergehende Stagnation jeglichen technischen Fortschritts.
Naja, das Urheberrecht kann man bei USB nun auch schlecht vorschieben.
Bernd K. schrieb: > Gilt das auch für Tastaturen, Mäuse und USB-Sticks? Wenn ja dann gute > Nacht, wenn nein dann warum Standardtreiber nicht auch für die anderen > generischen Geräteklassen? warum sollte man das für Std Devices tun wollen? natürlich nicht Welche Klasse würdest du den für einen Programierdongle unter Win empfehlen? Ich würde ja sagen DFU aber o Wunder das wird nicht unterstützt, weshalb es zig verschiedene halbgare Treiber gibt. Ich kenne übrigens Anbieter die für USB Midi eigene Treiber anbieten und auch lizenzieren, weil der MS Treiber mit Sysex manchmal Probleme hat. Stell dir vor die lassen in Ihrem Treiber dann nur bestimmte Pids zu damit man das Teil eben nicht universell benutzen kann ohne zu bezahlen was für eine böse Welt. Bernd K. schrieb: > CreateFileA, WriteFile, ReadFile, CloseHandle im Windows API und fertig > ist die Kommunikation mit dem HID-Device. Klar funktioniert das musst du halt nur noch schauen woher du den handle bekommst. Das ist der eigentliche Grund für libhidapi. HID ist halt die einzige Möglichkeit um direkt vom Usermode mit USB zu sprechen, die immer funktioniert das macht es ja gerade so attraktiv. Wenn man es schneller braucht muss ein Treiber her. Nochmal es geht hier darum wie man unter W10 problemlos einen Programmer ans laufen bekommt. Thomas
Thomas Z. schrieb: > Bernd K. schrieb: >> Gilt das auch für Tastaturen, Mäuse und USB-Sticks? Wenn ja dann gute >> Nacht, wenn nein dann warum Standardtreiber nicht auch für die anderen >> generischen Geräteklassen? > > warum sollte man das für Std Devices tun wollen? Warum dann für Seriellemulationen? Ist doch auch ein "Std Device", seit 20 Jahren. > HID ist halt die einzige Möglichkeit um direkt vom Usermode mit USB zu > sprechen, die immer funktioniert Unter Windows. Unter allen anderen geht es auch ohne dieses Versteckspiel, auch direkt vom Usermode. (Einzige Voraussetzung nannte ich schon: der Admin muss dem User die Zugriffsrechte eingeräumt haben. Noch ein Fall übrigens, wofür VID/PID-Paare durchaus hilfreich sind.) > Nochmal es geht hier darum wie man unter W10 problemlos einen Programmer > ans laufen bekommt. Wenn es seit der Varabschiedung von CDC 1.1 vor 20 Jahren einigermaßen überall einen entsprechenden Klassentreiber gegeben hätte, ich bin mir sicher, all diese Programmer hätten den mit Kusshand genommen. Die arbeiteten nämlich zuvor komplett mit seriellen Schnittstellen. (Das Atmel JTAGICE mkII konnte man dann auch alternativ über RS-232 oder USB bedienen.)
:
Bearbeitet durch Moderator
Thomas Z. schrieb: > das musst du halt nur noch schauen woher du den handle > bekommst. Das ist der eigentliche Grund für libhidapi. Pfadnamen die ich für CreateFileA() verwenden kann bekomm ich direkt vom Setup-API, ist ne halbe Bildschirmseite Code um alle Geräte mit vid oder pid zu enumerieren. Den Aufwand da noch extra ne separate dll zu brauchen wiegt das nicht auf.
Jörg W. schrieb: > Warum dann für Seriellemulationen? Ist doch auch ein "Std Device", seit > 20 Jahren. Ja und genauso lange existiert auch usbser.sys. Du machst das daran fest dass dieser Treiber halt bisher eine Inf bräuchte und erst seit W10 ohne auskommt? OK kann man so sehen. Ich bin mir aber sehr sicher das das bei MS nie eine prio hatte. Es gab ja schon immer Chips mit passenden Treibern. Das ganze ist erst mit der breiten Verfügbarkeit von leistungsfähigen Controllern mit USB so richtig interessant geworden da bekommt man den usbcomport praktisch umsonst. Der Vergleich mit anderen Systemen bringt nichts wenn ich ein Win System habe. Ich hab mal USB Hardware im Auftrag entwickelt und auf meine Frage nach Linux Support die Antwort erhalten dass dafür kein Budget vorhanden sei und die Zielgruppe sowieso nur Mac und Win sei. Thomas
Thomas Z. schrieb: > Jörg W. schrieb: >> Warum dann für Seriellemulationen? Ist doch auch ein "Std Device", seit >> 20 Jahren. > > Ja und genauso lange existiert auch usbser.sys. Du machst das daran > fest dass dieser Treiber halt bisher eine Inf bräuchte und erst seit W10 > ohne auskommt? Ja. Ebendieses inf-File macht(e) den Nutzern die Arbeit schwer. Wenn es so einfach wäre, gäbe es diesen Thread nicht.
Jörg W. schrieb: > Wenn es seit der Varabschiedung von CDC 1.1 vor 20 Jahren einigermaßen > überall einen entsprechenden Klassentreiber gegeben hätte, ich bin mir > sicher, all diese Programmer hätten den mit Kusshand genommen. Die > arbeiteten nämlich zuvor komplett mit seriellen Schnittstellen. (Das > Atmel JTAGICE mkII konnte man dann auch alternativ über RS-232 oder USB > bedienen.) Nun ja dann stellt sich natürlich die Frage warum die das nicht einfach gemacht haben. Eine passende Installations Inf auf die entsprechende pid und usbser.sys hätte ja genügt. Wir drehen uns aber im Kreis. Jörg W. schrieb: > Ja. Ebendieses inf-File macht(e) den Nutzern die Arbeit schwer. > > Wenn es so einfach wäre, gäbe es diesen Thread nicht. Eigendlich ging es darum unter Win libusb zum laufen zu bekommen, weil eben libusb unter win sehr störrisch sein kann und die entsprechenden Programmierer die Win Installation stiefmütterlich behandeln. Deshalb ja auch die Zadig Geschichte. Das Packet ist gut aber halt Linux lastig und deshalb unter Win manchmal schwer zu verdauen. Thomas
:
Bearbeitet durch User
Thomas Z. schrieb: > Nun ja dann stellt sich natürlich die Frage warum die das nicht einfach > gemacht haben. Eine passende Installations Inf auf die entsprechende pid > und usbser.sys hätte ja genügt. Wir drehen uns aber im Kreis. Das ist schon zu viel, sag mal ist das wirklich so schwer zu verstehen? Stell Dir vor Du müsstest für jeden popeligen USB-Stick, für jede mal schnell ans Laptop angeschlossene Maus, für jede mal eben woanders angestöpselte Tastatur erst noch jedesmal umständlich die .inf irgendwo auf ner hinter das Sofa gerutschten verkratzten 4GB großen DVD voll mit Werbemull suchen? Jedesmal!? So ein Gerät will ich einfach anstöpseln und es funktioniert ohne dauerndes Treibergestresse und Installationsdatenträger rauskramen oder ellenlang im Internet herumsuchen nach der bescheuerten genau passenden .inf! Genau dafür daß man einfach Plug und Play machen kann wurden genau definierte Geräteklassen doch überhaupt erst erfunden! Ich brauch doch auch keine .inf Datei um den neuen Staubsauger in jede beliebige Steckdose zu stecken! Plug & Play!
:
Bearbeitet durch User
Bernd K. schrieb: > Ich brauch doch > auch keine .inf Datei um den neuen Staubsauger Und dein Kaffeetassen-Wärmer oder LED-leuchte am USB braucht auch keine .inf - sofern dein Port einfach so seine 5V liefert. Merke: derartige Vergleiche hinken mehr als das Rumpelstilzchen. Und eigentlich geht es hier auch nicht um den USB, sondern um eine Modernisierung der Programmier-Geschirre der TO in dessen Fertigung. Wenn er bislang nur steinaltes Zeugs verwendet hatte, was an derzeitigen PC's nicht mehr betreibbar ist, dann bleiben ihm wirklich nur 2 Möglichkeiten: 1. altes Zeug entsorgen und durch neueres Zeugs ersetzen. Egal ob Eigenentwicklung oder zugekauft. 2. einen alten PC mit altem OS hernehmen, als Insel betreiben und daran das alte Geschirre betreiben. Unsereiner hatte damals ja auch den stinkteuren Microchip-Programmer entsorgen müssen und durch eine Eigenentwicklung ersetzt, weil sowohl die V.24 als auch die DOS-Programme so langsam obsolet geworden waren. Als Entwickler sollte man sowas drauf haben - sowohl softwareseitig als auch hardwareseitig. Ich halte es deshalb für völlig angemessen, dem TO zu sagen, daß er es ähnlich zu tun in der Lage und auch willens sein sollte. Womit das Problem erledigt ist. W.S.
W.S. schrieb: > Womit das Problem erledigt ist. Mir dünkt, du hast das Eingangsposting nichtmal richtig gelesen.
Robert H. schrieb: > Kennt jemand von auch eine Software, ggf. auch einen Programmer dazu der > evtl. mit einer kleinen GUI zum Testen und vor allem mit einer > Kommandozeilenversion der Software kommt, die meinen Anforderungen > entsprechen würde? > Oder hat jemand eine Idee das mit den oben genannten Tools EINFACH zu > lösen. > > Im voraus schon mal besten Dank > Gruß > Robert Hi, wir nutzen AVR Rolo Flash, funktioniert ganz gut, auch bei Leute ohne mC Kentnissen. https://shop.halec.de/roloFlash/ Mfg aus dem Rhein-Ruhr Gebiet
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.