Bascom? MKII Programmer. erst löschen nötig

OP #5048825
Lesenswert?

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
(Firma: matzetronics) #5048847
Lesenswert?

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.
Gast #5048851
Lesenswert?

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.
OP #5048866
Lesenswert?

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)
Gast #5048940
Lesenswert?

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.
#5052981
Lesenswert?

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.
Gast #5053476
Lesenswert?

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.
Gast #5053485
Lesenswert?

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.
Gast #5053495
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren