Wie findet man möglichst genau die Frequenz des internen RC-Oszilators heraus ?

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hallo zusammen,

was stimmt an meinem Assemblerprogramm für den ATtiny26 nicht, da ich 
bei beiden Versionen 6 Takte verwende, aber die Frequenz die ich messe 
im Verhältnis 2 zu 1 steht.

Ich habe schon einiges zum internen RC-Oszilator gelesen
( OSCCAL-Register usw. ), aber irgendwie habe ich keine Idee wie ich die 
wirkliche Frequenz des internen RC-Oszilators einfach ermitteln kann.

Ein funktionierender Assemblercode wäre natürlich das Beste.

Ich will halt herausfinden wie sich eine Änderung des Wertes im
OSCCAL-Register auswirkt, um den RC-Oszi möglichst genau auf 1Mhz zu 
trimmen.

Um es noch mal klarer zu machen :

Das durch ändern des OSCCAL-Wertes sich die Frequenz ändert kann ich 
feststellen. Aber wie ich dann auf die tatsächliche Frequenz des 
RC-Oszilators schliessen kann, das ist mir noch nicht klar.

Es ist sicher wieder eine einfache Sache, deshalb findet man auch nicht 
die passende Routine, da dies für die meisten Programmierer wohl zu 
einfach ist.

Bernd_Stein

[123 (Gast)]

Aus dem Takt leiten sich die Timertakte ab, die Formeln stehen im 
Datenblatt. Programmier einen Timer, messe den Output und errechne 
daraus den internen Takt.

[MaWin (Gast)]

> Das durch ändern des OSCCAL-Wertes sich die Frequenz ändert
> kann ich feststellen.

Klar.

Die Fraquenz ändert sich auch durch leichte Schwankungen der 
Versorgungsspannung, durch die Umgebungstemperatur, durch die Höhe des 
Rauschens auf der Versorgungsspannung durch einstreuungen eines 
Rundfunksenders, durtch die Anzahl der auf high geschalteten Ausgänge,

was ist jetzt das Besondere daß sich diese Frequenz auch ändert wenn man 
an dem Register rumspielt ?


Ein RC-Oszillator ist schlichht und einfach ungeeignet wenn es um GENAUE 
Frequenzen geht, dafür wurden Quartze erfunden, was hast du daran nicht 
verstanden ?

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

123 schrieb:
> Aus dem Takt leiten sich die Timertakte ab, die Formeln stehen im
> Datenblatt. Programmier einen Timer, messe den Output und errechne
> daraus den internen Takt.
>
Ach mist - da hab ich doch was vergessen !!!

Genau da liegt schon mal das Problem, ich bin nicht in der Lage an Hand 
der Takte der jeweiligen Befehle auf die Frequenz des RC-Oszilators zu 
schliessen.

Hier nachträglich mein Programm :

;                       ATtiny26 im Auslieferungszustand
;

;.list
.include "tn26def.inc"      ;Label Zuweisungen

;Konstanten Zuweisungen
;.equ    =   ;

;µC Pinbelegung
.equ led_ws     = PORTB6    ;LED Weiss

;Einige Befehle arbeiten nur ab r16 aufwärts
.def a              = r16   ;Allgemeines Arbeitsregister A ( GPR_A )
.def b              = r17   ;Allgemeines Arbeitsregister B ( GPR_B )
.def c              = r18   ;Allgemeines Arbeitsregister C ( GPR_C )

;Prgrammspeicher festlegen
.CSEG       ;Code Segment ( Programmspeicher )
.ORG $0000  ;Programm beginnt bei Adresse 0


;Interuppt Vektoren
    rjmp RESET          ;Reset handler
    reti                ;rjmp EXT_INT0     ;IRQ0 handler
    reti                ;rjmp PIN_CHANGE  ;Pin change handler
    reti                ;rjmp TIM1_CMP1A   ;Timer1 compare match 1A
    reti                ;rjmp TIM1_CMP1B   ;Timer1 compare match 1B
    reti                ;rjmp TIM1_OVF     ;Timer1 overflow handler
    reti                ;rjmp TIM0_OVF       ;Timer0 overflow handler (Programmlaufanzeige)
    reti                ;rjmp USI_STRT     ;USI Start handler
    reti                ;rjmp USI_OVF     ;USI Overflow handler
    reti                ;rjmp EE_RDY     ;EEPROM Ready handler
    reti                ;rjmp ANA_COMP     ;Analog Comparator handler
    reti                ;rjmp ADCIRQ    ;ADC Conversion Handler

