Servus, nach einigen Jahren "Arduino-IDE", nun C(umsteiger) und
attiny-Einsteiger stehe ich vor dem Problem der Genauigkeit der attinys.
Kumpel fragte mich, ob ich das hinbekomme, ich sagte ja:
Nach Start/Reset sollen einige LEDs ~acht Stunden leuchten danach aus.
Gewünscht ist also nur: Nach Start entsprechend lange high danach
schlafen bis zum nächsten Reset.
Also das ganze mit einer LED getestet. Hier mein Code:
1
#include<avr/io.h>
2
#include<util/delay.h>
3
#include<avr/sleep.h>
4
5
intmain(void)
6
{
7
DDRB|=(1<<PB3);
8
PORTB|=(1<<PB3);
9
_delay_ms(60000);
10
PORTB&=~(1<<PB3);
11
12
WDTCR=0x0;
13
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
14
sleep_enable();
15
sleep_cpu();
16
sleep_disable();
17
}
18
// Schaltet die LED recht genau eine Minute ein...
Bis 2-3 Minuten passt das so. Wenn ich allerdings auf zB 60 Minuten
(3600000 ms) gehe, driftet es teilweise um bis zu +-7 Minuten ab.
Bei acht Stunden macht das vermutlich einiges aus. +- 15-30 Minuten ist
Akzeptabel. Ist das so ohne Quarz realisierbar?
Dein Programm läuft nur einmal, d.h. nach dem _delay_ms ist Schluss.
Und ein Delay ist niemals genau.
Die 8 Stunden mit einem Delay zu realisieren ist nicht zielführend.
Dazu gibt es Timer.
Beispiel:
1
ISR(TIMER0_COMPA_vect)// 1 ms Timer ISR
2
{
3
staticuint16_tcount=0;
4
if(++count>999){
5
systick=1;// systick is global (volatile)
6
count=0;
7
}
8
}
9
init_timer()
10
{
11
// initialize timer0
12
TCCR0A|=(1<<WGM01);// CTC Mode
13
TCCR0B|=PRESCALER0;// prescaler 1024 and CTC Mode
14
TCNT0=0;
15
OCR0A=(F_CPU/1024)-1// 1 ms at 1 MHz cpu clock
16
}
17
voidmain(void)
18
{
19
do{
20
if(systick){// do something every 1 second
21
22
.
23
.
24
systick=0;
25
}
26
}while(1);
Mit der count variable in der ISR kannst Du deinen Timer fein
einstellen,
falls die 1 MHz Takt der CPU nicht ganz 1 MHz sind.
Ist ein Weg wie man das machen kann, aber nicht der Wahrheit letzter
Schluss.
Bekanntlich führen viele Wege nach Rom.
Ahoi Codix,
Codix schrieb:> Dein Programm läuft nur einmal, d.h. nach dem _delay_ms ist Schluss.
Dass ist ja eigentlich auch das das Ziel. Einmalig durchlaufen und dann
schlafen/totstellen bis zum Manuellen Reset.
> Und ein Delay ist niemals genau.>> Die 8 Stunden mit einem Delay zu realisieren ist nicht zielführend.> Dazu gibt es Timer.
DAS dachte ich mir schon...
>> Beispiel:>
1
>ISR(TIMER0_COMPA_vect)// 1 ms Timer ISR
2
>{
3
>staticuint16_tcount=0;
4
>if(++count>999){
5
>systick=1;// systick is global (volatile)
6
>count=0;
7
>}
8
>}
9
>init_timer()
10
>{
11
>// initialize timer0
12
>TCCR0A|=(1<<WGM01);// CTC Mode
13
>TCCR0B|=PRESCALER0;// prescaler 1024 and CTC Mode
14
>TCNT0=0;
15
>OCR0A=(F_CPU/1024)-1// 1 ms at 1 MHz cpu clock
16
>}
17
>voidmain(void)
18
>{
19
>do{
20
>if(systick){// do something every 1 second
21
>
22
>.
23
>.
24
>systick=0;
25
>}
26
>}while(1);
27
>
28
>
>
Das werde ich später/morgen mal testen/umsetzen.
> Mit der count variable in der ISR kannst Du deinen Timer fein> einstellen,> falls die 1 MHz Takt der CPU nicht ganz 1 MHz sind.
Ich gehe mal fest davon aus, das der Takt halbwegs stimmt :-)
Wie geschrieben muss das nicht 100% korrekt sein. +- 2-5% reicht auf 8h
vollkommen aus.
>> Ist ein Weg wie man das machen kann, aber nicht der Wahrheit letzter> Schluss.> Bekanntlich führen viele Wege nach Rom.
Aber das ist aber ein weg, der mich in die richtige Richtung schubbst
:-)
Vielen Dank dafür!
Peter G. schrieb:> Dass ist ja eigentlich auch das das Ziel. Einmalig durchlaufen und dann> schlafen/totstellen bis zum Manuellen Reset.
Huh?
Warum nimmst Du nicht einen NE555 und baust ihn als One-Shot-Timer auf?
Es gibt genügend Literatur im Netz dazu, auch hier.
Mit dem NE555 kannst Du Verzögerungszeiten bis zu Tagen realisieren.
Da lohnt sich der Aufwand mit einem ATtiny eigentlich nicht.
Außer man will so etwas programmieren und dabei lernen.
Das ist nie falsch.
Codix schrieb:> Huh?> Warum nimmst Du nicht einen NE555 und baust ihn als One-Shot-Timer auf?> Es gibt genügend Literatur im Netz dazu, auch hier.> Mit dem NE555 kannst Du Verzögerungszeiten bis zu Tagen realisieren.> Da lohnt sich der Aufwand mit einem ATtiny eigentlich nicht.
Das war auch meine erste Idee. Dann kam aber:
"Mal flott umstellen auf 4 oder 12 Stunden...". Drum ist auch nen
ISP-Header eingeplant :-)
>> Außer man will so etwas programmieren und dabei lernen.> Das ist nie falsch.
Das kommt auch noch dazu. Ich will weg von "Arduino" hin zu reinen C.
Das fand ich einen guten Anfang dazu.
Peter G. schrieb:> Ich gehe mal fest davon aus, das der Takt halbwegs stimmt :-)
Der stimmt auch nur so halbwegs. Das Problem dürfte u.a. sein, dass er
auch mit der Temperatur driftet und von der Betriebsspannung des AVR
abhängt (siehe Datasheet). Du willst ja den internen RC-Oszilator
benutzen. Ich denke aber, dass dein Vorhaben damit in der Tat umsetzbar
ist im Rahmen der geforderten Genauigkeit.
Mit Delay würde ich hier aber auch nicht arbeiten sondern einen Timer
benutzen. Ich würde den Wachtdog im Interrupt-Mode benutzen, Vorteil vom
Watchdog ist, dass er den Attiny aus dem Power-Down-Sleep aufwecken kann
(Strom sparen, reicht ja wenn die LED Strom frisst). In der ISR darf der
Tiny dann eine Variable hochzählen bis er das Äquivalent für die 8h
erreicht hat.
Codix schrieb:> Und ein Delay ist niemals genau.
Was sollte einen mit Delay() festgelegten Zeitablauf auf einem Tiny, auf
dem keine Interrupts oder sonstige zeitlichen Unwägbarkeiten laufen,
stören. Delay_ms() ist dann auch nur eine Programmschleife, die mit der
Genauigkeit des CPU-Takt abgearbeitet wird und solange keine internen
Zähler überlaufen, ist das so genau, wie der Takt, sofern die
Kalibrierung stimmt. Der Vorteil durch einen Timer-Interrupt ist hier
allenfalls theoretischer Natur.
Wenn ein _delay_ms (60000) mit ausreichender Genauigkeit eine Minute
dauert, erzeugt das bisschen Overhead durch eine drumrum gebaute
For-Schleife mit 480 Durchläufen allenfalls eine zusätzliche Verzögerung
von ein paar Millisekunden, die wohl kaum dazu führen, dass die
Spezifikation von "~8h" gerissen wird.
Wie ist der Wertebereich der verwendeten _delay_ms()-Funktion?
Wie genau stimmt die 1 Minute bei _delay_ms (60000)?
M. K. schrieb:> Peter G. schrieb:>> Ich gehe mal fest davon aus, das der Takt halbwegs stimmt :-)>> Der stimmt auch nur so halbwegs. Das Problem dürfte u.a. sein, dass er> auch mit der Temperatur driftet und von der Betriebsspannung des AVR> abhängt (siehe Datasheet). Du willst ja den internen RC-Oszilator> benutzen. Ich denke aber, dass dein Vorhaben damit in der Tat umsetzbar> ist im Rahmen der geforderten Genauigkeit.
Es ginge sogar noch deutlich genauer. Das Interessante am Tiny85 ist
nämlich, dass er die beiden wichtigsten Einflußgrößen auf den Takt des
RC-Oszillators auch selber messen kann. Mit dieser Möglichkeit kann man
den Taktfehler weitgehend kompensieren.
Leider sind allerdings auch die Messungen dieser beiden Größen mit einem
relativ großen Fehler behaftet, d.h.: um ein Kalibrierung des Systems
kommt man auch damit nicht herum und diese ist natürlich deutlich
aufwendiger als wenn man einfach bei gegebener Temperatur und Spannung
an einem einzigen Punkt den Takt kalibriert.
Tut man sich aber den Kalibrierungsaufwand an, ist eine Messgenauigkeit
für die Zeit im Bereich von einem Promille problemlos realisierbar.
D.h.: bei 8 Stunden Messdauer beträgt der Fehler dann maximal ca. 30s.
Und zwar bei jeder Spannung und Temperatur (im zulässigen Bereich).
Ich persönlich würde mir allerdings diesen Aufwand nicht antun, sondern
lieber ein paar Cent in einen Uhrenquarz investieren. Den Tiny85 kann
man nämlich auch damit antreiben und damit kann man eine noch deutlich
höhere Genauigkeit erreichen und dies ganz ohne irgendwelche
Kalibrierungsmaßnahmen...
Dass der Tiny bei 32kHz auch noch sehr viel weniger Energie braucht als
bei 1MHz, ist ein angenehmer Nebeneffekt, den man gerne mitnimmt.
Wolfgang schrieb:> Der Vorteil durch einen Timer-Interrupt ist hier> allenfalls theoretischer Natur.
Nö, auch praktischer Natur. Mit dem Timer Interrupt kann man den Tiny in
den Power Down schicken und so die Stromaufnahme auf deutlich unter 1 uA
jagen. Beim delay bräuchte ein Tiny, bei 1 MHz interner RC-Oszilator und
3 V Versorgungsspanung, rund 600 uA. Ist schon ein kleiner Unterschied,
aber feiner Unterschied, fernab jeder theoretischen Natur direkt in der
Praxis.
Peter G. schrieb:> Bei acht Stunden macht das vermutlich einiges aus. +- 15-30 Minuten ist> Akzeptabel. Ist das so ohne Quarz realisierbar?
Das ist mit dem internen RC-Oszillator ohne weiteren Abgleich zu
erreichen. Nimm dazu einen Timer, wie oben geschrieben.
M. K. schrieb:> Mit dem Timer Interrupt kann man den Tiny in> den Power Down schicken und so die Stromaufnahme auf deutlich unter 1 uA> jagen.
Nein. Wenn der Timer weiter laufen soll, geht kein Power Down und die
Stromaufnahme ist deutlich höher. Eine Alternative wäre ein periodisches
Aufwecken mit WDT. Die Stromaufnahme liegt dann bei 6 - 8 µA.
Codix schrieb:> Warum nimmst Du nicht einen NE555 und baust ihn als One-Shot-Timer auf?
Für langen Zeiten brauchst Du riesige Elkos mit -20/+50% Toleranz und
deren Leckstrom macht es noch ungenauer.
Dagegen ist der ATtiny (+/-2%) ein Präzisionstimer.
Soll es noch genauer werden, kann man den ATtiny25 auch mit einem 32kHz
Uhrenquarz laufen lassen.
Moin, schaue er ins Datenblatt
https://www.mouser.com/ds/2/268/Atmel-2586-AVR-8-bit-Microcontroller-ATtiny25-ATti-1066528.pdf
Auf Seite 31, OSCCAL – Oscillator Calibration Register und lese er!
Damit kann eine hinreichende genaue Zeit erreicht werden, besser wäre
eben mit nem Uhrenquartz zu arbeiten aber ob die LED's nun paar ms
früher oder später geschaltet werden ist wohl bei dieser Anwendung
vernachlässigbar...
Das ganze wird mit dem richtigen Timer(8bit/16bit) im CTC-Mode erledigt
somit umgehst du das Vorladen der Timerregister. Dazu eine Priese
Interrupts und schon löppt deine 8h Timer....
Hallo,
die Abweichung des internen RC-Oszilltors ist in den Diagrammen hinten
im Datenblatt unter Internal Oscillator Speed.
Spannungs- und Temperaturabhängig ca. 3%. Wäre also bei 8 Stunden ca. 15
Minuten Abweichung machbar, vermutlich noch genauer wenn Spnnung und
Temperatur nicht so sehr schwanken.
Die Abweichung von der Sollfrequenz kann ziemlich groß sein, dafür hat
AVR das Kalibrierungsbyte hinterlegt, das kann man nutzen.
Es gibt auch einen internen Temperatursensor, den man zum korrigieren
nutzen kann.
Wenn man das nur als Einzelstück baut, kann man ihn auch nehmen wie er
ist, man muß dann eben einmalig die tatsächliche Taktfrequenz ausmessen
und im Programm berücksichtigen. Ob das der Timer macht oder eine
Busyloop oder delay() vom Arduino spielt keine Rolle solange das
Programm wirklich nur wartet und nichts anderes macht.
Eingentlich darf er in 60 Minuten nur um ca. +/- 2 Minten abweichen,
waren es bei Dir wirklich mal + 7 Minuten und mal - 7 Minuten mit dem
selben ATiny85?
Gruß aus Berlin
Michael
m.n. schrieb:> Nein. Wenn der Timer weiter laufen soll, geht kein Power Down und die> Stromaufnahme ist deutlich höher. Eine Alternative wäre ein periodisches> Aufwecken mit WDT.
Siehe dazu auch:
M. K. schrieb:> Ich würde den Wachtdog im Interrupt-Mode benutzen, Vorteil vom> Watchdog ist, dass er den Attiny aus dem Power-Down-Sleep aufwecken kann
Und auch der WDT ist auch ein Timer ;)
M. K. schrieb:> Und auch der WDT ist auch ein Timer
Aber in der Regel ist der Watchdog-Oszillator noch viel ungenauer, als
der interne Taktoszillator des µC
Thomas E. schrieb:> M. K. schrieb:>> Und auch der WDT ist auch ein Timer>> Aber in der Regel ist der Watchdog-Oszillator noch viel ungenauer, als> der interne Taktoszillator des µC
Öhm, nö
Ok, der AVR mag dann die Ausnahme von der Regel sein (hab's nicht
geprüft).
Von anderen Prozessorfamilien kenne ich das so, daß dort der Watchdog
einen eigenen Oszillator hat, der zwar im Power-Down schön wenig Strom
verbraucht, aber dafür eben auch eine grottenschlechte Präzision der
Frequenz hat.
z.B. bei einem STM32:
"The LSI RC acts as an low-power clock source that can be kept running
in Stop and Standby mode for the independent watchdog (IWDG) and
Auto-wakeup unit (AWU). The clock frequency is around 40 kHz (between 30
kHz and 60 kHz)."
Peter G. schrieb:> Nach Start/Reset sollen einige LEDs ~acht Stunden leuchten danach aus.>> Bis 2-3 Minuten passt das so. Wenn ich allerdings auf zB 60 Minuten> (3600000 ms) gehe, driftet es teilweise um bis zu +-7 Minuten ab.>> Bei acht Stunden macht das vermutlich einiges aus. +- 15-30 Minuten ist> Akzeptabel. Ist das so ohne Quarz realisierbar?
Man kann das ganz einfach rechnen. Die Toleranz des eingebauten
Oszillators steht ja bestimmt im Datenblatt vom betreffenden uC; musst
Du mal nachschauen.
Gehen wir mal davon aus, dass die Toleranz +-2% beträgt.
Jetzt kannst Du rechnen: 8h * 60 = 480min
480min * +-0.02 = +-9.6min
Die Toleranz beträgt also +-9.6min
Wenn das nicht ausreicht, musst Du einen Quarz nehmen, da hast Du dann
nur noch Toleranzen so um 20ppm oder wenn die Umgebungsbedingungen wie
Temperatur und Speisung einigermassen konstant sind, kannst Du die
genaue Frequenz des internen Oszillators messen und die Abweichung in
der Software rausrechnen.
Johnny B. schrieb:> Gehen wir mal davon aus, dass die Toleranz +-2% beträgt.> Jetzt kannst Du rechnen: 8h * 60 = 480min> 480min * +-0.02 = +-9.6min
Unkalibriert sind es +-10%, kalibriert man kommt man locker unter +-1%.
Und wie schon gesagt wurde: Mit einem Quarz kommt man ganz ohne
Kalibration auf deutlich unter +- 0.1% (und wenn nicht sollte man mal
überlegen ein Cent mehr auszugeben für nen anständigen Quarz).
M. K. schrieb:>> Aber in der Regel ist der Watchdog-Oszillator noch viel ungenauer, als>> der interne Taktoszillator des µC>> Öhm, nö
Kannst Du das nochmal erläutern? Habe gerade versucht, das
herauszufinden, aber bislang nur eher die Bestätigung meiner Aussage
gefunden, nämlich daß der Watchdog-Oszillator auch beim ATTINY eher
unpräziser ist, als der normale interne CPU Taktoszillator. Außerdem
lässt der WD-Oszillator sich auch nicht kalibrieren, wie der Takt-Oszi.
BTW,
M. K. schrieb:> Mit dem Timer Interrupt kann man den Tiny in> den Power Down schicken und so die Stromaufnahme auf deutlich unter 1 uA> jagen.
Öhm, Nö.
M. K. schrieb:> Nö, auch praktischer Natur.
Es ging hier um die Genauigkeit bei der Zeitsteuerung.
Niedriger Stromverbrauch war bisher als Bewertungskriterium nicht
genannt.
Thomas E. schrieb:> Kannst Du das nochmal erläutern? Habe gerade versucht, das> herauszufinden, aber bislang nur eher die Bestätigung meiner Aussage> gefunden, nämlich daß der Watchdog-Oszillator auch beim ATTINY eher> unpräziser ist, als der normale interne CPU Taktoszillator. Außerdem> lässt der WD-Oszillator sich auch nicht kalibrieren, wie der Takt-Oszi.
Kalibrieren wie den internen RC-Oszilator kann man ihn nicht, richtig.
Dafür muss man ihn vermessen und wissen, dass dann z.B. 16 ms nicht 16
ms sind sondern vielleicht 15.8 ms (der WDT also nicht mit 128 kHz läuft
sondern z.B. mit 125 kHz). Er lässt sich ja auch nicht so fein justieren
wie die anderen Timer. Grundsätzlich aber hat er die gleiche Genauigkeit
wie der RC-Oszilator da er ja mit der selben Technik gebaut wird. Und
wenn man auf 8h bezogen seinen tatsächlichen Takt berücksichtigt bekommt
man die 8h auch mit +-1% hin ;)
Thomas E. schrieb:> Öhm, Nö.
Stimmt, ich hab noch mal geschaut, im PWR_DOWN hat er mit aktiven WDT
zwischen 3 und 8 uA. Immer noch deutlich weniger als ihn im Active- oder
Idle-Mode zu lassen. Ich lege (inzwischen) meine uCs immer schlafen wenn
sie nichts zu tun haben als zu warten und wecke sie nur auf wenns was zu
tun gibt.
M. K. schrieb:> Mit einem Quarz kommt man ganz ohne Kalibration auf> deutlich unter +- 0.1%
Schrieb ich ja; mit einem 0815 Quarz etwa 20ppm.
(20ppm = 0.002%)
Codix schrieb:> Warum nimmst Du nicht einen NE555 und baust ihn als One-Shot-Timer auf?
Der 555 ist für lange Laufzeit auch deshalb recht unpraktisch, weil es
circa 8 Stunden dauert, eine Laufzeit von 8 Stunden zu testen, und man
das üblicherweise mehrfach machen muss. Digital kann man gut von
Sekunden auf Stunden skalieren. Bei Trimmpotis und leckstrombehafteten
Elkos funktioniert das nicht so gut.
Für lange Laufzeiten verwendete man deshalb früher beispielsweise den
XR2240. Gibts aber nicht mehr, weil von µCs abgelöst.
Peter D. schrieb:> Codix schrieb:>> Warum nimmst Du nicht einen NE555 und baust ihn als One-Shot-Timer auf?>> Für langen Zeiten brauchst Du riesige Elkos mit -20/+50% Toleranz und> deren Leckstrom macht es noch ungenauer.
Dafür gibt es IC wie CD4541. Oscillator und Divider bis 2^16. Bei
Reichelt 27 Cent. Will man genau abstimmen, so braucht man keine 8
Stunden warten: einfach Frequenz bei RC-Glied messen, sie sollte dann
2,27(5) Hz sein.
Für Impuls 32768 Schwingungen lang braucht man dann C ~= 470n,
Widerstand 750k und Trimmer 100k.
Will man kleinere Werte, so kann man dazu noch CD4020 nehmen, Trc nimmt
man dann 16384 mal kleiner.
A. K. schrieb:> Der 555 ist für lange Laufzeit auch deshalb recht unpraktisch, weil es> circa 8 Stunden dauert, eine Laufzeit von 8 Stunden zu testen, und man> das üblicherweise mehrfach machen muss.
Die Temperatur müsste man dann auch noch stabil halten. Da sind schnell
mal +-15min. Abweichung drin.
Und Austesten möcht ich das auch nich. :)
M. K. schrieb:> Grundsätzlich aber hat er die gleiche Genauigkeit> wie der RC-Oszilator da er ja mit der selben Technik gebaut wird.
Sie werden zwar mit derselben Technik umgesetzt, unterscheiden sich aber
wegen der verschiedenen Frequenzbereiche in ihren Eigenschaften doch
ziemlich dramatisch.
Die Diagramme bezüglich der Abhängigkeiten von Spannung und Temperatur
im Vergleich der beiden Oszillatoren offenbart das schon auf den
allerersten Blick...
> Und> wenn man auf 8h bezogen seinen tatsächlichen Takt berücksichtigt bekommt> man die 8h auch mit +-1% hin ;)
Wenn man Spannung und vor allem Temperatur konstant halt. Das gilt für
den WDT genauso wie für den "normalen" RC-Oszillator. Die oben
beschriebene Kalibrierung unter Einbeziehung von Spannung und Temperatur
funktioniert aber natürlich mit dem WDT genauso. Allerdings: das
Nachführen der Kalibrierung zur Laufzeit und die dafür nötigen Messungen
kosten wiederum Rechenzeit, reduzieren also den Zeitanteil des
PowerDown. Es ist also ein Tradeoff zwischen Genauigkeit der Zeitmessung
und Energieverbrauch nötig, der stark von den erwartbaren
Einsatzbedingungen und den Anforderungen an die Genauigkeit abhängt.
> Stimmt, ich hab noch mal geschaut, im PWR_DOWN hat er mit aktiven WDT> zwischen 3 und 8 uA. Immer noch deutlich weniger als ihn im Active- oder> Idle-Mode zu lassen.
Ja. Selbst bei nur 32kHz (Uhrenquarz) zieht er im Idle ca. 70µA. Nunja,
es war schon immer etwas teurer, besonders billig zu bauen. Mit 'nem
Mega wär' das nicht passiert. Da kann man alles "gleichzeitig" haben:
PowerDown, Uhrenquarz-Genauigkeit, keine Kalibrierung und viel
Rechenpower (wenn sie denn benötigt wird).
Bei heutigen Quarzpreisen ist Verzicht auf Quarz kaum noch sinnvoll.
Man kann z.B. mit 5 billigen IC und Uhrenquarz 8 Stunden-Timer etwa so
machen, wie auf dem Bild. Stromverbrauch wird ziemlich klein, deutlich
unter 1 mA, wenn von 3 Volt gespeist.
Hier ist Hauptverbraucher der Oszillator selbst. Alles andere in
uA-Bereich.
Und das ist Problem bei allen Lösungen, auch mit AVR: man kann beliebig
mit PD usw. Verbrauch von Schema sparen. Aber in Oszillator arbeitet
Inverter in Verstärker-Modus, und das braucht Strom.
Bitte merkt: Verbrauch wird bei AVR meistens unter ext. F_CPU angegeben.
Warum?
Man kann genauso AVR mit Uhrenquarz takten. So wird Schema kleiner, 1x
IC. Dafür aber Programmieren. Dann auch noch ein Problem: man sollte AVR
mit Uhrenquarz sehr, sehr langsam programmieren. Das machen nicht alle
Adapter.
P.S. um Zählen bei Erreichen von 8 Stunden zu halten, sollte auf dem
Bild Pin 9 von DD2 mit dem Ausgang von Trigger verbunden werden.
Maxim B. schrieb:> Bei heutigen Quarzpreisen ist Verzicht auf Quarz kaum noch sinnvoll.
Jepp. Jedenfalls, wenn man Quarzgenauigkeit benötigt und nicht
mechanische Anforderungen dagegen sprechen. Quarze sind leider
mechanisch relativ empfindliche Bauelemente.
> Man kann z.B. mit 5 billigen IC und Uhrenquarz 8 Stunden-Timer etwa so> machen, wie auf dem Bild. Stromverbrauch wird ziemlich klein, deutlich> unter 1 mA, wenn von 3 Volt gespeist.
Das kann sich ja nur um einen Scherz handeln. Das kann ein Attiny bei
ca. 70µA...
> Hier ist Hauptverbraucher der Oszillator selbst. Alles andere in> uA-Bereich.
Beim ATtiny ist halt auch der Oszillator im (einstelligen) µA-Bereich...
> Man kann genauso AVR mit Uhrenquarz takten. So wird Schema kleiner, 1x> IC. Dafür aber Programmieren. Dann auch noch ein Problem: man sollte AVR> mit Uhrenquarz sehr, sehr langsam programmieren. Das machen nicht alle> Adapter.
So what? Man kann doch notfalls einen anderen ATtiny als Programmer
benutzen. Die kauft man doch sowieso mindestens im Zehnerpack, weil
sonst die Versandkosten in keinem vernünftigen Verhältnis zum Wert der
Ware stehen...
Johnny B. schrieb:> Gehen wir mal davon aus, dass die Toleranz +-2% beträgt.> ...>> Wenn das nicht ausreicht, musst Du einen Quarz nehmen, ...
Erstmal kann man gucken, was die Ursache für die Toleranz. Systematische
Abweichungen durch Temperaturabhängigkeiten oder Einfluss der
Versorgungsspannungsspannung lassen sich berücksichtigen.
c-hater schrieb:> Man kann doch notfalls einen anderen ATtiny als Programmer> benutzen.
Wie im Märchen, einen Drachen schaffen, damit diese Drache den ersten
frißt? :)
Ob das wirklich sinnvoll ist, bin ich nicht sicher. Überhaupt, AVR in
DIP8 ist für mich fragwürdig: Vcc, Gnd, Reset. Es bleiben 5 Ausgänge, 3
von denen müssen zusammen mit ISP leben. Wenn mit Quarz, dann nur 3
Ausgänge übrig. Dazu noch weder SPI noch USART vorhanden... Wozu solche
Qual? Lieber gleich Mega in DIP28 nehmen.
Was Empfindlichkeit von Quarz betrifft, auf der Platte ist sie kaum
höher als von Keramik-Kondensator. Und Kondensatoren braucht man
sowieso.
c-hater schrieb:> Die Diagramme bezüglich der Abhängigkeiten von Spannung und Temperatur> im Vergleich der beiden Oszillatoren offenbart das schon auf den> allerersten Blick...
Tun sie das?
Oliver
Wolfgang schrieb:> Einfluss der> Versorgungsspannungsspannung lassen sich berücksichtigen.
Scheint mir aber irgendwie unnötig umständlich zu sein (wie auch erst
recht der Vorschlag von M. Köhler, den Watchdog-Timer per Software zu
kalibrieren). Man könnte auch einfach einen µC nehmen, der von Hause aus
einen genaueren internen Oszillator hat.
Z.B. beim PIC12F1840 wird vom Hersteller eine Toleranz von 2% ohne extra
Kalibierung durch den User spezifiziert (als Maximalwert bei 0..60 Grad
garantiert, nicht nur als "typical Value" ins DB gemalt).
Von Batteriebetrieb war vom TO auch nicht die Rede, also sind die
200-300µA, die sich der PIC beim Durchlaufen mit 500 kHz genehmigt wohl
auch kein Problem.
Oliver S. schrieb:> c-hater schrieb:>> Die Diagramme bezüglich der Abhängigkeiten von Spannung und Temperatur>> im Vergleich der beiden Oszillatoren offenbart das schon auf den>> allerersten Blick...>> Tun sie das?
Natürlich. Die Form allein zeigt's. Man muss schon komplett blind sein,
um die Unterschiede nicht erkennen zu können...
Wohlgemerkt: man muß auch noch intelligent genug sein, um zu erkennen,
das es sich jeweils um den Frequenzbereich handelt, in dem der jeweilige
Oszillator eingesetzt wird, bzw. überhaupt einsetzbar ist...
Dass die Unterschiede genau aus diesen unterschiedlichen
Frequenzbereichen resultieren, darauf wies ich sogar explizit hin, um
es Leuten wie dir etwas einfacher zu machen...
Thomas E. schrieb:> Man könnte auch einfach einen µC nehmen, der von Hause aus> einen genaueren internen Oszillator hat.> Z.B. beim PIC12F1840 wird
Man kann alles. Aber ob es sinnvoll ist, von AVR zu einem Kontroller mit
Bank-SRAM und kostenpflichtigen Compiler zu wechseln? 20 Cent für
Uhrenquarz oder ein paar Hundert € für Compiler?
c-hater schrieb:>> Tun sie das?>> Natürlich. Die Form allein zeigt's. Man muss schon komplett blind sein,> um die Unterschiede nicht erkennen zu können...
Nun ja, die Form ist schon anders. Allerdings stehen da noch so komische
Zahlen an den Rändern der Diagramme. Die sollte man nicht so ganz
ignorieren...
Oliver
Maxim B. schrieb:> Man kann alles. Aber ob es sinnvoll ist, von AVR zu einem Kontroller mit> Bank-SRAM und kostenpflichtigen Compiler zu wechseln? 20 Cent für> Uhrenquarz oder ein paar Hundert € für Compiler?
Das o.a. Progrämmchen des TO schafft auch die kostenlose Version gerade
noch so im Speicher unterzubringen, und um die Registerbänke muss man
sich selbst in der kostenlosen Version nicht kümmern.
Thomas E. schrieb:> Z.B. beim PIC12F1840 wird vom Hersteller eine Toleranz von 2% ohne extra> Kalibierung durch den User spezifiziert (als Maximalwert bei 0..60 Grad> garantiert, nicht nur als "typical Value" ins DB gemalt).
Also nix mit Außeneinsatz im Winter... Und auch ansonsten: 2% sind ja
irgendwie auch nicht so der Kracher. Macht bei 8h Messzeit knapp 10
Minuten Abweichung.
> Von Batteriebetrieb war vom TO auch nicht die Rede, also sind die> 200-300µA, die sich der PIC beim Durchlaufen mit 500 kHz genehmigt wohl> auch kein Problem.
Uhrenquarz + Tiny sind VIEL genauer UND nicht nennenswert teurer
UND brauchen nennenswert weniger Strom. Warum, zum Teufel, sollte man
sich da einen PIC12 antun? Nenne einen vernünftigen Grund!
c-hater schrieb:> Also nix mit Außeneinsatz im Winter...
Dann nimm halt den Winterbetrieb mit bis zu -40 Grad - dann ist die
Abweichung max. 5% - immer noch genauer, als die unkalibrierten 10% beim
AVR, und immer noch in der vom TO angegebenen Toleranz (15-30 Minuten).
c-hater schrieb:> sollte man> sich da einen PIC12 antun? Nenne einen vernünftigen Grund!
Wenn der die gestellte Aufgabe ausreichend gut erledigt, warum sollte
man ihn dann als Lösung ausschließen? Bloss weil Du die Architektur
nicht magst?
Oliver S. schrieb:> Nun ja, die Form ist schon anders. Allerdings stehen da noch so komische> Zahlen an den Rändern der Diagramme. Die sollte man nicht so ganz> ignorieren...
Tatsache, das sollte man tatsächlich nicht.
Also tue das doch einfach und lasse deine Erkenntnisse hier ab. Du wirst
feststellen, dass die Fehler über den Betriebsbereich in ähnlichen
Größenordnungen liegen (was wegen der gemeinsamen Architektur logisch
ist), du wirst, wenn du intelligent bist, aber auch feststellen, dass
eine Kompensation des WDT-Fehlers sehr viel mehr Rechenaufwand (oder
große Tabellen) benötigt, eben weil der Verlauf der Kennlinien so anders
ist...
Maxim B. schrieb:> Man kann alles. Aber ob es sinnvoll ist, von AVR zu einem Kontroller mit> Bank-SRAM und kostenpflichtigen Compiler zu wechseln? 20 Cent für> Uhrenquarz oder ein paar Hundert € für Compiler?
Nachdem die AVRs kaufmännisch so schlecht performt haben, daß sie von
den PICs aufgekauft wurden, kann man sich solche Dusseligkeiten auch
sparen.
MfG Klaus
c-hater schrieb:> Also tue das doch einfach und lasse deine Erkenntnisse hier ab. Du wirst> feststellen, dass die Fehler über den Betriebsbereich in ähnlichen> Größenordnungen liegen
Damit wäre das jetzt schonmal geklärt. War doch gar nicht so schwer,
oder?
Und jetzt liest du nochmals die Anforderung des TO, um die es in diesem
Thread geht. Der will keine Atomuhr bauen, sondern
Peter G. schrieb:> Bei acht Stunden macht das vermutlich einiges aus. +- 15-30 Minuten ist> Akzeptabel. Ist das so ohne Quarz realisierbar?
Was willst du da mit gigantischen Tabellen großartig korrigieren?
Pi mal Daumen mal 42, fertig.
Oliver
Klaus schrieb:> achdem die AVRs kaufmännisch so schlecht performt haben
Das ist Problem von Firma. Aber Compiler zu kaufen ist schon Problem von
Nutzer. Merkst du mal Unterschied? Ein paar Hundert € ist nix für dich?
Ich bin z.B. nicht so reich, um mehrere Hundert € einfach zu ignorieren.
Ich habe selbst lange auf PIC gekuckt. Aber diese zwei Sachen, gebankte
SRAM und teure Compiler - das hält mich bei AVR. Wenn schon zu wechseln,
dann lieber gleich auf STM32. Auch kostenlose Compiler und frei
zugängliche (und auch viel größere) RAM. Wenn AVR nicht mehr reicht.
Übrigens, hier hat man noch eins bei AVR vergessen: es gibt CLKPR. Man
kann Arduino Pro Mini mit 16 MHz Quarz für 2,2 € pro Stück bei Chinesen
kaufen und mit CLKPR mit 62500 Hz Takt arbeiten. Man kann auch CLKPR
kurz auf 16 MHz umschalten, machen ganze Kram und dann wieder auf 62500
Hz gehen. Quarz ist schon im Preis drin, auch Spannungsregler.
Was eingebaute Oszillator betrifft: einmal habe ich damit
experimentiert, Stoppuhr programmiert. Mit OSCCAL habe ich es versucht,
möglichst genau 8 MHz zu bekommen. Ergebnis: entweder eine Sekunde in
ein paar Minuten zu schnell, oder zu langsam. Auflösung von OSCCAL
reicht nicht, um für Stoppuhr ausreichend genau Takt zu bekommen.
Peter D. schrieb:> Soll es noch genauer werden, kann man den ATtiny25 auch mit einem 32kHz> Uhrenquarz laufen lassen.
Alternativ geht auch das hier (ich habe das aber selbst noch nie
ausprobiert):
6.2.4 Internal 128 kHz Oscillator
The 128 kHz internal Oscillator is a low power Oscillator providing a
clock of 128 kHz. The frequency is nominal at
3V and 25C. This clock may be select as the system clock by programming
the CKSEL Fuses to “0100”.
When this clock source is selected, start-up times are determined by the
SUT Fuses as shown in Table 6-9.
Table 6-7. Start-up Times for Internal Calibrated RC Oscillator Clock
SUT[1:0]
Start-up Time
from Power-down
Additional Delay from
Reset (VCC = 5.0V) Recommended Usage
00 6 CK 14CK(1) BOD enabled
01 6 CK 14CK + 4 ms Fast rising power
10(2) 6 CK 14CK + 64 ms Slowly rising power
11 Reserved
Table 6-8. Start-up Times for Internal Calibrated RC Oscillator Clock
(in ATtiny15 Mode)
SUT[1:0]
Start-up Time
from Power-down
Additional Delay from
Reset (VCC = 5.0V) Recommended Usage
00 6 CK 14CK + 64 ms
01 6 CK 14CK + 64 ms
10 6 CK 14CK + 4 ms
11 1 CK 14CK(1)
Table 6-9. Start-up Times for the 128 kHz Internal Oscillator
SUT[1:0]
Start-up Time from
Power-down
Additional Delay from
Reset Recommended Usage
00 6 CK 14CK(1) BOD enabled
01 6 CK 14CK + 4 ms Fast rising power
10 6 CK 14CK + 64 ms Slowly rising power
11 Reserved
ATtiny25/45/85 [DATASHEET] 29
2586Q–AVR–08/2013
Note: 1. If the RSTDISBL fuse is programmed, this start-up time will be
increased to 14CK + 4 ms to ensure programming
mode can be entered.
Auf jeden Fall kann man den "Calibrated Internal Oscillator" noch weiter
anpassen.
F. F. schrieb:> Auf jeden Fall kann man den "Calibrated Internal Oscillator" noch weiter> anpassen.
Aber nicht genug genau für Timer. Zu große Schritte bei Anpassung mit
OSCCAL
Maxim B. schrieb:> Was eingebaute Oszillator betrifft: einmal habe ich damit> experimentiert, Stoppuhr programmiert. Mit OSCCAL habe ich es versucht,> möglichst genau 8 MHz zu bekommen. Ergebnis: entweder eine Sekunde in> ein paar Minuten zu schnell, oder zu langsam. Auflösung von OSCCAL> reicht nicht, um für Stoppuhr ausreichend genau Takt zu bekommen.
Für einen Zeitgeber braucht man keinen Takt von exakt 8MHz. Es reicht,
wenn die Taktfrequenz hinreichend stabil ist bzw. Abhängigkeiten
ausreichend genau bekannt sind.
Dann nimm nen Pic mit integrierten Temperaturfühler und programmiere dir
nen Wolf!
Wenns genauer als ~2% sein MUSS nem ich ne Quarz, ich leb ja nich ewig.
Teo D. schrieb:> Dann nimm nen Pic mit integrierten Temperaturfühler
Lieber AVR. Bei Mega gibt es auch Temperaturfühler :) Dafür aber
leichter mit SRAM und kostenlose Compiler.
Maxim B. schrieb:> Aber Compiler zu kaufen ist schon Problem von> Nutzer. Merkst du mal Unterschied? Ein paar Hundert € ist nix für dich?> Ich bin z.B. nicht so reich, um mehrere Hundert € einfach zu ignorieren.
Was schreibst Du da dauernd von "teurem Compiler"? Der Compiler IST
kostenlos! Nur gibt es damit halt keine Optionen zur Code-Optimierung.
Trotzdem kann man damit arbeiten und für die meisten Anwendungen, die
man (sinvoll) mit einem kleinen 8-Bit µC macht, reicht die Qualität des
Codes im freien Mode aus.
Maxim B. schrieb:> Ich habe selbst lange auf PIC gekuckt. Aber diese zwei Sachen, gebankte> SRAM und teure Compiler
Wieso stört Dich das Banking, wenn Du in C programmieren willst? Im
C-Code hat man damit nichts zu tun. Das sind für mich keine validen
Argumente gegen diese Controller-Typen für die Anwendung, um die es hier
geht.
Was evtl. tatsächlich gegen die Verwendung eines PICs statt AVR spricht,
ist natürlich die Ausstattung des TO mit Programmierhardware. Es macht
vermutlich für ihn keinen Sinn, sich nur dafür ein PICKit anzuschaffen -
dann lieber einen AVR und den Oszi umständlich kalibrieren oder besser
einen Quarz oder Resonator verwenden.
Thomas E. schrieb:> Der Compiler IST> kostenlos! Nur gibt es damit halt keine Optionen zur Code-Optimierung.
Was nutzt Compiler ohne Code-Optimierung? Das ist Müll.
Maxim B. schrieb:> Was nutzt Compiler ohne Code-Optimierung? Das ist Müll.
Könntest du diesen Gedanken vielleicht ein wenig vertiefen?
Insbesondere im Hinblick auf eine völlig triviale Programmieraufgabe mit
reichlich verfügbarem Flash und RAM.
Danke!
Stimmt schon. Für TO-Aufgabe reicht auch Assembler. Obwohl auch hier
wird PIC durch eigenartige SRAM unbequem.
Übrigens, früher habe ich schon zwei Lösungen gar ohne Mikrocontroller
gezeigt, mit Quarz und auch ohne. Ohne Quarz reicht schon 1x IC. Kein
Programmieren, keine Probleme mit SRAM. CD4541 + Kondensator, 2
Widerstände und vielleicht noch ein Trimmer. 10 Minuten löten, 20
Sekunden Trimmer abstimmen - und fertig! Es gibt auch andere IC dieser
Art.4536 (36 Cent bei Reichelt) hat 2^24 Divider. So kann man ganz
bequem mit Kondensator ~ 2n2 oder 4n7 und Widerstand unter 1M arbeiten.
Maxim B. schrieb:> Für TO-Aufgabe reicht auch Assembler. Obwohl auch hier> wird PIC durch eigenartige SRAM unbequem.
Wenn Du das unbequem findest, warum führst Du nun schon wieder völlig
sinnfrei Assembler an? Der TO hatte nicht vor, irgendwas in Assembler zu
machen, und Dein erster Satz müsste eigenlich lauten: "Für TO-Aufgabe
reicht auch nicht optimiertes C". Assembler bemüht man dann, wenn man
z.B. zeitkrische Aufgaben mit C nicht vernünftig gelöst bekommt.
Offensichtlich suchst Du einfach nur krampfhaft Gründe, um die 8-Bit PIC
Architektur zu bashen, ohne Bezug zu den gestellten Anforderungen.
Zur Hardware-Lösung hatte der TO bereits geschrieben, daß er diese wegen
später evtl. gewünschter Programmierbarkeit der Zeiten nicht möchte.
Maxim B. schrieb:> Was nutzt Compiler ohne Code-Optimierung? Das ist Müll.Norbert schrieb:> Könntest du diesen Gedanken vielleicht ein wenig vertiefen?> Insbesondere im Hinblick auf eine völlig triviale Programmieraufgabe mit> reichlich verfügbarem Flash und RAM.
Müll sicher nicht aber es nervt/ärgert einen schon. Die haben da den GCC
ja auch nur etwas(?) modifiziert.
Wirklich gebraucht, habe ich die volle Optimierung nur, wenn ich einen
PIC16F84 mit C vergewaltigt habe. :)
Thomas E. schrieb:> Assembler bemüht man dann, wenn man> z.B. zeitkrische Aufgaben mit C nicht vernünftig gelöst bekommt.
Nicht nur. Auch wenn man nicht zu viel für Compiler ausgeben will.
Eigentlich verstehe ich schlecht: für eine Plattform gibt es gute und
kostenlose Compiler, für andere nicht. Was ist hier überhaupt zu
diskutieren? Klar: Fa Microchip will nicht, daß die Bastler ihre PIC
benutzen. Wozu sollte man unbedingt gegen ihre Wille durchsetzen?
Dazu noch sind PIC und AVR grob gesagt ähnlich nach ihren Möglichkeiten.
PIC hat bißchen bessere (manchmal) Peripherie, AVR hat bessere (wenn
auch nicht absolut für C geeignete) Speicherverwaltung. Aber die Sache
mit Compiler bringt Klarheit in Vergleich.
Optimierung ist sehr wichtig. Sonst ist man zu oft gezwungen, mit
Assembler zu hantieren. Das kann man gut verstehen, wenn man für AVR
verschiedene Stufen ausprobiert. Ist Optimieren ausgeschaltet, wird
nicht nur größere Datei gemacht, sondern auch viel langsamere. Dann kann
man schon kaum Vorteile für C gegen Basic finden :)
Maxim B. schrieb:> Eigentlich verstehe ich schlecht:
Noch ein Argument FÜR dich.
Was wirklich ärgerlich ist, das die Modernen PICs, die für C optimiert
wurden, dies NICHT vom Compiler unterstützt wird, auch nicht für Geld.
Was soll der Scheiß?
Maxim B. schrieb:> Eigentlich verstehe ich schlecht: für eine Plattform gibt es gute und> kostenlose Compiler, für andere nicht.
Das sollte man (zumindest im Hobby-Bereich) bei der Wahl des MC
berücksichtigen.
Dieter F. schrieb:> Teo D. schrieb:>> Was soll der Scheiß?>> Frag doch bitte den Hersteller ... der sollte es wissen.
Oh sorry, die Frage war rein rhetorisch. Ich werds nächstes mal
kennzeichnen. ;)
Hat nicht jeder von euch ein 32khz Prüfnormal daheim, mit dem man die
Geräte kalibriert.
Innerhalbe < 1Sek ist das Gerät kalibriert (tmr0 wird verwendent, pin7)
Einfach hier z.B. ein minimaler sketch, aber bitte mit externem Quarz.
1
//Attiny85 , running @ 8MHZ
2
// Using timer 0
3
//
4
// +-\/-+
5
// Ain0 (D 5) PB5 1| |8 VCC
6
// Ain3 (D 3) PB3 2| |7 PB2 (D 2) INT0 Ain1
7
// Ain2 (D 4) PB4 3| |6 PB1 (D 1) pwm1
8
// GND 4| |5 PB0 (D 0) pwm0
9
// +----+
10
void setup(){
11
DDRB |= (1<<PB0); //Set pin PB0 as output
12
TCNT0 = 0;
13
TCCR0A=0;
14
TCCR0B=0;
15
16
TCCR0A |=(1<<COM0A0); //Timer0 in toggle mode Table 11-2
17
TCCR0A |=(1<<WGM01); //Start timer 1 in CTC mode Table 11.5
18
TCCR0B |= (1 << CS00);// Prescaler table 11.6
19
OCR0A=121; //CTC Compare value 32,786885 khz, 0.0576% error , 243 on 16mhz !
Chris S. schrieb:> Hat nicht jeder von euch ein 32khz Prüfnormal daheim, mit dem man die> Geräte kalibriert.
Da fehlt ganz klar die Temperaturkompensation.
-------------
Auch gefallen mir deine Anweisungsketten nicht.
Irgendwie scheinen mir die Einrückungen kaputt gegangen zu sein.
(aber das ist ein ganz anderes Thema)
Bei niederer Spannung ist der Drift von 25 Grad zu -40 Grad +5,3%
und bei 85 Grad sind es -4%. Wenn man nicht -40 sondern -20 annimmt,
dann
sind es -+4%, welcher der TO erlaubt, da er von 20Minuten Fehler bei 8
Stunden
als akzeptabel spricht. Dies sind genau 4%.
Maxim B. schrieb:> Was eingebaute Oszillator betrifft: einmal habe ich damit> experimentiert, Stoppuhr programmiert. Mit OSCCAL habe ich es versucht,> möglichst genau 8 MHz zu bekommen. Ergebnis: entweder eine Sekunde in> ein paar Minuten zu schnell, oder zu langsam. Auflösung von OSCCAL> reicht nicht, um für Stoppuhr ausreichend genau Takt zu bekommen.
Das kommt einzig darauf an, was man als "ausreichend" definiert. OSCCAL
erlaubt es, bei gegebener Temperatur und Spannung den Zieltakt auf
besser als 1% genau zu treffen. Mehr verspricht das Datenblatt nicht und
mehr geht auch nicht.
Das heisst aber nun nicht, das man keine genauere Zeitmessung
hinbekommen könnte. Man muss die Kompensation des Taktfehlers einfach
nur anders machen.
Dazu gibt es zwei Möglichkeiten:
1) Man kann OSCCAL modulieren. D.h.: man wechselt alle paar ms zwischen
zwei benachbarten Werten von OSCCAL. Über das "Tastverhältnis", mit dem
die jeweiligen Werte wirksam werden, kann man (über längere Zeit
gesehen) viele Zwischenwerte zwischen den beiden mittels OSCCAL
tatsächlich einstellbaren Werten erreichen.
2) Man läßt OSCCAL einfach beim bestmöglichen Wert und bestimmt den
Restfehler. Den kompensiert man dann einfach bei der Zeitmessung in
Software, indem man an geeigneter Stelle der eigenen Zeitzählung einen
Korrekturwert addiert. Wenn man z.B. Sekunden zählen möchte und den
Timer so konfiguriert hat, dass er bei exakt 8MHz im Sekundenrythmus
überlaufen würde und dann stellt man fest, dass die so erfasste Zeit
nach einer Stunde nicht 3600 ist, sondern z.B. 3616, was macht man dann?
Na klar: man addiert bei jedem Schlag des Timers nicht eine Sekunde zum
eigenen Sekundenzähler, sondern nur 0,996 Sekunden. Und schon passt das.
Sinnvollerweise wird man dann aber lieber den Timer auf Zehntel- oder
Hundertstel- oder gar Tausendstelsekunden konfigurieren und dann dort
halt 9,96, 99,6 oder 996 addieren. Kommt auf die Anwendung an, was
sinnvoll und machbar ist.
Auch, welche von diesen beiden Varianten man wählt, hängt stark vom
konkreten Gesamtproblem ab. Die OSCCAL-Modulation ist insofern schick,
als dass sie alle vom Systemtakt abgeleiteten Timings gleichermassen
beeinflusst. Schlecht ist hingegen, dass die Modulation umso
rechenzeitfressender wird, je kleiner das Intervall ist, in dem der
mittlere Takt stimmen soll. Auch die "Auflösung", also die Zahl der
erreichbaren Zwischenstufen und damit die mögliche Genauigkeit des
mittleren Taktes zwischen den beiden echten OSCCAL-Werten verringert
sich, je kleiner das Intervall wird, in dem man moduliert.
Der älteste Geheimtip..
man zählt die Timer Takte zwischen zwei Tagesschau-Gongs und korrigiert
danach Präzise den Zähler des Timers durch die ermittelte Abweichung.
Philipp K. schrieb:> Der älteste Geheimtip..>> man zählt die Timer Takte zwischen zwei Tagesschau-Gongs
Nimm lieber die Zeilenfrequenz, da muss man nicht auf die Tagesschau
warten. :)
Teo D. schrieb:> Philipp K. schrieb:>> Der älteste Geheimtip..>>>> man zählt die Timer Takte zwischen zwei Tagesschau-Gongs>> Nimm lieber die Zeilenfrequenz, da muss man nicht auf die Tagesschau> warten. :)
Oder man nimmt den einen Tagesschau-Gong direkt von ARD und den anderen
von einem dritten Programm. Die liegen nur ein bis zwei Sekunden
auseinander ;-)
Um mal wieder auf's eigentliche Thema zu kommen:
Die Tage hatte ich an anderer Stelle ein Programm gezeigt, bei dem neben
einer Periodendauer von fünf Sekunden auch noch die Stromaufnahme gering
sein sollte: Beitrag "Re: Micropower Pulsgenerator"
Dort kann man den Wert für PERIODENDAUER_IN_SEKUNDEN auf ca. 28800
einstellen bzw. passend korrigieren, um auf acht Stunden Intervalle zu
kommen. Die Variable 'sekunden' muß auf unit16_t geändert werden.
Ein ATtiny13, 25, ... nebst Abblockkondensator reichen aus, um das oben
geforderte Timing zu erreichen.
Ich denke 8 Stunden ist schon nicht ohne..wenn man es halbwegs genau
haben möchte.
Wenn man das unbedingt mit dem Attiny machen möchte bleiben ja nur 3
Möglichkeiten.. ds3231 oder man sucht sich einen fest eingestellten tcxo
mit TTL Ausgang, 32768 Extern.
Da spielen ja noch andere Sachen eine Rolle, man kann auch Glück haben
das man einen Attiny erwischt der weit in den Specs liegt und mit
eigener Kalibrierung bei Zimmertemperatur schon ziemlich genau ist.
(Thema selbst ausprobieren)
Andererseits kommt es auf die freien Pins an, welche Pins noch frei sind
etc.. ein guter 32khz Qaurz kann bei 8Stunden schon genauer als die
interne Clock sein, kostet halt nur 2 Pins.
Hab mal bei Ds1307 Breakouts den Billig Oscillator gegen Qualitäts 32khz
getauscht und es war nur noch nach Tagen abweichungen größer 1 Minute
erkennbar. (Vorher 10 Minuten am Tag)
Philipp K. schrieb:> Wenn man das unbedingt mit dem Attiny machen möchte bleiben ja nur 3> Möglichkeiten.. ds3231 oder man sucht sich einen fest eingestellten tcxo> mit TTL Ausgang, 32768 Extern.
Mann, Mann, Mann. Und was ist die 3.?
Der TO braucht eine Genauigkeit von +/- 50000 ppm und Du machst
Vorschläge für +/- 1 ppm. Was hast Du denn nicht verstanden?
m.n. schrieb:> Was hast Du denn nicht verstanden?
Schreib das doch jedem mit einem nicht ganz passenden Kommentar.
Ich finde auch, das die erste Antwort mit dem Timer anstatt sleep
ausgereicht hätte.. Anstatt dessen waren hier schon etliche blödere
Vorschläge, hast Du es jetzt als einziger Verstanden?
1. Attiny kalibrieren.
2. Wenn mans schick haben möchte mit ds3231
3. Besser als der interne ist jeder gute 32kHz Quarz.
Kann man nur vorschlagen.. Anstatt sinnlos zu diskutieren und
abzuschweifen.
Philipp K. schrieb:> 1. Attiny kalibrieren.> 2. Wenn mans schick haben möchte mit ds3231> 3. Besser als der interne ist jeder gute 32kHz Quarz.
4. Die Abweichung messen und über Software eine Korrektur fahren.
Jeder der sich mit Mikrocontrollern beschäftigt und beim Timer angelangt
ist, wird gefühlt 1000 Beiträge im Netz dazu gefunden haben. Angefangen,
wie hier schon weiter oben gepostet, mit der genauen Sekunde.
Ergänzend hinzu: Aber wie bei vielen dieser Beiträge (erkennt man schon
an der Art der Fragestellung), wusste der TO nicht einmal was ppm ist
und der "Eierkocher Timer" dann doch nicht sooo genau gehen muss. ;-)
Hallo,
man muß für diese Anwendung auch nicht zwingend calibrieren, es ist doch
egal, ob der Oszillator auf 8MHz oder auf 7,9MHz oder 8,1MHz. Die
Schwankungen durch Temperatur und Spannung bleiben gleich, man muß eben
nur einmal testen oder messen, mit welcjhen Takt er wirklich läuft.
Dann sagt man dem Compiler eben F_CPU = 7350000 o.ä.
Immer unter der Vorraussetzung das es sich um ein Einzelstück handelt
und die Abweichung über 8 Stunden bei +- x Minuten liegen darf. Es ist
ja kein Intervall, wo sich entstandene Fehler aufsummieren können, es
wird ja jedesmal wieder bei 0 gestartet.
Es ist auch völlig egal, ob man einen Timer nimmt oder delay oder eine
Buysloop in ASM solange es keine Interrupts gibt die das Timing
beeinflussen.
Gruß aus Berlin
Michael
c-hater schrieb:> 1) Man kann OSCCAL modulieren.>> 2) Man läßt OSCCAL einfach beim bestmöglichen Wert und bestimmt den> Restfehler.
Alles das ist viel komplizierter, als Quarz für 20 Cent zu nehmen.
Michael U. schrieb:> Die> Schwankungen durch Temperatur und Spannung bleiben gleich, man muß eben> nur einmal testen oder messen, mit welcjhen Takt er wirklich läuft.> Dann sagt man dem Compiler eben F_CPU = 7350000 o.ä.
Wenn mehrere Geräte, dann muß man bei jedem einzeln Frequenz ausmessen?
Zu aufwendig. Viel Mühe, und danach bekommt man sowieso nur
RC-Stabilität.
Maxim B. schrieb:> Michael U. schrieb:>> Die>> Schwankungen durch Temperatur und Spannung bleiben gleich, man muß eben>> nur einmal testen oder messen, mit welcjhen Takt er wirklich läuft.>> Dann sagt man dem Compiler eben F_CPU = 7350000 o.ä.>> Wenn mehrere Geräte, dann muß man bei jedem einzeln Frequenz ausmessen?> Zu aufwendig.
Bei einer einfachen Anwendung lasse ich an einem Ausgang ein 10 kHz
erzeugen und kontrolliere das Timing mit einem einfachen Frequenzzähler
bzw. Scope. Sofern die Abweichung unerwartet hoch liegt, kann mit zwei
Tastern '+' bzw. '-' die Frequenz per OSCCAL angepaßt und im EEPROM
gespeichert werden.
Die Taster bestehen aus Drahtbrücken und die Kontakte liegen am
SPI-Stecker.
Aufwendig ist dabei absolut garnichts!
Typische Abweichungen bei einem 'frischen' ATtiny25 liegen unter 3%,
weshalb eine Korrektur in der Regel nicht erforderlich ist. Jedesmal
einen Quarz und zwei Kondensatoren zu ergänzen wäre völlig überzogen.
Wenn ich dann 10 kStück pro Monat ausliefere, wird der Abgleich von
einem 'Automaten' erledigt: irgendein Arduino ;-)
m.n. schrieb:> Jedesmal einen Quarz und zwei Kondensatoren zu ergänzen wäre völlig überzogen.> Wenn ich dann 10 kStück pro Monat ausliefere, wird der Abgleich von> einem 'Automaten' erledigt: irgendein Arduino ;-)
Da stimme ich zu, allerdings hatte ich nicht den Eindruck das wir über
10kStück / Monat reden.
Aber hören wir einfach noch mal rein:
1
Kumpel fragte mich, ob ich das hinbekomme, ich sagte ja:
2
Nach Start/Reset sollen einige LEDs ~acht Stunden leuchten danach aus.
Norbert schrieb:> Da stimme ich zu, allerdings hatte ich nicht den Eindruck das wir über> 10kStück / Monat reden.
Wenn Du mal verfolgst, welche Reaktionen hier kommen, sobald Du auch nur
ein RC-Glied einfügen möchtest, werden Dir gleich die Kosten bei 1 Mio
Stückzahl um die Ohren gehauen. Der Ironiekringel bezog sich daher auf
die gesamte Aussage.
Ein noch dümmeres Totschlagargument ist die Aussage: "Ich brauche das
nicht!"
Cool bleiben ;-)
> Wenn Du mal verfolgst, welche Reaktionen hier kommen, sobald Du auch> nur ein RC-Glied einfügen möchtest, werden Dir gleich die Kosten> bei 1 Mio Stückzahl um die Ohren gehauen.
Aber wehe du sparst an einer Schaltung für KFZ an umfangreichen
Maßnahmen gegen Verpolung, phantastische Spannungsspitzen und sonstigem
"Dreck". Dann bist du auf einmal verantwortungslos. Man denke nur an die
armen iPhones, die durch solche Verantwortungslose Ladegeräte zerstört
werden können.
Wie wir wissen werden diese Geräte von den Kindern ja auch immer schön
mit einer Kordel um den Hals getragen, damit sie nie auf den
Treppenstufen oder gestreutem Bahnsteig zerschellen. Niemand käme auf so
dumme Ideen, sie sich in die Gesäßasche der ohnehin schon knallengen
Jeans zu quetschen und dann drauf zu setzen. Nein, Smartphones werden im
Allgemeinen wie rohe Eier behandelt und gepflegt. Da muss der gemeine
Elektroniker ebenso mitspielen.
Aber wehe du verschwendest ein R/C Glied!
F. F. schrieb:> 4. Die Abweichung messen und über Software eine Korrektur fahren.
Den Tagesschau Gong hatte ich ja auch schon vorgeschlagen, ist nur ein
praktischer Anwendungsfall der 4. :)
zum NE555/RC Glied..
man kann bei Hochwertigen Komponenten des Schaltkreises davon ausgehen
das die fertig korrigierte Zeit einige Jahre nur minimale Abweichung
zeigen wird.
Jedenfalls kenne ich Zeitglieder die nach ca 30 Jahren immernoch relativ
genau waren.
Philipp K. schrieb:> zum NE555/RC Glied..>> man kann bei Hochwertigen Komponenten des Schaltkreises davon ausgehen> das die fertig korrigierte Zeit einige Jahre nur minimale Abweichung> zeigen wird.
Stimmt, Abweichung wird minimal In keinem Fall mehr als +-10%. Nur 12
Monate in 10 Jahren :)
Das ist natürlich nur wenn man passende Kondensatoren (keine Elko) nimmt
usw.
In den Zeiten wo ein Quarz weniger als ein Kondensator kostet... Ja,
durch enorme Anstrengungen und viel Mühe, mit teuren Kondensatoren, gut
abgeschirmt mit Thermostat, kann man RC-Generator bestimmt unter 1%
bringen. Aber wozu ganze Zirkus? Wenn wir mit einem Quarz für 20 Cent
und 2 Kondensatoren je 1 Cent ohne jede Abstimmung gleich 0,01% und
besser haben?
Hallo,
Maxim B. schrieb:> Stimmt, Abweichung wird minimal In keinem Fall mehr als +-10%. Nur 12> Monate in 10 Jahren :)> Das ist natürlich nur wenn man passende Kondensatoren (keine Elko) nimmt> usw.
meine Oma hätte zu mir gesagt: der Quatsch wird immer quetscher bis er
quietscht...
Wenn die Abweichung 10% ist sind das bei 8 Stunden 48 Minuten.
Heute und auch in 10 Jahren.
Er will keine Uhr bauen, der Fehler wird nicht aufsummiert!
Gruß aus Berlin
Michael
Michael U. schrieb:>> Wenn die Abweichung 10% ist sind das bei 8 Stunden 48 Minuten.> Heute und auch in 10 Jahren.> Er will keine Uhr bauen, der Fehler wird nicht aufsummiert!>> Gruß aus Berlin> Michael
Warum hier immer noch die Möglichkeit nicht besprochen wird, als Takt 50
Hz aus dem Netz zu benutzen? Abweichung ist dort unter 1%, wie bei gutem
RS-Generator. In China baut man sogar Uhren so :)
Zwar ist Aufwand auch höher, als mit einem Quarz, aber man kann wohl
auch so machen...
Hallo,
Maxim B. schrieb:> Warum hier immer noch die Möglichkeit nicht besprochen wird, als Takt 50> Hz aus dem Netz zu benutzen? Abweichung ist dort unter 1%, wie bei gutem> RS-Generator. In China baut man sogar Uhren so :)
naja, eher hier für uns um die in Herde und Mikrowellen einzubauen...
Beitrag "Netzabweichung im Verbund"
Ansonsten: der TO hat sich nicht zu den LEDs und deren Versorgung
geäußert, wenn die LEDs den Gartenweg beleuchten sollen, sind vielleicht
nichtmal die 50Hz greifbar.
Aufwand wäre für diesen Zweck vermutlich eher minimal, ein passendes
Stück "Antenne" am Analogcomparator könnte schon reichen...
Gruß aus Berlin
Michael
Lambda schrieb:>> ein passendes>> Stück "Antenne">> 1/4 Lambda bei 50Hz sind 1500km. Passt also.
Warum dann nicht einfach gleich auf 77,5 kHz abstimmen? Dann ist die
Antenne nur noch knapp einen km lang und man hat sogar Atomzeit von der
PTB! ;)
Maxim B. schrieb:> Warum hier immer noch die Möglichkeit nicht besprochen wird, als Takt 50> Hz aus dem Netz zu benutzen? Abweichung ist dort unter 1%, wie bei gutem> RS-Generator. In China baut man sogar Uhren so :)
Sogar STM32 haben einen eigenen 50Hz Takteingang für die interne RTC ;)
Thread beobachten
Seitenaufteilung abschalten