Eines vorweg, ich bin Ziemlich neu in Assembler, also seid mir nicht böse wenn es sich um ein Layer8 Problem handelt... Zu meinem Problem: Ich würde gern für ein zeitkritisches Projekt ein Programm in Assembler schreiben. Das Ganze funktioniert bereits in C, allerdings wird ein Interrupt zu langsam ausgeführt. Ich habe dann das Programm in Assembler neu geschrieben, doch da will es nicht funktionieren. Nach Längerem Kampf mit dem Simulator bin ich schließlich auf die mögliche Ursache gestoßen. Wenn ich versuche etwas (z.B. 0x11) in das USICR zu schreiben landet es im USIDR. Selbiges Passiert beim USISR wo die Daten im USIBR landen. Also immer im übernächsten Register. Wen ich in USIDR oder USIBR schreibe landen die Daten teilweise aufgeteilt, teilweise komplett in USICR und USISR. Ich wollte euch nun fragen, ob dieses Verhalten normal ist, oder ob es sich um einen Bug im Simulator bzw. im Assembler handelt. Ich verwende AS7.0.2389, die neueste Version. Leider habe ich nur einen STK500 kompatiblen ICSP, also ohne Debugging-möglichkeit. Mikro ist wie im Titel geschrieben ein ATTINY1634.
Angehängte Dateien:
-
Assembler.JPG
160 KB
fehlt da nicht ein (prozessorspezifisches) include der reigsterbeschreibung? oder wird das über compilerflags geregelt?
Sven K. schrieb: > fehlt da nicht ein (prozessorspezifisches) include der > reigsterbeschreibung? oder wird das über compilerflags geregelt? Die Registerbeschreibung ist im SolutionExplorer unter Dependencies/tn1634def.inc vorhanden. Muss ich nochmal separat einbinden?
Ich habe in der Zwischenzeit auch versucht den FLASH zu dissembeln. Der Disassembler zeigt als Zieladresse für "out USICR, r16" 0x2C an. Manuell bin ich bis auf die Opcodes nicht schlau aus dem Hexfile geworden.
Es gibt zwei Stellen, an denen die Registeradressen einem symbolischen Namen zugeordnet werden. (Eigentlich sogar drei Stellen, aber zwei verschiedene Dateien). Da gibt es manchmal Unterschiede in den beiden Dateien. Das ist schon mehrfach vorgekommen. Die eine Stelle sind die H-Dateien. Offenbar, wenn im Programmtext die richtige Adresse steht, ist die H-Datei in Ordnung. Das Assemblieren tut also, was gewollt ist. (Zu dem 0x2c anstelle des 0x4c siehe unten). An der zweiten Stelle, nämlich den atdf-Dateien sind die einzelnen Prozessoren für den Simulator/Debugger beschrieben. (Das sind Dateien mit der Endung "atdf"). Darin stehen u.a. die Registeradressen. Der Pfad ist "packs\atmel\*\atdf\*.atdf" (der Stern steht für den uC). Such einfach mal darin nach den Registernamen und vergleiche die Angaben mit der H-Datei bzw. mit dem Datenblatt. Vermutlich ist da eine Abweichung. Was die Adressen 0x2c und 0x4c betrifft, so sind ein Teil der Peripherieregister sozusagen unter zwei verschiedenen Adressen und mit zwei verschiedenen Befehlen (In/Out vs. LD/ST) zu erreichen. Lies bitte mal im Datenblatt den Abschnitt "5.2 Data Memory (SRAM ) and Register Files" dazu.
Hi Theo, vielen Dank für deine Aufschlussreiche Antwort. Im .h File seht „0x2C“ und im .atdf File „0x4C“ (stimmt auch mit dem DB überein). Also habe ich mir nochmal die tn1634def.inc angeschaut und siehe da: hier liegt der Hund begraben. Es waren nicht nur die Adressen für das USI falsch, sondern auch noch die CompareB Register falsch Adressiert. Im Anhang nochmals eine Korrigierte Version, für alle die ebenfalls auf dieses Problem stoßen!
Das habe ich noch nicht verstanden - USICR steht für 0x2a, woher kommt dieses 2c bzw. 4c?
Gabriel M. schrieb: > Hi Theo, vielen Dank für deine Aufschlussreiche Antwort. > [...] Gerne geschehen. Schön, dass Du Dich bedankst. Mein Nick ist allerdings "Theor" mit 'r' am Ende. :-)
Pardon, aber das muss jetzt sein!
DAS WORT ZUM MONTAG
Meine Damen und Herren!
Wir alle haben unsere Sorgen und Nöte und lassen uns nicht mit billigem
Trost über die Last des Alltags hinwegtäuschen. Aber als ich neulich in
meiner Musikbox blätterte, da stieß ich auf folgende kleine Zeile:
"Theo, wir fahr'n nach Lodz".
Nun, was wollen uns diese Worte sagen? Da ist von einem Menschen die
Rede.
Von einem ganz bestimmten Menschen. Nicht Herbert, nicht Franz, nicht
Willy,
nein, Theo ist gemeint. Aber um welchen Theo handelt es sich? Ist es
nicht
jener Theo in uns Allen? Jener Theo, der in so wunderbaren Worten
vorkommt,
wie Theologie, Theodorant, Tee oder Kaffee. Und an diesen
geheimnisvollen
Theo ist eine Botschaft gerichtet:
"Theo, wir fahr'n nach Lodz".
Vier fahr'n. Da sind also vier Menschen unterwegs. Und wer sind diese
vier?
Sind es die Vier Jahreszeiten? Die vier Musketiere? Oder sind es vier
alle? Schweigt Brüder. Da fällt mir in diesem Zusammenhang eine
Geschichte ein. Ich besuchte neulich einen Freund. Einen Millionär. Der
glaubte, der unglücklichste Mensch der Welt zu sein, weil ihm sein
Rasierpinsel ins Klo gefallen war. Da nahm ich ihn beiseite und
sprach: "Freilich bist du übel dran, daß dir dein Rasierpinsel ins Klo
gefallen ist. Aber es gibt Leute, die viel schlechter dran als du.
Die haben
noch nicht einmal einen Bart. "Da fiel es ihm wie Schuppen aus den
Haaren.
Und sollte nicht auch einer von uns, oder morgen, oder heute, oder
vielleicht
nicht. Wer weiß.
Schönen guten Abend.
Entschuldigung, den Autor vergessen (aber ist ja eigentlich klar): Otto Waalkes
S. Landolt schrieb: > Das habe ich noch nicht verstanden - USICR steht für 0x2a, woher kommt > dieses 2c bzw. 4c? Nur ein unglücklich gewähltes Beispiel für die Tatsache, dass bestimmte Register zwei verschiedene Adressen haben. Einen Zusammenhang mit einen bestimmten Register hatte ich absichtlich nicht hergestellt, Die Tatsache, dass man nach dem Kontext vermuten könnte, dass ich mich auf ein konkretes, vom TO genanntes Register bezog, habe ich schlicht nicht berücksichtigt.
Nein, ich meinte die Tatsache, dass in dem eingangs gezeigten AtmelStudio-Bild links der Befehl 'out USICR,r16' steht, rechts aber 'USIDR' rot markiert ist und auch unten im Flash 0x2c adressiert wird.
Aufschlussreich wäre, wenn Gabriel sein altes, fehlerhaftes tn1634def.inc auch noch hier einstellen würde.
S. Landolt schrieb: > Nein, ich meinte die Tatsache, dass in dem eingangs gezeigten > AtmelStudio-Bild links der Befehl 'out USICR,r16' steht, rechts aber > 'USIDR' rot markiert ist und auch unten im Flash 0x2c adressiert wird. Da passen offensichtlich die Part-Definitions, die der Assembler gesehen hat nicht zu denen, die der Simulator/Debugger sieht. Da lt. Screenshot für den Simulator/Debugger das korrekte Target gewählt wurde, bleiben zwei Fehlermöglichkeiten: 1) Ein Bug in den Partdefinitionen des Simulators/Debuggers. 2) Der Assembler bekam nicht die richtigen Partdefinitionen zu sehen (ob das der Fall war, kann man dem Screenshot leider nicht entnehmen) Ich würde mal stark auf 2) tippen. Das korrekte Partdefinitonsfile ist nämlich zumindest nicht sichtbar im Quelltext eingebunden. Spannend wäre die Frage, wie der Assembler es trotzdem geschafft hat, das Symbol USICR irgendwie in eine IO-Adresse zu verwandeln. Normalerweise gibt das Mecker...
Übrigens habe ich hier noch eines vom August 2011, keine Ahnung, worin der Unterschied zu dem vom Mai besteht.
an c-hater Es muss doch eigentlich 2) sein, sonst stände im Flash 'bd 0a', oder?
S. Landolt schrieb: > Aufschlussreich wäre, wenn Gabriel sein altes, fehlerhaftes > tn1634def.inc auch noch hier einstellen würde Bittesehr S. Landolt schrieb: > Übrigens habe ich hier noch eines vom August 2011, keine Ahnung, worin > der Unterschied zu dem vom Mai besteht. Vielen Dank für die neue Version, sie scheint in Ordnung zu sein. Es wundert mich, dass ich eine veraltete Version habe, obwohl ich extra AS geupdatet habe aber nun denn...
> Bittesehr ... DEFEKT_tn1634def.inc
Okay, hier wurde der USI-Bereich gründlich durchgemischt.
Dass allerdings in beiden Dateien 'THIS IS A MACHINE GENERATED FILE
... Created: 2011-05-12 14:38' steht, ist ... - nun ja, zumindest
ausgesprochen irritierend. Als ob sich jemand einen schlechten Scherz
erlaubt hätte.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.