ATMEGA32 gegen ATMEGA644 tauschen

Hallo,

habe versucht auf meinem Roboter Board RNBFRA v.1.22 den darauf befindlichen ATMEGA32 gegen einen ATMEGA644 zu tauschen. Die Pinbelegung ist ja bei beiden Chips gleich und der Mega644 hat das doppelte an Speicher etc. Allerdings kam beim proggen die Fehlermeldung, dass der Chip darauf nicht erkennbar ist.

Meine Fragen:

- Benötigt der Mega644 einen anderen Vorwiederstand als der Mega32?
- wenn ja, wie kann ich den Wiederstand auf dem Board finden und gegen welchen muss ich ihn austauschen?
- wenn nein, was könnte noch die Ursache sein, dass der Chip nicht funktioniert?

Vielen Dank schon mal für Eure Replys.

Gruß
Euer Sascha.

Hallo,

den Mega32 kann man soweit ohne Probleme gegen den Mega644 tauschen, hab auf dem RN-Control auch schon den Mega644p laufen.
Man braucht nur ein passendes Programm um den zu flashen, das diesen auch kennt.

Welches Prog verwendest Du zum flashen ?
Evtl. liegts auch noch daran, wenn er neu ist läuft der nur mit 1MHz, und zu langsam für das Prog :-k

Was willst du mit dem "Wiederstand" ?
Ein AVR hat/braucht/will keinen Vorwiderstand :-k

Hallo Linux_80,
vielen Dank für die Infos. Dachte nur ein Chip braucht einen Vorwiederstand. Verwende Bascom AVR zum flashen des Chips. Da kann man den m644 auch auswählen und als regfile m644def.dat im code angeben.
der Programmkopf sieht bei mir momentan so aus:

Code:

---

$regfile = "m644def.dat"
$crystal = 8000000
$baud = 9600
$hwstack = 64
$swstack = 128
$framesize = 64

---

Wenn der im neuzustand (also ohne fusebitskonfiguration - ohne external clock) auf 1 MHz läuft, muss ich wohl die Angabe mit $crystal = 8000000 auf 1000000 ändern, oder? Werde es dann heute abend mal damit versuchen.
Vielen Dank nochmal!
Gruß
Sascha

Hallo Linux_80,
Habe es mit $crystal = 1000000 versucht - da kam die gleiche fehlermeldung. (siehe beigef. Bild.)
Was steht auf Deinem Chip hinter der Bezeichnung ATMEGA644P?
Steht da 10PU oder 20PU?
Gruss
Sascha

Hallo,

hast Du nun einen Mega644 oder den Mega644P ?
Der 644P hat die ID:1E960A den kennt Bascom noch nicht !
Wir haben aber schon irgendwo diese Config-Datei dazu im Forum gepostet, musst mal suchen.

Und, ich hab die 20MHz Version, das ändert aber nix daran.

Hallo Linux,
ja habe den mit dem p hinten dran und mit 20 mhz :-) also ATMEGA644P 20PU
Werde danach suchen...
Vielen Dank für die Infos!
Gruss
Euer Sascha

Hallo Linux_80,
Super! es hat mit der Datei, die Du entwickelt hast, geklappt - er läuft!
Vielen Dank an dieser stelle.
Gruß
Euer Sascha

Habe soeben den Quarz gegen einen 20Mhz Quarz getauscht - jetzt läuft das programm mit der Angabe 20000000 aber sehr sehr langsam ab. Irgendwie hat man bei den Fusebits-Werten auch ganz andere Parameter zur Auswahl als beim ATMEGA32. Kannst Du bitte hier die Fusebits-Einstellungen als Bild vom ATMEGA644P posten?
Vielen dank schon mal.
Gruß
Sascha

Hi,

da brauchts kein Bild,
wenn Du nur das umgestellt hast, was Du vom M32 her kennst, läuft der nur 1/8 davon.
Schau mal bei den Fuses nach CKDIV8, das gibts bei den neueren AVRs, und deaktivere es, dann klappts auch mit den 20MHz.

Hallo Linux_80,
Ok, Es lag am teiler durch 8 - es läuft jetzt von der geschwindigkeit her normal. Allerdings funktionieren die Befehle:
Driveinit()
Drivewirtesector
und Drivereadsector der MMC-Karte nicht mehr - wenn ich den Teiler hingegen wieder aktiviere funktionieren sie wieder aber das Programm läuft sehr langsam. Kann es sein, dass der Prozessor nun "zu schnell" für mein board ist oder liegt es an etwas anderem? Ausserdem Funktioniert die Positionierung des cursor-befehls mit dem I2C-Bus nun auch nicht mehr, wenn der teiler deaktiviert ist.
Habe mal einen Bildschirm-Ausdruck beigefügt.
Oder kann das an der TWI-Angabe liegen - muss ich die noch ändern oder muss die so bleiben. (hab sie auch schon testweise geändert und bekam dann haufenweise fehlermeldungen... - war wohl der falsche wert.)
Vielen Dank an dieser Stelle nochmals und viele Grüße
Sascha

Hi,

wenn Du den Teiler "drin" hast, musst Du das auch im Programm angeben, also bei $crystal 20000000/8.

Mit den MMC-Funktionen hatte ich noch nix zu tun, aber beim TWI sollte das so klappen, wenn man das per Config TWI einstellt. Ich hatte damit noch keine Probleme.

Du kannst ja mal den langsameren Quarz probieren, aber dann auch im Programm so angeben, sonst stimmt die UART-Übertragung auch nicht mehr.

ok, so funktioniert es wieder - aber ist es nicht schlecht, wenn der Teiler durch 8 in den fusebits auf enabled steht? - wegen der 20 MHZ - die kann ich dann doch garnicht nutzen, oder?
Das mit dem Quarz habe ich auch schon probiert - da läuft er dann aber nur mit 8 MHZ (Habe einen 8MHZ-Quarz ganz am anfang getestet, bevor ich den 20 MHZ ringelötet hab). Also genauso schnell wie der ATMEGA32.

Jetz haben wir bald alle Grundlagen durch ;-)

Wenn der Teiler in den Fuses gesetzt ist hat man natürlich keine 20Mhz mehr für den AVR, dieses Fuse ist aber wohl eher für noch langsamern Takt gedacht, wenn Stromsparen wichtig ist usw. also unter 1MHz zB.

Du musst halt wissen wie schnell der AVR laufen muss, damit er das schafft was Du von ihm haben willst.
Und auf jeden Fall immer den richtigen effektiven Takt bei Crystal angeben, damit der Rest vom Programm auch noch funktioniert, das wären UART, TWI, Wartezeiten und was sonst noch alles in die Richtung geht, zB. Software-SPI. Denn Bascom berecht das aus diesem Wert für das Programm beim compilieren !

vielen Dank für die Infos.
Damit sind alle Unklarheiten beseitigt :-)
Viele Grüße
Euer Sascha