Forum: Mikrocontroller und Digitale Elektronik AVR asm eigene Flags


von Thomas F. (tommy_fux)


Lesenswert?

Hallo,

bin Anfänger und versuche mich gerade an den AVRs. Ich benutze einen
Mega 8 und möchte mir eigene Flags defenieren aber wie?
Mein Versuch:

.DSEG
.equ Eigene_Flags = 0x0060
.equ Flag1 = 1
.equ Flag2 = 2
.equ Flag3 = 4
.equ Flag4 = 8

im Programm dann:

lds R16,Eigene_Flags ;die Flags laden

und dann entweder:

cbr R16,Flag2 ;die Flags löschen

oder

sbr R16,Flag2 ;die Flags setzen

aber macht man das auch so oder ist das der falsche Ansatz?
Würde mich über eure Hilfe freuen!

Gruß Tommy

von Karl-heinz D. (kalledom)


Lesenswert?

Beim PIC geht das:
Eigene_Flags  EQU  0x60
#DEFINE  F_OK  Eigene_Flags,0  ; Flag OK = 1 / nicht OK = 0
#DEFINE  F_Ret  Eigene_Flags,1  ; Flag CR
#DEFINE  F_Semi  Eigene_Flags,2  ; .....

von Michael U. (Gast)


Lesenswert?

Hallo,

der Ansatz ist völlig in Ordnung so.
Allerdings würde ich mir für die Flags ein Register reservieren,
speziell wenn diese häufig genutzt werden sollen, stört das ständige
lds/sts schon. Du mußt die Änderung ja auch wieder zurückspeichern und
zum Abfragen sowieso jedesmal die Flags mit lds in ein Register
holen...

Bei mir sieht es meist so aus:

.def FLAGS = r16

.equ FLAG_DTMF = 0
.equ FLAG_XYZ  = 1
.
.
.equ FLAG_ENDE = 7

Bitnummern statt Wertigkeiten (1,2,4,8...) zu benutzen, hat den
Nachteil, daß es dann eben sbr FLAGS,(1<<FLAG_DTMF) heißen muß,
dafür geht aber ein sbrs FLAGS,FLAG_DTMF problemlos.

Gruß aus Berlin
Michael

von Karl-heinz D. (kalledom)


Lesenswert?

Hallo Michael,

ist denn für die Bits/Flags FLAG_DTMF und FLAG_XYZ kein Bezug zum
Register-Namen FLAGS erforderlich ?

von Karl-heinz D. (kalledom)


Lesenswert?

Ja ja, ich seh schon, deshalb auch der Unterschied zwischen EQU und
DEFINE.
Der Bezug ist bei:
sbrs FLAGS,FLAG_DTMF
statt; also steht FLAG_DTMF nur für die zugewiesene Ziffer ?

Das bedeutet, ich kann Bit 0 in jedem beliebige Register über FLAG_DTMF
ansprechen ?

von Rolf Magnus (Gast)


Lesenswert?

Ja. FLAG_DTMF ist nix weiter, als eine Konstante mit dem Wert 0.
Bei den vordefinierten Flags ist das auch nicht anders. Deshalb muß man
aufpassen, nicht versehentlich ein Flag im falschen I/O-Register zu
verstellen.

von Michael U. (Gast)


Lesenswert?

Hallo,

möglich, daß es da oder dort Fehler vermeiden würde, wenn diese
Zuordnung per Direktive festgelegt wäre und der Assembler dann mault,
wenn ich sbi FALSCHES_REGISTER,(1<<FLAG_DTMF) schreiben würde.
Macht er aber nicht, muß ich eben selber aufpassen.
Ich könnte ja z.B. ein Macro definieren:

.macro set_dtmf
  sbr FLAGS,(1<<FLAG_DTMF)
.endmacro

Dann wäre der Zusammenhang gesichert und der Aufruf wäre nur noch
set_dtmf

Mache ich für sowas normalerweise nicht, so tippfaul bin ich nicht. :)

Ich könnte ja auch schreiben:

.dw  0b0110000000000001

Macht genau dasselbe, kann nur keine Sau lesen (außer dem AVR...).

Ich hoffe zumindest, ich habe das jetzt auf die Schnelle aus dem
AVR_Instr.pdf richtig codiert... ;)

Gruß aus Berlin
Michael

von Karl-heinz D. (kalledom)


Lesenswert?

