Atmel Studio 7 erkennt AVRISPmkII nicht mehr

Atmel Studio 7 erkennt AVRISPmkII nicht mehr

Dirk

Administrator
Teammitglied
28. Jan. 2007
4.328
166
63
Mittelhessen, Giessen
Sprachen
  1. ANSI C
  2. C++
  3. C#
  4. Java
  5. Kotlin
  6. Pascal
  7. Assembler
  8. PHP
Dirk hat eine neue Ressource erstellt:

Atmel Studio 7 erkennt AVRISPmkII nicht mehr - Eine Lösung hierzu

Heute musste ich meinen AVRISPmkII Programmer verwenden, da ich hier einen speziellen Programmierstecker am ISP Kabel angekrimpt habe.

Atmel Studio 7 hat den AVRISPmkII Programmer aber nicht mehr erkannt. Im Programmierdialog wird nur noch der Simulator angezeigt.

Eine Lösung, die ich gefunden habe (bitte auf eigene Verantwortung verwenden):

  1. Zadig Driver Installer herunterladen und ausführen.
  2. Im Menüpunkt Options "List all devices"...

Weitere Informationen zu dieser Ressource...
 
Hi,

dann geht das also wie bei Bascom nur noch über die libusb. :confused:
Man gut das ich hier AVR-Studio 4 und 5 noch auf dem NAS habe.
Das reicht mir auch soweit erst einmal aus.
Ich versteh ja das man mal alte Zöpfe abschneiden muß.
So alt ist der AVRISPmk2 aber nun auch noch nicht. o_O
Beim STK500 oder Dragon würde ich es da eher verstehen.

Gruß
Dino
 
Ich versteh ja das man mal alte Zöpfe abschneiden muß
Ich hatte letztens mal 'ne Anzeige von Microchip zu den AVRs gesehen (Vereinigung Atmel-Microchip), wo diverse Pros zu den AVR angepriesen wurden. Auch der tolle kostenfreie C-Compiler im Atmel Studio. Daß es auch einem kostenfreien Assembler gibt, wurde nicht erwähnt.

Der in einigen neuen B-Megas integrierte "Peripheral Touch Controller" wird in den Datenblättern ja auch nicht dokumentiert (nur erwähnt) - auf meine Anfrage beim Support bekam ich die Antwort, irgendson Wizzard zu verwenden, der irgendwas generiert, was man dann in seinen C-Code einbinden kann.

Rat mal, was einer der nächsten alten Zöpfe sein wird...
 
So alt ist der AVRISPmk2 aber nun auch noch nicht

Nein ist er nicht, ich finde den auch gut. Ich weiß nicht warum das nicht mehr funktioniert hat, ob ich bei der Installation des Studio was falsch gemacht habe, ob es daran liegt, dass ich ältere Studio Versionen noch installiert habe?! Da ich schnell eine Lösung brauchte (ich habe einen speziellen Stecker am ISP Kabel und wollte den nicht bei einem anderen Programmer ans Kabel krimpen) habe ich in Netz gesucht. Es gibt mehrere, die das Problem haben oder hatten, einige haben dann den Treiber geändert, danach ging es wieder.

Das Problem was ich die ganze Zeit schon beim Studio 6 hatte, was mich auch ziemlich nervt: Wenn der Programmer am Target angeschlossen und keine Betriebsspannung eingeschaltet ist, bibt es einen Fehler nach dem Auswählen des Programmers im Programmierdialog. Erst mit Betriebsspannung geht es dann.
 
Rat mal, was einer der nächsten alten Zöpfe sein wird...

Du meinst Assembler? Also ich hoffe mal nicht, kann ich mir aber auch eigentlich nicht vorstellen. Ich habe zwar schon lange kein Projekt mehr in Assembler realisiert, aber einige und teileweise noch richtig komplexe hinter mir. Also wenn ich da mal nicht im Notfall ändern/erweitern und neu assemblieren kann ... :confused:

Ohne Assembler kein Compiler :) Also wird das nicht passieren mit dem Zopf ;)
 
