Wie man wirklich schön mit Macros Delays genau einstellbarer Länge in Assembler realisiert, nämlich <b>nicht</b> mit mehreren verschachtelten Schleifen, sondern nur mit einer Schleife, soll diese Datei mit einbindbaren Macros zeigen. Dies habe ich zusammengestellt aus einer noch dickeren delay.inc, die ich einst mal programmierte. Wenn Interesse an der etwas unübersichtlicheren, aber mächtigeren delay.inc besteht (die allerdings dann den kostenlosen avrterse [ http://www.elektronikseiten.de/avrterse/ ] statt avrasm benutzt), bitte kurz hier posten. Lutz Spamprotection: remove 0815 l.0815lisseck@gmx.de
Manchmal verstehe ich die Leute einfach nicht. Die sagen, ich nehme den AVR, weil der 8051 wir zu langsam ist und dann wird pure Rechenleistung nur mit Warten verheizt ??? Ich nehme Delays nur für sehr kurze Zeiten. Alles über 256 Taktzyklen wird besser mit einem Timerinterrupt gemacht. Ich suche ein Macro, dem ich einen Wert 1...255 übergeben kann und das dann ein Delay von exakt 1...255 Zyklen macht. Peter
Dürfte mit dem orginalen AVR Assembler nicht zu realisieren sein. Dieser kann ja bis heute kein IF ... THEN ... ELSE. Auf den IAR wollte ich nicht umsteigen, da dieser doch einige Umstellung in den Quellcodes erfordert und die komplette Entwicklungsumgebung nicht gerade preiswert ist.
Wer gerne If-Then-Else zur bedingten Kompilierung benutzen will, sich
gegenüber avrasm und dem avrstudio fast nicht umstellen möchte, der
sollte das oben erwähnte Avrterse mal ausprobieren. Es ist kostenlos und
man muss lediglich im Avrstudio angeben, die Datei statt mit avrasm mit
avrterse assemblieren zu lassen. Dann läufts nahezu wie gewohnt, nur mit
einem mächtigeren Assembler, der Macroverschachtelung, bedingte
Assemblierung etc. unterstützt.
Damit kann man dann auch das gewünschte Macro haben, das automatisch den
passenden Code für 0 - ca. 100 Zyklen Verzögerung generiert. Man braucht
nur unten stehendes Macro zu verwenden und lnop (basiert auf rjmp PC +
1) und delay_8Cycles (basisert auf einen rcall direkt zu einem nop + ret
=> 8 Zyklen) einbinden.
Lutz
;***********************************************************************
****
;* delay_XCycles
;***********************************************************************
****
;* Typ : Macro, Öffentlich
;* Kurzbeschreibung : Erzeugt nop, lnop, delay_8cycles - Kombinationen,
;* die mit möglichst wenig PrgMem X-Cycles verzögert
;* Eingabe : @0: Anzahl zu verzögernder Zyklen
;* Ausgabe : keine
;* Benutzte Register : 2 Byte Stacktiefe
;* Zyklen : @0
;* PrgMem-Verbrauch : Variabel, wird aber für X > 100 zu groß
;***********************************************************************
****
.macro delay_XCycles
; Verzögerungszyklenzahl in 8'er, 2'er und 1'er-Komponenten
; zerlegen
.set delay_XCInput = @0
.set Delay_XCFakt8 = ((delay_XCInput & $fffff8) / 8)
.set Delay_XCTempA = delay_XCInput - (Delay_XCFakt8 * 8)
.set Delay_XCFakt2 = ((delay_XCTempA & 0b1110) / 2)
.set Delay_XCFakt1 = delay_XCTempA - (Delay_XCFakt2 * 2)
.set Delay_XCTempA = (Delay_XCFakt8 * 8) + (Delay_XCFakt2 * 2) +
Delay_XCFakt1
.if (Delay_XCTempA != Delay_XCInput)
.echo "Trouble in Delay_XCycles!"
.endif
.set Delay_XCUsedWords = Delay_XCFakt8 + Delay_XCFakt2 +
Delay_XCFakt1
.if (Delay_XCUsedWords > 20)
.echo "Warnung: delay_XCycles verbrät mehr als 20 Words PrgMem!"
.echo "nämlich", Delay_XCUsedWords,"Words."
.endif
.count Delay_XCFakt8 ; 8'er NOP's
delay_8Cycles
.endcount
.count Delay_XCFakt2 ; 2'er NOP's
lnop
.endcount
.count Delay_XCFakt1 ; 1'er NOP's
nop
.endcount
.endmacro
Jetzt wird nicht nur Rechleistung verheizt sondern auch noch Programm Flssh. AVRterse hatte ich mir auch mal angesehen. Da die Aufrufparameter bzw. genrierten Dateien nicht ganz AVRASM konform sind, ist dieser keiner direkt Ersatz für diesen. Ich hab mich so an die komfortable Entwicklungsumgebung gewöhnt, die eine schnelle und komfortable Fehlersuche ermöglicht.
Ja, das if-endif habe ich schon sehr vermißt. Dann werde ich mal den avrterse probieren. Vielleicht hat der auch nicht mehr den .db-Bug. Peter
@peter Der .db Bug ist doch seit Version 3.54 beseitigt. Bei einer ungeraden Zahl von Bytes wird doch automatisch ein Null-Byte zusätzlich generiert. Ist ja immer Prinzip für die 16 Bit orientierte Architektur des Programm-Flash ja korrekt. Wieso dies aber zusätzlich noch einem Warning im Listing versehen wird, ist für mich auch nicht ganz verständlich. Allerdings ist bei der Version 3.55 als auch 4.05 der Warning Fehler in Verbindung mit MEGA323 und MEGA32 und LPM Reg,Z noch verhanden. Die MEGAs verfügen über diese Befehle, wird auch korrekt assembliert, trotzdem erscheint im Listing ein WARNING. Das ATMEL z.B. die IF...THEN...ELSE Direktive noch nicht implementiert hat, erscheint mir wohl ein Zugeständnis an die Anbieter von Entwicklungstools zu sein. Wenn die kostenlosen Tools bereits alles können, wer kauft dann noch etwas anderes.
Hallo Mikki, ich hatte den .db-Bug jahrelang bei jeder neuen Version an Atmel gemailt und irgendwann aufgegeben. Jetzt haben sie ihn also endlich doch noch korrigiert. Ich habe gerade Studio 4.00 installiert und da ist der Assembler 1.54 von November 2001 dabei. Das ist bestimmt der erste ohne den .db-Bug. Das mit den Warnungen ist wirklich nicht so toll, aber immer noch besser als falsch generierter Kode. Dieser Bug war das absolut hinterhältigste, was ich jemals gesehen habe. Ich glaube ich hatte damals über 2 Tage gebraucht, um dahinter zu kommen, warum ein völlig korrektes Programm immer wieder abschmiert. Das ganze restliche Studio brauche ich ja nicht und werde es nun wieder löschen. Peter
@peter Ging mir ähnlich. Atmel kriegt das mit den Revisions- ständen ebenfalls noch immer nicht auf die Reihe. Beim Studio 3.55 ist schon der AVRASM 1.55 mit dabei.
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.