Frage zu meinem Blinker

ähm fehlt da nicht noch ein .ORG xxxx vor der Stackpointer 
initialisierung?

Andy11 schrieb:
> ja aber wieviele Warte Schleifen muss ich denn jetz noch hingeben

Mut du ausrechnen :-)

> wie dumm ist das, gibt es da keine andere möglichkeit?

Doch natürlich.
Aber lass dir Zeit. Das lernst du schon noch
(Der Weg führt über Timer)

Hubert schrieb:
> Mit welchem Takt betreibst du das STK500? Es kann sein, dass es für das
> Auge schlichtweg zu schnell schaltet. Im AVR-Studio kannst du den Takt
> des STK auf ein paar kHz absenken, dann könnte sich was andern.

Nicht!
Das gibt Ärger beim ISP flashen.

Auch wenn du im Prinzip recht hast ... wenn er das tut jagst du ihn in 
das nächste Problem rein.

Flo schrieb:
> Malpunkte zwischen den letzten Zahlen -.-

Nimm die Leerzeichen raus, dann interpretiert die Fornesoftware das 
nicht mehr als Fettdruck

  r16*256*256

(ICh weiß, das ist lästig. Ich finds auch doof)

Hubert schrieb:
> Das Studio meckert doch wenn der Takt zu langsam ist - Aber so kann man
> sich eine Vorstellung von der Schnelligkeit des AVR machen. Oder ISP
> geschwindigkeit anpassen.

Der ISP Takt darf max, 1/4 der µC Frequenz sein. Wenn er Pech hat, kann 
er den µC danach über ISP überhaupt nicht mehr ansprechen, sondern muß 
über High-Voltage Programming gehen. Hatten wir vor kurzen hier im 
Forum. Ein Schlauberger hat die CPU Frequenz soweit runtergedreht, dass 
es keine ISP Einstellung mehr gab, mit der er ihn hätte ansprechen 
können :-)

Andy11 schrieb:
> naja ok timer hört sich schon mal gut an, jedoch habe ich gedacht, dass
> ein timer bis maximal 1 Register zählen kann und das wären ja dann wohl
> wieder die 255

Der Sekundenzeiger deiner Uhr kann auch nur bis 59 zählen, und trotzdem 
kannst du damit Minuten, Stunden, ja sogar Tage stoppen. Wie machst du 
das?

> aber ich habe keine idee, wie ich so einen "timer realisieren könnte"
> gibts da ein paar vorschläge?

Ganz ehrlich:
Auch wenn ich ein großer Verfechter von Timern bin: Du solltest 
verstehen, warum deine kurze Schleife viel zu schnell abgearbeitet wird, 
was du dagegen tun kannst und vor allen Dingen, wie du ausrechnen 
kannst, wie lange ein bestimmtes Code Stück braucht.
Genau das ist nämlich einer der Vorteile von Assembler: Du hast 
Kontrolle über jeden einzelnen Taktzyklus (na ja ... fast)

Hubert schrieb:
> Aber das STK wird doch über die Serielle Schnittstelle angesprochen.

Ach?
Wusste gar nicht das das STK den Chip über die serielle Schnittstelle 
programmiert  :-)

Andy11 schrieb:

> ich habe wirklich schon viele aufgaben außerhalb assembler gemeistert,
> ich weiß aber echt nich wie ich das mach, mir fehlt einfach der
> Denkansatz

Es ist ganz einfach.
Überschlagsmässig kannst du davon ausgehen, dass jeder Befehl im AVR 
einen Taktzyklus braucht. Branch Befehle brauchen 2 Takte, wenn die 
Bedinung zutrifft

1

Zwischen:

2

  ldi r16, 255

3

4

Warte:

5

  dec r16                1 Takt

6

  cpi r16, 0             1 Takt

7

  brne Warte             2 Takt

Das heist: Ein Durchlauf durch die Schleife dauert 4 Takte. Durch r16 
machst du 255 Durchläufe durch die Schleife. Macht 255 mal 4 = 1020 
Takte.

Agenommen dein µC läuft mit 1Mhz. WIe lange dauert das dann?
Nun 1Mhz heist, dein µC hat in 1 Sekunde 1 Million Takte zur Verfügung. 
Du brauchst nur 1020. Diese 1020 Takte dauern daher

             1 Mio            1 Sekunde
             1020              x
           -----------------------------
                   1020 * 1
              x = ---------- = 0.00102 Sekunden
                   1000000

Solange dauert es daher, bis dein µC die Schleife 255 mal abgearbeitet 
hat. (Bei einer Taktfrequenz von 1Mhz)

Andy11 schrieb:

> in Bascom sag ich aber auch nur

Du musst dich jetzt entscheiden:
Soll dir BASCOM in Zukunft weiterhin alles abnehmen oder willst du 
selber für deine Verfehlungen verantwortlich sein und endlich mal deinem 
µC auf die Beinchen schauen, was der so treibt :-)

