Zeitschleife Mikrocontroller

[sisi]

eitschleife Mikrocontroller
Hallo Forumnutzer,

ich habe folgende Code für eine Zeitschleife aus AVR: http://www.mikrocontroller.net/artic...-Tutorial:_LCD

Längere Pause für manche Befehle
delay5ms: ; 5ms Pause
ldi temp1, $21
WGLOOP0: ldi temp2, $C9
WGLOOP1: dec temp2
brne WGLOOP1
dec temp1
brne WGLOOP0
ret ; wieder zurück


Was hier vorgeht, habe ich soweit verstanden. Jetzt möchte ich auch eine Zeitschleife für 5ms Pause von 16 Mhz (Attiny 26). Das Problem liegt bei der Bestimmung der Durchläufe. Kann mir jemand erklären, wie ich diese bestimmen kann? T=((1)/!6Mhz)= 65,2 ns-->(5ms)/(65,2ns)= 80000 Taktzyklen notwendig...weiter weiß ich nicht


Mfg

[Holomino]

Im Datenblatt des Controllers (PDF) findest Du in der Tabelle "Instruction Set Summary" in der letzten Spalte die Angabe der "Clocks". Das sind die Prozessorzyklen, die jeder Assemblerbefehl für seine Ausführung braucht. Für "ldi" z.B. 1 Zyklus, für "ret" 4 Zyklen.

Wo mehrere Werte angegeben sind (z.B. "brne") befragst Du die Assemblerhilfe für den jeweiligen Befehl.
Der Rest ist "aufaddieren" und ggf. in den Loops multiplizieren.

Der schnellere Weg: Wenn Du die Frequenz weißt, die die Routine vor der Anpassung verwendete, rechnest Du einfach ( so Pi mal Daumen) $C9 * alte Frequenz / 16MHz. Das passt dann nicht auf die Nanosekunde, lässt sich aber z.B. im Simulator später durch Variieren der beiden Loop-Werte noch verbessern.

[sisi]

danke für die schnelle Antwort..Ich muss dazu sagen, dass ich erst seit einer Woche mich mit Mikrocontroller und assembler befasse.

Also die Tabelle habe ich bereits angeschaut..
delay5ms: ; 5ms Pause
ldi temp1, $21--------------------------------------------------> 1 Takt
WGLOOP0: ldi temp2, $C9-------------------------------------> 1 Takt
WGLOOP1: dec temp2------------------------------------------> 1 Takt
brne WGLOOP1--------------------------------------------------> Sprung 2 Takte, sonst 1 Takt
dec temp1-------------------------------------------------------> 1 Takt
brne WGLOOP0--------------------------------------------------> Sprung 2 Takte , sonst 1 Takt
ret----------------------------------------------------------------> 4 Takte
Innere Schleife ( dec + brne = 3 Takte) ..... Jedoch weiß ich nicht wie ich nicht wie ich die 80000 Takte auf die drei schleifen verteilen soll. Also ich weiß nicht wie ich die einzelnen Durchläufe nun berechnen soll.....

MFG

[Holomino]

Jo, eine Woche ist vielleicht etwas knapp.
Du weißt aber schon etwas über Hexadezimalcodes (z.B. dieses magische $C9 ist eine 201)?

Es sind zwei Schleifen. Die innere
WGLOOP1: dec temp2------------------------------------------> 1 Takt
brne WGLOOP1--------------------------------------------------> Sprung 2
wird $C9, also 201 mal ausgeführt

201* 3 Takte = 603 Takte


Die äußere Schleife
WGLOOP0: ldi temp2, $C9-------------------------------------> 1 Takt
.//Innere Loop mit 603 Takten
.
dec temp1-------------------------------------------------------> 1 Takt
brne WGLOOP0--------------------------------------------------> Sprung 2

wird durch das vorladen von $21 in temp1 33 mal ausgeführt.
Du kannst also rechnen 33 * (4 + 603) = 20031 Takte

Wenn wir es ganz genau nehmen, musst Du jetzt noch Einsprung (z.B. jmp) und Rücksprung (ret) und den Takt für das Vorinitialisieren des temp1-Registers dazuzählen, das sind aber nur Peanuts.

Ich sage Dir also auf den Kopf zu: Das sind etwa 20000 Takte, die Routine war ursprünglich für 4MHz gebaut. Der Autor war ein Elektrotechnikingenieur der alten Schule ("ohne besondere Anforderungen reichen zwei Stellen nach dem Komma").

In der Praxis setz einfach ein $32 anstatt der $C9, dann klappst auch mit den 16MHz.

- - - Aktualisiert - - -

FALSCH FALSCH FALSCH: In der Praxis setze für die $21 eine $84 ein.
(ich hab's noch gemerkt)

[sisi]

Brauche ich da eigentlich nicht eine dritte schleife? Wie kommst du aus ($21= 33, $84=132 bzw $32=50)??

[Holomino]

Hatte ich ja fast geahnt, dass Du die Hexadezimalschreibweise nicht kennst.

Führende "$" oder "0x" vor Zahlen kennzeichnen im AVR Assembler die Hexadezimaldarstellung einer Zahl.

Statt der Zehnerbasis unseres herkömmlichen Zahlensystems verwendet diese die 16er-Basis. Mit der 16er-Basis stellst Du einen Bytewert mit 2 Stellen dar.
Die Praxis. Du zählst: 0,1,2,3,4,5,6,7,8,9, STOPP, jetzt kommt nicht 10, es geht weiter mit A,B,C,D,E,F, STOPP, jetzt kommt nicht G, weil mit "F" hast du eigentlich "15" gemeint, jetzt geht es weiter mit der nächsten Stelle, also 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 1A, 1B, 1C, 1D, 1E, 1F, 20,...
bei FF hast Du damit den höchstmöglichen Wert 255 für ein Byte erreicht.

Sinn dieses durchaus für Außenstehende völlig unverständlichen Machwerkes der Hexadezimalcodierung ist die Zusammenfassung eines Bytes (8 Bits) in zwei Zeichen. Du fasst dabei jeweils die unteren 4 und die oberen vier Bits zu einem Zeichen 0..F zusammen.

Witz des ganzen: Geübte rechnen Dir in Windeseile diese Hexadezimalzahlen in reale Zahlen um und auch wieder zurück, aber nicht nur dass: Am Zahlenwert 201 musst Du erst rechnen, ob das vierte Bit von unten gesetzt ist oder nicht. In der Hexadezimalschreibweise ist das ein Hingucken: 4tes Bit ist in der unteren Gruppe, also in der 9. 9 ist größer als 8, also ist die 8 gesetzt, also ist das vierte Bit von unten gesetzt.

Die Hexadezimalschreibweise ist also ein guter Kompromiss zwischen der normalen Ganzzahldarstellung (einzelne Bitwerte lassen sich nicht ablesen) und der Binärschreibweise (8 Stellen sind zu lang zum Schreiben)

Kleine Übung: Wenn Du's nicht verstanden hast (ich bin kein Lehrer), Google es woanders nach, aber spätestens dann müsstest Du mir sagen können, was die Zahl $AA in unserem Zahlensystem ist. Wenn Du das nicht drauf hast, brauchst Du mit Assembler nicht weiter zu machen. Das begegnet Dir so oft, da kann man sich kaum verweigern.

Die dritte Schleife brauchst Du nicht, weil du mit dem Zahlenbereich der äußeren Schleife hinkommst. Statt 20000 Takten willst Du 80000 Takte warten, daher kannst Du den Schleifenzähler $21 mit 4 multiplizieren, das macht dann $84.