;-----------------------------------------------------------------------------
;Programmstart nach einem Reset ( Initialisierungen )
;-----------------------------------------------------------------------------
RESET:

;Stack initialisieren
    ldi  r16,RAMEND         ;Setze den Stack-Pointer...
    out  SP,r16             ;...an das SRAM-Ende.

;RC-Oszilator kalibriren
.set w_osccal   = $c1
    ldi  a,w_osccal
    out  OSCCAL,a

;Ports initialisieren
    ldi  A,0b01000000       ;Ein,- oder Ausgang fuer...
    out  DDRB,A             ;...diesen Port bestimmen

;-----------------------------------------------------------------------------
;Hauptprogrammschleife ( HPS )
;-----------------------------------------------------------------------------
hps:
;ca. 81kHz
;    sbi  PORTB,led_ws       ;
;    cbi  PORTB,led_ws       ;6 Takte
;    rjmp hps                ;


;ca. 161kHz
    ldi  c,1<<led_ws        ;
    in   b,PORTB            ;
    eor  b,c                ;6 Takte
    out  PORTB,b            ;
    rjmp hps                ;

.exit

Bernd_Stein

[Piete (Gast)]

Bernd Stein schrieb:
> 123 schrieb:
>> Aus dem Takt leiten sich die Timertakte ab, die Formeln stehen im
>> Datenblatt. Programmier einen Timer, messe den Output und errechne
>> daraus den internen Takt.
>>
> Ach mist - da hab ich doch was vergessen !!!
>
> Genau da liegt schon mal das Problem, ich bin nicht in der Lage an Hand
> der Takte der jeweiligen Befehle auf die Frequenz des RC-Oszilators zu
> schliessen.


123 meinte sicher einen Timer konfigurieren und über die OCR Register 
die OC output lines steuern. Dort dann die Frequenz messen und auf die 
interne zurückschließen. Da braucht man keine Takte im Programm zu 
zählen.

[123 (Gast)]

Piete schrieb:
> 123 meinte sicher einen Timer konfigurieren und ...
Genau.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Piete schrieb:
>
> 123 meinte sicher einen Timer konfigurieren und über die OCR Register
> die OC output lines steuern. Dort dann die Frequenz messen und auf die
> interne zurückschließen. Da braucht man keine Takte im Programm zu
> zählen.
>
Ohne Takte im Programm zählen zu müssen habe ich auch schon hinter mir.

;                       ATtiny26 im Auslieferungszustand
;
;.list
.include "tn26def.inc"      ;Label Zuweisungen

;Konstanten Zuweisungen
.equ w_osccal   = $Dc

;µC Pinbelegung
.equ led_ws     = PORTB6    ;LED Weiss

;Einige Befehle arbeiten nur ab r16 aufwärts
.def a              = r16   ;Allgemeines Arbeitsregister A ( GPR_A )
.def b              = r17   ;Allgemeines Arbeitsregister B ( GPR_B )
.def c              = r18   ;Allgemeines Arbeitsregister C ( GPR_C )

;Prgrammspeicher festlegen
.CSEG       ;Code Segment ( Programmspeicher )
.ORG $0000  ;Programm beginnt bei Adresse 0

;Interuppt Vektoren
    rjmp RESET          ;Reset handler
    reti                ;rjmp EXT_INT0      ;IRQ0 handler
    reti                ;rjmp PIN_CHANGE    ;Pin change handler
    reti                ;rjmp TIM1_CMP1A    ;Timer1 compare match 1A
    reti                ;rjmp TIM1_CMP1B    ;Timer1 compare match 1B
    reti                ;rjmp TIM1_OVF      ;Timer1 overflow handler
    rjmp TIM0_OVF       ;Timer0 overflow handler 
    reti                ;rjmp USI_STRT      ;USI Start handler
    reti                ;rjmp USI_OVF       ;USI Overflow handler
    reti                ;rjmp EE_RDY        ;EEPROM Ready handler
    reti                ;rjmp ANA_COMP      ;Analog Comparator handler
    reti                ;rjmp ADCIRQ        ;ADC Conversion Handler

;-----------------------------------------------------------------------------
;Programmstart nach einem Reset ( Initialisierungen )
;-----------------------------------------------------------------------------
RESET:

;Stack initialisieren
    ldi  r16,RAMEND         ;Setze den Stack-Pointer...
    out  SP,r16             ;...an das SRAM-Ende.

