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
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?
>Wie bekommst du eigentlich eine F_CPU von 1,6 MHz?
Das hat mir das Datenblatt gesagt.
MfG Paul
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
@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
@ 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
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
@Spess Gut, das versuche ich morgen mal. @Falk Dein Programm erzeugt mir eine Frequenz von 50Hz. Das ist alles sehr seltsam. Staunend Paul
@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
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
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
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.
@ 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. ...
@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 "+/-".
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.
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
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
>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 :-)
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 :-))
>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...
@ 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
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
@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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.