Man kann beides tun. So wie man Auto fahren kann, ohne sich um die 
Details des Motors kümmern zu müssen. Aber Autoschrauber wird man nur 
dann, wenn man einen Lötkolben am richtigen Ende anfassen kann und einen 
eine defekte Batterie nicht sofort die Schweißperlen auf die Stirn 
treibt weil man nicht weiß wo man die suchen muss ... und was zum Teufel 
macht die Batterie in meinem Auto und wie sieht die eigentlich aus.

Oder glaubst du, dass BASCOM was anderes macht um 1 Sekunde zu warten 
:-)

Andy11 schrieb:

> ist mir schon klar, es ging mir nur darum es auch vernünftig
> anzuschreiben in assembler

Wo liegt jetzt das Problem?
Du willst vielleicht eine Verzögerung von insgesamt 0.2 Sekunden.

0.00102 Sekunden hast du schon. Wenn du daher diese Konstruktion

  0.2 / 0.00102 = 196

mal ausführst, hast du die 0.2 Sekunden

1

Zwischen:

2

3

  ldi r17, 196

4

5

Warte1:

6

  ldi r16, 255

7

8

Warte:

9

  dec r16 

10

  cpi r16, 0

11

  brne Warte

12

13

  dec r17

14

  cpi r17, 0

15

  brne Warte1

OK. stimmt nicht ganz genau, weil natürlich die Bearbeitung von r17 auch 
seine Zeit braucht.

Du brauchst noch längere Zeiten?
Nun du hast noch r18, r19, r20 ..... und du kannst noch genügend viele 
Schleifen immer weiter drumherum bauen.

Wenn man 60 mal 1 Sekunde wartet, hat man in Summe auch 1 Minute 
gewartet :-) Will man 1 Stunde warten, dann wartet man eben 60 Minuten, 
wobei jede einzelne der Warteminuten dadurch entsteht, dass man 60 mal 1 
Sekunde wartet.
Eigentlich ganz einfach und stellt dich im realen Leben vor keinerlei 
Probleme.
BASCOM macht letzten Endes auch nichts anderes. Nur rechnet sich BASCOM 
eben still und heimlich aus, wie oft welche Teile wiederholt werden 
müssen, damit 1 Sekunde Wartezeit entsteht. Jetzt weißt du wie's gemacht 
wird. Vorher hast du dich nicht darum gekümmert :-)

Andy11 schrieb:

> aber hier habe ich auch 2* (255*4) Taktzyklen und das müsste dann
> 2040/1Mio = 2ms

Moment.
Bis jetzt war alles mehr oder weniger hypothetisch, weil du bisher deine 
Taktrequenz nicht bekant gegeben hast.

Und ausserdem wird der innerste Teil nicht  2*255 mal abgearbeitet, 
sondern 255*255 mal:
Das letzte Codestück zählt r16 von 255 bis 0 runter. Und das r17=255 mal

> lang sein und trotzdem ist der Unterschied deutlich zu
> erkennen

Welcher Unterschied?

Andy11 schrieb:

> kommt zwar beim 2ten Teil

welchen 2ten Teil. Die Schleifen sind jetzt ineinander geschachtelt!

Du hast den Code hier

1

Zwischen:

2

  ldi r16, 255

3

  ldi r17, 255

4

5

Warte:

6

  dec r16

7

  cpi r16, 0

8

  brne Warte

9

10

  dec r17

11

  cpi r17, 0

12

  brne Warte

13

ret

Ich markiere dir mal die Schleifen und rücke etwas ein

1

Zwischen:

2

  ldi r16, 255

3

  ldi r17, 255

4

5

Warte:              ; <---+<--+

6

    dec r16         ;     |   |

7

    cpi r16, 0      ;     |   |

8

    brne Warte      ; ----+   |

9

                              |

10

  dec r17           ;         |

11

  cpi r17, 0        ;         |

12

  brne Warte        ; --------+

wenn r17 um 1 runtergezählt wurde und noch nicht bei 0 angelangt ist, 
beginnt r16 erneut von 255 bis wieder 0 runterzuzählen. Daraufhin wird 
r17 wieder um 1 erniedrigt und r16 macht wieder seinen 255-er Drchlauf 
usw. usw. In Summe wird alse r16 insgesammt 255 mal (durch r17) von 255 
auf 0 runtergezählt.  256*256

Andy11 schrieb:
>> beginnt r16 erneut von 255 bis wieder 0 runterzuzählen
>
> aber wieso?? der Registerinhalt ist doch schon 0, würde der jetzt weiter
> runterzählen ist die Zahl dann negativ

der kann nicht negativ werden. Auf dieser Ebene gibt es so erst mal kein 
Vorzeichen. Nach 0 kommt wieder 255.

> ich sag ja dem register nicht, dass sein wert wieder 255 ist

nein.
aber wenn r16 0 ist und du machst einen dec drauf, dann ist r16 danach 
255

Genauso umgekehrt 255 + 1 -> 0

so schlecht war das mit der Uhr da weiter oben gar nicht :-) Nach 59 
kommt 0. Das geht immer so rundum.