;Timer0 intialisieren 
    in   a,TCCR0            ;Timer/Counter0 Control Register laden...
    ori  a,1<<CS00          ;...und Timertakt = Systemtakt/ 1...
    out  TCCR0,a            ;...Timertakt = 1MHz => 1µs einstellen...
    in   a,TIMSK            ;Timer/Counter0 Maskenregister laden und...
    ori  a,1<<TOIE0         ;...Timer/Counter0 Overflow Interrupt... 
    out  TIMSK,a            ;...enablen (TOIE0)

;Calibrationsbyte anpassen
    ldi  a,w_osccal
    out  OSCCAL,a

;Ports initialisieren
    sbi  DDRB,led_ws        ;LED_Weiß Portpin als Ausgang


    sei                     ;Globale Interruptfreigabe I-Bit (Bit7) im...
                            ;...SREG (Status Register) setzen.

;-----------------------------------------------------------------------------
;Hauptprogrammschleife ( HPS )
;-----------------------------------------------------------------------------
hps:
    rjmp hps

;******************************************************************************
;Anfang der Interruptserviceprogramme ( ISR )
;******************************************************************************
;
;******************************************************************************
;Timer0 Overflow Interuppt ist aufgetreten. Portpin toggeln
;******************************************************************************
TIM0_OVF: 
    ldi  c,1<<led_ws
    in   b,PORTB
    eor  b,c
    out  PORTB,b
    reti                    ;Ruecksprung aus der TIM0_OVF ISR


.exit

Bernd_Stein

[Karl H. (kbuchegg)]

Bernd Stein schrieb:

> Ohne Takte im Programm zählen zu müssen habe ich auch schon hinter mir.

Und?
Wo liegt jetzt das Problem?

Frequenzzähler an den Toggle-Pin, die Frequenz gemessen, das mal 128 
ergibt die µC-Taktfrequenz.

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

Mann kann auch die Befehlstakte auszählen.

Siehe Datasheet Befehlsübersicht.

Namaste

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Karl Heinz Buchegger schrieb:
> Bernd Stein schrieb:
>
>> Ohne Takte im Programm zählen zu müssen habe ich auch schon hinter mir.
>
> Und?
> Wo liegt jetzt das Problem?
>
Ich weiß es ja ebend nicht. Das Programm erzeugt eine Frequenz
von ca. 2,3kHz.
>
> Frequenzzähler an den Toggle-Pin, die Frequenz gemessen, das mal 128
> ergibt die µC-Taktfrequenz.
>
Würde dann ca. 291kHz ergeben. Aber das passt ja vorn und hinten nicht.

Wie kommst Du auf 128 ?

Verstehst Du jetzt mein Problem ?

Bernd_Stein

[Karl H. (kbuchegg)]

Bernd Stein schrieb:
> Karl Heinz Buchegger schrieb:
>> Bernd Stein schrieb:
>>
>>> Ohne Takte im Programm zählen zu müssen habe ich auch schon hinter mir.
>>
>> Und?
>> Wo liegt jetzt das Problem?
>>
> Ich weiß es ja ebend nicht. Das Programm erzeugt eine Frequenz
> von ca. 2,3kHz.

Vermessen?

> Wie kommst Du auf 128 ?

Weil die ISR alle 256 µC-Takte aufgerufen wird. Bei jedem Aufruf 
wechselt der Pin die Polarität. D.h. 2 Aufrufe sind für 1 'komplette' 
Schwingung notwendig.

[Magnus M. (magnetus)]

Karl Heinz Buchegger schrieb:
>> Wie kommst Du auf 128 ?
>
> Weil die ISR alle 256 µC-Takte aufgerufen wird. Bei jedem Aufruf
> wechselt der Pin die Polarität. D.h. 2 Aufrufe sind für 1 'komplette'
> Schwingung notwendig.

Dann wäre ich für den Faktor 512.

Schäm dich, Karl Heinz!

=)

[Karl H. (kbuchegg)]

Magnus Müller schrieb:

> Dann wäre ich für den Faktor 512.
>
> Schäm dich, Karl Heinz!

Bin schon in der Ecke :-)

[R. M. (rmax)]

Und mit einem Faktor von 512 kommt man bei den gemessenen 2,3kHz auf 
einen internen Takt von knapp 1,2MHz, was mir bei jungfräulicher CLKDIV 
Fuse durchaus plausibel erscheint.

[Christian B. (casandro)]

Der Grund warum man die Frequenz genau bestimmen will ist übrigen 
relativ einfach. Will man nur eine serielle Schnittstelle betreiben, 
kann es ausreichend und billiger sein, den internen RC-Oszillator 
einfach für ein zwei Temperaturen abzugleichen und dann dazwischen 
einzustellen.

Nicht jeder braucht einen Quarz.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

