Attiny 15+Assembler-Problem

Deine Schleiferei bei Takt 1-3 braucht ohne das Laden der Register 1071 
Takte. Das erscheint mir sehr wenig für ein Däumchendrehen von 1s egal 
bei welcher Taktrate. Ich schätze jemand wollte die Schleifen 
schachteln, aber hat das nicht gemacht.

Ansonsten ist noch ein Denkfehler im Programm:

Wenn die Schleifen durchlaufen wurden, werden in gewissen Fällen alten 
Schleifenzähler vom letzten Mal benutzt (abängig von R17). Und die 
wurden ja vorher schön runtergezählt... bei den der Vorbelegung 255 (0) 
geht das fast gut; bei 24 (0) nicht.

Wie bekommst du eigentlich eine F_CPU von 1,6 MHz?

@ Paul Baumann (Gast)

>Ich verzweifle hier an einem Tiny 15, den ich probehalber mal mit
>angehängtem Programm laufen ließ, weil er mit dem Programm von gestern:

Dein 3. ASM Programm ? ;-)

>Resultat: Das Blinkprogramm erzeugt eine Frequenz von 100Hz! (Mit
>Oszillograph angeguckt)

>Das läßt darauf schließen, daß der Tiny15 mit 160Mhz statt 1,6Mhz läuft.

Spitze! Den würde ich für teuer Geld auf Ebay verticken.

>gequält GRINS

:-0

>AVR-Studio irgendwo die Taktfrequenz angeben muß, oder habe ich einen
>Riesendenkfehler?

Eher das.

Was du WILLST sind VERSCHACHTELTE Schleifen, um eine lange Wartezeit 
zu erreichen. Was du hast sind drei kurze Schleifen nacheinander. 
Uups. ;-)
Besser so (und gewöhn dir mal ne gescheite Formatierung an).

1

;**********************************************************

2

.include "Tn15def.inc"    ; Definitionen f r ATTiny15

3

.def temp = r16      ; temp als Universalregister definieren

4

.Def Blinkinhalt=R17

5

.Def Teiler1=R18

6

.def Teiler2=R19

7

.def Teiler3=R20

8

.def Vergleicher=R21

9

;**********************************************************

10

11

.cseg

12

.org0

13

  rjmp  RESET     ; Reset Marke

14

15

RESET:

16

; hier gehts los

17

18

    ser  temp         ; temp = FF

19

  out  DDRB,temp    ; Datenrichtungsregister f r Port B auf Ausgang schalten

20

21

Anfang:

22

  ldi  r17,1    ; LED Muster

23

  ldi  r18,5    ; Wartezähler

24

Takt3:

25

  ldi  r19,255

26

Takt2:

27

  ldi  r20,255

28

Takt1:

29

  dec  r20         ;Z hle nacheinander die Register herunter

30

      brne  Takt1       ;um bei 1,6Mhz 1Sekunde zu erzeugen

31

32

  dec  r19

33

      brne  Takt2

34

35

  dec  r18

36

      brne  Takt3

37

38

Ausgabe:

39

  out  portb,r17

40

      lsl  r17

41

      rjmp  Anfang

MfG
Falk

@Paul:

Von Warteschleifen halte ich nicht viel, besonders bei sooooo langen 
Zeiten. Ich hatte vor längerer Zeit mal einen Blinker auf Tiny12 für
Beitrag "Re: Modelbau"
programmiert, der allerdings etwas mehr macht, als nur zu blinken. 
Vielleicht gibt Dir die Analyse des Programms ja ein paar neue 
Denkanstöße. ;-)

Gruß in die Mitte Deutschlands,
Hannes

spess53 wrote:
> Hi
>
> Meine Hilfe für Paul bedeutet nicht, das ich solche Warteschleifen
> befürworte. Aber in diesem oder ähnlichen Fällen liegt meine Priorität
> im Erfolgserlebnis des Einsteigers. Vielleicht sollten auch einige
> andere auch mal daran denken, daß sie mit null Ahnung angefangen haben.
>
> MfG Spes

