ATmega8 vs. ATmega8A

Nichts neues, sind beide veraltet. Fuer neue Designs solltest Du den 
Atmega88 verwenden, da hat Atmel diverse Verbesserungen vorgenommen, 
auch an den Peripherieeinheiten. Frueher oder spaeter (wenn nicht schon 
passiert) werden die alten Kerne wahrscheinlich abgekuendigt.

Greets,
Michael

Michael G. schrieb:
> Nichts neues, sind beide veraltet. Fuer neue Designs solltest Du den
> Atmega88 verwenden, da hat Atmel diverse Verbesserungen vorgenommen,
> auch an den Peripherieeinheiten. Frueher oder spaeter (wenn nicht schon
> passiert) werden die alten Kerne wahrscheinlich abgekuendigt.
>
> Greets,
> Michael
>
Hier kann man sehen was ATMEL als

           " Devices not Recommended for New Designs "

ansieht.

http://www.atmel.com/devices/mature.aspx?Products=010%20Atmel%20AVR%208-%20and%2032-bit%20Microcontrollers

Bernd_Stein

Diese Liste wird bald mal erweitert.
Mich aergert nur dass der Mega169 drinnen steht ;) Aber da geht's doch 
schon los...

Replaced by Mega169A hmmm. Also das ist strange ich bin mir fast 100 
dass der Mega169 schon die neue USI implementiert hat, sonst haette ich 
ja kaum den ganzen Code anpassen muessen fuer das Projekt, oder kann das 
dann doch nur der "A"? Eigentlich macht das wenn dann nur sinn wenn der 
"A" sowohl pin- als eben auch registerkompatibel zur alten Variante ist 
aber wahrscheinlich irgendwie aus dem neuen die gefertigt wird. Aber so 
kann man Verwirrung stiften...

Greets,
Michael

Michael G. schrieb:
> Frueher oder spaeter (wenn nicht schon
> passiert) werden die alten Kerne wahrscheinlich abgekuendigt.

Wenn man sich schon die Mühe macht, einen A-Typ zu entwickeln, wird der 
Absatz auch entsprechend groß sein, d.h. eine Abkündigung ist 
unwarschenlich.

Ich würde allerdings auch zu den Nachfolgern (ATmega48..328) raten, 
damit ist man flexibler.

Ein wichtiger Unterschied ist aber, der ATmega8A hat nicht mehr den 
internen Kurzschluß zwischen VCC und AVCC.


Peter

Peter Dannegger schrieb:
> Ein wichtiger Unterschied ist aber, der ATmega8A hat nicht mehr den
> internen Kurzschluß zwischen VCC und AVCC.

Ein ATmega8-16PU mit Fertigungsnummer 1025 hat diesen Kurzschluss auch 
nicht mehr.
Der Übergang zum Mega8A dürfte da einigermaßen fließend sein.
Hubert

So lala schrieb:
> Ist ja alles sehr interessant, geht aber nicht wirklich auf meine Frage
> ein...
> Ich möchte nicht wissen, ob es zeitgemäß und "zukunftssicher" ist, auf
> einen Mega8 zusetzen, sondern in wie fern Fortschritte bei dem Mega8A
> erzielt werden konnten ;)
Was hälst du davon einfach mal die ANs zu lesen. Da ist doch nicht 
umsonst auf der Mega8A-Seite bei den Documents ein "Migration from 
ATmega8 to ATmega8A"

Die nicht erwähnten Kleinigkeiten dürften wohl ein paar Errata-Fixes 
sein. Dafür schaust du dir einfach die Datenblätter an.

So lala schrieb:
> Mit "kein Kurzschluss zwischen VCC und AVCC" meint ihr, dass nun eine
> Diode intern verbaut ist, richtig?

Damit ist gemeint das man AVCC versorgen muss, da sonst PortC nicht 
funktioniert. Wenn man den ADC verwenden will ist die Beschaltung lt. 
Datenblatt angebracht.

Wenn daran gedacht ist das der Mega8 abgekündigt wird, hätte man wohl 
kaum den Mega8A herausgebracht. Für die nächsten fünf Jahre würde ich 
mir da keine Gedanken machen.

"In order to optimize the manufacturing process and to further reduce 
current
consumption, an optimized version of ATmega8 has been introduced."

Sprich, der Chip ist kleiner (Die shrink) und damit billiger.

Das hat zur Folge, daß die Ausgangsstufen hochohmiger sind und damit der 
Spannungsabfall größer (0,7V -> 0,9V).
Außerdem ist die Referenz schlechter geworden (2,3-2,7 -> 2,3-2,8V).


