Assembler Zeitverzögerung

nop !?!?

WAIT

http://www.bretmulvey.com/avrdelay.html

Den Befehl Wait gibt es aber laut doc0856 von Atmel nicht...

Pascal schrieb:
> doc0856 von Atmel nicht...

Hast Du irgendwas von Atmel gesagt?

Seiphen machen sauber den Reiphen, geele!?

Da fällt mir ganz spontan ein daß ich meine Winterreiphen noch nicht 
montiert habe....

Pascal schrieb:
> eine Zeitverzögerung einprogrammieren?

Zählschleifen sind taktabhängig. DCF77 auswerten und nach xx Jahren 
kommt evtl. Dein Wert atomgenau (falls DCF77 noch verfügbar ist).
https://www.mikrocontroller.net/articles/AVR

EINEN Befehl gibt es bei den meisten µCs nur für das
Nichtstun über eine Befehlszykluszeit.
Der Name ist meist NOP (No OPeration)

Wenn es um mehr, als einige µs geht - und das Programm auch
noch mehr erledigen soll, ist es fast immer günstiger,
dafür einen Timer zu bemühen.

Variante 1:
Einen Timer darauf konfigurieren, dass er regelmäßig das
Programm jede ms o.ä. unterbricht (Interrupt). In der
Interruptroutine wird eine Variable, die man vorher auf die
gewünschte Verögerung in ms gesetzt hat, (falls sie nicht
schon NULL ist,) heruntergezählt und beim Erreichen von NULL
die LED ausgeschaltet, oder was da sonst gemacht werden soll...

Variante 2:
Einen Timer so konfigurieren, dass er nach x µs einen
Interrupt auslöst. In der Interruptroutine sperrt man die
folgenden Interrupts und schaltet die LED ....

Jacko schrieb:
> Nichtstun über eine Befehlszykluszeit.
> Der Name ist meist NOP (No OPeration)

Wenn man 2 Zyklen warten will, geht auch
goto $+1

oder

D8 nop ; Zyklen 8 warten
D8 nop ; Zyklen 7 warten
D8 nop ; Zyklen 6 warten
D8 nop ; Zyklen 5 warten
D4 return Zyklen 4 warten

Aufgerufen werden Sie mit call.

Ansonsten geht auch noch Schleifen runterzählen.
Ich habe mir Delay-Routinen (8MHz) gebaut mit 4-512 µS, 500µS-127,5 mS 
und 100ms-22,5 Sec (beinhaltet ein clrwdt)

Wenn der MCU zwischen durch was tun soll.
Kann man das ganez über Timer lösen. Man setzt dann ein Timeout und 
prüft Zyklisch ob es schon abgelaufen ist. Das geht mit und ohne 
Interrupt.

Da uns Pascal immer noch nicht verraten hat, um welchen Zeitbereich es 
sich handelt, ist raten oder spekulieren angesagt.

Vielleicht hilft dir ja das Programm "PicLoops"

>Vielleicht hilft dir ja das Programm "PicLoops"

Nachdem Pascal, im zweiten Anlauf verraten hat, dass es um Atmels geht, 
sollte alles, was mit "Pic" anfängt, vorsichtig angewandt werden.

Pascal hat sich jetzt ein neues Hobby gesucht, nachdem er gemerkt hat, 
dass Assembler doch nicht so einfach ist, wie er es sich gedacht hat. 
Der Arduino dient jetzt als Wurfgeschoss gegen diebische Elstern.

ASM Superprofi schrieb:
> Pascal hat sich jetzt ein neues Hobby gesucht, nachdem er gemerkt
> hat,
> dass Assembler doch nicht so einfach ist, wie er es sich gedacht hat.
> Der Arduino dient jetzt als Wurfgeschoss gegen diebische Elstern.

Ein Kumpel meintet das C Programmieren ist wie barfuß durch den Schnee 
zu laufen.
Dann ist der Definition nach Assembler Programmieren wie nackt durch den 
Schnee zu kriechen.

Wenn man denken kann wie ein MCU arbeitet ist ASM nicht mehr so 
kompliziert.

Ich würde auch ungern ARM ASM programmieren. Das ist dann eher 
Masochismus. Bei den Atmels macht es dann doch noch Spass. Man ist quasi 
in der ersten Reihe und bekommt bare metal alles mit. Ein riesengrosser 
Lerneffekt. Aber ich will jetzt keine unnötige ASM vs C Debatte starten. 
Beide Sprachen haben Ihren Anwendungsfall.

jannyboy schrieb:
> Ein Kumpel meintet das C Programmieren ist wie barfuß durch den Schnee
> zu laufen.
Er darf gerne versuchen einen kleinen 8bitter mit 2K Flash in Erlang zu 
programmieren :-)

> Dann ist der Definition nach Assembler Programmieren wie nackt durch den
> Schnee zu kriechen.
Ist doch nach der Sauna ganz nett.

