Atmega328 U(?) Prüfsummen Fehler

Atmega328 != Atmega328p

"Der ATmega328P ist eine Weiterentwicklung des ursprünglichen ATmega328. Das P steht für Picopower. Die Stromaufnahme konnte zur P-Variante etwas reduziert werden."

https://www.richis-lab.de/uC01.htm

Sind beide Versorgungspaare angeschlossen? Sonst fällt mir nichts ein - die Page-Size ist beim ATmega328 doppelt so groß, aber da er ja korrekt erkannt wird ...

Rafael H. schrieb:

Auf den neuen Controller steht ATMEGA328-U, und nicht wie bestellt ATMEGA328-PU.

Das "P" ist die Bestellbezeichnung für ein DIP-Gehäuse.

Da du die Gehäuseform rein äußerlich ganz gut erkennen kannst :-), wird die nicht mit drauf geschrieben.

Zu deinem MyAVR-Problem kann ich dir leider nicht helfen, ich habe keine Ahnung, was sie da überhaupt anstellen.

Ich hatte seinerzeit mit dem myAVR im AVR911 modus auch solche Fehler. Die bieten auch eine STK500-Version zum Download an. Seitdem ich die benutze, funktioniert der Programmer absolut zuverlässig und das schon seit fast 10 Jahren.

Mal versucht, die Geschwindigkeit beim Flashen herabzusetzen? Die AVRs laufen ab Werk nur mit 1Mhz (interner 8Mhz RC-Taktgeber und CLKDIV8 gesetzt). Das sollte zwar eigentlich 250kbit/s beim Flashen erlauben, aber ich hatte auch schon Controller, bei denen das nicht ganz zuverlässig funktionierte.

Ben B. schrieb:

aber ich hatte auch schon Controller, bei denen das nicht ganz zuverlässig funktionierte

Das Limit selbst ist (digital-)technisch bedingt und wird exakt eingehalten, aber die genaue Frequenz des RC-Oszillators ist natürlich nicht exakt.

Aber es gab ja weiter oben schon den Hinweis, eine andere Firmware für den Programmer zu benutzen.

Ben B. schrieb:

Mal versucht, die Geschwindigkeit beim Flashen herabzusetzen? Die AVRs laufen ab Werk nur mit 1Mhz (interner 8Mhz RC-Taktgeber und CLKDIV8 gesetzt). Das sollte zwar eigentlich 250kbit/s beim Flashen erlauben, aber ich hatte auch schon Controller, bei denen das nicht ganz zuverlässig funktionierte.

Ja, das ist tatsächlich ein recht übliches Problem. Typisch dafür ist: Je "kürzer" die Aktion, desto wahrscheinlicher funktioniert sie.

Dev-ID auslesen: funktioniert (nahezu) immer Fuses schreiben oder Lesen funktioniert meistens Flash/EEP schreiben oder lesen funktioniert umso seltener, je mehr Daten bewegt werden sollen.

Ob S. schrieb:

Typisch dafür ist: Je "kürzer" die Aktion, desto wahrscheinlicher funktioniert sie.

Ist ja auch irgendwie logisch: wenn der Takt nicht gerade übertrieben zu hoch ist, funktioniert die Abtastung der SCK-Flanke durch den MCU-Takt noch. Aber irgendwann "überholt" eine SCK-Flanke den abtastenden MCU-Takt und geht damit im Protokoll "verloren". Ab da ist Finito.

Jörg W. schrieb:

Ist ja auch irgendwie logisch: wenn der Takt nicht gerade übertrieben zu hoch ist, funktioniert die Abtastung der SCK-Flanke durch den MCU-Takt noch. Aber irgendwann "überholt" eine SCK-Flanke den abtastenden MCU-Takt und geht damit im Protokoll "verloren". Ab da ist Finito.

Ganz genau so ist das. Ist halt das "gerade so an der Grenze"-Szenario.

Ich habe keine Ahnung, warum Atmel damals die Defaults ihrer IDEs so gewählt hat, dass man mit einiger Wahrscheinlichkeit früher oder später auf eben dieses Szenario trifft, wenn man einfach nur die Defaults benutzt. Das hätte man sicherlich besser (anwenderfreundlicher) machen können. Klar, der Durchsatz wäre suboptimal, aber das ist einem Neueinsteiger sicherlich lieber als diese "geht"/"geht nicht"-Sache. Der weiss halt einfach noch nicht, was da im Detail passiert.

Hier geht's aber nicht um Atmel, sondern um MyAVR. Die hätten es ja besser machen können. ;-)

Hallo zusammen

Auf meinem alten Galep4 sehe ich folgendes: Ein ATmega328P U hat die Bauteilkennung: 1E 95 0F Ein ATmega328U gibt hier: 1E 95 14

Hat jemand Angaben zum U Typ? Ich finde dazu nichts, oder ich suche falsch??

Kann das Problem von Rafael H damit zusammenhängen, wenn beim Programmieren solches verglichen und P erwartet wird?? (Sorry Vermutung, bin Newbie)

Martin schrieb:

oder ich suche falsch?

Ja. Es ist gar keinen U. (Mit "U" in der Typnummer wurden USB-fähige AVRs markiert.)

0x1e 0x95 0x14 ist der ganz normale ATmega328. Der ATmega328P hat die 0x1e 0x95 0x0f (ist also älter, ursprünglich wollte man offenbar nur "Picopower" verkaufen), und der ATmega328PB hat 0x1e 0x95 0x16.

Alles das, was nach dem Bindestrich in der Bestellnummer kommt, bezeichnet die Gehäuseform, so also auch das "-PU" (welches das DIP-Gehäuse kennzeichnet).

oder ich suche falsch?? ... bin Newbie

Das Datenblatt ist eine gute Quelle.