Peter

So lala schrieb:
> Aber wie kommt es denn, dass Intel und AMD progressiv damit werben,
> welche neuen High-k-Metal-Gates sie verwenden, während Atmel keinerlei
> Infos preisgibt?

Die von Intel für die CPUs verwendete Fertigungstechnik ist die neueste 
Technik, aufwendig, teuer und anfangs mit Problemen gesegnet. Und 
arbeitet mit Spannungen um 1V herum.

Controller wie die AVRs hingegen werden mit Fertigungstechnik 
produziert, die vielleicht vor einem Jahrzehnt Spitze war. Das ist nicht 
unbedingt etwas, womit man lautstark angeben kann. Dafür ist sie 
vergleichsweise billig und gut eingefahren.

Ausserdem fertigt Intel die Prozessoren selbst. Das ist deren eigene 
Technik. Viele IC-Hersteller hingegen fertigen nicht mehr selbst, 
sondern lassen fertigen. Also nicht in deren eigener Technik.

Anonymus schrieb:
> Stimmt nicht.

Ach, dafür musstest du den Thread ausbuddeln?  Lohnt nicht.  Dass es
ganz sicher den notwendigen Absatz auch für den technisch bereits
etwas angeältelten ATmega8 gibt, geht klar und deutlich daraus hervor,
dass sich sonst wohl keiner die Mühe gemacht hätte, einen ATmega8A
überhaupt erst aufzulegen.

Ansonsten wurde das ja schon gesagt: es handelt sich um einen
die shrink, bei dem die Metallisierungslagen mit kleineren
Strukturen ausgeführt werden, aber die Geometrie der eigentlichen
aktiven Bereiche beibehalten wird.  Es ist dann wie auf einer
Leiterplatte: auch die Metallisierung schluckt nicht ganz unerheblich
Fläche, sodass man mit schmaleren Verbindungen eben Platz auf dem
Chip spart.  Da die Geometrie der aktiven Bereiche gleich bleibt,
ändert sich allerdings das elektrische Verhalten nur wenig, sodass
man die Chips problemlos als 1:1-Ersatz für die Vorgänger vermarkten
kann.

Außerdem kommt mit dem neuen Prozess sicher einher, dass die Fertigung
auf moderneren Maschinen zu insgesamt geringeren Kosten führt.
Letztlich werden die A-Typen ja für etwa die Hälfte der alten Typen
verkauft.

Ich hab auch den Eindruck, daß die Mature-Liste jetzt deutlich kleiner 
geworden ist.
Einige vormals abgekündigte AVRs sind also wieder zurück im 
Lieferprogramm.

Die Sache mit den -,A,P,PA Typen finde ich allerdings auch recht 
undurchsichtig.
Oft ändert sich (fast) nichts, manchmal aber erhebliches.
Z.B. der ATtiny2313A hat zusätzliche Interrupts gegenüber dem 
ATtiny2313.

Peter Dannegger schrieb:
> Z.B. der ATtiny2313A hat zusätzliche Interrupts gegenüber dem
> ATtiny2313.

Ja, warum man die A-Linie nicht konsequent als 1:1-Ersatz ohne neue
Features und dergleichen durchgezogen hat (von mir aus mit Bugfixes),
verstehe ich auch nicht.

Die Bytes der zusätzlichen Vektoren können auch weiterhin in altem Code 
anderweitig verwendet werden, da die Vektoren nicht genutzt werden. Auch 
die übrigen Änderungen wirken auf mich abwärtskomptibel, beeinflussen 
alten Code also nicht.

Offensichtlich gab es einen Anlass, diese zusätzlichen Features 
einzubauen.

Atmel hätte natürlich zwei separate Chips anbieten können. Einen 
unveränderten 2313A, und einen etwas erweiterten 2314. Die wären 
natürlich beide in Wirklichkeit exakt identisch gewesen, aber den 
traditionsbewussten Kunden zuliebe anders gelabelt. ;-)

Mike schrieb:
> tja manche Kunden wollten oder konnten die A Linie wohl nicht
> akzeptieren

Hat aber nichts mit dem zu tun, was du da von mir zitiert hast.  Ist
ein komplett anderes Paar Schuhe.

