Forum: Mikrocontroller und Digitale Elektronik Atmega644 via simplen ISP-Parallelportadapter programmieren


von Kermit (Gast)


Lesenswert?

Hallo,

ich möchte für ein komplexeres Projekt nun mit AVRs anfangen (bisher 
habe ich nur PIC16er programmiert), weil ich komplexere Rechnungen 
anstellen will und die AVRs eben mit den freien gcc ohne Limits in C 
programmieren kann. Dazu habe ich mir den Atmega644 ausgesucht, da 
dieser viel Flash und (leider zuviele - aber man weiß ja nie, was noch 
als Erweiterung kommt) viele I/O-Pins hat.

Dazu eine simple Frage: Kann man diesen "modernen" Controller noch mit 
diesem simplen Parallelport-Adapter 
http://thomaspfeifer.net/einfaches_atmel_programmierkabel.htm (nur 3 
Widerstände) noch über die ISP-Pins programmieren? Ich habe einen 
normalen PC mit echten Parallelport (kein Laptop). avrdude habe ich mal 
gebaut:

`--> ./avrdude -c bascom -p ? 2>&1 | grep 644
  m644p = ATMEGA644P      [/usr/local/etc/avrdude.conf:4169]
  m644 = ATMEGA644       [/usr/local/etc/avrdude.conf:3979]

Softwareseitig sollte es also gehen? Hat jemand Erfahrung mit diesem 
Controller und simplen Parallelport-Anschluss?

von Dietmar (Gast)


Lesenswert?

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.

von Teplotaxl X. (t3plot4x1)


Lesenswert?

Du kannst damit einmalig nen Bootloader reinflashen und diesen danach 
benutzen.
Zu mehr taugen die LPT-Dinger auch nich.

von Mike (Gast)


Lesenswert?

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

von Kermit (Gast)


Lesenswert?

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.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

> Zum Thema Bootloader: Wozu ist der gut? Ist der etwa auch notwendig,
> wenn man nur internen (=aus dem Flash) Code nutzen möchte?
AVRs können immer nur Code aus dem Flash ausführen. Ein Bootloader ist 
auf einem AVR ein Programm, dass sich Programmcode über eine beliebige 
Schnittstelle lädt und in den Flash speichert. Ein solcher könnte z.B. 
Code über RS-232 laden, vorrausgesetzt, du hast einen MAX232 zur 
Pegelwandlung (die AVRs brauchen 5V, RS-232 hat -+12V). Das ist auch 
recht schnell.
> 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!
Man könnte die Fuse-Bits versehentlich so einstellen, dass der AVR keine 
Neu-Programmierung mehr annimmt.
> Zur Klarstellung: Ich habe kein Windows, darum kommt WinAVR, etc. nicht
> in Frage.
AVRDude läuft auch unter Linux.

von Christian U. (z0m3ie)


Lesenswert?

>Wieso zu langsam? Das Ding hat doch nur 32kB Flash.

Der 644 ?? der hat 64Kb
und das über Bitbaning Programmer dauert schon Minuten...

von Kermit (Gast)


Lesenswert?

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.

von Justus S. (jussa)


Lesenswert?

Kermit schrieb:

> 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.

es gibt ein Fusebit, dass das Programmieren über ISP verhindert, HV geht 
aber dann immer noch...

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Christian U. schrieb:
> Der 644 ?? der hat 64Kb
> und das über Bitbaning Programmer dauert schon Minuten...

Also das ist nun wirklich übertieben.
Klar an der Kasse wo man ansteht dauert es eh immer am längsten. ;)

Ich programmiere gerade nen Mega32 der etwa zu 70% voll ist, das dauert 
bei 1Mhz Takt schon etwa 20-30 Sekunden, aber mit höherem Takt geht es 
halt auch deutlich schneller. Also noch alles im Rahmen wie ich finde.

Und die Fuses habe ich mir bisher auch nur durch eigenes Zutun 
verkorkst, und ich wüßte jezt auch nicht so direkt ne bestätigten Fall 
aus dem Forum wo wirklich der Programmer schuld war...

Ursache war doch bisher immmer:
- Ich hab da mal einfach probiert die Fuse umzustellen
- Bedienfehler (Ponyprog nicht erst Fuses gelesen z.B.)
- viel zu langes Kabel ( > 1 Meter ) wobei ich gerade festetelle das 
mein Programmer auch an nem 1,5m lang angebundenem Druckerumschalter 
hängt.

von Dietmar (Gast)


Lesenswert?

> 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.

von Reinhard S. (rezz)


Lesenswert?

Ich hab mein Net-IO (Mega32) bisher problemlos per Parallel 
programmiert.

Hab aber auch noch nie einen USB-Programmer -> mir ist kein Vergleich 
möglich.

von Günti (Gast)


Lesenswert?


von Kermit (Gast)


Lesenswert?

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?

von Oliver (Gast)


Lesenswert?

>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

von Andreas (Gast)


Lesenswert?

Doch, durch schreiben des JTD Bits im Register MCUCR.

Gruss
Andreas

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
Noch kein Account? Hier anmelden.