Hallo,
ich hab schon einige Atmegas verbaut und Programmiert, jedoch steh ich
beim Atmega328PB irgendwie auf dem Schlauch.
Hab jetzt meine Platinen bekommen aber ich kann ihn über den myAVR ISP
Programmer nicht ansprechen.
Jetzt mal als erstes die Grundlegende Fragen... welche Pins am Chip
werden hier benötigt?
Im Datenblatt steht die SPI Schnittstelle mit folgendem Pinning... siehe
Anhang
Flashen wollte ich ihn mit dem myAVR ProgTool, hier kann man nur den
atmega328P auswählen. http://shop.myavr.de/index.php?sp=download.sp.php
Ich hab meinen so verkabelt:
ISP -------- ATMEGA328PB
1 MISO ---- PIN 16
2 VCC ----- PIN 4 und 18
3 SCK ----- PIN 17
4 MOSI ---- PIN 15
5 RESET --- PIN 29
6 GND ----- PIN 5 und 21
Tom schrieb:> Ich hab meinen so verkabelt:
Stimmt so.
> Hab jetzt meine Platinen bekommen aber ich kann ihn über den myAVR ISP> Programmer nicht ansprechen.
Platinen überprüfen.
> Flashen wollte ich ihn mit dem myAVR ProgTool, hier kann man nur den> atmega328P auswählen.
Trotzdem sollte es gehen.
M328P auswählen, der Prommer sollte nach Verbinden zumindest falsche
Signature Bytes melden.
Pullup am Reset ist vorhanden
Ich denke es liegt am Programmer... evtl. schickt dieser falsche Daten
oder das Timing zum Chip passt nicht.
Der 328PB ist anscheinend etwas anders was das Timing angeht.
Im Datenblatt steht was von Bootloader welcher die zusätzlichen UARTS
und SPI schnittstellen verwaltet... aber ich werde da nicht ganz schlau
daraus...
Hier das Datenblatt
http://ww1.microchip.com/downloads/en/DeviceDoc/40001906C.pdf
> Der 328PB ist anscheinend etwas anders was das Timing angeht.
Das würde mich überraschen, denn er wird als Drop-In-Replacement für den
ATmega328P gehandelt.
Stefanus F. schrieb:> Die Angaben PB5, PB6 und PB7 in Figure 23-6 sind sicher falsch.
Die sind aus dem Datenblatt von Microchip, warum sollten die falsch
sein?
Tom schrieb:>> Die Angaben PB5, PB6 und PB7 in Figure 23-6 sind sicher falsch.> Die sind aus dem Datenblatt von Microchip, warum sollten die falsch> sein?
Weil die richtigen Pins PB3, PB4 und PB5 sind. Steht auch in der Tabelle
unter Zeichnung. Vergleiche mit dem Datenblatt vom ATmega328P.
Als das noch in der Hand von ATmel lag, was die Zeichnung noch korrekt:
https://www.rlocman.ru/i/File/2016/03/02/Atmel-42397-8-bit-AVR-Microcontroller-ATmega328PB_Datasheet.pdf
(ohne falsche Portnummern).
Seit Microchip an den Datenblättern herum fummelt, wird geschlampt, was
das Zeug hält. Das ist schon das dritte irreführende Bild, auf das ich
gestoßen bin.
Tom schrieb:> Stefanus F. schrieb:>> Die Angaben PB5, PB6 und PB7 in Figure 23-6 sind sicher falsch.>> Die sind aus dem Datenblatt von Microchip, warum sollten die falsch> sein?
Reg dich nicht auf, du hast es richtig angeschlossen.
Du hast nicht 2 Stück 100nF Keramikkondensatoren an Vcc vergessen? (Pin
4 und Pin 18).
Als nächstes ein 10 nF zu AVcc. Aber ohne die sollten es immerhin keine
so drastischen Ergebnisse geben.
Hallo,
leider steht hier keine Lösung des Problems. Stand nämlich soeben vor
selbigen. Bei mir lag es daran das ich meinen mkII Treiber vor einer
Weile mit dem Zadigtool behandelt hatte. Musste ich machen damit er in
der Arduino IDE nutzbar wurde. Atmel Studio erkennt damit zwar den mkII,
kann aber sonst nichts machen. Erst als ich den Treiber mit dem
Zadigtool zurückgeändert habe klappt es in AS7 wieder.
Das Problem ist damit unabhängig vom µC. Vielleicht hilft es ja
jemanden.
Und ja das aktuelle Manual ist grottig. Microchip versaut was vorher
gestimmt hat.
Veit D. schrieb:> Und ja das aktuelle Manual ist grottig. Microchip versaut was vorher> gestimmt hat.
Da kannst du so dermaßen einen 'drauf lassen. Glücklich ist jeder, der
die alten Atmel-DBs archiviert hat. Ja, da war auch nicht immer alles
korrekt, aber gegen das, was diese vollkommen unfähigen MC-Plinse
liefern, sind die so wertvoll und wertstabil wie Gold.
Wenn man das Elend sieht, wird klar, warum ich mit den PICs nie warm
werden konnte, obwohl zumindest einige davon nominell durchaus attraktiv
im Vergleich zum Atmel-Sortiment waren.
Aber was nützt mir ein Chip, bei dem das Datenblatt gequirlte Scheisse
erzählt? Der kann noch so gut sein, für mich ist er de facto
unbrauchbar.
c-hater schrieb:> Glücklich ist jeder, der die alten Atmel-DBs archiviert hat.
Kann ich bestätigen. Die neuen Datenblätter sind bunter, aber enthalten
neue Fehler. Warum haben die das überhaupt gemacht, hat irgendein
Entwickler mehr Farbe angefordert?
Stefanus F. schrieb:> Die neuen Datenblätter sind bunter, aber enthalten> neue Fehler. Warum haben die das überhaupt gemacht, hat irgendein> Entwickler mehr Farbe angefordert?
Nö, das war ganz sicher eine Idee der Marketing-Abteilung, vielleicht
sogar des höheren Managements. Letzteres hat aber in jedem Fall
entschieden, dass es so laufen soll.
Und auf jeden Fall waren all die nicht beteiligt, die eine kompetente
Meinung zur Sache hätten äußern können, also diese unbeliebten
Technik-Leute, die alles nur nur sinnlos zerreden...
Merke: Nichts erleichtert das Fällen von Entscheidungen mehr als die
Abwesenheit jeglichen Sachverstands.
Das allerdings ist kein alleiniges Problem von MC, nein, man findet es
in fast jeder Firma. Je größer sie ist, desto weniger geht es bei so
einer Entscheidungsfindung um technische Sachverhalte. Eben deshalb,
weil die Entscheider davon sowieso rein garnix verstehen...
Hallo,
das mit den farbigen Blockbildern am Anfang der Manuals fiel mir damals
auch sofort auch kurz nach der Übernahme. Damals dachte ich, naja warum
nicht. Etwas Farbe kann ja nicht schaden. Was ich aber niemals vertehen
werde ist warum Dinge die Richtig sind ins Falsche geändert werden. Da
muss jemand bewusst drin rumgepfutscht haben.
Was Schade ist, den die 8Bitter gefallen mir nachwievor, auch die neue
Mega0Serie. Die STM32Bit u.ä. sind mir leider zu kompliziert im Aufbau,
was ich auch nie ausreizen würde. Auch weil ich gerade mit der
Mega0Serie warm werde.
