mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ISP-Programmer für Produktion


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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
von Karl M. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Über den Dingen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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

von Karl M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Karl M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Denis G. (denis)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
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

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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
von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
2 lesenswert
nicht lesenswert
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
von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
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

von Mathias H. (mathias)


Bewertung
1 lesenswert
nicht lesenswert

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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“.

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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
von Edgar S. (Firma: keine) (heinbloed1)


Bewertung
1 lesenswert
nicht lesenswert
Guck dir mal dir Produkte der Firma Conitec an, die haben solche System.

von Marian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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

von Marian (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Marian,
danke für den Link auf die Anleitung. Bist mir zuvorgekommen.

Gruß und schönen Tag noch
Robert

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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
von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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

von Robert H. (kee4)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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:
#if defined(HAVE_LIBHIDAPI)
  /*
   * Try HIDAPI first.  LibUSB is more generic, but might then cause
   * troubles for HID-class devices in some OSes (like Windows).
   */
  serdev = &usbhid_serdev;
  for (usbpid = lfirst(pgm->usbpid); rv < 0 && usbpid != NULL; usbpid = lnext(usbpid)) {
    pinfo.usbinfo.flags = PINFO_FL_SILENT;
    pinfo.usbinfo.pid = *(int *)(ldata(usbpid));
    pgm->fd.usb.max_xfer = USBDEV_MAX_XFER_3;
    pgm->fd.usb.rep = USBDEV_BULK_EP_READ_3;
    pgm->fd.usb.wep = USBDEV_BULK_EP_WRITE_3;
    pgm->fd.usb.eep = 0;

    strcpy(pgm->port, port);
    rv = serial_open(port, pinfo, &pgm->fd);
  }
  if (rv < 0) {
#endif  /* HAVE_LIBHIDAPI */
#if defined(HAVE_LIBUSB)
    serdev = &usb_serdev_frame;
    for (usbpid = lfirst(pgm->usbpid); rv < 0 && usbpid != NULL; usbpid = lnext(usbpid)) {
      pinfo.usbinfo.flags = PINFO_FL_SILENT;
      pinfo.usbinfo.pid = *(int *)(ldata(usbpid));
      pgm->fd.usb.max_xfer = USBDEV_MAX_XFER_3;
      pgm->fd.usb.rep = USBDEV_BULK_EP_READ_3;
      pgm->fd.usb.wep = USBDEV_BULK_EP_WRITE_3;
      pgm->fd.usb.eep = USBDEV_EVT_EP_READ_3;

      strcpy(pgm->port, port);
      rv = serial_open(port, pinfo, &pgm->fd);
    }
#endif  /* HAVE_LIBUSB */
#if defined(HAVE_LIBHIDAPI)
  }
#endif
  if (rv < 0) {
    avrdude_message(MSG_INFO, "%s: jtag3_open_common(): Did not find any device matching VID 0x%04x and PID list: ",
                    progname, (unsigned)pinfo.usbinfo.vid);

Zuerst wird also libhidapi ausprobiert, danach libusb.

Bin ich gerade überfragt, warum die libhidapi da nichts findet.

von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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).

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
> 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!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Mein Gott, warum nicht einfach avrdude installieren und fertig?

Thread gelesen?

Vermutlich nicht.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Treiber installieren

Genau die damit einhergehenden Probleme sind im Eröffnungsposting 
beschrieben.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
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
von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
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

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> vier robuste FT2232H-Adapter dran und damit die parallele Taktstrasse
> bestueckt. Vielleicht klappt das auch mit AVRdude.

Ja, sollte.

von W.S. (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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
von W.S. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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
von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
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

von Florian P. (ol1cr0n)


Bewertung
0 lesenswert
nicht lesenswert
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ß

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Naja, das Urheberrecht kann man bei USB nun auch schlecht vorschieben.

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas Z. (usbman)


Bewertung
0 lesenswert
nicht lesenswert
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
von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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
von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Womit das Problem erledigt ist.

Mir dünkt, du hast das Eingangsposting nichtmal richtig gelesen.

von Frank T. (unwichtig)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.