Mein letztes Projekt mit einem Tiny 12, der einen PIC16F876 auf der
gleichen Platine überwacht, war 2001. Die 'Beiden' sitzen in einem
selbstüberwachenden FI-Schutzschalter und vertragen sich eigentlich
recht gut.
Aus vielerlei Gründen war mir der PIC damals etwas sympathischer, als
der Tiny und ein weiteres Projekt mit einem PIC hat mich dann ganz von
Atmel entfernt.
Da ich STK-200 und ST-500 habe und mir vor einem Jahr zwei
Experimentier-Boards mit ATMEGA16, LCD, etc. zugelegt habe, möchte ich
mal langsam wieder was mit AVR machen.
Für PIC bin ich mit MPLAB ICD1 und ICD2, sowie eigenen Platinen und
über 100 PIC16F877 (PLCC, TQFP und DIP40) etwas besser ausgestattet,
mich interessiert aber, was am AVR evtl. besser ist, als am PIC.
Deshalb horche ich ein wenig mit hier rein und frische meine
Gehirnzellen ein wenig auf.
Das mit dem EQU ist mir jetzt beim AVR wieder klar: Variablen.

von Philipp Burch (nicht einglogt) (Gast)


Lesenswert?

Ok, um mal die meiner Meinung nach grössten Nachteile der PICs gegenüber
den AVRs aufzuzählen:
- Takt wird intern durch vier geteilt (Bei den "gewöhnlichen" PICs
zumindest)
- RAM-Banking (spielt aber nur bei ASM-Programmierung eine Rolle)

von Karl-heinz D. (kalledom)


Lesenswert?

Der Takt wird beim 80C166 durch 2 geteilt (40MHz externer Oszillator,
20MHz Bus-Takt) und beim PIC durch 4; was ist da dran für ein Nachteil
? Dafür haben beide eine Pipeline-Befehls-Verarbeitung, also die
gleichzeitige Verarbeitung von 4 Befehlen; beim AVR weis ich es nicht.
Ich programmiere bei den µC ausschließlich in Assembler; mit dem
RAM-Banking und den Rom-Pages komme ich bestens zurecht, finde es für
bestimmte Dinge sogar angenehm (Schutz vor falschem Zugriff). Solche
'Sachen' gibt es auch bei den größeren µC (z.B. 80C166-Familie),
teilweise noch viel schlimmer. Das sehe ich nicht unbedingt als Vor-
oder Nachteil sondern mehr als angenehm oder unangenehm.
Nenn mir einen gravierenden Vor- oder Nachteil ?
Ich habe das Gefühl, daß die sich beide nichts tun; jeder hat da sein
Für und Wider, oder kleine (Un-) Annehmlichkeiten, an die man sich
schnell gewöhnt. Jeder Hersteller hat für 'seine' Marktlücke was
entwickelt und für uns Entwickler und Anwender ergibt sich mehr das
Problem: wer die Wahl hat, hat die Qual.
Was mir beim Tiny 'aufgestoßen' war, die begrenzte Stacktiefe von 4.
Daraufhin habe ich mein Konzept geändert und konnte dann damit leben.
Der PIC16F877 hat eine Stacktiefe von 8; auch nicht weltbewegend, vor
Allem, wenn man vom 80C166 kommt, ist das vollkommen ungewohnt.

von Michael U. (Gast)


Lesenswert?

Hallo,

vorneweg: ich kenne die PIC überhaupt nicht persöhnlich...
Gaaanz früher habe ich 6800, Z80, 6510 (im C64) nahe genug gekannt,
dann lange garnichts.
Irgendwann bin dann über die AVR gestolpert und dabei geblieben.
Ich stimme voll mit Dir überein, das jede Familie ihre Vor- und
Nachteile hat, dazu hat jeder irgendwann seine Vorlieben.
Die AVR erledigen wohl 90% ihrer Befehle in einem Taktzyklus.
Der Rest sind 2, maximal 3.
Das die kleinen Vertreter Einschränkungen haben, ist auch klar.
Ich benutze auch nur Assembler, schon weil ich wenig Lust habe, auf
meine "alten" Tage die Zeit mit dem Erlernen von C zu verbringen.
Das Thema Portierbarkeit steht für mich nicht, ist nur Hobby und die
Software ist ohnehin auf eine konkrete Hardware zugeschnitten.
Die AVR sind kompatibel genug untereinander, daß ich auf den nächst
"größeren" ausweichen kann, wenn es wirklich nötig ist.