Nun muss ich den alten Kram noch mal vorholen, habe ja auch alten Kram 
nachproduzieren lassen.
Kleine Reglerplatine mit vormals Mega8, jetzt Mega8A. Es waren noch 
Restbestände Mega8-bestückt da. Brennen mit Studio7 und 
Original-AVR-ISP-MK2, die Mega8A ließen sich problemlos befüllen, aber 
kein einziges von ca. 20 Mega8. Immer verschiedene Fehlermeldungen, mal 
falsche Signatur, mal liess er sich angeblich nicht löschen, mal 
verify-Fehler. Die waren alle schon mal programmiert, sollten nur auf 
den neuesten Stand gebracht werden, also auch keine fusebit-Fehler, 
keine Chance.
Laptop mit AVR-Studio 4.19 ausgepackt, STK500 dran - klappt.
Was kann das sein?
Mit dem ISP-MK2 habe ich noch nie irgendwelche Probleme gehabt, das 
klappte immer.

Mit so einem diffusen Fehlerbild sehr schwierig zu sagen.

Werden die Teile in einer funktionierenden Schaltung programmiert? 
Nicht, dass da nur die Abblockung der Betriebsspannung zu schlecht ist 
oder sowas.

In der Schaltung. Aber die ist in Ordnung, da sind schon massig Platinen 
im Umlauf und bis auf den Prozessor identisch
Probeweise mal den Mega8 mit dem STK500 gelöscht, lock- und fusebits auf 
Werkseinstellungen zurückgesetzt und dann mit dem MKII probiert - 
funktioniert nicht.
Geht schon beim Signaturlesen los, paarmal funktionierts, plötzlich ist 
es vorbei (lma3).
Es ist eindeutig so: mit 4.19 und STK500 geht alles, mit V7 und MKII 
lassen sich nur die Mega8A programmieren. Irgendwas muss da anders sein. 
Der Gegentest (MKII mit 4.19) steht noch aus, will nach dem 
firmware-upgrade nicht mit dem MKII arbeiten.

Ob sie mit der aktualisierten Firmware was verhunzt haben?

Kannst du einen Gegentest mit AVRDUDE machen?

Jörg W. schrieb:
> Kannst du einen Gegentest mit AVRDUDE machen?

Noch nie benutzt, werde ich gleich mal probieren.
Was mich auch ein wenig wundert - beim STK500 kann ich zwischen Mega8 
und Mega8A wählen, beim MKII nicht. Aber das scheint auch egal zu sein, 
Signatur ist gleich und beim STK500 funktioniert Mega8 mit 
Mega8A-Einstellung und auch umgekehrt.

Jörg W. schrieb:
> Kannst du einen Gegentest mit AVRDUDE machen?

Hm, bietet unter setup verschiedene COM-und LPT-Ports, die ich alle 
nicht habe. Meiner hat USB :-)

Und StudioV7 und STK500 funktioniert auch.

Wackelkontakt erklärt nicht die 100%ige Trennung zwischen Mega8 und 
Mega8A.
Studio V7.0.1417
MKII: Bildchen

spess53 schrieb:
> Na ja, für 1MHz Taktfrequenz ist der ISP-Takt von 250KHz zu hoch.

Sollte eigentlich nicht, gemäß Beschreibung sollte der ISP-Takt nicht 
mehr als 1/4 des IO-Taktes sein und das ist da ja gegeben. Das Problem 
kenne ich aber, ich geh da auch gern weiter runter mit dem ISP-Takt wenn 
das Beschreiben mal nicht klappt.

Ich bin auch bis 64 kHz runtergegangen, ändert nichts. Und als die 
Probleme auftraten, liefen die Mega8 ja schon mit externem 
8MHz-Resonator. Es bleibt mysteriös.
ISP-Signale sehen alle sauber aus, versorgt wird die Platine mit 12V, 
5V-Regler, 5V sind sauber.

H.Joachim S. schrieb:
> Jörg W. schrieb:
>> Kannst du einen Gegentest mit AVRDUDE machen?
>
> Hm, bietet unter setup verschiedene COM-und LPT-Ports, die ich alle
> nicht habe. Meiner hat USB :-)

Wenn du -c avrisp2 benutzt, dann ist -P usb impliziert.

Ich glaube, das ist mir langsam scheissegal...
Einen DIL-Mega8-16PU ins STK500 gesteckt und den MKII an SPROG2 - 
funktioniert.
Die fraglichen Mega8: 16AI 0502G, ganz schön alt schon :-). Ich sortier 
die jetzt sicherheitshalber aus, werden nicht mit ausgeliefert.

Kannst sie ja bei ebay verkaufen, schließlich lassen sie sich im
STK500 programmieren, also sind sie nicht per se kaputt.