Du meinst Assembler? Also ich hoffe mal nicht, kann ich mir aber auch eigentlich nicht vorstellen.
Jain... eher so, daß irgendwann eben in neuen/aktualisierten Datenblättern keine Dokumentation der Hardware, Register usw mehr vorhanden ist - wie eben jetzt schon beim PTC...

Übrigens hatte ich damals schon Probleme mit der Installation des 7er Studios. Die hat nämlich bei mir nebenbei 'n neuen Jungo-Treiber installiert, sodaß der AVRISP mkII auch beim 6er Studio nicht mehr verwendbar war (siehe hier).

Tschuldigung, daß ich mich hier mit soviel OT breitgemacht habe...
 
Jain... eher so, daß irgendwann eben in neuen/aktualisierten Datenblättern keine Dokumentation der Hardware, Register usw mehr vorhanden ist - wie eben jetzt schon beim PTC...

Ich denke in diese Richtung wird es gehen und dies finde es auch nicht so gut. Man merkt dies bei neuen Datenblättern, die Peripheriemodule werden nur noch grob angerissen. Es wird immer mehr auf fertige Libs gesetzt, vieles ist auch komplexer geworden. Einiges finde ich sinnvoll, anderes finde ich überflüssig, überladen, das programmiere ich lieber selbst ... solange ich es kann.

Tschuldigung, daß ich mich hier mit soviel OT breitgemacht habe...
Ich denke mal, das ist hier überhaupt nicht "schlimm" ;) Es geht ja auch nicht um irgendeine Frage oder Problem von einem Foren-Mitglied, über das wir hier diskutieren. Also alles gut :)

Dirk :ciao:
 
Hi,

Ich denke in diese Richtung wird es gehen und dies finde es auch nicht so gut. Man merkt dies bei neuen Datenblättern, die Peripheriemodule werden nur noch grob angerissen. Es wird immer mehr auf fertige Libs gesetzt, vieles ist auch komplexer geworden. Einiges finde ich sinnvoll, anderes finde ich überflüssig, überladen, das programmiere ich lieber selbst ... solange ich es kann.

Mikrocontroller ohne vernünftiges Datenblatt werde ich boykottieren. Es gibt auch noch andere Hersteller mit schönen Micros ( so lange es kein PIC ist ;) )

Gruß
Dino
 
Mikrocontroller ohne vernünftiges Datenblatt werde ich boykottieren. Es gibt auch noch andere Hersteller mit schönen Micros ( so lange es kein PIC ist ;) )
Also so wie ich das sehe, sind die Datenblätter der neueren tinyAVR und megaAVR so detailliert wie bisher auch. Auch für diejenigen, die Assembler verwenden, wird auf die Assemblerinstructions eingegangen. Ausnahme ist hier anscheinend bei einigen ganz wenigen Mikrocontrollern das PTC Modul, da hatte @LotadaC schon mal hier nachgehakt. (Ich habe mich damit noch nicht beschäftigt, ich vermute dass hier die Einstellung recht komplex ist, so dass man das über den QTouch-Composer und nicht manuell über Register-Beschreiben macht).

Also im Moment noch alles gut :)
 
Naja, der Composer wird ja auch erstmal aus diesen komplexeren Berechnungen die Registerbits generieren, insofern wäre das bis hier noch Sprachenunabhängig. Möglicherweise ist das weitere Verfahren auch nicht ganz trivial, aber ob wir uns das zumuten, können wir doch selbst entscheiden, oder?!

Auch bei den neuen Datenblättern liest sich die Beschreibung der einzelnen Module weitgehend noch wie copy&paste (was ja nicht schlecht ist, wenn die eventuellen Anpassungen stimmen).
Beim PTC gibts keine bisherige Dokumentation zum kopieren, die müßte da also irgenwer komplett neu schreiben.

Ich vermute hinter dem PTC sowas ähnliches wie'n (mehrkanal-)PWM, welches die Sensorkapazität(en) in einen/mehrere (externe/n) Speicherkondensator(en) umläd (und die Anzahl der Umladevorgänge mitzählt), und diesen (ggf über einen AC) in den PWM-Pausen liest. Kippt dabei der Pegel, wird der IRQ getriggert, und die Anzahl kann ausgelesen werden. Möglicherweise auch ähnlich einem InputCapture-Event (mehrere Kanäle quasi-gleichzeitig).
So mal im groben. Wird sicher noch komplexer sein, aber wenn die da 'n seperates Hardware-Modul konstruieren, wird das auch weitgehend autark arbeiten (also einmal eingestellt nicht so viel Interaktion mit dem eigentlichen Programm fordern).