ALLE Programmierspachen sind doof.
Wo bleibt der Simultanübersetzer der Forumgestammel in super effizienten 
ASM Code umsetzt ?

Michael K. schrieb:
> ALLE Programmierspachen sind doof.

Ich laufe gerne barfuß und nackt durch den Schnee.

jannyboy schrieb:
> Ich laufe gerne barfuß und nackt durch den Schnee.

Ist wie mit Assembler.

Man kommt nur langsam voran, stößt sich an jedem kleinen Stein und nach 
einer Zeit spürt man die Schmerzen nicht mehr was manche dahingehend 
interpretieren das man weder Schuhe noch motorisierte 
Fortbewegungungsmittel braucht.

Durch die bald einsetzende Hypothermie fühlt man sich richtig gut, sogar 
zu warm ist einem aber eigentlich befindet man sich nur auf dem Weg zum 
Sterbeprozess.

War in Mobys diversen Assembler Threads sehr anschaulich zu beobachten.

Nein nein, mach mal. Assembler ist der kleinste gemeinsame Nenner und 
besser kann man seine MCU nicht kennenlernen.
Später ist man dann froh wenn der Compiler einen riesen Klumpen Arbeit 
erledigt um den man sich früher selbst gekümmert hat.

Jobst M. schrieb:
> Das ist eben etwas für richtige, harte Männer, nicht für Memmen! ;-)
Du meinst die Typen die Bienen kauen statt Honig zu essen ?

Wegstaben V. schrieb:
> Jep, eine Fourier-Transformation in Assembler mit Bruchzahlen führt zu
> orgiastischen Glücksgefühlen, wenns dann mal perfekt läuft.
Chuck Norris schreibt sowas vor dem Frühstück.

Witkatz :. schrieb:
> Merksatz Das schönste an Assembler ist der Umstieg auf C

Für den der von guter Asm-Programmietung keine Ahnung hat. Die 
eigentliche Programmlogik umzusetzen ist mit C nicht einfacher als mit 
Asm.

Und hier noch eine Analogie: ^^

Assembler: Schraubenschlüssel, Hammer und Feile. Die Teile muss man 
zuerst mit der Feile "ausarbeiten", bevor man sie zusammenschrauben 
kann.

C: Fräse, Dreh- und Bohrmaschine. Feile nach bedarf.

C++: CNC und weitere Computergesteuerte Werkzeuge. Die muss aber auch 
bedienen können. Hand- und Elektrowerkzeuge nach bedarf. Feile ist in 
der Nähe.

Java/DOTNET/BASIC usw: LEGO und Fischertechnik. Vorgefertigte Teile.

:)

MfG,
Andreas

Hi

>Und hier noch eine Analogie: ^^

Ich habe selten solche dümmlichen Aussagen über Assembler wie in diesem 
Thread gelesen.

MfG Spess

>Java/DOTNET/BASIC usw: LEGO und Fischertechnik. Vorgefertigte Teile.

Oh man, was haben umfangreiche Frameworks mit der leistungsunfähigkeit 
einer Sprache zu tun, genau nichts?

Gruß J

Matthias S. schrieb:
> onesec:  ldi  del,second
> wozwait: push  del
> wwait3:  push  del
> wwait2:  push  del
> wwait1:  subi  del,1
> Bullshit
>   ret

Ist das hier ein Wettbewerb für die weltweit dümmsten Delayroutinen? Ich 
glaub mir wird schlecht.

1

; Warteroutine bei 8 MHz W x 2 µS + 2 µS  

2

Delay1

3

    movwf D1

4

5

    nop

6

    decfsz  D1

7

    goto $-2

8

    return

9

10

Delay50ms

11

    movlw .100

12

13

; Warteroutine bei 8 MHz W x 500 µS

14

Delay2

15

    movwf D2

16

    movlw .248

17

18

    call Delay1

19

    decfsz D2

20

    goto $-3

21

    return

22

23

; Warteroutine bei 8 MHz W x 100 mS

24

Delay3

25

    movwf D3

26

27

    clrwdt

28

    movlw .200

29

    call Delay2

30

    decfsz D3

31

    goto $-4

32

    return

33

34

D8    nop

35

D7    nop

36

D6    nop

37

D5    nop

38

D4    return

Achtung PIC-Code :D

Schlecht. Aber besser als die davor.

Natürlich werde ich meine NICHT posten. Aber den Aufruf einer guten 
Routine sieht so aus:

delayms 12345
oder, wenn man Mikrosekunden möchte:
delayus 12345

Reichweite von 1-65535. Genau so muss sowas aussehen und nicht anders.

Hi

>Genau so muss sowas aussehen und nicht anders.

ASM Superprofi. Das ich nicht lache.

MfG Spess

ASM Superprofi schrieb:
> Schlecht. Aber besser als die davor.
>
> Natürlich werde ich meine NICHT posten.

Das sind die richtigen erst große Klappe und dann kommt nix. Naja wer 
nicht programmieren kann... Kann ja nichts posten... Ich verstehe das.

