Hi Leute, nachdem mein original AVRISP mkII langsam anscheinend den Geist aufgibt, habe ich mir einen Klon bei Amazon bestellt. Es handelt sich um den ARCELI Atmel BEI AVRISP mkii. https://www.amazon.de/gp/product/B07R6LVVZW/ref=ppx_yo_dt_b_asin_image_o00_s00?ie=UTF8&psc=1 Leider wird dieser bei mir im Gerätemanager als "USB-SERIAL CH340 (COM6)" und nicht als mkii erkannt. Benutze normalerweise WinAVR und AVRDUDE und LibUSB-Filter. Habe schon versucht verschiedene Treiber zu installieren, leider bisher erfolglos. Hat jemand von euch Erfahrung mit mkii Klone und eventuell das gleiche Problem wie ich gehabt? Wie habt ihr das gelöst? Vielen Dank!
Thomas F. schrieb: > nachdem mein original AVRISP mkII langsam anscheinend den Geist aufgibt, Du bist dir also nicht sicher. Woran machst du das fest, dass dass der originale langsam den Geist aufgibt? Eigentlich ist der Originale AVRISP mkII nahezu unzerstörbar. Vielleicht lässt er sich noch retten. Thomas F. schrieb: > USB-SERIAL CH340 Probiere mal den STK500 treiber. Ein AVRISP MK2 sollte kein CDC device sein.
abc schrieb: > Thomas F. schrieb: >> nachdem mein original AVRISP mkII langsam anscheinend den Geist aufgibt, > > Du bist dir also nicht sicher. > Woran machst du das fest, dass dass der originale langsam den Geist > aufgibt? > Eigentlich ist der Originale AVRISP mkII nahezu unzerstörbar. Vielleicht > lässt er sich noch retten. Er geht prinzipiell noch, hat wahrscheinlich einen Wackler am Flachbandkabel, dennoch hätte ich gerne einen zweiten funktionierenden als Ersatz. > Thomas F. schrieb: >> USB-SERIAL CH340 > > Probiere mal den STK500 treiber. > > Ein AVRISP MK2 sollte kein CDC device sein. Der STK500 Treiber lässt sich nicht auswählen. Selbst mit deaktivierter Treibersignaturprüfung bekomme ich es nicht hin. Ich habe langsam das Gefühl, da ist wirklich ein USB 2 Serial chip im Gehäuse des Programers verbaut. Hat sonst keiner dieses Problem? Oder handelt es sich hier wirklich um ein Teil was falsch ist. Bei den Bewertungen bei Amazon schreiben viele, dass es auf Anhieb geklappt hat.
Thomas F. schrieb: > Leider wird dieser bei mir im Gerätemanager als "USB-SERIAL CH340 > (COM6)" und nicht als mkii erkannt. Welche USB-VID/PID? Findest Du in den Details als "Hardware-IDs".
Thomas F. schrieb: > Der STK500 Treiber lässt sich nicht auswählen. Selbst mit deaktivierter > Treibersignaturprüfung bekomme ich es nicht hin. Das STK500 hat eine RS232-Schnittstelle und braucht keinen Treiber. Vermutlich ist das Ding nicht zum AVRISP mkII kompatibel, sondern zum alten AVRISP (mit RS232) hinter einem CH340. In dem Fall solltest Du es auf COM6 (den der CH340 bekommen hat) als STK500v2 (dazu ist der Original-AVRISP kompatibel) ansprechen können.
Hmmm schrieb: > Welche USB-VID/PID? Findest Du in den Details als "Hardware-IDs". USB/VID_1A86&PID_7523&REV_0264 Was kann man darüber herausfinden?
Thomas F. schrieb: > Hmmm schrieb: >> Welche USB-VID/PID? Findest Du in den Details als "Hardware-IDs". > > USB/VID_1A86&PID_7523&REV_0264 > > Was kann man darüber herausfinden? Dass es eine CH341/CH340 USB-Serial Bridge von QinHeng Electronics ist. Damit kann es, wie dir schon gesagt worden ist, keinesfalls ein AVRISPmkII sein, denn dieses benutzt kein UART-Protokoll *). Es wird also sehr wahrscheinlich vom Protokoll her ein STK500v2 sein. Auf höheren Ebenen benehmen sich die beiden durchaus ähnlich, aber sie sind eben nicht 1:1 austauschbar. *) Im AVRISPmkII wurde ein PDIUSBD12 von NXP verbaut. Ist schon lange abgekündigt, weshalb Atmel dann auch diese Geräte nicht länger produzieren konnte. Theoretisch könnte sich natürlich in China jemand hinstellen und einen anderen Controller so programmieren, dass er sich wie ein solcher PDIUSBD12 benimmt, aber das wäre Arbeit … einfach einen USB-Seriell-Wandler zu benutzen ist keine Arbeit.
Thomas F. schrieb: > USB/VID_1A86&PID_7523&REV_0264 > > Was kann man darüber herausfinden? Als welcher Hersteller und welches Produkt sich das Ding ausgibt, und das passt tatsächlich zum CH340, dürfte also mit dem AVRISP mkII nicht viel zu tun haben. Versuch's mal mit avrdude -c stk500v2 -P COM6
Funktioniert! Im Makefile auf ...
1 | # AVRDUDE_PROGRAMMER = avrispv2 |
2 | # AVRDUDE_PROGRAMMER = stk200 |
3 | # AVRDUDE_PROGRAMMER = usbasp |
4 | AVRDUDE_PROGRAMMER = stk500 |
5 | |
6 | |
7 | # AVRDUDE_PORT = usb |
8 | # AVRDUDE_PORT = lpt1 |
9 | AVRDUDE_PORT = COM6 |
umgestellt und geht! Vielen lieben Dank für die Hilfe! Jetzt kann ich damit programmieren, muss aber jedes mal mein Makefile umstellen. Um die Faulheit zu fördern, war die Idee, ein Programmiergerät im Keller zu haben und eins im Arbeitszimmer. Zwischen den beiden hin und herzuwechseln ist dann aber schon wieder Mehraufwand :-) Aber zumindest weiß ich jetzt das ich nicht weiter probieren brauche den Programer als mkii zu installieren. Ich bestell mal noch einen Klon und überlege den ARCELI wieder zurück zu schicken. Ich berichte, ob der folgende Klon wirklich als mkii benutzt werden kann: https://www.amazon.de/gp/product/B00KM6ZA9I/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 Nochmals vielen Dank!
:
Bearbeitet durch Moderator
Thomas F. schrieb: > Ich bestell mal noch einen Klon Kannst du dir schenken. Den Grund schrieb ich dir oben: den für einen richtigen Clone nötigen PDIUSBD12 gibt es schon lange nicht mehr. Daher benutzen alle Nachbauten einen USB-Seriell-Wandler.
Lese hier mit und frage mich dauernd: warum in die Ferne schweifen, das Gute liegt so nah .... Ich habe viele Jahre gute Erfahrungen mit diesem Programmer gemacht, funktionerte problemlos: https://www.diamex.de/dxshop/Diamex-AVR-Prog-Programmer-fuer-ISP-PDI-TPI Er ist zwar nicht hundertprozentig kompatibel zum AVRISP MKII, aber erscheint als solcher unter den diversen Programmier- umgebungen. "Grösster" Nachteil aus meiner bescheidenen Sicht ist dass er nur mit 3.3V oder 5V zurecht kommt. Grösster Vorteil ist dass man auch das TPI-/PDI-Programmierinterface bekommt was für neuere AVR Controller wichtig ist. Wehrmutstropfen: aktuell nicht lieferbar.
jo mei schrieb: > Er ist zwar nicht hundertprozentig kompatibel zum AVRISP MKII Insbesondere ist er, wie ich kürzlich erfahren durfte, nicht kompatibel mit dem USB-Standard. :-/ https://github.com/avrdudes/avrdude/issues/935
https://www.ehajo.de/USP-mkII-AVR-Programmer/300.027 Ich kann bestaetigen, dass sich dieser ganz normal als avrispmkii in avrdude ansprechen laesst.
Jörg W. schrieb: > Insbesondere ist er, wie ich kürzlich erfahren durfte, nicht kompatibel > mit dem USB-Standard. :-/ Soll er doch. Er hat mir immmer treu und zuverlässig das getan was man von einem AVRISP-MKII erwartet. Lieber doch unkompatible Fernost-Nachbaukacke kaufen? Ich pflege übrigens keine geschäftlichen oder sonstigen Beziehungen zu der Firma Diamex.
Thomas F. schrieb: > Der STK500 Treiber lässt sich nicht auswählen. Selbst mit deaktivierter > Treibersignaturprüfung bekomme ich es nicht hin. Du bist da an der falschen Stelle. Im Gegensatz zum Atmel ISP mkII hat dein Gerät offenbar einen USB-UART Chip vom Typ CH340, für den der entsprechende Treiber installiert werden muss. Es wird nicht direkt via libusb sondern über einen virtuellen seriellen Port angesprochen. Demzufolge kann es sich nicht um einen "Atmel ISP mkII" handeln, nicht einmal um einen Nachbau dessen. Andere Programmieradapter mit (virtuellem) seriellem Port nutzen meistens das STK500 oder STK500v2 Protokoll. Windows zeigt den COM Port im Gerätemanager an. Linux tut es unmittelbar nach dem Anstecken mit dem Befehl "sudo dmesg". In der Programmier-Software musst du den (virtuellen) COM Port einstellen und das STK500 Protokoll. Treiber-Download: http://www.wch-ic.com/downloads/CH341SER_ZIP.html
jo mei schrieb: > Er hat mir immmer treu und zuverlässig das getan > was man von einem AVRISP-MKII erwartet. Für andere eben nicht, daher der Bugreport, den ich zitiert habe. Wenn es einfach überall zuverlässig seinen Dienst täte, wäre die Inkompatibilität niemandem aufgefallen. Es hängt damit dann einfach vom Wohlwollen des Betriebssystems ab, ob es dann trotzdem mit dem Teil reden will. Laut Diamex wird an dem Verhalten auch nichts mehr geändert, dieweil sie ein völlig anders gestricktes Nachfolgemodell auf den Weg bringen wollen (vielleicht gibt's die alten ja deshalb auch nicht mehr).
Jörg W. schrieb: > Kannst du dir schenken. Den Grund schrieb ich dir oben: den für einen > richtigen Clone nötigen PDIUSBD12 gibt es schon lange nicht mehr. Daher > benutzen alle Nachbauten einen USB-Seriell-Wandler. Hatte mir nach deinem Kommentar auch nicht mehr viel Hoffnung gemacht und mich mit dem STK500 Klon statt mkii Klon abgefunden, hatte einen weiteren KLon zu dem Zeitpunkt aber bereits bestellt UND!!! Heute ist er gekommen und funktioniert tadellos als mkii Klon. Habe bisher nur die Geschwindigkeit erhöht und ein paar µC programmiert, aber bisher ist mir kein negativer Unterschied zum Original aufgefallen! Es handelt sich um diesen hier: https://www.amazon.de/gp/product/B00KM6ZA9I/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 Falls es wichtig ist dies zu betonen, ich führe auch keine geschäftlichen Beziehungen zu diesem Lieferanten oder dieser Firma. Nachdem ich mir aber schwer getan habe einen funktionierenden zu finden und das Thema anscheinend öfters aufkommt, hoffe ich dass ich manchen damit helfen kann. Auch vielen Dank an all die anderen Kommentare und die Info, dass der von Diamex auch funktioniert. Der USB Standard wäre mir auch egal, solang das Ding tut was es soll.
Thomas F. schrieb: > Heute ist er gekommen und funktioniert tadellos als mkii Klon. D.h. mit
1 | -c avrisp2 -P usb |
?
Cool, dann hat sich also wirklich jemand die Mühe gemacht, dieses custom
protocol vom NXP-Chip nachzubauen.
(Diamex)
> Der USB Standard wäre mir auch egal, solang das Ding tut was es soll.
Naja, die Inkompatibilität ist ja nur deshalb aufgefallen, weil es eben
genau das nicht immer gemacht hat.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Cool, dann hat sich also wirklich jemand die Mühe gemacht, dieses custom > protocol vom NXP-Chip nachzubauen. Tatsächlich hat der gar kein Protokoll. Das ist nur ein USB-Device-Controller, alles, was der macht, legt der µC fest, der ihn ansteuert. IDs, USB-Descriptoren, das komplette Programm. Das ist beim PDIUSBD12 genauso wie bei dessen kleinem Bruder, dem via I2C angesteuerten PDIUSBD11. Beide unterstützen nur Full-Speed-USB (12 MBit/sec). Das hier nachgebaute "custom protocol" steckt komplett in dem µC des avrisp, was wohl ein AtMega128 ist, wenn ich dieses Bild hier https://display3000.com/shop/media/images/mkii_innen_600.jpg richtig interpretiere. Wenn man den Sourcecode der Firmware des Atmega128 hat, kann man die auf einen Atmega32U4 o.ä. portieren (sofern die Firmware nicht so umfangreich sein sollte, daß sie mehr Flash braucht als der bietet).
USB-Dinge schrieb: > Tatsächlich hat der gar kein Protokoll. Das ist nur ein > USB-Device-Controller, alles, was der macht, legt der µC fest, der ihn > ansteuert. IDs, USB-Descriptoren, das komplette Programm. Das war mir in diesen Details nicht klar. Ja, in der Tat, der originale AVRISPmkII hat einen ATmega128 drauf. Da selbst die komplette STK500v2-Firmware in einen ATmega8535 gepasst hat, denke ich, dass man einen solchen Clone auch locker in einem ATmega32U* unterbekommen können sollte. Der AVRISP hat zwar noch ein paar Zusatzfunktionen, um verpolte Stecker etc. zurückmelden zu können, aber der STK500 hat dafür noch den kompletten Code für HVSP und HVPP mit an Bord.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.