Hallo,
baue gerade die erste Schaltung für mich zusammen.
Ein Timer mit ATtiny 45 - 20 PU.
Der soll einen Transistor einschalten und nach einer bestimmten Zeit
wieder ausschalten. Die Zeit soll einstellbar sein.
Soweit klappt das auch alles noch ganz gut. Allerdings habe ich, wenn
ich 30 Sekunden einstelle eine Wartezeit von realen 25 Sekunden.
Mir ist klar, dass das keine Quarzuhr wird, aber ein Drift von 20%
erscheint mir dann doch etwas zuviel des Guten. Ist das normal?
Wen es interessiert, hier der Quellcode:
1
$regfile = "atTiny45.dat"
2
$crystal = 1000000
3
$hwstack = 10
4
$swstack = 10
5
$framesize = 20
6
7
Led Alias Portb.3
8
Transistor Alias Portb.2
9
Taster Alias Pinb.0
10
Langtaster Alias Pinb.4
11
12
Config Taster = Input
13
Config Transistor = Output
14
Config Led = Output
15
Config Langtaster = Input
16
17
Dim Zeit As Long
18
Dim Exitbit As Bit
19
Dim Count As Byte
20
Dim Faktor As Byte
21
22
Do
23
Zeit = 0
24
Exitbit = 0
25
If Taster = 1 Then
26
Gosub Settings
27
End If
28
Waitms 50
29
Toggle Led
30
Loop
31
End
32
33
Settings:
34
Led = 1
35
Waitms 200
36
Led = 0
37
Waitms 200
38
Led = 1
39
Waitms 200
40
Led = 0
41
Faktor = 0
42
While Exitbit = 0
43
Led = 1
44
Waitms 100
45
If Langtaster = 1 Then
46
Zeit = Zeit + 5000
47
Faktor = Faktor + 1
48
End If
49
Led = 0
50
Waitms 1000
51
If Taster = 1 Then
52
Exitbit = 1
53
End If
54
Wend
55
Exitbit = 0
56
Count = 0
57
Do
58
Toggle Led
59
Waitms 100
60
Count = Count + 1
61
Loop Until Count = 10
62
Waitms 1000
63
While Faktor > 0
64
Led = 1
65
Waitms 300
66
Led = 0
67
Waitms 300
68
Faktor = Faktor - 1
69
Wend
70
Waitms 1000
71
Count = 0
72
Do
73
Toggle Led
74
Waitms 100
75
Count = Count + 1
76
Loop Until Count = 10
77
Waitms 1000
78
Faktor = 0
79
While Exitbit = 0
80
Led = 1
81
Waitms 100
82
If Langtaster = 1 Then
83
Zeit = Zeit + 5800
84
Faktor = Faktor + 1
85
End If
86
Led = 0
87
Waitms 1000
88
If Taster = 1 Then
89
Exitbit = 1
90
End If
91
Wend
92
Count = 0
93
Do
94
Toggle Led
95
Waitms 100
96
Count = Count + 1
97
Loop Until Count = 10
98
Waitms 1000
99
While Faktor > 0
100
Led = 1
101
Waitms 300
102
Led = 0
103
Waitms 300
104
Faktor = Faktor - 1
105
Wend
106
Waitms 1000
107
Count = 0
108
Do
109
Toggle Led
110
Waitms 100
111
Count = Count + 1
112
Loop Until Count = 10
113
114
Transistor = 1
115
Led = 1
116
Waitms Zeit
117
Transistor = 0
118
Led = 0
119
Count = 0
120
Return
Aber irgendwie glaube ich nicht, dass das Problem im Code liegt... muss
ja nur waitms 30000 durchführen.
Dass das nicht 5000, sondern 5800 sind hat den Grund, dass nach 6
maligem Drücken des Tasters in der Schleife auch etwa 30 echte Sekunden
rauskommen.
Ist das normal? Wenn ja, gibt es dazu irgendwo Kurven, die die
Abweichung charakterisieren?
Grüße
Korbinian Geiger schrieb:> das nicht, aber geht aus der Fragestellung nicht hervor, was gemeint> ist?
Das ist aber relativ irrelevant.
Solange du keinen Timer einsetzt und statt dessen alles mit waitms
machst, darfst du dich nicht wundern, dass die Zeiten hinten und vorne
nicht stimmen.
Die einzelnen Anweisungen brauchen ja auch Zeit. Wieviel weißt du aber
nicht. Schlimmer noch, je nachdem welcher Pfad durchs Programm genommen
wird, ist das unterschiedlich, weil ja auch unterschiedliche Anweisungen
genommen werden.
Langer Rede kurzer Sinn: Du kommst um einen Timer nicht herum, wenn du
eine Uhr vernünftig bauen willst.
Warum nimmst du eigentlich nicht die in BASCOM bereits eingebaute Uhr?
Die würde einigermassen genau funktionieren.
Falls Du testen möchtest, ob da etwas in Deinem Code-Gewürge schief
läuft, oder etwas mit dem Takt nicht stimmt, schreib in 'ne Loop einfach
ein wait 30 und toggle damit 'ne Led.
Hast du mal überprüft wo Zeit beim delay Aufruf auch wirklich 30000 ist?
Wenn ja, dann ist der Compiler oder die Taktquelle -entschuldigen Sie
den Ausdruck- scheiße.
Die andere Frage ist: wie ist dein µC getaktet?
Wenn du da keinen Quarz drauf hast, sondern mit dem internen
Taktgenerator arbeitest, dann ist das eine weitere Fehlerquelle. Soo
genau ist der nicht. Sonst bräuchte man ja auch keine Quarze mehr.
Korbinian Geiger schrieb:> Mir ist klar, dass das keine Quarzuhr wird
Wenn das aber eine Uhr werden soll wird an einem Quarz kein Weg
vorbeiführen. Ich glaube kaum, dass man mit einem (internen)
RC-Oszillator eine genaue und langzeitstabile Uhr hinbekommt.
Genauere Zeiten gibt es mit externem Quarz/-oszillator und Verwendung
von Timern. Wait und Waitms sind Krücken, deren exesszives Anwenden zum
Humpeln führt. Angaben zur Genauigkeit des internen Oszillators gibt es
im Datenblatt. Wenn ich mich recht entsinne, sind unkalibriert schon mal
10% Abweichung von vorneherein drin. Abhängigkeit von Vcc und Temperatur
können ein Übriges tun.
Karl Heinz schrieb:> Warum nimmst du eigentlich nicht die in BASCOM bereits eingebaute Uhr?> Die würde einigermassen genau funktionieren.
Wo finde ich die, respektive, wo finde ich Informationen dazu?
Horst schrieb:> Hast du mal überprüft wo Zeit beim delay Aufruf auch wirklich 30000 ist?
Dazu dient der Teil hier:
1
While Faktor > 0
2
Led = 1
3
Waitms 300
4
Led = 0
5
Waitms 300
6
Faktor = Faktor - 1
7
Wend
Dieser lässt die LED so oft blinken, wie der Faktor für die
Multiplikation war.
Karl Heinz schrieb:> Die andere Frage ist: wie ist dein µC getaktet?
Wird das nicht durch $crystal vorgegeben? Also in dem Fall 1 MHz?
Korbinian Geiger schrieb:> Wird das nicht durch $crystal vorgegeben? Also in dem Fall 1 MHz?
NEIN, das wird von den Fuses und eventuell der externen Beschaltung
vorgegeben. Mit $crystal sagst du nur dem Compiler wie groß sie ist,
damit er z.B. die delay-Schleifen richtig berechne kann.
Max H. schrieb:> vorbeiführen. Ich glaube kaum, dass man mit einem (internen)> RC-Oszillator eine genaue und langzeitstabile Uhr hinbekommt.
Kommt darauf an, 1% und etwas weniger ist auf jeden Fall erreichbar.
Ist halt temperaturabhängig, aber von 20 bis 25 Grad funzt es. Wenn
es genauer sein soll, dann Quarz und Timer.
Korbinian Geiger schrieb:> Karl Heinz schrieb:>> Die andere Frage ist: wie ist dein µC getaktet?> Wird das nicht durch $crystal vorgegeben? Also in dem Fall 1 MHz?
Nein, damit teilst du nur dem Bascom mit, wie schnell dein µC wirklich
läuft (nicht laufen soll!). Bascom nimmt diesen Wert als Grundlage für
seine Berechnungen.
Wenn der µC also mit dem internen RC-Oszillator läuft (normal 8MHz) und
du im Bascom 1MHz angibst, dann weiß Bascom von den realen 8MHz nichts
und rechnet alles für einen Takt von 1MHz aus. Das heißt, dein Programm
läuft achtmal so schnell, wie es eigentlich soll.
Bitte glaub den anderen Leuten, die dir schon geraten haben, einen Timer
und einen Quarz für die Uhr zu verwenden.
Marc Vesely schrieb:> 1% und etwas weniger ist auf jeden Fall erreichbar.
Bei 0.5% wären es 7.2 Minuten Abweichung pro Tag, so etwas würde ich
nicht als Uhr verwenden wollen.
Karl Heinz schrieb:> Warum nimmst du eigentlich nicht die in BASCOM bereits eingebaute Uhr?> Die würde einigermassen genau funktionieren.
Vielleicht weil die Uhr einen 32768Hz Quarz am asynchronen Timer
benötigt und der Tiny45 das nicht hat?
Da ich an den Fusebits noch nichts geändert habe gehe ich von der
Werkseinstellung aus. Sollte also laut Datenblatt Calibrated internal
Oscillator mit "approximately" 8 MHz sein.
MySmartUSB hat noch den Haken bei "divide clock by 8 internally" drin.
Heißt das, dass der Rechentakt 1 MHz beträgt?
Korbinian Geiger schrieb:> Da ich an den Fusebits noch nichts geändert habe gehe ich von der> Werkseinstellung aus. Sollte also laut Datenblatt Calibrated internal> Oscillator mit "approximately" 8 MHz sein.>> MySmartUSB hat noch den Haken bei "divide clock by 8 internally" drin.>> Heißt das, dass der Rechentakt 1 MHz beträgt?
Ja. Aber du hast das 'appoximately' vergessen. Das sind nicht 8Mhz. Noch
nicht einmal annähernd. Dementsprechend sind das auch nicht 1Mhz,
sondern bei dir offensichtlich etwas mehr. Wenn es deiner Beobachtung
nach rund 20% sind, dann wird dein µC wohl mit sowas um die 1.2Mhz
getaktet. Also stell den Crystal Wert mal auf 1200000 und probier
nochmal. Mit ein wenig Glück könnte die Zeit dann sogar noch stimmen,
wenn die Heizperiode anfängt.
Nachtrag: Es soll keine Uhr werden, das ganze soll einen selbstgebauten
UV-Belichter steuern. Ich bin völlig zufrieden, wenn ich -sagen wir mal
5 Minuten- vorgebe und real 5 Minuten und 10 Sekunden rauskommen.
Es muss nicht ein Präzisionsmeisterwerk werden, aber etwa 2-3%
Genauigkeit hätte ich dann doch ganz gern.
Ich habe hier auch noch ATmega 8 und 16. Sieht es da mit interner Uhr
besser aus bzw. ließe sich damit was genaueres einstellen? Wenn ja, wie?
Der Eintrag zum Timer im BASCOM-Wiki ist leider sehr dürftig.
Korbinian Geiger schrieb:> Da ich an den Fusebits noch nichts geändert habe gehe ich von der> Werkseinstellung aus. Sollte also laut Datenblatt Calibrated internal> Oscillator mit "approximately" 8 MHz sein.>> MySmartUSB hat noch den Haken bei "divide clock by 8 internally" drin.>> Heißt das, dass der Rechentakt 1 MHz beträgt?
Nein :-) Das heißt, daß er "ungefähr" 1 MHz beträgt ("approximately")
Aber dein Rechenweg war schon richtig :-)
Korbinian Geiger schrieb:> Sieht es da mit interner Uhr> besser aus
Da war ich vorschnell. Auch die eingebaute Uhr kann sich ohne Quarz
keine genauen Zeiten aus den Fingern saugen. Jede Uhr steht und fällt
mit der Genauigkeit ihres Taktgebers. Ausgenommen Sonnenuhren.
"Wo nichts ist, hat der Kaiser das Recht verloren" sagt man in
Österreich.
Korbinian Geiger schrieb:> Ich habe hier auch noch ATmega 8 und 16. Sieht es da mit interner Uhr> besser aus bzw. ließe sich damit was genaueres einstellen? Wenn ja, wie?> Der Eintrag zum Timer im BASCOM-Wiki ist leider sehr dürftig.
Da gilt das gleiche.
Den internen Oszillator kann man nehmen, wenn gar nichts mit
irgendwelchen Zeiten gebraucht wird, sondern nur Ein- und Ausgangspins
bedient werden müssen, vielleicht noch LEDs angesteuert oder
irgendsowas. Dafür ist er gut. Aber sobald auch nur irgendeine Zeit ins
Spiel kommt, nimm einen Quarz.
Opfere die paar Cent für einen Quarz. Bei Reichelt kostet ein HC49 mit
10MHz z.B. 14Cent.
Gesetzt den Fall, ich nutze einen Quarz als Taktvorgabe.
Kann ich dann mit waitms noch die geforderte Genauigkeit von 2-3%
erreichen oder eher nicht?
Und wenn nicht: Wo kann ich denn mehr zu dem Timer nachlesen?
Max H. schrieb:> Ich würde dem µC einfach mit einem Quarz betreiben, das liefert mit> wenig Aufwand genaue Zeiten.
Das Problem beim Attiny45 ist aber, dass das 2 von 5 Pins kostet.
mfg.
Korbinian Geiger schrieb:> Kann ich dann mit waitms noch die geforderte Genauigkeit von 2-3%> erreichen oder eher nicht?
Spiel doch ein wenig mit OSCCAL ;-)
Oder schreib:
$crystal = 1200000
Korbinian Geiger schrieb:> Gesetzt den Fall, ich nutze einen Quarz als Taktvorgabe.> Kann ich dann mit waitms noch die geforderte Genauigkeit von 2-3%> erreichen oder eher nicht?
Ja. Auch BASCOM sollte annehmabr ausrechnen können, wie oft der µC
Däumchen drehen muss, damit sich das bei bekannter Daumen-Drehrate auf
eine bestimmte Zeit ausgeht.
> Und wenn nicht: Wo kann ich denn mehr zu dem Timer nachlesen?
Such dir ein BASCOM Tutorial. Das Kapitel Timer sollte eigentlich
überall enthalten sein.
Aber auch hier gilt: Auch der interne Timer des µC kann sich keine
exakten Zeiten aus den Fingern saugen.
Aber eigentlich will man nicht mit waitms arbeiten. Das macht Programme
so unflexibel. Denn während der µC in waitms Däumchen dreht, kann er
nichts anderes mehr machen - der zieht das Däumchen drehen gnadenlos
durch.
Mit einem Timer kann man das besser strukturieren, so dass der µC
bedienbar bleibt, während die Zeit abläuft. An der Genauigkeit der Zeit
ändert das aber nichts. Die steht und fällt mit dem Taktgeber. Und da
steht nun mal ein (unkalibrierter) RC-Schwingkreis gegen einen Quarz.
Korbinian Geiger schrieb:> Gesetzt den Fall, ich nutze einen Quarz als Taktvorgabe.> Kann ich dann mit waitms noch die geforderte Genauigkeit von 2-3%> erreichen oder eher nicht?>> Und wenn nicht: Wo kann ich denn mehr zu dem Timer nachlesen?
Hier wird alles sehr gut erläutert. Wie sie funktionieren, was es für
Betriebsarten gibt, wie man mit ihnen umgeht...
http://www.mikrocontroller.net/articles/AVR-Tutorial:_Timer
oder auch hier:
http://www.mikrocontroller.net/articles/FAQ#Timer
Was in der Bascom-Hilfe drinsteht, mußt du selbst mal nachschauen.
MWS schrieb:> Spiel doch ein wenig mit OSCCAL ;-)>> Oder schreib:> $crystal = 1200000
Bei OSCCAL braucht es einen externen Frequenzmesser, habe ich das auf
die Schnelle richtig verstanden? Habe ich aber nicht. Außer der im UNI-T
61E ist genau genug.
Wenn ich an $crystal rumspiele, wird die Genauigkeit schon besser.
Karl Heinz schrieb:> Such dir ein BASCOM Tutorial. Das Kapitel Timer sollte eigentlich> überall enthalten sein.>> Aber eigentlich will man nicht mit waitms arbeiten. Das macht Programme> so unflexibel. Denn während der µC in waitms Däumchen dreht, kann er> nichts anderes mehr machen - der zieht das Däumchen drehen gnadenlos> durch.http://halvar.at/elektronik/kleiner_bascom_avr_kurs/timer_counter/
Nach dem hier arbeite ich mich momentan vor. Timer kommen erst zum
Schluss. Aber da es offenbar in dem Fall ohne Timer nicht gscheit geht,
werde ich mich da mal einlesen.
Korbinian Geiger schrieb:> MWS schrieb:>> Spiel doch ein wenig mit OSCCAL ;-)>>>> Oder schreib:>> $crystal = 1200000>> Bei OSCCAL braucht es einen externen Frequenzmesser, habe ich das auf> die Schnelle richtig verstanden?
Nein, hast du falsch verstanden.
OSCCAL ist die Kalibrierung.
Willst du unbedingt 1000000 in dein Programm schreiben und der
eingebaute Schwingkreis läuft schneller/weniger schnell als diese
1000000 (eigentlich 8000000), dann kann man den Schwingkreis mit OSCCAL
verstellen.
Wie du dann rausfindest, ob du OSCCAL weit genug verstellt hast oder
nicht, das bleibt dir überlassen. Du kannst natürlich eine LED toggeln
lassen und das mit einem Frequenzzähler ausmessen. Du kannst auch im
Sekundentakt die LED umschalten und mit einer Armbanduhr mitstoppen, wie
lange 100 Toggler brauchen und so zurückrechnen ob und wie du OSCCAL
verstellen musst. Du kannst OSCCAL auch so lange verstellen, bis die
Zeiten annähernd richtig sind.
Wie du das machst bleibt dir überlassen.
Wichtig ist nur, dass die Zahl by CRYSTAL möglichst gut mit der
tatsächlichen Taktfrequenz des µC übereinstimmt. Ob du jetzt die
Taktfrequenz auf die Zahl hinziehst, oder die Zahl so veränderst, dass
sie der Taktfrequenz entspricht, ist (bei dir) egal. Übereinstimmen
müssen sie! Und das möglichst unter allen Bedingungen. D.h. auch dann
wenn es kälter oder wärmer wird.
> http://halvar.at/elektronik/kleiner_bascom_avr_kurs/timer_counter/> Nach dem hier arbeite ich mich momentan vor. Timer kommen erst zum> Schluss. Aber da es offenbar in dem Fall ohne Timer nicht gscheit geht,> werde ich mich da mal einlesen.
NOchmal:
Der Timer liefert die nicht mythisch irgendwie genaue Sekunden.
Mit dem Timer organisierst du dein Programm anders, so dass es bedienbar
bleibt, während die Belichtungszeit abläuft. Aber genauer wirds nicht.
Die Genauigkeit der Zeit hängt einzig und alleine von der Genauigkeit
der Taktquelle ab. Und von sonst nichts anderem (Programmfehler mal
aussen vor gelassen)
Korbinian Geiger schrieb:> Bei OSCCAL braucht es einen externen Frequenzmesser, habe ich das auf> die Schnelle richtig verstanden? Habe ich aber nicht.
Mit OSCCAl kann man den RC-Oszillator "ziehen", das geht auch ohne
Messgerät, durch die Versuch-macht-kluch Methode.
Karl Heinz schrieb:>> NOchmal:> Der Timer liefert die nicht mythisch irgendwie genaue Sekunden.> Mit dem Timer organisierst du dein Programm anders, so dass es bedienbar> bleibt, während die Belichtungszeit abläuft. Aber genauer wirds nicht.> Die Genauigkeit der Zeit hängt einzig und alleine von der Genauigkeit> der Taktquelle ab. Und von sonst nichts anderem (Programmfehler mal> aussen vor gelassen)
Wenn ich hier mal einen kleinen Einspruch machen dürfte? :-)
Der Vorteil eines Timers ist doch, daß er unabhängig von der Software
laufen kann und hardwaremäßig zählt. Das heißt, schon alleine durch
diese Tatsache bekommst du doch eine höhere Genauigkeit als mit der
delay-Methode, wo außerdem noch sämtliche Befehle mit ihrer Laufzeit in
die Zeitbestimmung eingehen. Das würde ich schon als genauer bezeichnen.
Ein Timer kann natürlich nicht besser sein als die Taktquelle, weil er
ja von dieser angesteuert wird. Er kann auf keinen Fall aus dem
RC-Oszillator einen Quarz machen (hinsichtlich Genauigkeit). Aber wenn
der Takt stimmt (Quarz), dann ist ein Timer schon um Größenordnungen
präziser als irgendwelche delays. Einverstanden, Karl Heinz? :-)
npn schrieb:> Wenn ich hier mal einen kleinen Einspruch machen dürfte? :-)> Der Vorteil eines Timers ist doch, daß er unabhängig von der Software> laufen kann und hardwaremäßig zählt. Das heißt, schon alleine durch> diese Tatsache bekommst du doch eine höhere Genauigkeit als mit der> delay-Methode,
ja. ok.
Lass uns mal bei einem Neuling nicht zu kleinlich sein und davon
ausgehen, dass ein waitms(30000) dann auch wirklich akzeptable 30
Sekunden erzeugt. Auf die eine oder andere Millisekunde soll es uns
nicht ankommen.
Wobei du natürlich absolut recht hast. Dagegen ist grundsätzlich nichts
einzuwenden.
Marc Vesely schrieb:> Thomas Eckmann schrieb:>> Wo beziehst du Ein-Pin-Quarze? Und wie schliesst man die an?>> An XTAL1 oder an XTAL2?>> XTAL1.>> mfg.
Und der andere Pin bleibt in der Luft hängen? Oder was soll das jetzt?
Thomas Eckmann schrieb:> Und der andere Pin bleibt in der Luft hängen? Oder was soll das jetzt?
Er meint vermutlich einen Oszillator und schämt sich das zu sagen :-)
Thomas Eckmann schrieb:> Und der andere Pin bleibt in der Luft hängen? Oder was soll das jetzt?
Bleibt ein ganz normaler Pin, genauso wie von ATMEL vorgesehen.
Marc Vesely schrieb:> npn schrieb:>> Er meint vermutlich einen Oszillator und schämt sich das zu sagen :-)>> Und du bist Gedankenleser ?
höchstpersönlich :-D
Marc Vesely schrieb:> Bleibt ein ganz normaler Pin, genauso wie von ATMEL vorgesehen.
Hast du irgendwelche modernen Pharmazeutika genommen?
Hier war von Anfang an von einem Quarz die Rede.
mfg.
Thomas Eckmann schrieb:> Meine Güte. Das Zeug , das du genommen hast, muss echt gut sein.
Ach, du meinst diese veralteten Dinger die man beim TINY25-85 und
TINY5-10 normalerweise nicht benutzt ?
Natürlich benutzen moderne Menschen sowas schon lange nicht mehr
bei 8 und 6-Beinchen.
Ein Bild für Unwissende ist angehängt.
Marc Vesely schrieb:> Natürlich benutzen moderne Menschen sowas schon lange nicht mehr> bei 8 und 6-Beinchen
Ach Vesy, YMMD.
Wir sind hier in der Elektronik. Und wenn es um Quarze geht, dann meinen
alle, sowohl die modernen Menschen als auch die ewig gestrigen, Quarze.
Wenn du über Quarzoszillatoren reden möchtest, dann sag das doch
einfach. Dann reden alle mit dir über Quarzoszillatoren.
mfg.
Thomas Eckmann schrieb:> Wenn du über Quarzoszillatoren reden möchtest, dann sag das doch> einfach. Dann reden alle mit dir über Quarzoszillatoren.>> mfg.
Nö, keine Lust.
Über Frauen, Fußball, Rennen ?
Ich hab jetzt einfach mal aus Jux und Tollerei ein ganz simples Programm
geschrieben, das eine LED toggelt.
Wenn ich waitms 100 setze, habe ich eine Frequenz von 5.09 (laut meinem
UNI-T), wenn ich dagegen waitus 10 setze, habe ich 49 khZ.
?!
Korbinian Geiger schrieb:> Wenn ich waitms 100 setze, habe ich eine Frequenz von 5.09 (laut meinem> UNI-T), wenn ich dagegen waitus 10 setze, habe ich 49 khZ.>> ?!
Frequenz ist waitms (oder waitus) * 2, wenn die LED 100ms (oder 10us)
ON ist und 100ms (oder 10us) OFF ist.
Nichts falsches dabei.
EDIT:
Wenn man die kleine Zeitabweichung ausser Acht lässt.
Korbinian Geiger schrieb:> Ich hab jetzt einfach mal aus Jux und Tollerei ein ganz simples Programm> geschrieben, das eine LED toggelt.> Wenn ich waitms 100 setze, habe ich eine Frequenz von 5.09 (laut meinem> UNI-T), wenn ich dagegen waitus 10 setze, habe ich 49 khZ.>> ?!
Ohne den neuen Jux Code zu sehen kann man das nicht beurteilen!
Wenn du mit deinem Uni-T (was soweit ich das bei Google sehen konnte,
ein günstiges Multimeter ist) eine Frequenz von ~5Hz mist, scheint es
doch in etwa zu passen. Denk daran, dass dein Uni-T kein Präzisionsgerät
ist. Also kleine Abweichungen sind hier sehr gut möglich!
Ich hab jetzt die 30s Realzeit mit 34053 ms im Programm ergänzt. Bei 5
Minuten Laufzeit komme ich jetzt auf einen Fehler von etwa 6s, das passt
schon.
Trotzdem sehr interessant zu erfahren, was es da für Probleme gibt.
Fließt ins nächste Projekt mit Sicherheit ein!
Korbinian Geiger schrieb:> Wenn ich waitms 100 setze, habe ich eine Frequenz von 5.09 (laut meinem> UNI-T), wenn ich dagegen waitus 10 setze, habe ich 49 khZ.
Das passt doch schon ganz gut. 2% Abweichung ist für den RC schon fast
Güteklasse A-. Solange du waitMs 10 meinst. Das Toggeln an sich
verbraucht ja auch noch ein paar Takte.
Mit einem Timer kommst du besser hin. Der toggelt, ohne zusätzlich Zeit
zu verbraten.
Der interne Oszillator ist werkskalibriert. Und zwar bei 3V und 25°C.
Unter diesen Bedingungen hat er eine Abweichung von ca. 1%. Über den
gesamten Temperatur- und Spannungsbereich sind es 10%.
Diesen Kalibrierwert, den Inalt des OSCCAL-Registers, kannst du mit
einem AVRISPMKII auslesen. Veränder den einfach im Programm und miss
dann nach. Solange die Spannung und die Umgebungstemperatur gleich
bleiben, kommst du damit auf brauchbare Werte.
Wenn du ihn nicht auslesen kannst schreibst du einfach:
OSCCal = OSCCAl +1; oder -1.
Und tastest dich ran. Also in C könnte man das so schreiben. Aber das
solltest du in Basic auch hinkriegen.
mfg.
Marc Vesely schrieb:> Das ist schon das zweite Mal. Beim dritten Mal gibts Freibier ?
Klar.
Aber wir werden sicherlich gegensätzliche Vorstellungen haben, wer für
wen bezahlt.
mfg.
Thomas Eckmann schrieb:> Aber wir werden sicherlich gegensätzliche Vorstellungen haben, wer für> wen bezahlt.>> mfg.
LOL.
Nein, ich bezahle für uns beide, keine Sorge.
In etwa zu erreichende Zeit-bzw.Frequenzgenauigkeiten:
-mit wait ist die Zeit ungenau, und das abhängig vom Ablauf des
Programms
Genauigkeit geht eigentlich erst unter Verwendung eines Timers, sodass
die Software nicht mehr die Zeitmessung beeinflusst.
-mit internal oscillator bekommt man maximal Fehler im
zehn-Prozent-Bereich
den kann man über crystalxxxx korrigieren, sodass wenige Prozent Fehler
bleiben.
-mit OSCCAL kann man den internen RC-Oszillator korrigieren und kommt
damit auf unter 2% Fehler, bei einigermaßen vernünftigen Teperaturen und
konstanter Spannung (Netzbetrieb mit Spannungsregler, wie 7805)
-mit Quarz kommt man von vornherein auf weniger als 0,1% Fehler, das
sind pro Tag etwa 100sec Fehler
- mit entsprechender einmaliger Frequenzkorrektur (Trimmer am Quarz
oder auf den Einzelquarz erfolgtem Abgleich mit crystalxxx) kommt man
auf etwa 5 sec je Tag
-bei regelmäßiger Korrektur (Software, "die genaue Zeit") kommt man auf
unter 1 sec pro Tag
Wenn ich gleich ein 8-MHz-Quartz nehme, kriege ich eh eine höhere
Präzision und kalibrieren muss ich dann auch nichts.
Ach was solls, ich nehm einfach ein Quartz und einen Timer und gut ist.
Wenn ich das Quartz da habe, wie muss ich die Fusebits setzen? Würde mir
den Tiny nur ungern schrotten!
Kann ich dafür einen Fusebitrechner benutzen wie den hier?
http://www.engbedded.com/fusecalc/
Damit komme ich zurecht.
Wird das ganze auf dem Steckbrett überhaupt funktionieren? Laut dem
Mikrocontroller-Tutorial muss ich die Kapazität des Ports und der
Leiterbahnen mit einbeziehen, wenn ich die Kondensatoren berechne. Der
vorgeschlagene Wert ist 5 pF. Ist das bei einem Steckbrett nicht sehr
viel mehr?
Das Datenblatt des 8-MHz-Quartzes sagt, dass die Load Capacitance 10-32
pF ist, ich bräuchte also laut Tutorial 59 pF.
Sind 56 pF auch in Ordnung, hätte der lokale Conrad grad da?
Timer-Code muss ich noch schreiben, kommt später.
Natürlich ist die Verwendung eines Timers etwas, das man einem totalen
Anfänger nicht zumuten kann. Timer zeigt da schon fortgeschrittene
Kenntnisse.
Aber, nicht vergessen: Ein Quarz (ver)braucht halt zwei Pins am
Kontrollerbaustein.
Bei so einfachen Funktionen wie Timer ist es oft ein Argument, dass man
ohne Quarz mit einer 8-pin-Version zurechtkommt.
Korbinian Geiger schrieb:> Ach was solls, ich nehm einfach ein Quartz und einen Timer und gut ist.
Man muß ja nicht die HC-49 Riesen nehmen. Es gibt auch welche in SMD
2*3mm².
Ich hatte auch überlegt, ob ich nicht auf Oszillatoren umsteige, aber
die 5V Typen sind am Aussterben. Oft werden nur noch 3,3V und 2,5V Typen
angeboten.
Peter Dannegger schrieb:> Ich hatte auch überlegt, ob ich nicht auf Oszillatoren umsteige, aber> die 5V Typen sind am Aussterben. Oft werden nur noch 3,3V und 2,5V Typen> angeboten.
.. und brauchen immer (zu viel) Strom.
Wenn schon fertiger Oszillator, dann TCXO. Die kosten nicht viel mehr.
Peter R. schrieb:> Aber, nicht vergessen: Ein Quarz (ver)braucht halt zwei Pins am> Kontrollerbaustein.
Dann sollte er eine Nummer kleiner nehmen: ATtiny44
Peter R. schrieb:> Natürlich ist die Verwendung eines Timers etwas, das man einem> totalen> Anfänger nicht zumuten kann. Timer zeigt da schon fortgeschrittene> Kenntnisse.
Das habe ich auch schon festgestellt seufz
Dann für das erste doch ohne Timer. Noch kommt es auf große Genauigkeit
nicht an. Mit nachjustieren der Zeitwerte komme ich jetzt bei 5 Minuten
Laufzeit auf +-3 Sekunden, was für einen Belichter wohl ausreichend
genau sein sollte. Eine Uhr kann man damit natürlich nicht bauen, will
ich aber auch noch gar nicht. Wäre aber sicher ein interessantes
Projekt, um mit Timern und Quarzen anzufangen. So eine LED-Uhr, wie man
sie am Eingang von U-Bahn-Tunneln sieht hätte ich schon gern. :)
> Aber, nicht vergessen: Ein Quarz (ver)braucht halt zwei Pins am> Kontrollerbaustein.> Bei so einfachen Funktionen wie Timer ist es oft ein Argument, dass man> ohne Quarz mit einer 8-pin-Version zurechtkommt.
Das wäre in dem Fall noch nicht das große Problem gewesen, denn ich bin
mir sicher, dass ich auch einen Weg gefunden hätte, die Zeit mit nur
einem Taster einzustellen, dann etwas weniger komfortabel, aber sicher
auch möglich.
Da das ganze nun mit einer für mich ausreichenden Genauigkeit
funktioniert, werde ich die Schaltung auf Streifenraster umsetzen und
bedanke mich ausdrücklich für die Anregungen, Erklärungen und den Input!
Fließt mit Sicherheit spätestens dann ein, wenn ich mich an die Uhr
setze.
Danke bis hierher, ich lese aber weiterhin mit, falls noch Anregungen,
Anmerkungen oder auch Kritik kommen sollten.
Korbinian Geiger schrieb:> Das wäre in dem Fall noch nicht das große Problem gewesen, denn ich bin> mir sicher, dass ich auch einen Weg gefunden hätte, die Zeit mit nur> einem Taster einzustellen, dann etwas weniger komfortabel, aber sicher> auch möglich.
Klar.
Langer Druck, kurzer Druck ?
Langer Druck = Funktion aufrufen.
Kurzer Druck = Wert verandern.
Oder umgekehrt.