Paul fängt nicht bei null an, Paul hat schon einige ganz gute Programme 
in BASCOM geschrieben. Er kennt also einigermaßen die Hardware-Features, 
zumindest weiß er, dass es sie gibt und wo man Infos dazu bekommt. Nun 
zwingen ihn die kleinen (RAM-losen) AVRs aber zu ASM. Und da halte ich 
es schon für sinnvoll, ihm die Benutzung der vorhandenen (und bereits 
bezahlten) Hardware-Features aufzuzeigen.

Ja, auch ich habe mal bei null angefangen, aber mein erstes AVR-Programm 
(ASM, AT90S1200) hatte bereits einen Timer-Interrupt, dessen Nutzung die 
Programmierung erheblich vereinfacht hat.

Bit- & Bytebruch,
Hannes

Das Timing von Falks Code passt von der Größenordnung: 979220 Takte pro 
Update. Macht 0,61 s Verzögerung bei 1,6 MHz Systemtakt.

Allerdings funktioniert die Animation in dem Code nicht mehr.

(.org0 soll übrigens .org 0 heißen - Mein AVRStudio hat mich gerade mit 
einem Absturz freundlich drauf hinweisen wollen :( )

Wenn du noch

1

ldi  r18,5    ; Wartezähler

2

...

3

ldi  r20,255

in

1

ldi  r18,10    ; Wartezähler

2

...

3

ldi  r20,208

änderst kriegst du 0,999305625 s Verzögerung.

Wie taktest du den Controller eigentlich? Selbst gezüchtete 
Quarzkristalle? Geh erstmal sicher, dass das korrekt läuft und dass du 
mit dem Oszi richtig misst... irgendwas passt da nicht.

Warum benutzt du nicht den Timer? Timing über Warteschleifen lohnt sich 
nur bei zeitkritischen Aktionen oder wenn kein freier Timer mehr zur 
Verfügung steht. Beide Fälle sind in Anfängerprogrammen ziemlich selten.

Gruß

Kai

@ Paul Baumann (Gast)

>Dein Programm erzeugt mir eine Frequenz von 50Hz.
>Das ist alles sehr seltsam.

Nöö, ich war zu faul die Registerwerte auszurechnen ;-)
Ich hab nur die Struktur korrigiert.

@ Kai Giebeler (runtimeterror)

>(.org0 soll übrigens .org 0 heißen - Mein AVRStudio hat mich gerade mit
>einem Absturz freundlich drauf hinweisen wollen :( )

Jaja, ist nur fix hingetippt, ohne Syntaxcheck. :-0

MFG
Falk

Werner B. wrote:
> Info für alle die den ATtiny15 nicht kennen:
>
> Der wird mit mit einer fest vorgegebenen Frequenz von 1,6 MHz getaktet
> (+/- weil interner RC-Oszillator).

Das stimmt so nicht ganz. Der Tiny15 setzt beim Reset OSCCAL auf 0 
(siehe Datenblatt Seite 24, Initial-Value = 0). Er rennt also nicht mit 
1,6 MHz, sondern bedeutend langsamer. Um ihn mit 1,6 MHz rennen zu 
lassen, muss ihn das Benutzerprogramm calibrieren, indem es das 
exemplarabhängige Calibrationsbyte in das Register OSCCAL schreibt. 
Dieses exemplarabhängige Calibrationsbyte steht dem Benutzerprogramm 
aber nicht automatisch zur Verfügung, es muss mit dem ISP-Program vor 
dem "Brennen" aus dem Signature-Space (Adresse 0, H-Byte) des Tiny15 
ausgelesen werden.

>  Da kann man nicht dran drehen.

Da muss man sogar dran drehen, sonst läuft er zu langsam.

...

Werner B. wrote:
> @Hannes Lux
>
> Basistakt ist nach Datenblatt nun mal 1,6MHz und kann über eine Fuse
> nicht geändert werden (oder gar auf andere Taktquellen umgestellt). Für
> den Rest steht wie bei den anderen AVRs mit internem RC-Osc. das "+/-".

Wie's beim 15-er ist weiss ich nicht genau. Aber bei meinem
Tiny 12 ist es so, dass ohne Setzen des OSCCAL der Basistakt eher bei
700kHz liegt und nicht bei den spezifizierten 1.2Mhz.

Ohne OSCCAL zu setzen ist es eher sinnlos von irgendeiner
Taktfrequenz auszugehen oder gar damit Berechnungen anzustellen.

Werner B. wrote:
> @Hannes Lux
>
> Basistakt ist nach Datenblatt nun mal 1,6MHz

Aber erst nach Calibration des Oszillators!

> und kann über eine Fuse
> nicht geändert werden (oder gar auf andere Taktquellen umgestellt).

Das habe ich nie bestritten.

> Für
> den Rest steht wie bei den anderen AVRs mit internem RC-Osc. das "+/-".

Da machst Du es Dir aber einfach, denn der Rest ist nämlich verdammt 
wichtig. Der Tiny15 (auch Tiny12) läuft nämlich ab Werk ohne Zutun des 
Programmierers nicht mit dem im Datenblatt angehebenen "Basistakt", 
sondern bedeutend langsamer, da OSCCAL bei Reset mit 0 initialisiert 
wird und nicht, wie bei einigen moderneren AVRs, mit dem 
Calibrationsbyte. Das steht übrigens auch im Datenblatt...

...

>Ohne OSCCAL zu setzen ist es eher sinnlos von irgendeiner
>Taktfrequenz auszugehen oder gar damit Berechnungen anzustellen.

Auf 50 Hz kommt man damit aber trotzdem nicht... da ist noch was Anderes 
faul.

Kai Giebeler wrote:
>>Ohne OSCCAL zu setzen ist es eher sinnlos von irgendeiner
>>Taktfrequenz auszugehen oder gar damit Berechnungen anzustellen.
>
> Auf 50 Hz kommt man damit aber trotzdem nicht... da ist noch was Anderes
> faul.

Von welchem Code reden wir jetzt?

Mir geht es darum, bewusst zu machen, dass mittels OSCCAL nicht
nur kleine Korrekturen von vielleicht +/- 5 oder 10 kHz gemacht
werden. Der OSCCAL hat eine ordentliche Auswirkung! Kann mich
noch gut errinern, als ich meinen Tiny12 das erste mal Blinken
lies und die Zeiten alle vieeeeel zu lang waren. Durch Nachmessen
und Rückrechnen ergab sich dann anstelle der 1.2 Mhz (von denen
ich blauäugig ausgegangen bin) eine Frequenz von etwas unter 800kHz.
Da wurde mit erst bewusst, welchen Einfluss man mit OSCCAL hat
und wie wichtig es ist, diesen Wert zu setzen.

Der Satz ...

> Der wird mit mit einer fest vorgegebenen Frequenz von 1,6 MHz getaktet
> (+/- weil interner RC-Oszillator). Da kann man nicht dran drehen.

... suggeriert (zumindest für mich):
Im Prinzip sind das schon 1.6 Mhz. Ein paar Zerquetschete mehr oder
weniger könnens schon sein, aber das macht das Kraut nicht fett.

Und das stimmt ganz einfach nicht. Das +/- ist bei diesen Oszillatoren
durchaus erheblich.

>Von welchem Code reden wir jetzt?

Ich dachte, wir sind bei Falks Code angelangt... um mit dem auf 50 Hz 
Blinkfrequenz zu kommen, müsste der mit über 100 MHz getaktet sein.

Den Originalcode habe ich nicht durchgemessen...

OSCCAL reicht meines Wissens nach von 50% bis 200% der internen Taktung 
- kenne aber die Tinys kaum. Dass der Wert nicht von Werk aus kalibriert 
ist war mir z.B. neu. Bei den Megas ist das ja üblich.

Paul Baumann wrote:
> Nachtrag: Der Tiny15 sitzt auf einem Steckbrett, nur +Ub, Masse und über
> 470 Ohm eine LED an PB1 und +UB. 10k und 100n an PB5 (Reset) ändern
> nichts.

10k zwischen Reset und Vcc sollten schon sein, von 100nF an Reset halte 
ich persönlich nix, der Tiny15 hat BOD, der braucht das nicht. Aber 
100nF Keramik zwischen Vcc und GND solltest Du unbedingt einsetzen, wenn 
Du unkontrolliertes Verhalten vermeiden willst.

Ich habe Dein letztes Programm mal durch den Simulator gejagt, alle 1,22 
Sekunden (bei 1,6MHz Takt) schiebt es weiter. Es müsste also (halbwegs) 
funktionieren.

>
> MfG Paul

...

@  Paul Baumann (Gast)

>realen Leben erzeugt mir das Scheißding mit konstanter Bosheit ein
>Rechtecksignal mit 5V Amplitude von 50Hz, egal an welchem Ausgang. ;-(((

Kann es sein, dass das neue Programm gar nicht im Tiny landet? Lösch den 
Tiny mal und schau was er macht.

Versorgungsspannung OK? Was macht dein Programmieradapter wenn die 
Programmierung beendet ist?

>Sache erheblich erleichtern. Es dauert ziemlich lange, ehe ich das böse
>Wesen bekomme, aber das Ding hat es geschafft. :-((

Naja, ob ein Tiny mit 8 Pins das rechte Einstiegsmodell ist . . .???
Ein Mega8 kostet nichts und hat viele Pins.

MfG
Falk

Kai Giebeler wrote:
>>Von welchem Code reden wir jetzt?
>
> Ich dachte, wir sind bei Falks Code angelangt... um mit dem auf 50 Hz
> Blinkfrequenz zu kommen, müsste der mit über 100 MHz getaktet sein.

In der Tat.
50 Hz klingt für mich eher nach irgendeinem Problem in
der Stromversorung mit laufenden Resets. Schön im Takt
der Netzspannung :-)

>50 Hz klingt für mich eher nach irgendeinem Problem in
>der Stromversorung mit laufenden Resets. Schön im Takt
>der Netzspannung :-)

Mir schwant Schreckliches...

>Resultat: Das Programm LÄUFT!! und zwar auf beiden.

Glückwunsch!

@ Paul Baumann (Gast)

>2. Waren die Dinger entweder schon mal benutzt oder dei
>Werkseinstellungen sind neuerdings andere.

Oder du hast dir irgendwann mal aus Versehen die RSTDSBL Fuse gelöscht. 
Das kann auch duch falsch angelegte Versorgungspannung etc. passieren.

MFG
Falk

@Paul:

Wenn ich einen AVR mit dem Programmer verbinde, lese ich immer als 
erstes die Signature-Bytes ein, um die Verbindung zu überprüfen. Erst 
danach erfolgen Programmier-Zugriffe. Diese Gewohnheit hat mir schon so 
manchen Stress erspart.

...

@ Hannes Lux (hannes)

>Wenn ich einen AVR mit dem Programmer verbinde, lese ich immer als
>erstes die Signature-Bytes ein, um die Verbindung zu überprüfen. Erst
>danach erfolgen Programmier-Zugriffe. Diese Gewohnheit hat mir schon so
>manchen Stress erspart.

Eine gescheite Software prüft VOR der Programmierung automatisch ob 
der IC dranhängt, der im Projekt eingestellt ist.

MFG
Falk

Falk Brunner wrote:
> @ Hannes Lux (hannes)
>
>>Wenn ich einen AVR mit dem Programmer verbinde, lese ich immer als
>>erstes die Signature-Bytes ein, um die Verbindung zu überprüfen. Erst
>>danach erfolgen Programmier-Zugriffe. Diese Gewohnheit hat mir schon so
>>manchen Stress erspart.
>
> Eine gescheite Software prüft VOR der Programmierung automatisch ob
> der IC dranhängt, der im Projekt eingestellt ist.

Auch bei einer "gescheiten Software" ist dieses Vorgehen kein Nachteil. 
Ich denke mal, dass ich mit dem AVR-Studio eine "gescheite Software" 
benutze, denn ich gehöre nicht zu Denen, die das STK500 mit Ponyprog 
benutzen wollen.

>
> MFG
> Falk

...

Welchen Grund gibt es überhaupt, sich mit dem längst abgekündigten 
ATtiny15 abzugeben?

Der zur Zeit hergestellte funktionsgleiche IC heißt ATtiny25.

Vom ATtiny15 gibts bestenfalls noch Restbestände.


Peter

@ Peter Dannegger (peda)

>Welchen Grund gibt es überhaupt, sich mit dem längst abgekündigten
>ATtiny15 abzugeben?

Vor allem als Anfänger. Aber das hatten wir schon.

MFG
Falk