mikrocontroller.net

Forum: Projekte & Code Schicke Delaymacros für AVR (ASM)


Autor: Lutz Lisseck (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mikki merten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lutz Lisseck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mikki merten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mikki merten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mikki merten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.