Atmega644 via simplen ISP-Parallelportadapter programmieren

Lass es. Schneckenlangsam. Mir hat so einen Mist mal einen 644 
zerschossen (lag damals aber an Ponyprog). USB-Programmer, die 
STK500-kompatibel und zig mal so schnell arbeiten und ein vernünftig 
langes Kabel bieten, kosten ca 17 EUR - inklusive USB-Kabel. Und die 
lassen sich bequem aus AVR Studio heraus mit dem STK500-Plugin bedienen.

Ich mach das mit dem hier
http://www.mikrocontroller.net/articles/STK200
und langsam ist das nicht,
zu mindestens aus WinAVR via AVRDude nicht

Scheinbar fehlt mir ein wenig das Verständnis.

Wieso zu langsam? Das Ding hat doch nur 32kB Flash. Was soll da denn so 
lange dauern und warum sind die anderen Programmer schneller?

Zum Thema Bootloader: Wozu ist der gut? Ist der etwa auch notwendig, 
wenn man nur internen (=aus dem Flash) Code nutzen möchte?

Zum Thema zerstören: Kann man so einen Controller nur durch fehlerhafte 
Programmierung wirklich so "zerschießen", dass man den Flash nicht mehr 
neu schreiben kann? Das ist ja schwach!

Zur Klarstellung: Ich habe kein Windows, darum kommt WinAVR, etc. nicht 
in Frage. Und 20EUR für einen Programmer ist mir eigentlich schon viel 
zu viel. Ich wollte dafür eigentlich nichts zusätzlich ausgeben und bin 
nur auf den Trichter gekommen, weil ich eben von so simplen 
Parallel-Programmern gelesen habe (wofür ich alles da hätte).

Hm, jetzt bin ich doch tatsächlich wieder am Überlegen, ob ich nicht 
doch bei PIC-Controller bleiben soll, da ich dafür zumindest schon einen 
Programmer habe.

So, hab nun den Atmega644 bestellt. Dazu ein 74HC244 und ein 74HC367 für 
das STK200 Interface. Mit welchen Treiber empfiehlt sich denn der 
Aufbau? Beim 74HC367 scheinen noch zwei Eingänge negiert zu sein, oder 
was bedeuten die Kreise davor bei 
http://www.mikrocontroller.net/articles/STK200 ?

Zu der Belegung: Da sind ja 10Pins am ISP. Beim einfachen Interface 
hatte ich nur 5Pins. Hinzugekommen sind +5V und ein "N$1" Ein- oder 
Ausgang. Woran schieße ich den letzteres an?


Zu den Fuses: Gibt es wirklich ein Fusebit, dass man den Controller 
nicht noch ein mal schreiben kann? Das gibt's beim PIC nicht, da gibt's 
nur das code-protect, dass man ihn nicht mehr lesen kann. Neuschreiben 
ging aber immer.

> So, hab nun den Atmega644 bestellt. Dazu ein 74HC244 und ein 74HC367

Viel Spass. Mit Platine, Parallelportstecker/Flachbandkabel/ICs zwar ein 
paar Euro billiger, was einen Tag lang erfreut, aber an allen folgenden 
Tagen zahlst Du dann den Preis: Unzuverlässiger als die 
USB-Programmierer, langsamer, kann Schaltung nicht mit Spannung 
versorgen, hat keine LEDs, kein Gehäuse, keine STK500-Kompatibelität. 
Meine Tips für den Kauf eines preiswerten Programmers wären gewesen:

Stange-Programmierer für 16,99€ incl. USB-Kabel (nutze ich zur Zeit 
selber - erfodert bei der aktuellen AVR Studio-Version das letzte 
Servicepack für korrekte Funktion):
http://www.obd-shop.com/danila/product_details.php?id=356&lang=de

USB AVR Lab (15€ oder als Platine nur 3,50€):
http://update.ullihome.de/catalog/product_info.php/products_id/28

> Zu den Fuses: Gibt es wirklich ein Fusebit, dass man den Controller
nicht noch ein mal schreiben kann?

Es gibt mehrere: Reset-Fuse und die Wahl der Taktquelle.

oder,
 -  http://shop.ulrichradig.de/product_info.php?products_id=42

wohl kaum zu schlagen.   ;-)

So, ich habe mir nun die ganz simplen Parallelport Programmer mit nur 3 
Widerständen aufgebaut, den ich bereits oben verlinkt habe.
Er funktioniert bestens und sehr schnell! Ich weiß nicht, wofür man sich 
ein 20EUR teuren STK500 Programmer kaufen soll? Da bau ich mir 
irgendwand doch lieber gleich einen HV-Programmer!

Bis jetzt habe ich an den Fuses nicht verändert und nutze den internen 
1Mhz Takt für den Atmega644. Ich würde aber gerne PortC freischalten 
(jtag ist wohl standardmäßig ein?), um diesen auch für I/O nutzen zu 
können. Traue mich aber erst mal noch nicht an die Fuses.

Von dem Atmel Manual des Atmega644 bin ich nicht so begeistert. Das 
Inhaltsverzeichnis ist am Ende und nicht am Anfang. Aber vor allem würde 
ich gerne mal wissen, was nach einem Reset standardmäßig alles ein und 
abgeschaltet ist. Das muss man alles mühsam einzeln zusammensuchen, 
sofern es überhaupt drinsteht. Habe mich z.B. gefragt, ob die I/Os 
standardmäßig auf Ein- oder Ausgang stehen, bis ich dann gefunden habe, 
dass sie im "tristate" sind. Auch war ich mir nicht sicher, ob irgendwo 
ADCs oder ähnliches eingeschaltet sind, die ich deaktivieren muss (bei 
manchen PICs, z.B. der 16F628 ist das so), um die I/Os zu nutzen. Die 
jtag-Pins schalte ich man ja über die fuses ab oder kann ich das auch 
durch setzten irgendeines Register-Bits im Programmablauf ein- und 
ausschalten, so dass ich sie dann als normale I/Os nutzen kann?

>Ich weiß nicht, wofür man sich
>ein 20EUR teuren STK500 Programmer kaufen soll?

Vielleicht findest du es noch raus.

>Aber vor allem würde ich gerne mal wissen, was nach einem Reset standardmäßig 
>alles ein und abgeschaltet ist.

Ganz einfach - standardmäßig sind an den Ports alle Sonderfunktionen 
deaktiviert. Ports sind Eingänge, Pull-Ups sind deaktiviert. Auch alle 
internen Funktionsbausteine sind nicht aktiv. Das einzige, was intern 
laufen kann, ist der Watchdog, wenn die Fuse gesetzt ist.

>Die jtag-Pins schalte ich man ja über die fuses ab

Ja

>oder kann ich das auch
>durch setzten irgendeines Register-Bits im Programmablauf ein- und
>ausschalten, so dass ich sie dann als normale I/Os nutzen kann?

Nein

Oliver

Doch, durch schreiben des JTD Bits im Register MCUCR.

Gruss
Andreas