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?
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.
Du kannst damit einmalig nen Bootloader reinflashen und diesen danach benutzen. Zu mehr taugen die LPT-Dinger auch nich.
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.
> 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.
>Wieso zu langsam? Das Ding hat doch nur 32kB Flash.
Der 644 ?? der hat 64Kb
und das über Bitbaning Programmer dauert schon Minuten...
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.
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...
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.
> 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.
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.
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
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.