Ansonsten habe ich auch ein STK200, hat bisher auch gut gereicht. Wenn
es über erste Tests hinausgeht, meist ein BreadBoard-Steckversuch oder
eine verdrahtete Lochrasterplatte. ISP kommt immer mit rauf, also auch
nur Kabel ran zum neu beschreiben.
Entwicklungsumgebung ist AVR-Studio, Simulator benutze ich selten bis
garnicht, komischerweise konnte ich mich schon früher gut in die CPU
"hineindenken" und finde Fehler so meist sehr schnell.
Programmieren mit PonyProg, hat mich bis jetzt noch nie im Stich
gelassen, auch wenn man bei den Fuses immer 3x hinschauen und
vergleichen muß, ob die Haken richtig stehen.

Gruß aus Berlin
Michael

von Rolf Magnus (Gast)


Lesenswert?

> Dafür haben beide eine Pipeline-Befehls-Verarbeitung, also die
> gleichzeitige Verarbeitung von 4 Befehlen; beim AVR weis ich es
> nicht.

Der AVR hat im Prinzip eine zweistufige Pipeline (1. Befehl holen, 2.
Befehl ausführen), damit er einen Befehl in einem Taktzyklus ausführen
kann.

> Was mir beim Tiny 'aufgestoßen' war, die begrenzte Stacktiefe von
> 4.

Naja, du hast dir halt einen der wenigen AVRs ausgesucht, die kein SRAM
haben. Nimm z.B. den Tiny13, dann hast du den Nachteil nicht. Der hat 64
Bytes SRAM, die du, wenn du willst, komplett für den Stack verbraten
kannt.

von Karl-heinz D. (kalledom)


Lesenswert?

@Rolf Magnus
Es gibt Dinge, bei denen hat man keine Entscheidungsfreiheit. Wenn das
Ganze dann auch noch ein Quereinstieg ist, weil alle das sinkende
Schiff verlassen haben, ist mit einem Tiny 12 der Erstkontakt zu Atmel
nicht gerade begünstigt.

Ich beklage mich ja nicht weiter da drüber, wenn man's weis, kann man
damit leben, wenn man's nicht weis, da muß man dann durch.
Wenn einer nicht schwimmen kann, ist NICHT die Badehose schuld :-)

@Michael U.
Dann sind wir vielleicht ein wenig Altersgenossen / Leidensgenossen und
liegen beide auf dem Schrottplatz der Überqualifizierten ?
Ja ja Z80, Z8000, 80C166, PIC, Tiny und die restliche Elektronik, da
läppert sich was zusammen.
Wenn das dann noch Stück für Stück der Nachwelt zu Verfügung gestellt
wird, kommen schon einige Internet-Seiten zusammen. Bin gerade mal bei
35 oder so: http://www.domnick-elektronik.de/elek.htm

von Michael U. (Gast)


Lesenswert?

Hallo,

@Karl-Heinz Domnick

gerade mal schnell über Deine Webseite gesurft, beachtlich, beachtlich!
Gleich mal "gebookmarkt". :)

Naja, bei mir ist die Schiene nur Hobby, meine Brötchen verdiene ich
mit etwas EDV-Administration und Hardware-Pflege in einer Firma mit
knapp 20 Filialen. Vielleicht bis zur Rente, sind aber noch ein 10
Jahre... ;)

Ansonsten bastle ich zwischendurch an meiner "Eierlegenden
Wollmilchsau":
http://www.mikrocontroller.net/forum/read-4-389541.html#new

Zwischenspiel ist eine Zählergeschichte für einen Bekannten, auf einer
Ausstellung soll die Laufzeit eines Videos (DVD) und die noch
verbleibende Zeit zum nächsten Neustart angezeigt werden.
Eigentlich wollte ich das gleich flexibel genug machen und vor allen
möglichst vollautomatisch (die DVDs produziert mein Bekannter selbst).
Im Moment ärgert mich der LM1881, der sollte die Bildimpulse abliefern,
hat aber überhaupt keine Lust dazu. ;)
Da der mich früher nie geärgert hat, vermute ich inzwischen, der ist
einfach kaputt.....

Gruß aus Berlin
Michael

von Karl-heinz D. (kalledom)


Lesenswert?

Hallo Michael,
da hast Du Dir ja was vorgenommen; find ich toll. Es sind ja noch 10
Jahre Zeit; wenn Du erst mal in Rente bist, hast Du keine Zeit mehr
:-)
Der analoge 'Kram' ist nicht so meine Welt, obwohl ich da manchmal
auch dran muß.
Mir liegt mehr das Steuern und Regeln, weniger das Messen, obwohl es
ohne Meßwerterfassung nicht geht.
So halt jeder hat sein Säcklein zu tragen ....
Grüße aus Großbüllesheim
Karl-Heinz