R. Max schrieb:
> Und mit einem Faktor von 512 kommt man bei den gemessenen 2,3kHz auf
> einen internen Takt von knapp 1,2MHz, was mir bei jungfräulicher CLKDIV
> Fuse durchaus plausibel erscheint.
>
Ja, das macht Sinn und kommt hin.

DANKE an alle die hier mitgewirkt haben und mir somit theoretisch und 
praktisch weitergeholfen haben.

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Christian Berger schrieb:
> Der Grund warum man die Frequenz genau bestimmen will ist übrigen
> relativ einfach. Will man nur eine serielle Schnittstelle betreiben,
> kann es ausreichend und billiger sein, den internen RC-Oszillator
> einfach für ein zwei Temperaturen abzugleichen und dann dazwischen
> einzustellen.
>
> Nicht jeder braucht einen Quarz.
>
Das sehen die Meisten anders.

Zeig doch mal Dein Programm das das kann.

Um einige Unstimmigkeiten diesbezüglich aus dem Weg zu räumen.


In den meisten Threads ist dies nämlich ein Problem, das nur sinnvoll 
mit einem Quarz gelöst werden kann. Das heißt ohne Quarz zu großer 
Ressourcen verbrauch für diese unbefriedigende Lösung mittels internen 
RC-Oszilator.

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd Stein schrieb:
>...
>

> ...
> hps:
> ;ca. 161kHz
> ;    sbi  PORTB,led_ws       ;2 Takte 
> ;    cbi  PORTB,led_ws       ;2 Takte
> ;    rjmp hps                ;2 Takte
>                              ;Entspricht 6 Takte. 2T High, 4T Low 
>                              ;1MHz / 6 = 166,67kHz
> ;ca. 81kHz
>     ldi  c,1<<led_ws        ;1 Takt
>     in   b,PORTB            ;1 Takt
>     eor  b,c                ;1 Takt
>     out  PORTB,b            ;1 Takt
>     rjmp hps                ;2 Takte
>                             ;Entspricht halber Periode. *2=ganze Periode
>                             ;1Mhz / 12 = 83,33kHz
> .exit
>

>
Hannes Lux hatte mich unter anderem darauf hingewiesen,
das die Überschriften der beiden Programmteile vertauscht sind
( 81kHz bzw. 161kHz ).

Jetzt ist es richtig

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hier mal was einfaches, um bei einen ATtiny13 den internen Takt zu 
ermitteln:

 sbi  DDRB,PB2  ;Portpin B2 als Ausgang und auf Low setzen.
_TOGGLE:
 sbi  PINB,PB2  ;2 Takte, Portpin B2 Toggeln
 rjmp _TOGGLE   ;2 Takte

.EXIT  ;Assemblieren beenden

Nun misst man die Frequenz an diesem Portpin und multipliziert diese mit 
acht. Alle vier Takte, wird der Portpin invertiert, so das die Periode 
acht Takte lang ist. Ein Takt entspicht somit, 8x der gemessenen 
Frequenz, welche die CPU-Taktfrequenz ist.

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Mann, Mann, Mann immer diese unnötigen Probleme.

Jetzt hab ich endlich den den AtMega88PA ( von Reichelt ) mit einem 
20MHz-Quarz am laufen und dann muss ich feststellen, das er nur 16MHz 
macht.

Den Quarz mit einer einfachen 74HC00 Testschaltung geprüft, der macht 
seine 20MHz auch wenn das Signal scheisse aussieht.

Macht euer AtMega88PA auch diesen scheiss ?

Beitrag "AtMega88PA mit 20MHz Quarz"


Bernd_Stein

[S. Landolt (Gast)]

Dass aus einem 20 MHz-Quarz, wie und womit auch immer, 16 MHz 
herauskommen sollen, ist nur sehr schwer vorstellbar.
  Also die Standardfragen: Wie sehen die Fuses des ATmega88PA aus, wie 
wird die Frequenz gemessen, also ohne Programm direkt per CLKO-Pin oder 
per Programm mit "Pin-wackeln"?

[Sempfdazugeber (Gast)]

Das ist doch wieder ohne den obligatorischen 10:1-Tastkopf gemessen.

Kein Wunder das das Signal da Scheise aussieht.

[Zweitsempft (Gast)]

Bernd S. schrieb:
> Macht euer AtMega88PA auch diesen scheiss ?

Sempfdazugeber schrieb:
> Kein Wunder das das Signal da Scheise aussieht.

Ausserdem ist die Kurvenform für die Frequenzgenauigkeit nicht
relevant. Auch bekommt man vom Hersteller des Prozessors
keine Garantie für irgendeine genaue Kurvenform.

