mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 8h Timer mit attiny85 - Genauigkeit ohne Quarz


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Peter G. (peter_geher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
#include <avr/io.h>
#include <util/delay.h>
#include <avr/sleep.h>

int main(void)
{
  DDRB |= (1 << PB3);
  PORTB |= (1 << PB3);
    _delay_ms (60000);
  PORTB &= ~(1 << PB3);

  WDTCR = 0x0;
    set_sleep_mode(SLEEP_MODE_PWR_DOWN);
    sleep_enable();
    sleep_cpu();
    sleep_disable();
}
// 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?

Autor: Codix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
ISR(TIMER0_COMPA_vect) // 1 ms Timer ISR
{
        static uint16_t count=0;
        if ( ++count > 999 ){
      systick = 1;    // systick is global (volatile)
        count =0;                       
        }
}
init_timer()
{
 //  initialize timer0
   TCCR0A |= ( 1 << WGM01); // CTC Mode
   TCCR0B |= PRESCALER0 ;    // prescaler 1024 and CTC Mode
   TCNT0 = 0;
   OCR0A = (F_CPU/1024)-1   // 1 ms at 1 MHz cpu clock
}
void main(void)
{
    do {
         if ( systick ){ // do something every 1 second 
          
.
.
         systick = 0;
         }
    } 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.

Autor: Peter G. (peter_geher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
>
> ISR(TIMER0_COMPA_vect) // 1 ms Timer ISR
> {
>         static uint16_t count=0;
>         if ( ++count > 999 ){
>       systick = 1;    // systick is global (volatile)
>         count =0;
>         }
> }
> init_timer()
> {
>  //  initialize timer0
>    TCCR0A |= ( 1 << WGM01); // CTC Mode
>    TCCR0B |= PRESCALER0 ;    // prescaler 1024 and CTC Mode
>    TCNT0 = 0;
>    OCR0A = (F_CPU/1024)-1   // 1 ms at 1 MHz cpu clock
> }
> void main(void)
> {
>     do {
>          if ( systick ){ // do something every 1 second
> 
> .
> .
>          systick = 0;
>          }
>     } while ( 1 );
> 
> 
>
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!

Autor: Codix (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
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.

Autor: Peter G. (peter_geher)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Oliver S. (phetty)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Nimm einen ESP und hol die Zeit per NTP.
Zur Sicherheit noch ein Etc Modul dran.

Autor: Wolfgang (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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)?

Autor: c-hater (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: M. K. (sylaina)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: m.n. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: stiller Leser (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: Peter D. (peda)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: m.n. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
stiller Leser schrieb:
> meine Empfehlung:

Was empfiehlst Du denn nun?
Was im dem Link steht, hat doch nichts mit den Problemen des TO zu tun.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Michael U. (amiga)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: M. K. (sylaina)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 ;)

Autor: Thomas E. (picalic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ö

Autor: Thomas E. (picalic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)."

: Bearbeitet durch User
Autor: Johnny B. (johnnyb)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Thomas E. (picalic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ö.

: Bearbeitet durch User
Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> Nö, auch praktischer Natur.

Es ging hier um die Genauigkeit bei der Zeitsteuerung.

Niedriger Stromverbrauch war bisher als Bewertungskriterium nicht 
genannt.

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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%)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Kolja L. (kolja82)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Nimm einen ESP und hol die Zeit per NTP.
> Zur Sicherheit noch ein Etc Modul dran.

Warum nicht gleich so: 0180 4 100 100

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kolja L. schrieb:
> Warum nicht gleich so: 0180 4 100 100

Weils mit dem Weckanruf über 11833 noch einfacher geht. ;-)

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :)

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Maxim B. (max182)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Oliver S. (oliverso)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas E. (picalic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: Maxim B. (max182)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Oliver S. (oliverso)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas E. (picalic)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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!

Autor: Thomas E. (picalic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oliver S. (oliverso)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Norbert (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Uhrenquarz beim "blauen C": 80ct für 20ppm!
Beim "R" ab 20ct (auch 20ppm)

Worüber wird hier eigentlich diskutiert?

Autor: Maxim B. (max182)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: iPhone (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
"Hey Siri, Timer 8 Stunden"

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 25C. 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.

Autor: Maxim B. (max182)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe auch nicht OSCCAL gemeint. Da ist die Schrittweite zu groß, das 
ist richtig.

: Bearbeitet durch User
Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Teo D. (teoderix)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Maxim B. schrieb:
> Lieber AVR

(KA, kenn mich mit den Dingern nich aus, daher... OK, nächstes mal 
schreib ich 'µC':)

Autor: Thomas E. (picalic)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Thomas E. (picalic)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :)

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

: Bearbeitet durch User
Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß?

Autor: Dieter F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Teo D. schrieb:
> Was soll der Scheiß?

Frag doch bitte den Hersteller ... der sollte es wissen.

Autor: Dieter F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Teo D. (teoderix)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. ;)

Autor: Chris S. (aaa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
//Attiny85 , running @ 8MHZ
// Using timer 0
//
//                           +-\/-+
//  Ain0       (D  5)  PB5  1|    |8   VCC
//  Ain3       (D  3)  PB3  2|    |7   PB2  (D  2)  INT0  Ain1
//  Ain2       (D  4)  PB4  3|    |6   PB1  (D  1)        pwm1
//                     GND  4|    |5   PB0  (D  0)        pwm0
//                           +----+
 void setup(){
 DDRB |= (1<<PB0); //Set pin PB0 as output
 TCNT0 = 0;
 TCCR0A=0;
 TCCR0B=0;
 
 TCCR0A |=(1<<COM0A0); //Timer0 in toggle mode Table 11-2
 TCCR0A |=(1<<WGM01); //Start timer 1 in CTC mode Table 11.5
 TCCR0B |= (1 << CS00);// Prescaler table 11.6
 OCR0A=121; //CTC Compare value 32,786885 khz, 0.0576% error , 243 on 16mhz !
}
 
 void loop(){
 }

sowie ein Code zur Kalibration z.B. diesen hier:


#include <avr/io.h>
#include <util/delay.h>
#include <avr/sleep.h>
#include <avr/eeprom.h>



///////////////////////////////////////////////////////////////////////////////////////
// code for calibration
/////////////////////////////////////////////////////////////////////////////////////// 
 
#include <util/delay_basic.h>
#define F  F_CPU/999999UL ; // adj for <1Mhz 

calib_dly() { _delay_loop_2  ((6400/4)*F); } // 6,4ms
calib_delay(unsigned long cnt) { while(cnt--) calib_dly(); }  

unsigned int calib_val() {
    TIFR |= (1<<TOV0);  //clear the flag
     TCNT0 = 0;
    TCCR0B = 0x07;  //enable clock input to rising edge on external clock source
    calib_dly();
    TCCR0B = 0;  
    if(TIFR&(1<<TOV0)) return 256+TCNT0; 
    return TCNT0;
}
void calib_adj(unsigned char val) { for(;OSCCAL!=val;calib_dly()) if(OSCCAL<val) OSCCAL++; OSCCAL--;  } 
char calib_() { unsigned int t; unsigned char i; 
   l  TIMSK = 0;
    TCCR0A = 0;  // set mode to CTC (2)
    t=calib_val()+calib_val(); if(t<256) return 0; // no signal present.
    while(calib_val()>210) OSCCAL--; while(calib_val()<210); OSCCAL++;
  return 1;
  }    

int main(void)
{
  DDRB = (1 << PB3);
  PORTB = (1 << PB3);
  calib_delay(32); // 200ms led on
  PORTB ^= (d1 << PB3); // toggle led
  if(calib_()) {
     calib_delay(125); // 800ms led off
  PORTB ^= (1 << PB3); // toggle led
     calib_delay(32); // 200ms led off
  PORTB ^= (1 << PB3); // toggle led
     calib_delay(32); // 200ms led off
     eeprom_write_byte((char*)0,OSCCAL);
  }  calib_adj(eeprom_read_byte((char*)0));
  PORTB ^= (1 << PB3); // toggle led

#define MIN_  *9375
  calib_delay(60 MIN_ -32); 
  
  PORTB ^= (1 << PB3); // toggle led
  PORTB &= ~(1 << PB3);

  WDTCR = 0x0;
    set_sleep_mode(SLEEP_MODE_PWR_DOWN);
    sleep_enable();
    sleep_cpu();
    sleep_disable();
}

: Bearbeitet durch User
Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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)

Autor: Chris S. (aaa)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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%.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp K. (philipp_k59)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Teo D. (teoderix)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. :)

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp K. (philipp_k59)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: m.n. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Philipp K. (philipp_k59)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: F. F. (foldi)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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. ;-)

Autor: Michael U. (amiga)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: m.n. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 ;-)

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist praktisch, einverstanden.

Autor: Norbert (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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:
Kumpel fragte mich, ob ich das hinbekomme, ich sagte ja:
Nach Start/Reset sollen einige LEDs ~acht Stunden leuchten danach aus.

Autor: m.n. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 ;-)

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> 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!

: Bearbeitet durch User
Autor: Philipp K. (philipp_k59)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
Autor: Michael U. (amiga)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
Autor: Michael U. (amiga)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Lambda (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Michael U. schrieb:
> ein passendes
> Stück "Antenne"

1/4 Lambda bei 50Hz sind 1500km. Passt also.

Autor: Thomas E. (picalic)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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! ;)

Autor: Philipp K. (philipp_k59)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.