Natürlich habe ich die Drecksroutine kapiert. Aber wer heute noch sowas 
abliefert, der hat doch nicht mehr alle Tassen im Schrank. So eine 
unnötige Stackquälerei. Von der Wartbarkeit reden wir besser gar nicht 
erst.

Aufgabe: Warte 325ms!

Ooooh, kaputt.

Aufgabe: Warte 5us!

Mist, geht nicht.

ASM Superprofi schrieb:

> Natürlich werde ich meine NICHT posten.

Ich meine auch nicht. Wäre mir einfach peinlich, so deutlich zu zeigen, 
dass ich mal relativ viel Lebenszeit damit verschwendet habe, sowas 
Sinnloses zu programmieren...

> Aber den Aufruf einer guten
> Routine sieht so aus:
>
> delayms 12345
> oder, wenn man Mikrosekunden möchte:
> delayus 12345
>
> Reichweite von 1-65535. Genau so muss sowas aussehen und nicht anders.

Nö. Meine verbraucht Takte und zwar absolut exakt die spezifizierte 
Menge davon (nennen wir sie mal: "n"). Und man kann ihr als Parameter 
0<=n<=2^32-1 übergeben. Will man irgendeine Zeiteinheit warten, übergibt 
man als Parameter irgendwas wie dieses: n/FCLOCK für Sekunden oder 
n/(1000.0*FCLOCK) für ms oder n/(10000000.0*FCLOCK) für µs. Es spricht 
natürlich auch garnix dagegen, für Leute, die nicht einmal solche 
simplen Sachverhalte nachvollziehen können, einen zusätzlichen Satz von 
Makros zu schaffen, die diese Trivialitäten dann auch noch vor dem 
völlig hirnlosen Benutzer verbergen, der dann irgendwo in der Region 
generischer C-C&Pler liegen würde...

Im Endeffekt hätte man dann ziemlich genau den Delay-Schwachsinn, den 
z.B. der avrgcc bietet. Der ist recht schick, weil recht 
resourcen-effizient umgesetzt. Natürlich nicht ganz so effizient wie 
meine Lösung, aber darauf bin ich ausnahmsweise einmal NICHT stolz. 
Denn beides ist gleichermaßen vollkommen verblödete, vollkommen 
sinnlose, absolut schwachsinnige Scheiße! (Und ich schäme mich, 
Lebenszeit in meine Lösung investiert zu haben, zumal ich es schon zum 
Zeitpunkt der Implementierung zumindest im Prinzip besser wusste...)

Der Punkt ist nämlich: Software-Delays an sich sind in den allermeisten 
Fällen vollkommener Schwachsinn. Jedenfalls immer dann, wenn ihre Dauer 
die Dauer eines Interruptframes des Zielsystems nennenswert übersteigt, 
sagen wir mal ganz grob: >Faktor 2..3.

Jegliche SINNVOLLEN Software-Delays lassen sich also beim 
AVR8-Zielsystem mit einer ziemlich kleinen NOP-Rampe mit etwas 
Macro-Magie für die ganz kleinen Zeiten abhandeln (die NOP-Rampe kam 
irgendwo im Thread auch bereits vor, bin jetzt zu faul, hochzuscrollen 
und nachzuschauen, wer sich da als ein Mensch mit Durchblick geoutet 
hat).

Alles andere ist sinnlose Beförderung der Entropie durch sinnlose 
Umwandlung von elektrischer Energie in Abwärme durch den sinnlosen 
Verbrauch von Rechenzeit. Wer sowas braucht oder zu brauchen glaubt, 
kann einfach nur nicht programmieren. That's all.

Es geht hier um ZEIT verzögerung, nicht um TAKT verzögerung. Dir ist 
der Unterschied anscheinend nicht klar. Anscheinend programmierst du 
Assembler. Das macht die Sache noch korioser. Du solltest wissen, dass 
es keine allgemeine Lösung für alle Probleme gibt und wenn man TAKTE 
abwarten muss, dann heisst der Befehl sicher nicht delayus x, sondern 
nops x!

Und ich glaube nichtmal du verwendest eine taktorientierte Routine, um 
z.B. eine LED 20ms lang einzuschalten.

Ob man dafür den Prozessor in eine nop-Schleife schickt oder in einen 
sleep-state, ist wieder ein ganz anderes Thema und lohnt sich umso 
weniger, je kürzer die Zeiteinheit ist.

Und wenn ich einmalig in der Initialisierungsphase 200ms warten muss, 
werde ich sicher keinen Timer programmieren, sondern die 200ms lang 
Däumchen drehen. Obendrein laufen die MCUs von GUTEN Programmierern 
immer in der niedrigstmöglichen Taktrate. Ich tippe mal darauf, dass die 
meisten C-Programmierer gar nicht wissen, was CLKPR macht, oder haben es 
einmal gesehen, sich gewundert, dass man es nicht beschreiben kann (muss 
kaputt sein!) und haben es dann vergessen.