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
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 ; .....
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
Hallo Michael, ist denn für die Bits/Flags FLAG_DTMF und FLAG_XYZ kein Bezug zum Register-Namen FLAGS erforderlich ?
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 ?
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.
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
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.
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)
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.
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
> 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.
@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
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
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
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
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
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
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
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
.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
@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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.