Typische Anfänger-Korinthenkackerei ...

[Zweitsempft (Gast)]

Bernd S. schrieb:
> Mann, Mann, Mann immer diese unnötigen Probleme.

Wenn man die Frequenz genau messen will misst man nicht an den
Quarz-Pins direkt sondern benutzt einen Pin des Controllers
um einen Frequenz auszugeben die sich aus dem Takt des
Controllers ableitet. Damit vermeidet man eine Belastung des
Quarzes durch eine externe zusätzliche Last, also dem Tastkopf.

Wenn man wirklich ganz genau messen will dann nicht mit einem
DSO sondern mit einem Frequenzzähler. Ein DSO ist dafür nur
ein Schätzeisen (siehe auch Anzahl der Nachkommastellen).

[HildeK (Gast)]

Zweitsempft schrieb:
> Wenn man die Frequenz genau messen will misst man nicht an den
> Quarz-Pins direkt sondern benutzt einen Pin des Controllers
> um einen Frequenz auszugeben die sich aus dem Takt des
> Controllers ableitet.

Genau.
Und setzt die Fuse CKOUT und misst am PB0, der dann zum CLKO wird.
Kein Programm, nichts! Dort kommt genau die Oszillatorfrequenz heraus.

[c-hater (Gast)]

Bernd S. schrieb:

> In den meisten Threads ist dies nämlich ein Problem, das nur sinnvoll
> mit einem Quarz gelöst werden kann.

Nein. Es ist nur AM EINFACHSTEN mit einem Quarz zu lösen.

> Das heißt ohne Quarz zu großer
> Ressourcen verbrauch für diese unbefriedigende Lösung mittels internen
> RC-Oszilator.

Unsinn. Man muss einmal pro Exemplar die Offset der 
Takt/Temperatur-Kennlinie ermitteln, also "Kalibrieren" bei 
Inbetriebnahme. Für die Restlebenszeit genügt es dann, alle paar 
Sekunden mal die Temperatur messen und OSCCAL entsprechend der Kennlinie 
nachzujustieren. Das verbraucht so gut wie keine Rechenzeit und ist bei 
allen AVR8 mit internem Temperatursensor kinderleicht umzusetzen.

Ernsthaft stören tut das nur bei Anwendungen, die den ADC an den Grenzen 
seiner Leistungsfähigkeit betreiben. Da kann der eine eingeschobene 
Zyklus zur Temperaturmessung schon recht störend sein. Für alle anderen 
Anwendungen: Kinderkram, man muss einfach nur halbwegs programmieren 
können.

Genau die Abwesenheit dieser Fähigkeit scheint dein eigentliches Problem 
zu sein...

[tim (Gast)]

Bernd S. schrieb:
> Wie findet man möglichst genau die Frequenz des internen RC-Oszilators heraus ?

Weltempfänger mit Digitalanzeige und KW-Bereich, f-Offset vorher an 
einem Zeitzeichensender ermitteln.

[tim (Gast)]

tim schrieb:
> Bernd S. schrieb:
>> Wie findet man möglichst genau die Frequenz des internen RC-Oszilators heraus ?
>
> Weltempfänger mit Digitalanzeige und KW-Bereich, f-Offset vorher an
> einem Zeitzeichensender ermitteln.

Noch bequemer geht das mit einem RTL-SDR-Stick für 7 Euro von ebay und 
der kostenlosen Software SDR# (auch SDRsharp genannt).
Allerdings muss man für Frequenzen unter 25MHz noch einen Upconverter 
mit einem NE602 bauen (ist aber nicht schwer).

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

S. Landolt schrieb:
> Also die Standardfragen: Wie sehen die Fuses des ATmega88PA aus, wie
> wird die Frequenz gemessen, also ohne Programm direkt per CLKO-Pin oder
> per Programm mit "Pin-wackeln"?
>
Bitte hier kurz ein Blick drauf werfen, da sieht man alles zu den 
FUSE-Einstellungen.

Beitrag "AtMega88PA mit 20MHz Quarz"

Mit dem Oszilloskop. Siehe Foto ..NOK.

Ja, mit "Pin-wackeln". Der 3-Zeiler weiter oben hier im Thread. Die ist 
für mich die sicherste Methode um wirklich die Takterate der Befehle 
bestimmen zu können. Habe jedoch einen Programmierfehler gemacht : " 
rjmp  pc-2 ".

rjmp  pc-1 ist richtig.

Ist also alles in Ordnung mit den AtMega88PA's von Reichelt. Nur mit mir 
nicht ;-)

