Das eigentliche Problem passt gar nicht oben in den Betreff: Ich habe Bascom, Vollversion und aktuell. Als Programmer einen MKII, genau der Diamex All-AVR / ERFOS-ISP-2 der wohl mir dem AVR ISP MKii kompatibel ist. Die Treibverinstallation ist eine Katastrophe. Angeblich sollen im AVR Studio die Treiber liegen, kann sein, aber nicht im neuen 7.0. Über Zadic und USBLIB ....was auch immer ich nun gemacht habe, scheint es zu laufen, nachdem ich die Vieren die ich mir auf der Seite Sourceforge.net eingefangen habe, wieder gelöscht habe. OK. Nach dem anstecken wird der Chip erkannt und kann ausgelesen werden. Nehme ich nun das gleiche und programmiere ihn damit, dann läuft er nicht. Nach langen fummeln, hab ich festgestellt, das ich den Chip erst löschen muss, dann geht es. Kann es sein, das er nicht bei der 0000 anfängt zu brennen??? Wenn ich nämlich Inhalt und das eigentliche Programm vergleiche, kommt ein Fehler bei 003E. Dummerweise stehen in der Hex und im Mega die gleichen Werte. In Bascom habe ich USBprog Programmer / AVR ISP mkII gewählt. In der Systemsteuerung stehen die Treiber unter libusb-win32 devices. Der AVRISP... und libusb...... Windows ist Win 10 64bit Ich brauche jetzt einen funktionierenden ISP Programmer, notfalls kauf ich was anderes, hab mir den ganzen Tag versaut. Gruß Mario
Mario G. schrieb: > Angeblich sollen im AVR Studio die Treiber liegen, kann sein, aber nicht > im neuen 7.0 Atmel unterstützt den AVRISP MkII und versorgt ihn auch in AS7 mit neuer Firmware, hat aber keinen Grund, einen Diamex mit Treibern oder Firmware zu versorgen - denn der Diamex ist kein vollständig kompatibler Ersatz zum AVRISP MkII, sondern nur etwas, was an der USB Schnittstelle meistens so tut, als wäre es ein MkII. Wenn du also Probleme mit einem nicht-Atmel/Microchip Produkt hast, kannst du Atmel/Microchip nicht dafür verantwortlich machen. Wende dich an Diamex: http://www.diamex.de/dxshop/Startseite Ein externes Programm wie avrdude kommt aber mit so gut wie allen Programmern klar, die auf dem Markt sind.
i hab den all-avr unter win7 unn studio 7, funktioniert bestens i vermute W10 ist das problem, oder das problem istg vor dem rechner hihihi und ja, mit a bissel logischem denken sollte man draufkommen das vor dem programmieren geloescht werden muss vlG Charly
Abgesehen davon benutzt das Atmel Studio den Jungo Treiber, während avrdude den libusb Treiber verwendet. > Kann es sein, das er nicht bei der 0000 anfängt zu brennen??? Bei AVR Mikrocontrollern beginnt das Programm immer an Adresse 0, aber es kann Lücken haben. Im Hex-File stehen die Adressen drin, die der Programmer beschreiben soll. Die Verify Funktion der Bediensoftware berücksichtigt das.
Hallo, ich mach doch gar nicht Atmel dafür verantwortlich. Ich habe aber Bascom und steige als Gelegenheitsprogrammierer auch nicht um. Soll ich die Hex nun mit was anderen Brennen, das ist doch doof. Natürlich kann ich auch Fehler machen. Hab das Teil gerade geupdatet. Bringt aber auch nichts, außer das es nun ein Clone ist. Also was darf ich denn kaufen....für Bascom ;o)
Man kann in bascom einstellen, dass er vor dem flashen den Chip erased, so klappt das bei mir auch. Jan
Habe jetzt das Update von DIAMEX 1.9.0 drauf. Jetzt scheint es zu klappen.
Das man den Chip erst löschen muss bevor man ihn neu beschreibt, ist aber ganz normal. Ich programmiere über das AVR-Studio und dort ist das automatisch löschen vor dem programmieren fix eingestellt. Das sollte doch auch mit BASCOM möglich sein. Mit dem Programmer hat das nichts zu tun.
> Also was darf ich denn kaufen
Du hast doch schon einen Programmer mit gutem Ruf.
Mario G. schrieb: > Also was darf ich denn kaufen....für Bascom ;o) Polulu programmer funktioniert problemlos,den Diamex All-AVR kannst du unter Bascom vergessen,der funktioniert nicht. Nie wieder Diamex Schrott. http://www.mikrocontroller-elektronik.de/isp-programmer-fuer-arduino-bascom-und-atmel-studio/
rainbow7 schrieb: > den Diamex All-AVR kannst du > unter Bascom vergessen,der funktioniert nicht. > Nie wieder Diamex Schrott. und das, nachdem der TO schrieb: Mario G. schrieb: > Habe jetzt das Update von DIAMEX 1.9.0 drauf. > Jetzt scheint es zu klappen.
Mario G. schrieb: > Nach langen fummeln, hab ich festgestellt, das ich den Chip erst löschen > muss, dann geht es. Das war bei Bascom schon immer so! Sinn war, das man nachträglich z.B. ne Seriennummer in den Flash schreiben konnte! Dabei konnte man aber nur von FF richtung 00 schreiben! Nicht umgekehrt!
Ich habe bisher nur mit dem Ardoino Bootloader gearbeitet. Löschen war da nicht nötig. Was ich ebend komisch finde, das der Inhalt stimmt, er aber trotzdem nicht lief. Nur bei Adresse 3E meldet er einen Unterscheid. Komischerweise stehen aber die gleichen Werte drinne. Ich bin der Meinung das bei einem schlechten Reset der Counter? Nicht auf 0000 zeigt und die Programmierung falsch beginnt. Ich glaube das bei den Pics schon mal gelesen zu haben. Die habe ich übrigens auch nie gelöscht.
Mario schrieb: > Nur bei Adresse 3E meldet er einen Unterscheid. > Komischerweise stehen aber die gleichen Werte drinne. Nein, du musst den Inhalt manuell auslesen! In 3E siehst du dann den Wert! Wenn du den Chip programmierst und danach der Verify kommt, sagt er dir wo das Problem ist, aber im Programmer ist der alte Inhalt noch drinn. So kannst du serienprogrammierung machen. Menü: Options -> Programmer : Check (X) Autoflash (X) AutoVerify (X) UpLoadCode and Data Als Alternative kannst du auch (X) Programm after compile machen. Dann wird nach dem druck auf F7 nach dem erfolgreichen Kompillieren das File in den uC geladen.
Ahhh. Ok. Dann schau ich mal wie ich es eingestellt habe. Wie meinst Du manuell auslesen? Ich drücke nach dem Brennen" Read von Chip" . Er zeigt mir dann nicht wirklich den Inhalt an? Nach dem Update funktionierte es auch nur kurzzeitig. Lösche jetzt immer vorher. Ich finde das aber unsinn, da das jedes mal ein Schreibvorgang ist. Und wenn man viel probieren Muss, so wie ich gerade, weil auch Anfänger, ist das blöd.
Mario schrieb: > Lösche jetzt immer vorher. > Ich finde das aber unsinn, da das jedes mal ein Schreibvorgang ist. Ist aber trotzdem notwendig! Die Bits können durch das Programmieren nur gelöscht werden, nicht gesetzt. Deshalb wird beim Löschen der gesamte Speicher auf 0xFF gesetzt. Wenn das Setzen auf 0xFF nicht stattfindet, werden Bits, die beim alten Speicherinhalt auf 0 stehen, auf 0 stehenbleiben, auch wenn sie gesetzt sein müssen. Ich hoffe, ich habe mich einigermaßen verständlich ausgedrückt.
Achso. Dann ist alles klar. Dann ist doch aber unlogisch das ich das auch manuell machen , bzw ich brennen kann ohne zu löschen. Bei den Pics hab ich nie selbst gelöscht. Kann natürlich sein, das es das Programm automatisch gemacht hat. Ok. Dann hab ich was dazu gelernt. Sorry für meine sturheit. Das war mir nicht so logisch.
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.