Hat mit dem eigentlichen Thema aber nix mehr zu tun...
 
Hi,

Naja, der Composer wird ja auch erstmal aus diesen komplexeren Berechnungen die Registerbits generieren, insofern wäre das bis hier noch Sprachenunabhängig. Möglicherweise ist das weitere Verfahren auch nicht ganz trivial, aber ob wir uns das zumuten, können wir doch selbst entscheiden, oder?!
erinnert alles irgendwie an die Grafikkartenhersteller die auch mal gerne ein paar Bereiche geheim lassen damit kein anderer abkupfern kann :rolleyes:
Was dabei rauskommt sieht man dann ja an den Linux-Grafiktreibern. => Keine oder schlechte 3D Hardwareunterstützung. :mad: und viel Arbeit beim Reverse-Engineering :confused: und die Einbindung der proprietären Treiber ist jedesmal beim Kernelupdate nen Akt. Wenn der Hersteller dann mal wieder keine Lust hat steht man mit leeren Händen da und darf sich neue Hardware kaufen o_O

Da steht in der neuen Linux-User (07/2016) i Editorial auch nen schöner Text dazu. Selbst bei der Common-Creatives-Lizenz für Bilder sind etliche Fallstricke drin bei denen man Abmahnungen riskiert. Das einzig Wahre ist im Endeffekt dann doch nur das Vorgehen der Free-Software-Foundation.
Irgendwo hab ich letztens mal nen Bericht zu Patenten und Trivialpatenten gelesen. Etwa 25% der Entwicklungskosten werden wohl im Moment damit verbraten um Patentstreitigkeiten zu bezahlen oder um zu prüfen ob nicht irgend wer ne "ähnliche runde Ecke" patentiert hat.:oops: Das geht denen verloren die die eigentliche Arbeit machen und nutzt nur den Anwälten. Und da wundert man sich noch das es eigentlich nicht wirklich neue Inovationen gibt und alle auf der Stelle treten.
Schweift aber auch grad ein wenig vom Thema ab :eek:

Gruß
Dino
 


Also wenn ich nochmal zurück zum ursprünglichen Thema kommen darf......
.... zum Treiber des AVRISPmkII und AVR-Studio ......

Hat das wirklich etwas mit der neuen Version (7) zu tun?
Ich hatte das Problem mit dem Atmel Studio 6 auch schon, und zwar ab dem Zeitpunkt an, als ich auf Windows 10 umgestiegen bin.......

Und das lässt sich, wie schon erwähnt, mit dem Zadig Tool beheben.... soweit ich das gesehen habe, wurde das Treiberproblem mit dem mkII wurde auch schon in anderen Foren diskutiert.....
 
Hallo avr_newbie,

ich weiß nicht, ob es nur an der Version 7 liegt oder lag. Ich hatte bisher das Problem nicht, erst nach der Installation vom Studio 7 ging es bei mir nicht mehr. Ich brauchte eine schnelle Lösung und bin dann auch auf das Zadig Tool gestoßen. Das hat auch sofort funktioniert. Da mir das sehr geholfen hat, habe ich die Lösung mal in das Forum gestellt, vielleicht hilft es auch anderen.
 
Der Vollständigkeit halber noch, das gleiche Treiberproblem hatte ich auch bei dem JTAG ICE3 - auch unter Windows 10
 
Bei mir hat das auch mit dem Tool nicht geklappt.
Aber wegen:
ich weiß nicht, ob es nur an der Version 7 liegt oder lag. Ich hatte bisher das Problem nicht, erst nach der Installation vom Studio 7 ging es bei mir nicht mehr.
Hab ich das hier gefunden...
Neben dem dort im Bild zu sehenden Treiber Version 11.0.0.0 hab ich noch Version 11.1.0.0 vom 05.01.2013 auf dem Rechner gefunden. mit beiden läuft der mkII wieder im 6er Studio...
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)