Die anderen "Fotos" sind zusätzlich mit programmierter CLKO-Fuse 
aufgenommen.
Wenn beide Signale ( XTAL1 & CLKO ) "gemessen" werden, kommt leider Mist 
heraus.


Bernd_Stein

[Joachim B. (jar)]

Bernd S. schrieb:
> Ein funktionierender Assemblercode wäre natürlich das Beste.

kennst du nicht den Beitrag die genaue Sekunde?

https://www.mikrocontroller.net/articles/AVR_-_Die_genaue_Sekunde_/_RTC

[HildeK (Gast)]

Bei dem Oszillogramm "20MHz_AtMega88PA_CLKO.jpg" müsstest du auch noch 
deine Messanordnung optimieren.
Eigentlich bei allen ...

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

HildeK schrieb:
> Bei dem Oszillogramm "20MHz_AtMega88PA_CLKO.jpg" müsstest du auch noch
> deine Messanordnung optimieren.
> Eigentlich bei allen ...
>
Ist halt Breadboard-Style.

Aber meinst du das verändert die gemessene Frequenz ?

Dann zeig mal deine "Fotos" mit AtMega88PA bei 20MHz.


Joachim B. schrieb:
> kennst du nicht den Beitrag die genaue Sekunde?
>
> https://www.mikrocontroller.net/articles/AVR_-_Die_genaue_Sekunde_/_RTC
>
Hatte mir das mal vor Jahren angeschaut. Jetzt ist es mir erstens zuviel 
zu lesen, zweitens nur Beispiele in C, das ich überhaupt nicht kann.


Bernd_Stein

[Zweitsempft (Gast)]

HildeK schrieb:
> Bei dem Oszillogramm "20MHz_AtMega88PA_CLKO.jpg" müsstest du auch noch
> deine Messanordnung optimieren.
> Eigentlich bei allen ...

Sehr wohl richtig. Der richtige Umgang mit Messmitteln scheint
noch nicht sehr weit entwickelt zu sein.

Sozusagen (höflicherweise) noch Luft nach oben.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hier mal ein C-Beispiel, dass auf einem ATmega 2560 Arduino-Board läuft 
( 16 MHz Quarz ).
Es wird der CTC-Mode 4 des Timer3 ohne Vorteilung benutzt.
Die gemessene Frequenz am PE3-Pin bzw. OC3A bzw. D05, ist mal 2 zu 
nehmen, dann weiß man die CPU-Frequenz.

void setup() {
  TCCR3A |=  0b01<< COM3A0; // OC3A-Pin Toggeln
  TCCR3A &= ~0b11<< WGM30;  // CTC-MODE 4
  OCR3A   = 0;              // Hoechste Frequenz
  DDRE   |= 1<< PE3;        // OC3A als Compare Match A Ausgang
  TCCR3B |=  0b01<< WGM32;  // CTC-MODE 4
  TCCR3B |=  0b001<< CS30;  // Vorteiler = 1 und Timer3 starten
  TCCR3B &= ~0b110<< CS30;  // Vorteiler = 1 und Timer3 starten
}

void loop() {
  // put your main code here, to run repeatedly:

}

Ob dass Aussehen des Rechtecksignals dem Boardlayout geschuldet ist, 
weiß ich nicht.


Bernd_Stein

[Adam P. (adamap)]

Bernd S. schrieb:
> Ob dass Aussehen des Rechtecksignals dem Boardlayout geschuldet ist,
> weiß ich nicht.

1) Den alten Beitrag zu kommentieren hätte nicht sein müssen.

2) Ja, ab einer bestimmten Frequenz sieht ein Rechtecksignal so aus, bei 
guter Auflösung. Das Board-Layout und Messvorrichtung spielt natürlich 
auch eine große Rolle dabei.

3) Einige ATmega haben die Option den Takt auf Port B2 (glaub ich) 
ausgeben zu lassen, dann brauchst kein Timer.

4) Wenn dir der Takt so wichtig ist, dass du ihn wissen möchtest, nutze 
einen externen?! Der Interne läuft so wie er halt läuft, +- halt.

5) Du kannst dir auch das *.lss File anschauen und dann die ASM Befehle 
raussuchen die in der Abfolge von einem Pin-Toggle zuständig wären, dann 
im Datenblatt die Takt Zyklen je Befehl raussuchen, summieren, Frequenz 
berechnen... Falls Langeweile besteht.

;)

[Veit D. (devil-elec)]

Bernd S. schrieb:
>