von Thomas F. (tommy_fux)


Lesenswert?

Hallo,

erstmal danke für die vielen Tips und Tricks.
Ich merke schon ich stehe noch ganz am Anfang.
Hätte da schon wieder eine Frage - warum macht man BYTE-Reserve?
.DSEG
 Var1: .BYTE 1
.equ Var1 = 0x60
Bei beiden Möglichkeiten kann ich doch in Var1 einen Wert speichern.
Wann macht man was? Könnt ihr mir bitte ein Beispiel geben?
Danke euch!

Gruß Tommy

von olfi (Gast)


Lesenswert?

Die erste Var1 ist eine Variable die Speicher im µC benötigt und durch
dein Programm geändert werden kann, z.B. kannst du sie als Zähler
verwenden.

die 2te ist eine Konstante, kann nicht geändert werden. Dein Assembler
ersetzt beim Übersetzen diesen "Platzhalter" durch den Wert 0x60.

Gruß, olfi

von Thomas F. (tommy_fux)


Lesenswert?

Hallo,

ich habe mich da falsch ausgerückt (sorry Anfänger halt) meinte wenn
ich im SRAM der Adresse 60 den Namen Var1 gleichsetze dann kann ich die
ja auch genauso als Zähler benutzen oder?
Bitte laßt mich nicht dumm sterben.

Gruß Tommy

von Michael U. (Gast)


Lesenswert?

Hallo,

um einen Wert im SRAM irgendwie zu ändern, mußt Du ihn erst in ein
Register laden und nach der Veränderung wieder im Ram speichern.
Zähler als Beispiel heißt ja den Wert um 1 erhöhen.
Im Register gibt es dafür INC rxx oder ADDI xx,1 usw.
Für Werte im SRAM geht das alles nicht, es gibt nur die Möglichkeit,
einen Registerinhalt ins SRAM zu speichern oder einen Wert aus dem SRAM
in ein Register zu laden.
Direkte logische oder arithmetische Befehle, die den Wert im SRAM
ändern, gibt es nicht.

Gruß aus Berlin
Michael

von Thomas F. (tommy_fux)


Lesenswert?

Erstmal danke für deine Erklärung - das man einen Wert im SRAM nicht
direkt verändern kann habe ich verstanden. Aber was ich noch nicht
verstanden habe ist wenn ich mit dem Label Var1 mir im RAM 1Byte
reserviere - wo im RAM steht das dann? Und ist das nicht genauso als
wenn ich z. B. der RAM-Adresse 0x60 den Namen Var1 gebe. Dann habe ich
mir damit ja auch 1Byte im RAM für die Var1 reserviert oder?

Tommy

von Willi (Gast)


Lesenswert?

.DSEG
.ORG 0x200
Var1: .Byte 2
Var2: .Byte 2
BufferA: .Word 12
BufferB: .Byte 44
;usw..

Das ist bequemer, portierbarer und leichter zu ändern
als selbst die Adressen auszurechnen
und mitzuzählen.

MfG Willi

von Kri (Gast)


Lesenswert?

@Willi: leichter zu ändern, wenn du nicht weisst, wie viel du speichern
willst ok. Aber der Vorteil von der direkten Adressierung ist, dass ich
weiss, wo das ganze steht. Bei vielen Variablen mit grösseren Blöcken
hast du keine direkte Kontrolle, wieviel du noch für den Stackpointer
über hast.

@Thomas:
Im Prinzip machst nichts anderes, als dass du einer SRAM-Adresse einen
Namen gibst (oder umgekehrt - je nach Ansicht). Um beim Beispiel zu
bleiben:

Statt LDS rxx,VAR1 oder STS VAR1,rxx
kannst du genauso schreiben:
      LDS rxx,0x60 oder STS 0x60,rxx

Der Vorteil liegt darin, dass du mit den Namen besser den Überblick
behaltest und ist im Prinzip nichts anderes wie ein Platzhalter, bei
dem der Assembler die definierte SRAM-Adresse einsetzt.

Vergleichbar mit URL und IP-Adressen.

von Willi (Gast)


Lesenswert?

Huch !!
Sorry, da hatte ich noch die Seite offen...

MfG Willi

Bitte 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
Noch kein Account? Hier anmelden.