Hallo zusammen, ich lese schon einige Zeit in diesm Forum mit und habe auch schon kleine Programme auf ATMegas erstellt. Nun möchte ich auch einmal eine Anfängerfrage in das Forum stellen. Ich hoffe ihr könnt mir helfen. Bei der Programmierung in Assembler versuche ich die Variablen soweit als möglich in den Registern zu halten. Damit dies übersichtlich bleibt teile ich die Variablen bei der Definition am Anfang der ASM-Datei in verschiedene Gruppen ein: Grundsätzlich unterscheide ich ersteinmal zwischen globalen und lokalen Variablen. Beide Gruppen teile ich weiter in Variablen von "asynchronen" und "synchronen" Programmteilen (also ISR und Hauptprogramm/Unterprogramme). Dadurch kann ich recht einfach sehen, welche Variablen (oder besser Register) ich ohne vorheriges Sichern einfach in der ISR oder dem Unterprogramm als Hilfsvariable werwenden kann. Hier im Forum habe ich dafür den Begriff Scratch-Register gefunden. Nun würde ich diesen Registern per DEF-Direktive gern selbsterklärende Namen zuweisen. Da die Scratch-Register in den unterschiedlichen Routinen unterschiedliche Aufgaben übernehmen, sollen sie auch unterschiedlich (also mehrfach) benannt werden. Der Assembler übersetzt die Programme zwar ordentlich, allerdings bekomme ich für die doppelte Definiton der Register Warnungen: J:\Projekte\Sign.asm(52): warning: Register r21 already defined by the .DEF directive J:\Projekte\Sign.asm(54): warning: Register r15 already defined by the .DEF directive J:\Projekte\Sign.asm(55): warning: Register r21 already defined by the .DEF directive Ich verwende den AVRASM, AVR macro assembler 2.1.42 (build 1796 Sep 15 2009 10:48:36) Ich würde diese Warnungen für den DEF-Block der Scratch-Register nun gerne unterdrücken. Allerdings möchte ich die Warnung nicht ganz abschalten, da sie an anderer Stelle durchaus auf einen Fehler hinweisen kann. Leider habe ich dazu nichts in der AVRASM-Dokumentation finden können. Gibt es eine Möglichkeit meinen Wunsch zu realisieren? Mir würde schon ein Link mit einem groben Hinweis wo ich die Information finden kann helfen. Schon mal vielen Dank für Eure Hilfe. Frank
Ich mach das immer so:
; partly usable registers R0-R15
.DEF rglastcmd = R13 ; holds received and checked comand
.DEF rgtadrA = R14 ; left half of ir address to listen to
.DEF rgtadrB = R15 ; right half of ir address to listen to
; fully functional registers R16-R25
.DEF rgtmp = R16 ; tmp
.DEF rgtmp2 = R17 ; tmp
.DEF rgtmp3 = R18 ; tmp
.DEF rgi = R19 ; various counters
.DEF rgrxbitcount = R20 ; bit receive counter
.DEF rgrxbytecount = R21 ; byte receive counter
.DEF rgrxtmp = R22 ; rx shift register
.DEF rgrxstart = R23 ; 0 if no start occured, 1 if start was
received
.DEF rgtransip = R24 ; 1 if transfer to µc is in progress, 0 if not
; bit1 holds flag for next bit to write
; upper half is used as bit counter
rg davor um register schnell im code zu erkennen.
tmp sieht man gleich was es ist, kommt man nicht durcheinander mit
mehreren Namen für ein register, für temporäre Sachen und Parameter für
kurze Routinen.
Dazu noch Zähler, Status bytes und Konstanten, je nach Bedarf :)
Kommentare nicht vergessen und insbesondere die Funktion der temporären
register gut dokumentieren...
Hi Ich bin in 13 Jahren AVR-Assemblerprogrammierung ohne 'defs' oder sg. 'Scratchregister' ausgekommen. Und werde es auch weiterhin. 'defs' mögen bei kleineren Programmen die Anschaulichkeit verbessern, bei grösseren Programmen ist es eher lästig. MfG Spess
@ Niels Unwichtig leider hilft das Frank nicht weiter ihm geht es um die Unterdrückung der warning Hinweise und leider kann ich auch nicht helfen ich lebe einfach mit den warning Hinweisen (und übersehe sie) mich interessiert eigentlich nur die tabellarische Zusammenfassung am Ende - bin notorisch am Anschlag mit dem Flash-Speicher. :-) wann gibt es endlich ATtiny4313?
Frank Richter schrieb: > Dadurch kann ich recht einfach sehen, > welche Variablen (oder besser Register) ich ohne vorheriges Sichern > einfach in der ISR oder dem Unterprogramm als Hilfsvariable werwenden > kann. Oh, Oh... das kann aber eine böse Falle sein! Funktionen/Unterprogramme sollten immer so sein das sie möglichst rückwirkungsfrei seind, d.h. der Aufrufer hat danach alles wie es vorher war (Rückgabewert ausgenommen). Wenn du nämlich ein Unterprogramm hast was ein anderes aufruft (oder eine ISR die ein Unterprogramm aufruft) und jeder geht davon aus er kann machen was er will... gibt es ganz sicher Datenmatsch.
Also ich habe damals mit dem 8085 angefangen, in Maschinensprache zu programmieren, da gab es nur einen Accu, den Rest mußte man sich selbst ausdenken. Wenn man bedenkt, daß 16 universell ohne Einschränkungen verwendbare Register an sich doch recht wenige sind, wenn es um eine "richtige" technische Verwendung eines AVR gehen soll, so kommt man doch schnell an den Punkt, wo man den Überblick über die unterschiedlichen Verwaltungsverhältnisse unterschiedlicher Register(gruppen) verliert - soweit meine Meinung und Erfahrung: Ich verwende in allen Fällen eine Accu (R16), dann brauche ich mir nur um ihn Gedanken machen, wenn mal was nicht läuft. Bedenkt man, daß die Hilfsmittel arg beschränkt sind (die Simulatoren des AVR-Studio sind doch eher Dreck - wie will man z. B einen rxd-bedingten Interrupt eines USART auslösen: geht nicht, nur über Umschreiben der ISR und call aus dem Hauptprogramm!!), bleibt oft nur der eigene Speicheroszi, ein paar Aus- und Eingänge und ein Display, um Programme zu debuggen. Mir ist schon bewußt, daß der Accu die Vorteile des RISC-Prozessings zunichte macht, aber praktisch ist er allemal und man muß nur ihn verfolgen, wenns mal "hängt". Wie oben schon von anderen empfohlen: Eine genaue Dokumentation/Kommentierung ist wohl das wichtigste. Leider bietet AVR-Studio da auch keine wirklichen modernen Hilfmittel an, wie z. B. "Merkzettel"-Fensterchen oder Info-Fenster, wo man sich Funktion/Verwendung an einer betreffenden anderen Stelle im Text ansehen könnte, um die aktuelle Zeile zu verstehen. Ich persönlich halte inzwischen nicht mehr viel von den AVRs und der vom Hersteller zur Verfügung gestellten Entwicklungsumgebung, es wirkt und ist "billig", der tatsächliche Aufwand muß vom Entwickler/Hersteller betrieben werden - und das paßt einfach nicht mehr in diese Zeit!
Hi >wie will man z. B einen rxd-bedingten Interrupt eines >USART auslösen: geht nicht, nur über Umschreiben der ISR und call aus >dem Hauptprogramm!!), Wenn man keine Ahnung hat, sollte nam sich mit solchen Meinungen zurückhalten. Im obigen Fall hilft ein einfacher Klick auf das RXC-Bit im UCSRA-Register und schon wird der Interrupt ausgelöst. Und wenn du zu einem ganz konkreten Zeitpunkt (oder mehreren) haben willst erstellst du ein Stimuli-File. MfG Spess
Einer der Gründe, warum ich auf C umgestiegen bin. Da werden die Register/der Speicher automatisch und möglichst ideal verwaltet. Mehr Zeit sich auf die wirklich wichtigen Sachen zu konzentrieren.
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.