Mich würde mal interessieren, wo die genauen Unterschiede zwischen dem alten Mega8 und dem neuen Mega8A liegen. Ich konnte bisher über die Atmel Datasheets nur herausfinden, dass die Leistungsaufnahme unter Last von 11mA auf 6mA und im Idle von 4,5mA auf 2,2mA gesenkt wurde (und dass der Low-Zustand nun ein klein wenig anders definiert ist). Mir geht es weniger um "praktisch relevante" Unterschiede, da dies für meinen Zweck absolut keinen Unterschied macht (Azubi). Viel mehr interessiert mich als Physikbegeisterter, welche Umstellung bei der Fertigung vorgenommen wurden. Mir ist klar, dass Atmel sicher seine Geheimnisse hat und die Herstellung nicht im Detail offen legt, aber ich vielleicht gibt es ja doch das ein oder andere spannende Detail zu erfahren. Intel z.B. erklärt ja regelmäßig ein wenig, was die neue Fertigungs-Generation ausmacht (kleinere Strukturen, andere Dielektrika, etc...). Hier erhoffe ich mir ähnliche Erkenntnisse für den Schritt bei Atmel vom Mega8 zum Mega8A! Grüße So lala
:
Gesperrt durch Moderator
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
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 ;) Mit "kein Kurzschluss zwischen VCC und AVCC" meint ihr, dass nun eine Diode intern verbaut ist, richtig? Grüße So lala
So lala schrieb: > sondern in wie fern Fortschritte bei dem Mega8A > erzielt werden konnten ;) Ach je, geh einfach mal davon aus, das der -A sich billiger produzieren lässt. Oliver
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.
Timmo H. schrieb: > 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. Hat eigentlich irgendwer meinen Eingangspost durchgelesen...? Ich habe mir bereits die Atmeldokumente zu Gemüte geführt, und ich bin nicht an irgendwelchen veränderten Characteristiken interessiert. Ich möchte wissen, in welcher Form die Fertigung optimiert wurde. Kommen bessere Dielektrika zum Einsatz? Wurde die Strukturgröße der Transistoren verkleinert? Wurde die Metallisierung optimiert? Aber da scheint es keine Infos zu zu geben... Grüße So lala
normalerweise werden bugfixes und shrinking betrieben, sprich weniger silizium, weniger fehler ... -> billiger und zufridenere kunden ...
"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
Während eines Ineltek Seminars hat Atmel erklärt dass es sich hierbei NICHT um einen Design-Shrink handelt (darunter versteht man den Wechsel auf eine kleinere Geometrie zb. 110nm auf 90nm). Hier ist der Prozess gleich geblieben (deswegen ist der Leakage Current nicht hochgegangen) allerdings sind die Transistoren näher aneinander was ebenfalls zu kleinerer Siliziumfläche führt. Nachteil ist halt dass die A Varianten andere el. Eigenschaften besitzen (z.b. anfälliger auf EMV). Vorteil ist dass der Stromverbrauch deutlich runterging. Ist ja das witzige bei den Herstellern und Kunden, alle wollen immer billiger, dabei wird der Chip zwar billiger, es wird aber in Zukunft immer mehr "drumherum" notwendig um den Chip gegen Störungen abzusichern. Wenn ich mir die neuen CortexM4 von ST und Freescale anschaue, alle in 90nm, da braucht man auf den Chip nur noch "draufpusten" und der RTC ist mehr ein Random Number Generator als eine Realtime clock :-D
Ach, mit der Antwort kann man doch schonmal mehr anfangen ;) 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? Grüße So lala
>Nichts neues, sind beide veraltet. Fuer neue Designs solltest Du den Atmega88 verwenden, Stimmt nicht. Mir hat der Autor des AVR-Mikrocontroller-Lehrbuchs bei einem Treffen folgendes zu diesem Thema gesagt: Der ATmega8 ist in D der am meisten verkaufte AVR und mit AVR-Abkündigungen will Atmel seit dem großen Ärger seit der letzten (und einzigen großen) Abkündigungswellen künfig sehr vorsichtig sein. Damals war das Problem aber auch ein drastischer Produktionsengpass bei einer Werksumstellung gewesen. Was den ATMega8A anbelangt: Intern wurden vor allem Routings optimiert, sodaß geringere parasitäre Kapazitäten entstehen. Unter anderem dadurch konnten die Parameter deutlich verbessert werden. Durch die anderen Produktionsstätten ist außerdem die Toleranzrate geringer und die -zig Untertypen wurden unnötig. Der ATmega8A ist 2009 angelaufen und gilt als völlig (!) neuer Typ, d.h. mit voller garentierter Laufzeit, so als hätte es ihn vorher nie gegeben. ATmega88/168/328 sind nur pinkompatibel. Eigentlich wollte man damals intern aufräumen, das wurde aber mit einigen sehr ungünstigen Registeradressen erkauft. Theoretisch ist der ATmega8A dadurch sogar etwas besser ;-) OK, der Beitrag ist jetzt arg spät nach der Farge gekommen ;-) Aber vielleicht interessiert es ja nach wie vor.
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.
>sodass man die Chips problemlos als 1:1-Ersatz für >die Vorgänger vermarkten kann. Das war ja das Furchtbare an den Abkündigungen damals - du hast eine hochoptimierte Firmware, an der du nichts, aber auch wirklich gar nichts ändern willst, dann noch ein Zertifikat darauf, bist völlig zufrieden und plötzlich ziehen die dir den Chip unterm Hintern weg. Mein Chef war damals förmlich ausgerastet. Insofern sind wir hochzufrieden, daß es der ATmega8 "Langzeitware" ist. Zumal das Ding eine gute runde Zusammenstellung ist...
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. ;-)
Jörg Wunsch schrieb: > 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. tja manche Kunden wollten oder konnten die A Linie wohl nicht akzeptieren, z.b. muß man bei manchen Produkten eine komplett neue Zertifizierung durchführen wenn sich auch nur ein Buchstabe im BOM ändert - z.b. bei unseren Medizinprodukten ist es so. und auch wir kaufen weiterhin die "alten" Bauteile ohne A, nutzen aber die A Varianten in neuen Produkten Übrigens hab ich von unserem Disti erfahren dass es ein Lifetime Commitment auf min. 12Jahre gibt auf alle heute in Produktion befindlichen AVR :) Unser R&D CHef hat es schriftlich bekommen
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 :-)
Habe gestern gerade einen ATmega8-16PU mit dem neusten AS7 und originalem AVRISP MK2 mehrmals geflasht. Lief ohne Probleme. Vielleicht hat Dein MK2 einen Fehler. ISP6-Anschlußleitung mal auf Wackelkontakte oder Unterbrechungen geprüft.
Angehängte Dateien:
-
MKII.PNG
23 KB
Wackelkontakt erklärt nicht die 100%ige Trennung zwischen Mega8 und Mega8A. Studio V7.0.1417 MKII: Bildchen
Hi >Probeweise mal den Mega8 mit dem STK500 gelöscht, lock- und fusebits auf >Werkseinstellungen zurückgesetzt und dann mit dem MKII probiert - >funktioniert nicht. Na ja, für 1MHz Taktfrequenz ist der ISP-Takt von 250KHz zu hoch. MfG Spess
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.
Hi >Sollte eigentlich nicht, gemäß Beschreibung sollte der ISP-Takt nicht >mehr als 1/4 des IO-Taktes sein und das ist da ja gegeben. Nein. Er muss kleiner als 1/4 des IO-Taktes sein. Und das schließt auch die Gleichheit aus. MfG Spess
> Sollte eigentlich nicht, gemäß Beschreibung sollte der ISP-Takt > nicht mehr als 1/4 des IO-Taktes sein und das ist da ja gegeben. Wie sollte das eingehalten werden können, gar bei einem RC-Oszillator?
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.
Hi >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. Du hast es doch selbst gepostet: Beitrag "Re: ATmega8 vs. ATmega8A" Im rechten Bild steht der betreffende Satz im Feld ISP-Clock unter dem Schieberegler. Das Datenblatt sagt: Depending on CKSEL Fuses, a valid clock must be present. The minimum low and high periods for the Serial Clock (SCK) input are defined as follows: Low:> 2 CPU clock cycles for fck <12MHz, 3 CPU clock cycles for fck >=12MHz High:> 2 CPU clock cycles for fck <12MHz, 3 CPU clock cycles for fck >=12MHz Und >4 CPU clock cycles bedeutet bei mir eine Frequenz von < 1/4 der Taktfrequenz. >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? Schon mal etwas von den Toleranzen des RC-Oszillators gehört? Bei 5V und 25°C werden +-3% angegeben. MfG Spess
H.Joachim S. schrieb: > IRFR2705 mit 850pF Gatekapazität. Mit einer derartigen Last verletzt du vermutlich die Flanken- steilheits-Erfordernisse jedes heute üblichen Digital- Bausteins (da schaut meistens niemand drauf), mal abgesehen von CMOS-Waschmaschinen-Logik und Schmitt-Triggern. Ja gut, ist natürlich abhängig davon was der Treiber zu leisten vermag, es mag Ausnahmen geben. Ich habe schon so manchen LVC-Baustein eines Kollegen gesehen der wegen einer zu lahmen Signal-Flanke eben nicht mehr durch- geschaltet hat obwohl der Logik-Pegel korrekt angelegen hat.
Angehängte Dateien:
-
MKII.jpg
59 KB -
STK500.jpg
68 KB
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
MKII.PNG
15 KB -
STK500.PNG
9,9 KB
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.
H.Joachim S. schrieb: > ich kann nichts erkennen, was den Unterschied machen soll. Ich hatte es eigentlich geschrieben: Frickelfritze schrieb: > Ich habe schon so manchen LVC-Baustein eines Kollegen gesehen > der wegen einer zu lahmen Signal-Flanke eben nicht mehr durch- > geschaltet hat obwohl der Logik-Pegel korrekt angelegen hat. Wenn das Fremdsprache war, dann hier die Übersetzung: Eine nicht ausreichende Flankensteilheit eines Signals bringt den Empfänger potentiell dazu nicht den Logik- Pegel zu übernehmen.
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. ;)
Angehängte Dateien:
-
Doper_mit_ABS_Gehaeuse.jpg
110 KB
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
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"
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.
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.
Beitrag #5482125 wurde von einem Moderator gelöscht.
Beitrag #5957069 wurde von einem Moderator gelöscht.
Beitrag #5960921 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten