Attiny 15+Assembler-Problem

[Paul Baumann (Gast)]

Hallo
Ich verzweifle hier an einem Tiny 15, den ich probehalber mal mit 
angehängtem Programm laufen ließ, weil er mit dem Programm von gestern:
Beitrag "Hilfe zu AVR-Assembler-Befehl"
nur Unsinn machte.

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.

gequält GRINS

Kompiliert habe ich mit AVR-Studio 3.54. Kann es sein, daß ich im 
AVR-Studio irgendwo die Taktfrequenz angeben muß, oder habe ich einen 
Riesendenkfehler?

MfG Paul

[Stefan B. (stefan)]

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)]

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

Das hat mir das Datenblatt gesagt.

MfG Paul

[spess53 (Gast)]

Hi

Deine Verzögerung müsste etwa so aussehen:

start: ldi r18,4
Takt1: ldi r19,66       ;Zähle nacheinander die Register herunter
Takt2: ldi r20,201
Takt3: dec R20
       brne takt3
       dec r19
       brne Takt2
       dec r18
       brne takt1

      .....

      rjmp start

MfG Spess

[Paul Baumann (Gast)]

@Spess53
Wenn ich Deine Werte nehme komme ich auf 1,6Mhz/4/16/201=124,3Hz ?!

Ich habe in meinem Programm so gerechnet:1,6Mhz/255/255/24=1,02Hz.

Trotzdem werde ich mal Deinen Rat befolgen.

MfG Paul

[Falk B. (falk)]

@ 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).

;**********************************************************
.include "Tn15def.inc"    ; Definitionen f r ATTiny15
.def temp = r16      ; temp als Universalregister definieren
.Def Blinkinhalt=R17
.Def Teiler1=R18
.def Teiler2=R19
.def Teiler3=R20
.def Vergleicher=R21
;**********************************************************

.cseg
.org0
  rjmp  RESET     ; Reset Marke

RESET:
; hier gehts los

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

Anfang:
  ldi  r17,1    ; LED Muster
  ldi  r18,5    ; Wartezähler
Takt3:
  ldi  r19,255
Takt2:
  ldi  r20,255
Takt1:
  dec  r20         ;Z hle nacheinander die Register herunter
      brne  Takt1       ;um bei 1,6Mhz 1Sekunde zu erzeugen

  dec  r19
      brne  Takt2

  dec  r18
      brne  Takt3

Ausgabe:
  out  portb,r17
      lsl  r17
      rjmp  Anfang

MfG
Falk

[spess53 (Gast)]

Hi

Die Taktzahl in der Schleife von mir errechnet sich wie folgt:

Takte= r18*(3+r19*(3*r20))

und die Verzögerung:

  Takte/1600000 Hz

Deine Formel stimmt nicht!

MfG Spess

[Paul Baumann (Gast)]

@Spess
Gut, das versuche ich morgen mal.

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

Staunend
Paul

[Hannes L. (hannes)]

@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 (Gast)]

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

[Hannes L. (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

[Kai G. (runtimeterror)]

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

ldi  r18,5    ; Wartezähler
...
ldi  r20,255

in

ldi  r18,10    ; Wartezähler
...
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

[Werner B. (Gast)]

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). Da kann man nicht dran drehen.

[Falk B. (falk)]

@ 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

[Hannes L. (hannes)]

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. (Gast)]

@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 "+/-".

[Karl H. (kbuchegg)]

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.

[Hannes L. (hannes)]

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...

...

[Kai G. (runtimeterror)]

>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.

[Karl H. (kbuchegg)]

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.

[Paul Baumann (Gast)]

Hallo Männer!
Ich habe mich jetzt noch einmal drangesetzt und das Programm so 
geändert,
daß es ein Lauflicht erzeugt. Das macht es im Simulator auch, aber im 
realen Leben erzeugt mir das Scheißding mit konstanter Bosheit ein 
Rechtecksignal mit 5V Amplitude von 50Hz, egal an welchem Ausgang. ;-(((

Ein weiterer, neuer Tiny15 tut das Gleiche. Wenn dieses Dreckding nur 
ein wenig SRAM hätte, könnte ich mit Bascom drangehen, das würde die 
Sache erheblich erleichtern. Es dauert ziemlich lange, ehe ich das böse 
Wesen bekomme, aber das Ding hat es geschafft. :-((

Trotzdem danke ich Euch für Eure Hilfen und Anregungen, ich muß erst aml 
etwas essen.

MfG Paul

[Paul Baumann (Gast)]

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.

MfG Paul

[Kai G. (runtimeterror)]

>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.

[Hannes L. (hannes)]

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

...

[Falk B. (falk)]

@  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

[Karl H. (kbuchegg)]

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 :-)

[Paul Baumann (Gast)]

So, jetzt habe ich die Nerven verloren und die beiden Tinys mittels 
ELM-Chan-HV Programmer auf Werkseinstellung zurückgesetzt, obwohl sie 
beide
neu waren. Dann habe ich das letzte Programm von 13.54 Uhr ohne 
Änderung,
denn Fehler fand ich nicht mehr wieder mit dem anderen Programmer 
gebrannt.
Um Fehler beim Laden auszuschließen, habe ich den 2. Tiny mit dem 
HV-Programmer geladen und sie "über Kreuz" noch einmal eingelesen.

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

Schlußfolgerung:
1. Bin ich nicht irrsinnig ;-))
2. Waren die Dinger entweder schon mal benutzt oder dei 
Werkseinstellungen
   sind neuerdings andere.

So, jetzt kann ich mich auf das eigentliche "große" Programm (siehe 
erster
Beitrag) stürzen, um zu sehen, was da los ist.

Tief  durchatmend
Paul :-))

[Kai G. (runtimeterror)]

>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...

[Kai G. (runtimeterror)]

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

Glückwunsch!

[Paul Baumann (Gast)]

Danke!
MfG Paul

[Falk B. (falk)]

@ 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

[Hannes L. (hannes)]

@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.

...

[Falk B. (falk)]

@ 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

[Hannes L. (hannes)]

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

...

[Peter D. (peda)]

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

[Falk B. (falk)]

@ 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

[Paul Baumann (Gast)]

Geschafft! Auch das andere Programm, was ich eigentlich "beim Wickel" 
hatte, läuft jetzt auch.
@Hannes
Ich lese mit Ponyprog auch erst mal den Prozessorinhalt ein, um zu 
sehen,
ob alles richtig ist. Dummerweise habe ich nicht im Kopf, wie die 
Originaleinstellungen der Fuses sind, so daß ich davon ausgegangen bin,
daß das richtig drinstand. (Beide Tinys hatten die gleichen 
Einstellungen)

Das ist mir noch nie passiert, lehrt mich aber, immer vorher ins 
Datenblatt
zu gucken, was denn vom Hersteller als Original vergesehen ist.

Meine beiden Programmiergeräte sind Eigenbauten, einmal die Variante für 
die serielle Schnittstelle und Ponyprog und dann noch ein HV-Programmer 
nach Elm-Chan_org. Diese Biester haben mir noch nie Ärger gemacht.

Assembler ist zwar ein "hartes Brot", aber wenn es dann mal 
funktioniert,
vergißt man den Ärger, zumal es ja weniger am Programm als am Professor 
lag. ;-))

Trotzdem bleibt BASCOM meine erste Wahl bei AVR's mit SRAM, weil ich 
dort
mühelos Variablen definieren kann.

MfG Paul

[Paul Baumann (Gast)]

@Peter
Ich habe hier noch ein paar davon gehabt und wollte sie verwenden. So 
schön klein würde ich meine Schaltung mit anderen AVR's nicht kriegen.
Ich habe es auch irgendwo gelesen, daß die Tiny15 nicht mehr für 
Neuentwicklungen verwendet werden sollen, aber es ist doch nur für mich
zu Hause.

MfG Paul