> void setup() {
>   TCCR3A |=  0b01<< COM3A0; // OC3A-Pin Toggeln
>   TCCR3A &= ~0b11<< WGM30;  // CTC-MODE 4
>   OCR3A   = 0;              // Hoechste Frequenz
>   DDRE   |= 1<< PE3;        // OC3A als Compare Match A Ausgang
>   TCCR3B |=  0b01<< WGM32;  // CTC-MODE 4
>   TCCR3B |=  0b001<< CS30;  // Vorteiler = 1 und Timer3 starten
>   TCCR3B &= ~0b110<< CS30;  // Vorteiler = 1 und Timer3 starten
> }
>

Das ist mehr wie Grauenvoll. Bitte nicht nachmachen.

[Norbert (der_norbert)]

Veit D. schrieb:
> Bitte nicht nachmachen.

Für diejenigen welche es dennoch möchten, bitte unbedingt vorher über 
operator prededence nachlesen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Norbert schrieb:
> operator prededence
https://www.urbandictionary.com/define.php?term=Prededence

Aber auch ich würde diese Zeilen auf 4 verkürzen und einfach den 
kompletten Registerwert mit jeweils 1 Zugriff reinschreiben.

Bernd S. schrieb:
> Ob dass Aussehen des Rechtecksignals dem Boardlayout geschuldet ist
Es ist mit hoher Wahrscheinlichkeit auch der Messanordnung geschuldet.

> Die gemessene Frequenz
Was meinst du, wie möglichst genau dein Oszi die Frequenz messen kann?

Bernd S. schrieb:
> um den RC-Oszi möglichst genau auf 1Mhz zu trimmen.
Schon dieser Ansatz ist unsinnig, wie man leicht erkennt, wenn man sich 
mal die Abhängigkeit von Versorgung und Temperatur sowie die 
Langzeitkonstanz des RC-Oszillators anschaut.

Und um den RC-Oszi möglichst genau zu trimmen gibst du am besten eine 
stabile externe Frequenz auf einen Pin und gleichst deinen Oszillator 
ber Software auf diese Frequenz ab.

Fazit: wenn du eine verlässliche Taktfrequenz brauchst, dann schließe 
einen externen Oszillator an. Die sind so winzig (3x2mm) und so billig 
(<50Cent), dass es erst bei sehr großen Stückzahlen was bringt, über 
eine Kalibrierung des RC-Oszillators nachzudenken. Und wenn man das tut, 
braucht man übrigens nicht "möglichst genau" kalibrieren, sondern es 
reicht aus, das "hinreichend genau" zu tun. Denn "möglichst 
genau/viel/weit/hoch/..." ist fast automatisch auch "möglichst teuer".

[Norbert (der_norbert)]

Lothar M. schrieb:
>> operator prededence
> https://www.urbandictionary.com/define.php?term=Prededence

Gratulation, du hast einen Tipp-Feuler gefunden. ;-)

[Klaus H. (hildek)]

Auch wenn es ein zweimal aufgewärmter, uralter Thread ist: warum 
schreiben hier alle ein Programm um die Taktfrequenz zu messen?
Ich setze in dem Fall die CKOUT-Fuse und dann kommt an einem Pin die 
Taktfrequenz heraus. Zumindest beim Tinyx5 weiß ich das sicher.
Und beim 2560 habe ich gerade nachgeschaut: dort auch, auf Port E, Bit 
7.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Beim hiesigen Tiny26 gibt es allerdings keine alternative Pinfunktion 
CLKO und auch keine zugehörige CKOUT Fuse mehr...

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Veit D. schrieb:
> Das ist mehr wie Grauenvoll. Bitte nicht nachmachen.
>
Was genau meinst Du ?
Habe das hierher ab ca. Minute 13 gucken:

https://www.youtube.com/watch?v=TMI0dmm7hv4

Klaus H. schrieb:
> ... warum
> schreiben hier alle ein Programm um die Taktfrequenz zu messen?
> Ich setze in dem Fall die CKOUT-Fuse und dann kommt an einem Pin die
> Taktfrequenz heraus...
>
An den FUSES zu manipulieren kann in die Hose gehen und ich glaube die 
Arduino-IDE kann dies gar nicht.

Bernd_Stein

[Norbert (der_norbert)]

Du möchtest maskieren und gezielt bits auf ›0‹ setzen.
Das ist gut.
Schau dir mal an was:

uint8_t x = ~ 3 << 3;

ergibt.

Schau dir dann an was:

uint8_t x = ~(3 << 3);

ergibt.

Nimm das was eher deiner Intention entspricht.

[Klaus H. (hildek)]

Lothar M. schrieb:
> Beim hiesigen Tiny26 gibt es allerdings keine alternative Pinfunktion
> CLKO und auch keine zugehörige CKOUT Fuse mehr...

