[gelöst]ATmega168 läuft nicht,trotz funktionierender Schaltg

[robodriver]

Hallo Leute,

ich habe folgendes Problem:
Ich habe hier eine Schaltung die mit einem ATmega8 läuft (4MHz Quarz).
Aufgrund von Speichermangel habe ich mir nun einen ATmeag168 gekauft und wollte die Schaltung mit diesem betreiben.

Laut Datenblatt sind die beiden uC 100% Pinkompatibel.
Also habe ich in der Software das neue Def-File geladen, Compiliert und gebrannt...

Als Erkennung das mein Controller läuft wird am Anfang des Programmes eine Led kurz eingeschalten und gleich wieder ausgeschalten.

Wenn ich das Programm nun mit dem ATmega168 auf der Schaltung betreibe geht die LED an und bleibt an. Das zeigt eindeutig das der Controller nicht läuft.
Wenn ich ihn runter nehme und den Mega8 aufstecke, dann läuft alles einwandfrei. Also einen Hardwarefehler kann man schonmal ausschließen.

Die Fusebits habe ich bei beiden Chips entsprechend auf den Quarz angepasst: External Crystal 4MHz

Das Programm ist in Bascom geschrieben.

Hat jemand eine Idee woran das liegen könnte? Software und Hardware sind identisch, also kann es doch nur an den Fuses oder Locks liegen?

Hoffe ihr wisst Rat.
Vielen Dank schonmal

Robodriver

[sechsrad]

mir fehlt eine glaskugel für deine fehlerlokalisierung.
stell dein programm mal rein.

...Wenn ich das Programm nun mit dem ATmega168 auf der Schaltung betreibe geht die LED an und bleibt an. Das zeigt eindeutig das der Controller nicht läuft. ....


wenn die led an geht, funktioniert doch der atmega, sonst würde die led doch nicht angehen...lol....

[oberallgeier]

Hallo robodriver,

Deine Probleme sind schon ok. Das hat alles seine Richtigkeit. Auf dieses "Pinkompatibel" war ich auch reingefallen. Das stimmt hardwaremässig sogar, oder auch nicht - weil der 168 zusätzliche Funktionen hat.

......................Bild hier  

Beispiel: der mega8 hat 19 Interrupt-Vektoren, der m168 hat 26. Der m8 hat "kleine" Adressen der Interrupt-Vektoren, der m168 hat doppelt so breite.

Oder: der m168 hat doppelt so viele PWM-s. Das muss sich doch im Code niederschlagen. Die Registerbelegung ist dadurch deutlich unterschiedlich.

Also 1:1 programmieren geht eben nicht, weil die Kompatibilität sich nicht auf die Software bezieht . Du musst unbedingt bei Ports und insbes. bei Interrupts - also genaugenommen eben IMMER - die beiden docs miteinander vergleichen. Das habe ich gemacht. Kostet einige Zeit, ich weiss.

[linux_80]

Hallo,

wenn man das richtige Dat-File verwendet, sollte es passen, denn mehr kann man ja eigentlich nicht machen. Solange man keine Portnamen direkt verwendet, bzw. da schimpft dann der Compiler sowieso wenns den Namen so nicht gibt.

Was ich aber jetzt nicht gelesen habe, bei den Fusebits, hast Du da auch beim M168er das Clockdiv8 deaktiviert ? Das gibts beim M8 nicht, und würde heissen, das der 168er 8mal solange braucht, bis die LED wieder ausgeht.

[robodriver]

Ja, also ich bin auch der Meinung das es nicht am Programm liegen kann.
Das macht ja alles der Compiler für mich.

Was ich jetzt mal probiert habe: Ich habe ein kurzes Testprogramm geschrieben. In dem einfach nur die LED ein und ausgeschaltet wird. Dieses Programm läuft einwandfrei auf der Schaltung.
Die richtige Software ist allerdings reichliche 4kB groß. dies hier zu Posten würde sicher keinen Sinn machen oder?

In dem Programm werden folgende Dinge verwendet:
- TWI Interrupt
- Timer 2 als PWM (umgeändert, war vorher Timer1)

und das wars so weit auch schon. es gibt allerdings noch eine ganze Menge unter-subs. ich sag jetzt mal 3-4 Unterverzweigungen im worst Case wenn die Interrupts ungünstig kommen.

Vielleicht gibts ein Problem mit framesize hwstack oder swstack?
die hab ich auf folgende Werte gesetzt:
hwstack 64
soft stack 16
framesize 48

kommt das hin? Kann es daran liegen? Ich mein die Anfangsroutine läuft noch ohne subs (das LED blinken).


Den Teiler habe ich bei den Fuses deaktiviert



^^ hab alle 3 jetzt mal einfach auf 128 erhöht, funktioniert trotzdem noch nicht

[oberallgeier]

... ein kurzes Testprogramm ... LED ein und ausgeschaltet ...

Das wird schon codekompatibel laufen. Aber schon beim Timer/Counter2 scheiden sich die Geister - sprich Registernamen und Register-Bitnamen. Aber das hast Du sicher schon im doc2486 und doc2545 gelesen.

[robodriver]

okay, also ich habe jetzt nochmal anstelle des Timers2, wie im Originalprogramm den Timer 1 verwendet.
und da funktioniert es alles einwandfrei.

Also werd ich mir die Verwendung des timer2 nochmal genauer ansehen müssen. Der Funktioniert dann offensichtlich doch etwas anders als der Timer1...

Trotzdem danke nochmal für eure Hilfe

[oberallgeier]

Na ja, der Timer2 ist bei meinen mega8ern und mega168ern ein 8bittiger Timer, und Timer1 ist bei beiden Familien ein 16bittiger Timer. Usw. Wie gesagt, ich lese vorher die Dokumentation.

[robodriver]

welche Docu meinst du? Das Datenblatt?
Das habe ich da. Aber da wird alles super schön mit den Registern erläutert. Unter Bascom verwendet man aber kein einziges Register und der Compiler erstellt einem den notwendigen Quellcode mit einzelnen Befehlen. Somit nutzt mir das Datenblatt meist relativ wenig. nur für die Grundlagen.

Ich hab das ganze jetzt so weit gebracht, das der Controller zumindest läuft. Aber meine PWM-Ausgänge bleiben Null egal ob och ocr2A/B auf 0 oder 255 setze...

Konfiguration ist wie folgt:

Config Timer2 = Pwm , Compare Pwm = Clear Down , Prescale = 8

Pwm_rechts Alias Ocr2a
Pwm_links Alias Ocr2b

Der Fehler war bisher immer das ich compare a pwm = clear down und compare b pwm = clear down geschrieben habe. Das brachte keinen Fehler beim compilieren, aber offensichtlich hat es den Controller zum absturz gebracht... Also hab ichs jetzt umgeänder und das a und b raus gelassen... Aber es funktioniert wie gesatz rein gar nichts.
Die Ausgangspins bleiben bei 0
(Als Ausgang sind sie konfiguriert wurden)

weiß jemand noch was woran das jetzt wieder leigen könnte?

^^ vielleicht sollte man mit dem jetzigen neuen Problem auch ins Bascom Forum gehen, dann das ursprüngliche Problem ist ja gelöst.

[oberallgeier]

Ja, ich glaube das Bascom Forum ist besser - mit Bascom kann leider nicht weiterhelfen.