spess53 schrieb:
> Nein. Er muss kleiner als 1/4 des IO-Taktes sein. Und das schließt
> auch die Gleichheit aus.

Also ich hab nicht nachgeschaut, hab aber in Erinnerung, dass der 
ISP-Clock mehr als 3 IO-Clock-Cycles sein muss und der nächst "höher" 
IO-Clock-Cycle sind nunmal 4 Cycles was bedeutet, dass es mindestens 1/4 
der IO-Clock-Frequenz sein muss.

S. Landolt schrieb:
> Wie sollte das eingehalten werden können, gar bei einem RC-Oszillator?

Wieso sollte denn die Art der Taktquelle hier einen Einfluss haben? Ist 
doch egal ob es ein RC-Oszillator den IO-Takt generiert, ein Quarz oder 
ein Frequenzgenerator. Das versteh ich nun gar nicht, kannst du das 
weiter erläutern?

Und es gibt doch eine Erklärung.
Einen ausgelötet und in eine TQFP-Fassung: funktioniert.
Jetzt wollte ich es genau wissen. An der MOSI/OC2-Leitung hängt ein FET 
über 10R, 10k gegen Masse, IRFR2705 mit 850pF Gatekapazität. Den 10R 
ausgelötet - alles bestens.
Konsequenz: der Treiber im MKII ist wohl etwas schlapper und der Mega8 
möchte gern etwas steilere Flanken.

M. K. schrieb:

> Also ich hab nicht nachgeschaut,

Hättest du tun sollen.

> hab aber in Erinnerung, dass der
> ISP-Clock mehr als 3 IO-Clock-Cycles sein muss und der nächst "höher"
> IO-Clock-Cycle sind nunmal 4 Cycles was bedeutet, dass es mindestens 1/4
> der IO-Clock-Frequenz sein muss.

Völlig daneben.

Wie schon geschrieben wurde, es muss kleiner 1/4 der CPU-Frequenz
sein.  Das hängt damit zusammen, dass die interne Abtastung ab 1/4
dann irgendwann eine Flanke auf der SCK-Leitung nicht mehr „sieht“.

Theoretisch dürfte sie 1/4 sein, aber nur für den (nicht praktikablen)
Fall, dass SCK und CPU-Takt phasenstarr zueinander sind.

Theoretisch darf SCK beliebig langsam werden.

> S. Landolt schrieb:
>> Wie sollte das eingehalten werden können, gar bei einem RC-Oszillator?
>
> Wieso sollte denn die Art der Taktquelle hier einen Einfluss haben?

Weil „1 MHz“ vom RC-Oszillator eben auch mal 998 kHz sein können.
Damit ist mit 250 kHz SPI-Takt die Bedingung „kleiner 1/4“ eben dann
ganz und gar nicht mehr erfüllt.

H.Joachim S. schrieb:
> Und es gibt doch eine Erklärung.

Schön, dass du's gefunden hast.

Klar ist es nicht schön, nennenswerte kapazitive Lasten dran zu haben, 
war aber bisher beim ISP nie ein Problem. Blöd ist eben, dass der MOSI 
und OC2 auf dem gleichen Pin liegen. Ja, man könnte einen Treiber 
dazwischensetzen oder sonstige Vorkehrungen treffen - aber wie gesagt, 
war nie ein Problem.
Anbei mal MOSI, STK500 (115kHz) funktioniert, MKII (125kHz) nicht. Und 
nein, ich habe Bilder die nicht verwechselt :-)

Soweit zur Theorie, der MKII könnte einen schlapperen Treiber haben.
Flanken um die 100ns beim MKII.

edit: jetzt müsste man auch sck mit drauf haben, wahrscheinlich liegen 
die beim MKII etwas anders, mache ichgl eich nochmal.
Auf jeden Fall ist aber beim ISP-timing ein Unterschied zwischen Mega8 
und Mega8A.

Ich gebs auf, ich kann nichts erkennen, was den Unterschied machen soll. 
Pegelwechsel auf MOSI mit fallender SCK-Flanke, Übernahme mit steigender 
Flanke, passt alles.

Das gilt aber nur für Taktleitung, nicht für die Datenleitung. An der 
Takleitung hängt nichts weiter dran.

die ausreichende Flankensteilheit. Wäre mir zumindest neu, dass auch die 
Datenleitung Kriterien bezüglich der Flankensteilheit hat. Zur 
Taktflanke muss das Signal stabil anliegen.
Ansonsten: das "vermatscht" aussehende (STK500) funktioniert, das andere 
nicht.