Ja richtig. Das war der vor fast 12 Jahren angefragte Typ. Jetzt 
kürzlich ging es um den Mega2560.
Es gibt noch einige andere Dinge, die bei dem Tiny26 fehlen (z.B. WDI, 
PCINT-Maske), deshalb nehme ich lieber die neueren Varianten 
Tiny261/461/861, die pinkompatibel sind.

Bernd S. schrieb:
> An den FUSES zu manipulieren kann in die Hose gehen und ich glaube die
> Arduino-IDE kann dies gar nicht.

Nun, über die Arduinodinge weiß ich nichts. Aber die Fuse aktivieren ist 
mit einer brauchbaren IDE nicht wirklich ein Problem.

[Arduino F. (Firma: Gast) (arduinof)]

Klaus H. schrieb:
> Nun, über die Arduinodinge weiß ich nichts. Aber die Fuse aktivieren ist
> mit einer brauchbaren IDE nicht wirklich ein Problem.

Die Arduino IDE nutzt AVRdude.
Damit ist das Fuse setzen nicht das Problem.
Nur dass die IDE kein direktes UI dafür bietet, außer über die Boards 
Menüs.

Klarer:
Fuses setzen funktioniert über das anpassen der boards.local.txt oder 
boards.txt Dateien. Und anschließend über das "Bootloader brennen", 
selbst wenn kein Bootloader mit im Boot ist.

Bernd S. schrieb:
> An den FUSES zu manipulieren kann in die Hose gehen
Ja! (wenn man einen Bock schießt)
Aber ohne gehts auch nicht (immer)

Bernd S. schrieb:
> und ich glaube die
> Arduino-IDE kann dies gar nicht.
Dafür macht sie das aber ganz prächtig!

[Bernd G. (Gast)]

Mit dem Spektrumanalysator auf den Versorgungspin gehen. Abblock-C 
ausnahmsweise mal sehr klein oder ganz weglassen.

[Joachim B. (jar)]

Arduino F. schrieb:
> Fuses setzen funktioniert über das anpassen der boards.local.txt oder
> boards.txt Dateien. Und anschließend über das "Bootloader brennen",
> selbst wenn kein Bootloader mit im Boot ist

welcher Bootloader?

Der alte fette der 2k flash kostet?

Wenn ich bedenke das der Optiboot das mit nur 512 Byte schafft und somit 
1,5k vom knappen flash (328p) freischaufelt

[Daniel C. (Gast)]

Bernd S. schrieb:

> Das durch ändern des OSCCAL-Wertes sich die Frequenz ändert kann ich
> feststellen. Aber wie ich dann auf die tatsächliche Frequenz des

Ein dünnes Kabel ein oder zwei mal um den Aufbau wickeln und dann über 
einen 50-Ohm-Metallschicht- oder Kohlewiderstand an einen Spectrum 
Analyzer oder ein SDR an den 50-Ohm-Eingang anschließen.
Dann sollte sich die Taktfrequenz direkt im Spektrum ablesen lassen.

Ein RTL-SDR-Stick oder ein MSI2500-MSI001-Klon kosten ca. 10 bis 20€ bei 
der Bucht und sind für solche Messungen äußerst praktisch (Achtung, der 
RTL-SDR-Stick benötigt eventuell noch einen Down-Konverter für 
niedrigere Frequenzen, von da her würde ich den MSI2500-MSI001 
bevorzugen).

Nach meiner Erfahrung ist die Frequenz von internen RC-Oszillatoren 
ziemlich temperaturabhängig.

Ein ATMEGA hat einen CLKO-Pin (Clock-Out). Wenn man ihn in den Fuses 
aktiviert, kann man dort die Schwingfrequenz direkt als TTL-Pegel 
gewinnen (falls mal ein Umstieg auf einen anderen Controller-Typ 
ansteht).

[Arduino F. (Firma: Gast) (arduinof)]

Joachim B. schrieb:
> welcher Bootloader?

Warum schreibe ich:
Arduino F. schrieb:
> selbst wenn kein Bootloader mit im Boot ist.
?

Damit du das ignorierst?
Ach du hast das noch nicht einmal ignoriert.
Aber dafür null Komma gar nicht verstanden.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Joachim B. schrieb:
> welcher Bootloader?
>
> Der alte fette der 2k flash kostet?
>
> Wenn ich bedenke das der Optiboot das mit nur 512 Byte schafft und somit
> 1,5k vom knappen flash (328p) freischaufelt
>

https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/arduino-bootloader-brennen


Bernd_Stein