ATMega128 ersetzt durch 2561 - nix geht mehr/warum?

[Re T. (toobatch)]

TACH!

also arbeite hier an boards die mal mit nem ATMEGA 128 bestückt waren 
(es geht erstmal um die inbetriebnahme //  und nen OS zu progn. mit 
Treiber für Ethernet und RS232 Schnittstellen)

Laut AVR sind die beiden uC pinkompatibel .. also zumindest prinzipell 
funktionieren müsste es die auszutauschen und dann mit kleinen 
veränderungen im code irgendwas zu laufen zu kriegen, bloß in den 2561 
geht jetzt gar nix mehr.  krieg nicht mal nen Pin zum toggeln .

zur kompatibilität:
http://www.atmel.com/dyn/resources/prod_documents/doc2581.pdf

Takt ist da, Fuseeinstellungen müssten passen ...

ein board ist noch mit nem 128  bestückt, da funktioniert alles ...


mir fällt nix mehr ein was  das problem sein könnte :  hab die AVR 
checkliste hier von der Site auch mehrmals durchgespielt, mit oszi 
gemessen . (hab auch mehrere boards hier _ eher unwarscheinlich das alle 
2561 uC defekt sind in irgend einer form.)



kann das irgendwie mit dem bootloader zusammenhängen das der nicht an 
die richtige Appl.Startadresse springt und sich irgendwo verhängt.

vll hat jmd erfahrung mit dem Controlleraustausch und den verbunden 
Problemen.

danke schonmal im vorraus!!!!

[mui (Gast)]

Beim kopmpilieren des Quellcodes den Controllertyp eingestellt?

[André (Gast)]

musst du die .inc"...def.inc" einfügen! ;)

[Re T. (toobatch)]

ja schon .. dises mcu.

schreibe in C.

hab keine ahnung von diesem ganzen make(file)  zeug ...
aber weiß nicht wie ich anders zu nem ganz  einfachen programm komme , 
da benutz ich jetzt ein anderes projekt mit makefile.
hab alles auskommentiert bis auf  main() und dort so ein paar ein paar 
pinansteuerungen >> quelltext stimmt.


könnte das ja manuell machen per komandozeile compilieren und linken .. 
aber hab da auch nich so richtig ahnung.
nicht das dieses make  nicht das macht was es soll...

im simulator (AVR studio) läufts aber.

der code steht eher so in der mitte des Flashspeicherbereichs davor 
alles 0xFFFF-anweisungen.

beim simulieren macht der erstmal irgendwas (pointerreg. hochzählern 
oder so )  aber dann kommt er irgendwann in diese schleife wo die Ports 
invertiert werden.

jmd ne bessere idee wie ich den uC testen kann ?

DDRxn hab ich gesetzt.


ich krieg ne kriese hier !

[Re T. (toobatch)]

.inc"...def.inc"  ??   was soll das bitte sein ?

[Re T. (toobatch)]

sowas muss doch zum testen reichen:

 
#define __AVR_ATmega2561__  // oder im makefile definieren
#include<avr/io.h>

void main()
{  int i;    


  DDRA = 0xFF;  //DataDirektionReg. auf OutputPin
  DDRB = 0xFF;
  DDRC = 0xFF;
  DDRD = 0xFF;
  DDRE = 0xFF;

  PORTA=0x00;  // feste konst. Belegung
  PORTB=0xFF;
  PORTC=0xFF;
  
for (i = 0;; i++)
{
  PORTD^=0xFF;  //toggle -Pins 
  PORTE^=0xFF;
}
 
}

die  uC machen aber nix , wenn ich mit oszi messe .