Atmega328 U(?) Prüfsummen Fehler

[Rafael H. (rasiel)]

Hallo Zusammen

Ich benötige eure Hilfe :-)
Ich habe bei RSComp. 5 ATmega328-PU bestellt (RSNummer 131-0277).
Nun wollte ich mein Programm(In VSCode geschrieben und kompiliert) in 
diese 5 Controller mit dem MyAVR Progtool flashen, leider ohne Erfolg 
:-(

Problem:
1.Ich lese die Hardware aus. Wird erkannt als Mega328. (siehe Bild 
1_AVR).

2.Ich lade das HexFile und brenne es. Leider mit dem Fehler
"Prüfsummenvergleich Fehler" (Siehe Bild 2_AVR).

3.Also wieder einmal das MC Studio geöffnet (Atmega328) ausgewäht + ein 
Test geschrieben, kompiliert (siehe Bild 3_Build) und versucht mit dem 
AVRProgTool zu programmieren. Selber Fehler...

4.Um den Programmer zu testen, Controller auf ein Atmega8L gewechselt 
(Software+Physisch), kompiliert, programmiert funktioniert TipTop :-)

5. Ich kann mir fast nicht vorstellen das alle 5 Controller defekt sein 
sollten?

Was mir zusätzlich noch aufgefallen ist. Auf den neuen Controller steht 
ATMEGA328-U, und nicht wie bestellt ATMEGA328-PU. Könnte das eine Rolle 
spielen? Ich habe nirgends die eine Doku zu (nur U) gefunden...?

Danke für eure Unterstützung
MFG Rafi

[Harald K. (kirnbichler)]

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

[S. L. (sldt)]

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

[Jörg W. (dl8dtl) (Moderator)]

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.

[Bernd S. (wirrer_haarschopf)]

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.

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Ob S. (Firma: 1984now) (observer)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Ob S. (Firma: 1984now) (observer)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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

[Martin (marcopit)]

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)

[Jörg W. (dl8dtl) (Moderator)]

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

[S. L. (sldt)]

> oder ich suche falsch?? ... bin Newbie

Das Datenblatt ist eine gute Quelle.