Kompatibilität ISP-Programmer

Mich irritiert, dass im Produkt-Titel "Atmel" steht, aber es ist in 
Wirklichkeit ein Produkt von Sewed Technologies (China).

In der Produktbeschreibung steht, dass die USB Schnittstelle mit einem 
PL2303 realisiert wurde. Hierbei handelt es sich typischerweise um eine 
chinesische Fälschung, daher hat die Firma Prolific die Unterstützung 
dieses Chips aus dem aktuellen Treiber entfernt. Workaround: 
http://stefanfrings.de/avr_tools/index.html#pl2303

Dann erstaunt mich, dass das Gerät laut Produktbeschreibung eine 
Batterie enthält. Wozu?

Zur Kompatibilität: Im Datenblatt steht klar "It can works with AVR 
Studio", einschließlich Anleitung und Screenshots.

Aktuell ist aber das Atmel Studio, welches mit nicht-originalen 
Produkten deutlich restriktiver umgeht. Ist aber eigentlich egal, denn 
debuggen kann man damit ohnehin nicht und zum Flashen kann man auch gut 
andere Programme außerhalb der IDE nutzen.

Ponyprog scheint diesen Adapter nicht zu unterstützen: 
Beitrag "Ponyprog + STK500"

Hi,

ich denke ich nehme diesen:
https://www.reichelt.de/programmer-usb-isp-fuer-alle-avr-controller-diamex-all-avr-p110345.html?PROVID=2788&wt_mc=amc141526782519998&gclid=CLLAyLbq5NQCFc0V0wodkJgBlw&&r=1

Mir ist vorallem wichtig, das PonyProg damit umgehen kann. Ich möchte 
alte Programme lesen können and anschließend "neuere" Baugleiche chips 
flaschen können.

mfg

isp-programmer schrieb:
> ich denke ich nehme diesen:
> 
https://www.reichelt.de/programmer-usb-isp-fuer-alle-avr-controller-diamex-all-avr-p110345.html?PROVID=2788&wt_mc=amc141526782519998&gclid=CLLAyLbq5NQCFc0V0wodkJgBlw&&r=1

Gute Wahl.

> Mir ist vorallem wichtig, das PonyProg damit umgehen kann.

Das bezweifle ich. Das Prinzip von PonyProg beruht darauf, die Pins 
einer dummen Schnittstelle per Software anzutreiben (Bitbanging). Das 
funktioniert seit Windows Vista bar nicht mehr zuverlässig und schon gar 
nicht durch irgendwelche USB Adapter.

Für Ponyprog brauchst du einen echten Parallel-Port, der direkt von der 
CPU über Port 0x378 angesprochen werden kann. Moderne Rechner haben so 
etwas nicht mehr.

> Mir ist vorallem wichtig, das PonyProg damit umgehen kann.

>> Das bezweifle ich. Das Prinzip von PonyProg beruht darauf, die Pins
>> einer dummen Schnittstelle per Software anzutreiben (Bitbanging). Das
>> funktioniert seit Windows Vista bar nicht mehr zuverlässig und schon gar
>> nicht durch irgendwelche USB Adapter.
>>
>> Für Ponyprog brauchst du einen echten Parallel-Port, der direkt von der
>> CPU über Port 0x378 angesprochen werden kann. Moderne Rechner haben so
>> etwas nicht mehr.

Oh so ein misst. Dann benötige ich eine Alternative zu PonyProg. Mit 
PonyProg konnte man sogut die FuseBits und andere Dinge Einstellen. .. 
Sogar den Atmel wiederbeleben wenn man die FuseBits falsch gesetzt hat 
.. Gibt es eine Alternative?

isp-programmer schrieb:
> Gibt es eine Alternative?

Für AVR Mikrocontroller ist avrdude das Maß aller Dinge. Dazu passend 
gibt es grafische Oberflächen, zum Beispiel AVR8-Burn-O-Mat das du auch 
auf der Seite findest, die ich Dir weiter oben empfohlen hatte.

