Hallo,
ich versuche verzweifelt einen 6-Kanal-LED-Dimmer mit einem ATmega644 zu
programmieren, jedoch scheitert momentan alles am Timer0. An Timer2
funktioniert alles und Timer1 habe ich, auf Grund der Problememit
Timer0, noch nicht imlementiert.
Problem ist, OC0B wird nicht angesteuert. Wie gesagt, alle anderen
Kanäle funktionieren wie sie sollen.
Wer kann mir zeitnah helfen, da es sich um ein eiliges Projekt handelt?
Die Adressbits benutze ich momentan zum Testen der PWM, hier hängt an
den Pins ein DIL-Schalter, der später für die Adressvergabe des
Bausteins in einem Bussystem diene soll. Jetzt gibt er mir Werte für die
Compares vor.
Hier mal der betreffende Code-Auszug:
Peter Gerblich schrieb:> was auch immer im HEX drinne steckt, es funktioniert. Mich würde nun
interessieren, was
> hier programmiert wurde.
Nix anderes als im von Dir gezeigten Code, nur angepasst auf die Syntax
des verwendeten C-Compilers, low/high statt lo8/hi8, SPL/SPH statt
ioSPL/ioSPH, der Rest passte.
Evtl. der falsche Controller definiert ?
Habe die HEX-Datei analysiert und festgestellt, dass die
Interuptvektoren fehlen. Habe mein Listing kurzer Hand angepasst, also
ebenfalls die Int's weggelassen und siehe da, ich erhalte fast das
gleiche Hex-Dump. Aber eben nur fast: 2 Byte Unterschied, und dass war
der Knackpunkt. Für "out OCR0B,r16 " erzeugt er mir "07 B9" Statt "08
BD". Ich habe dann statt des Alias die Adresse von OCR0B (0x28)
verwendet, und schon funktioniert auch der 2te Kanal von Timer0. Der
Fehler liegt also eindeutig in der Linkdatei meiner Entwicklungsumgebung
(SiSy-AVR). Testweise habe ich als Kontroller das 164er-Pendant des
644er angegeben. Dort wird alles korrekt übersetzt. Hoffe nur, dass es
der einzigste Fehler in der Link-Datei war, sonst wirds noch nen
Späßchen geben mit der Programmiererei.
Ohne dem Hex-Dump von MWS hätte ich den Fehler nie herausgefunden, also
vielen Dank nochmals an Alle, die mir bei der Fehlersuche geholfen
haben.
VG Scorpius
Ein 0xB907 ist ein OUT 0x07,R16, wird also in den korrekten Befehl mit
dem richtigen Quellregister übersetzt, nur die Ziel-IO-Adresse stimmt
nicht.
Überprüf' doch mal die .inc Datei für den ATM644P Deines Assemblers, da
wird wahrscheinlich nur die falsche Adresse für OCR0B definiert sein.
Bei der Gelegenheit würd' ich die 644er.inc gleich mit der .inc des
ATM164 abgleichen, eben um weitere Überraschungen zu vermeiden.
Falls Dir das nicht bekannt ist: Du kannst selbst wenn AVR-Studio die
.obj Deiner Entwicklungsumgebung nicht schluckt, doch immerhin das
erzeugte Hex laden, auch simulieren.
Einfach in AVR-Studio auf Öffnen gehen und das Hexfile laden, dann
siehst Du gleich wo's klemmt.
Momentan benutze ich AVR-Studio noch nicht. Arbeite am momentanen
Projekt mit Sisy-AVR. Ins AVR-Studio müsste ich mich erst einarbeiten
und dafür ist im Moment zu kurzfristig, wegen Termin. Trotzdem Danke für
Deine Hilfe.
Kann man mit AVR-Studio disassemblieren?
Peter Gerblich schrieb:> Kann man mit AVR-Studio disassemblieren?
Ja, klar, das war ja der Inhalt meiner Message.
Du kannst im laufenden Programm Variablen, Register und auch Befehle
ändern.
Lädst Du ein Hex, dann öffnet nur das Disassemblerfenster.
Wenn eine .obj Datei geladen wird, siehst Du zuerst den Quellcode und
kannst entweder ein Disassemblerfenster aufmachen (unter View oder per
Icon), oder aber Rechtsklick auf die Codezeile und "Goto Disassembly".
Zumindest bei AVR GCC und bei Bascom ist das so, wie's bei SiSy ist kann
ich nicht sagen, einfach ausprobieren.
Soviel einarbeiten ist das nicht, links Register, Mitte Quelltext oder
Disassembler, rechts IO, so zumindest in der Standardeinstellung. Das
hätte Dir viel mehr Zeit erspart, als Dich die Einarbeitung gekostet
hätte.
Trifft übrigens für die AVR-Studio 4.. zu, nicht für die Beta 5, die
find' ich eher kompliziert.
Peter Gerblich schrieb:> Trotzdem Danke für> Deine Hilfe.
Gerne.