spess53 schrieb:
> Und >4 CPU clock cycles bedeutet bei mir eine Frequenz von < 1/4 der
> Taktfrequenz.

Richtig nur ne "4" sehe ich da nicht, nur eine "3" ;)

spess53 schrieb:
> Schon mal etwas von den Toleranzen des RC-Oszillators gehört? Bei 5V und
> 25°C werden +-3% angegeben.

Das braucht man aber nicht auf den RC-Oszillator einschränken sondern 
gilt für alle Taktquellen. ;)

Ich besaß auch einen Original AVR-ISP MK2, der mir mit Kontrollern aus 
verschiedenen Chargen viel "Freude" bereitet hat. Ich habe dann einen 
"AVR-DOPER" gebaut, der alle Signale (MOSI, MISO,SCK, RESET) über Gatter 
von 74HC126 führt. Seither habe ich keinen Ärger mehr gehabt.

Selbstbau ist immer gut, da man:
a) weiß, was drin ist
b) auf sich selbst schimpfen kann, wenn es nicht funktioniert

:)

MfG Paul

Dieter F. schrieb:
> M. K. schrieb:
>> Also ich hab nicht nachgeschaut, hab aber in Erinnerung, dass der
>> ISP-Clock mehr als 3 IO-Clock-Cycles sein muss und der nächst "höher"
>> IO-Clock-Cycle sind nunmal 4 Cycles was bedeutet, dass es mindestens 1/4
>> der IO-Clock-Frequenz sein muss.
>
> Guggst Du etwas zurück - 3. Bild:
>
> Beitrag "Re: ATmega8 vs. ATmega8A"

Ich redete vom Datenblatt aber danke für den Hinweis ;)

H.Joachim S. schrieb:
> Ich gebs auf, ich kann nichts erkennen, was den Unterschied machen soll.

Wahrscheinlich bräuchte man einen längeren LA-Trace, bis zu einer
Stelle, an der dann wirklich ein Fehler aufgetreten ist.

Mit dem Oszi erwischst du ja immer nur eine Momentaufnahme.

Stimmt auch wieder - solange ich was sehen kann läufts ja noch.

Es gibt ja Sachen, die lassen einem keine Ruhe :-)
Also den Logicport ausgepackt und angeschlossen - Fehler weg. Nach und 
nach die einzelnen Leitungen abgezogen - alles egal bis auf die 
SCK-Leitung. 10pF von SCK nach Masse - einwandfreie Funktion. 
Wahrscheinlich reicht auch eine etwas längere ISP-Leitung....

Möglicherweise hätte auch ein Serienwiderstand genügt – ich tippe auf
Überschwinger infolge reflektierter Signale.

Da der Treiber des STK500 „weicher“ ist, passiert das dort nicht.

Serienwiderstand 47R hilft auch :-)
Und was hat das wiederum mit der Kapazität an MOSI zu tun?
Fehler tritt nur auf wenn alle 4 Bedingungen erfüllt sind:
1. Mega8-MC
2. AVRISP-MKII verwendet wird
3. der Mosfet an der MOSI-Leitung hängt
4. die SCK-Leitung kürzestmöglich angebunden ist (ISP-Kabel ca. 20cm, 
auf der Platine <1cm)

H.Joachim S. schrieb:
> Und was hat das wiederum mit der Kapazität an MOSI zu tun?

Durch die Überschwinger wird MOSI an Stellen abgetastet, wo es durch
die kapazitive Belastung noch nicht stabil ist.

Hm, nach ner halben Taktperiode?
Aber Überschwinger sieht man hier schon:
Beitrag "Re: ATmega8 vs. ATmega8A"
Nicht wirklich aussagekräftig/bedrohlich, aber der Unterschied zum 
STK500 ist schon da.

@ H.Joachim Seifert (crazyhorse)

>Aber Überschwinger sieht man hier schon:
>Beitrag "Re: ATmega8 vs. ATmega8A"
>Nicht wirklich aussagekräftig/bedrohlich, aber der Unterschied zum
>STK500 ist schon da.

Su siehst gar nichts, dazu müßtest du die Zeitauflösung deutlich 
hochdrehen, so auf 10ns/DIV und mit einem GUTEN Tastkopf HF-tauglich 
messen, sprich kurze Masseleitung. Möglicherweise gibt es ein 
Übersprechen vom MOSI auf SCK, wenn dort de fette Kapazität dranklemmt.