> Sogar den Atmel wiederbeleben wenn man die FuseBits falsch gesetzt hat

Dafür brauchst du einen High-Voltage Programmieradapter. Allerdings: 
Wenn du kein Vollidiot bist, passiert Dir das höchstens zwei mal. Dafür 
lohnt sich der Aufwand nicht. Schmeiß die einfach weg und kaufe neue 
Mikrocontroller.

Karl B. schrieb:
> mit dem STK500 entsprechend gejumpert

Vorsicht: Die meisten STK500 kompatiblem Programmieradapter unterstützen 
den High-Voltage Modus leider nicht.

Mit "kompatibel" meinen sie lediglich: Softwarekompatibel, also das 
gleiche Kommunikationsprotokoll zwischen PC und Programmieradapter. Das 
sagt aber noch nichts darüber aus, welche Mikrocontroller und 
Schnittstellen dorthin unterstützt werden.

Stefanus F. schrieb:

> isp-programmer schrieb:

>> Mir ist vorallem wichtig, das PonyProg damit umgehen kann.

> Für Ponyprog brauchst du einen echten Parallel-Port, der direkt von der
> CPU über Port 0x378 angesprochen werden kann.

Das stimmt so nicht, bzw. nur bezüglich der Programmierung via LPT. Bei 
Programmierung via COM kann Ponyprog wahlweise auch das 
Windows-"COMM"-API benutzen, d.h.: es gibt dann keine Abhängigkeit zu 
irgendwelchen Hardware-Adressen. Das Device muss einfach nur eine 
RS232-Schnittstelle über ein "full-featured" COM-Port-Interface 
bereitstellen, dann funktioniert die Sache. Also auch mit den üblichen 
generischen USB-COM-Adaptern. Dahinter gehört dann eben noch eine kleine 
Hardware. Genau dieselbe, die man auch bei "echten" COM-Ports verwenden 
müsste, damit Ponyprog die zum Programmieren benutzen kann.

Allerdings: Wenn das Device per USB angebunden ist, ist die 
Programmierung dramatisch langsam. Das liegt am Bitbanging, was nix für 
USB mit seinem systemimmanenten 1ms-Lag ist. Aber funktioniert immerhin. 
Kann man ja über Nacht laufen lassen...

Aber das alles hat letztlich nix mit dem Diamex-Teil zu tun. Das wird 
auf jeden Fall nicht mit Ponyprog funktionieren. Das hat aber einen ganz 
anderen Grund. Zwar präsentiert sich das Gerät ebenfalls als COM-Port, 
aber das ist eben kein generischer COM-Port, sondern einer, der nur das 
STK500V2-Protokoll versteht. Mit Bitbanging über die Steuerleitungen 
kann der garnix anfangen...

c-hater schrieb:
> Allerdings: Wenn das Device per USB angebunden ist, ist die
> Programmierung dramatisch langsam.

Deswegen habe ich diese Variante gar nicht erwähnt.

Stefanus F. schrieb:

> c-hater schrieb:
>> Allerdings: Wenn das Device per USB angebunden ist, ist die
>> Programmierung dramatisch langsam.
>
> Deswegen habe ich diese Variante gar nicht erwähnt.

Schwache Ausrede. Man muss den generischen COM-Port ja nicht zwingend 
via USB anbinden. Es gibt COM-Port-Karten und es gibt nach wie vor neue 
Computer mit echten COM-Ports.

Vermutlich wird das auch noch die nächsten 10 Jahre noch so bleiben...

c-hater schrieb:
> Es gibt COM-Port-Karten und es gibt nach wie vor neue
> Computer mit echten COM-Ports.

Ist ja alles schön, aber nicht das, was dem TO vorschwebt. Er will ein 
USB Gerät.

Karl B. schrieb:
> Bedarfsfall also nicht gegeben.

Hä? Du bist nicht "isp-programmer (Gast)" !