OSCCAL extrem?

Andreas B. schrieb:
> Hat jemand da belastbare Infos darüber?

Belastbar ist allein das Datenblatt, bei allem was darüber hinausgeht 
bist Du vollkommen auf Dich allein gestellt und kannst Dich auf nichts 
mehr berufen. Microchip wird jede Verantwortlichkeit abstreiten.

Und wenn im Datenblatt nichts darüber steht, daß die durch OSCCAL 
einstellbaren Frequenzen prinzipiell nicht nutzbar wären, wird es wohl 
funktionieren, mit den im Datenblatt genannten Einschränkungen.

Oliver

ploto schrieb:
> Link zum Datenblatt? Kapitel? In meinem gibt es kein OSCCAL Register.
S.339
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8495-8-bit-AVR-Microcontrollers-ATtiny441-ATtiny841_Datasheet.pdf
OSCCAL0, wenn Du kleinlich sein willst. ;-)

Bernd K. schrieb:
> Belastbar ist allein das Datenblatt, bei allem was darüber hinausgeht
Die Kurve steht ja drin.

Oliver S. schrieb:
> mit den im Datenblatt genannten Einschränkungen.
Da stehen eben keine.

In den ganzen Beschreibungen steht nur wie man den OSC auf 8MHz 
kalibriert. Das ist es ja gerade, was mich grübeln läßt.

Andreas B. schrieb:
> Oliver S. schrieb:
>> mit den im Datenblatt genannten Einschränkungen.
> Da stehen eben keine.
> In den ganzen Beschreibungen steht nur wie man den OSC auf 8MHz kalibriert.
Und im Abschnitt "6.6.3 OSCCAL0 – Oscillator Calibration Register" auch 
warum man das tun sollte:

1

Note that this oscillator is used to time EEPROM and Flash write accesses, 

2

and write times will be affected accordingly. Do not calibrate to more than 

3

8.8MHz if EEPROM or Flash is to be written. Otherwise, the EEPROM or Flash 

4

write may fail.

Lothar M. schrieb:
> Und im Abschnitt "6.6.3 OSCCAL0 – Oscillator Calibration Register" auch
> warum man das tun sollte:

Das ist ein Argument. ;-)
Danke!

Andreas B. schrieb:
> Da stehen eben keine.

Naja, eine hat ja Lothar schon  genannt, hier ist eine weitere, noch
engere:

1

The application software can write this register to change the

2

oscillator frequency. The oscillator can be calibrated to frequencies

3

specified in Table 25-2 on page 239. Calibration outside that range is

4

not guaranteed.

In besagter Tabelle steht:

1

Fixed freq. within:

2

7.3 – 8.1 MHz

Oliver S. schrieb:
> Und wenn im Datenblatt nichts darüber steht, daß die durch OSCCAL
> einstellbaren Frequenzen

Ich behaupte mal die einzige Frequenz die man garantiert damit 
einstellen kann ist die nominelle Frequenz. Keine andere.

Zum Beispiel könnte durch starke Exemplarstreuung die Einstellung von 
OSCCAL sowieso schon nahe am oberen oder unteren Limit stehen und die 
nominelle Frequenz gerade noch gerade so erreicht werden, dieses 
Exemplar wäre dann immer noch offiziell OK, aber OSCCAL ist schon nah am 
Limit und Du erreichst Deine gewünschte Frequenz bei diesem Exemplar 
schlichtweg nicht.

Am Ende stellst Du zum Beispiel fest daß nur noch bei einem Bruchteil 
der gekauften Exemplare die Frequenz wirklich so weit nach oben ziehen 
kannst, je extremer die gewünschte Frequenz desto mehr Ausschuss wirst 
Du haben und desto teurer wird der Spaß.

Ihr habt mich schon überzeugt. ;-)

Yalu X. schrieb:
> The oscillator can be calibrated to frequencies
> specified in Table 25-2 on page 239. Calibration outside that range is
> not guaranteed.

Das heißt nur, das garantiert wird, das man die angegebene Frequenz 
einkalibrieren kann.
Wenn man will kann man "beliebig" viel oder wenig dazutrimmen, nur wird 
nicht jeder Chip diese Werte erreichen.
Manche muss man extrem einbremsen, manche extrem beschleunigen für 8MHz, 
andersrum wird einer nur 2-8 MHz schaffen, ein anderer 7-17.
Laufen tut jeder mit jeder einstellbaren Frequenz, da es sich um einen 
RC-Oszillator handelt.
Grenzen nur gegeben durch Spannung und evtl. interne Timings wie oben 
genannt z.B. für Flash Write.

Yalu X. schrieb:
> aja, eine hat ja Lothar schon  genannt, hier ist eine weitere, noch
> engere:
>
> The application software can write this register to change the
> oscillator frequency. The oscillator can be calibrated to frequencies
> specified in Table 25-2 on page 239. Calibration outside that range is
> not guaranteed.

Da steht nur, daß ausserhalb der in der Tabelle genannten Werte keine 
Kalibrierung auf die in der Tabelle genannte Toleranz garantiert wird, 
nicht mehr und nicht weniger.

Ich lese das Datenblatt immer noch so, daß man OSCCAL0 im Programm in 
2-er Schritten auf 255 hochziehen kann, und der Prozessor dann mit 17MHz 
läuft (passende Betriebsspannug vorausgesetzt). EEPROM-Zugriffe  und 
Flash-Prorammierung tun es dann nicht mehr, alles andere so, wie es mit 
17Mhz RC-Takt halt funktioniert.

Das Problem "anschwingen" stellt sich auch nicht, da bei einem Reset 
immer der Factory-Calibration-Wert ins Register geschrieben wird.

Oliver

Ich würde mir keine eigenen Frequenzen ausdenken.
Im Datenblatt steht ja ... 16 MHz.

Nach unten hin sollten bei 6 MHz keine Probleme auftreten.

Aber die von Dir anvisierten 17 MHz ergeben sich nur aus einer 
"linearen" Interpretation der OSCCAL-Kennlinie.

Ich würde aber nichts, das mir was Wert ist, auf einen linearen 
Zusammenhang des OSCCAL-Wertes zur Frequenz wetten.

m.n. schrieb:
> Die Sache sehe ich eher pragmatisch: Bei knapp 1000 ATmega48 habe ich
> die OSCCAL auf 255 gesetzt, um die max. Geschwindigkeit des int.
> Oszillator nutzen zu können. Ausschuss = 0!

Aber wie groß ist die Streuung der rellen Taktfrequenz?
Der dort zitierte Ausschuss bezieht sich auf "läuft mit 17MHz", nicht 
"tut nix".

Jens M. schrieb:
> Yalu X. schrieb:
>> The oscillator can be calibrated to frequencies
>> specified in Table 25-2 on page 239. Calibration outside that range is
>> not guaranteed.
>
> Das heißt nur, das garantiert wird, das man die angegebene Frequenz
> einkalibrieren kann.

Du hast recht, so ist das wohl gemeint.

Oliver S. schrieb:
> Ich lese das Datenblatt immer noch so, daß man OSCCAL0 im Programm in
> 2-er Schritten auf 255 hochziehen kann, und der Prozessor dann mit 17MHz
> läuft.

Na dann probiers einfach aus. Was Du da herausliest steht da zwar nicht, 
stattdessen steht da schwarz auf weiß gedruckt daß nur Frequenzen von 
7.3MHz bis 8.1MHz garantiert erreicht werden können, aber wenn Du 
meinst...

Ich persönlich hätte arge Bauchschmerzen wenn ein Produkt davon abhängig 
wäre daß so ein Husarenstück definitiv funktioniert und ich meinen Kopf 
für so ein abenteuerliches Versprechen weit jenseits der Zusagen aus dem 
Datenblatt (Faktor 2 darüber!) hinhalten müsste.

Wenns gut geht hast Du Glück, wenn Du Pech hast stellt sich raus daß die 
Hälfte der extra für den Zweck gekauften Exemplare sich zum Beispiel 
nicht weiter 12 MHz ziehen lassen (was ja auch völlig OK wäre laut 
Datenblatt) und dann siehst Du alt aus!

m.n. schrieb:
> Die Sache sehe ich eher pragmatisch: Bei knapp 1000 ATmega48 habe ich
> die OSCCAL auf 255 gesetzt, um die max. Geschwindigkeit des int.
> Oszillator nutzen zu können. Ausschuss = 0!
> Sofern man das EEPROM beschreiben möchte, kann man den Oszillator ja
> temporär auf 8 MHz zurückstellen.

Das wäre eine Möglichkeit. Nur: Was hast Du von einer unbekannten 
Taktfrequenz. Meist hat man ja eine Anwendung, wo man einen Mindesttakt 
benötigt. Sonst bräuchte man ihn ja nicht hochzuschrauben.
Das Argument von Bernd K. ist da schon einleuchtend:

Bernd K. schrieb:
> Zum Beispiel könnte durch starke Exemplarstreuung die Einstellung von
> OSCCAL sowieso schon nahe am oberen oder unteren Limit stehen und die
> nominelle Frequenz gerade noch gerade so erreicht werden, dieses
> Exemplar wäre dann immer noch offiziell OK, aber OSCCAL ist schon nah am
> Limit und Du erreichst Deine gewünschte Frequenz bei diesem Exemplar
> schlichtweg nicht.

Für mich ist das EEprom Argument schon das ausschlaggebende, da ich 
während des Programmlaufs auf das EEprom schreiben möchte.

Je weiter man sich aus dem Fenster lehnt desto schneller werden die 
Haare grau! Und das ist ein irreversibler Prozess!

Bernd K. schrieb:
> Wenns gut geht hast Du Glück, wenn Du Pech hast stellt sich raus daß die
> Hälfte der extra für den Zweck gekauften Exemplare sich zum Beispiel
> nicht weiter 12 MHz ziehen lassen (was ja auch völlig OK wäre laut
> Datenblatt) und dann siehst Du alt aus

Wenn du genaue und garantierte Frequenzen brauchst, dann bleib in den 
angegeben Grenzen. Wenn die Anwendung es zulässt oder erfordert, daß der 
Prozessor einfach so schnell wie möglich läuft, dann schreib 255 ins 
Register, und lass ihn laufen. Laufen wird der, auf welcher Frequenz 
genau, ist nicht garantiert, und alles ist gut. Alt muß da niemand 
aussehen, solange man weiß, was man da tut.

Oliver

Oliver S. schrieb:

> Ich lese das Datenblatt immer noch so, daß man OSCCAL0 im Programm in
> 2-er Schritten auf 255 hochziehen kann

Ja.

> und der Prozessor dann mit 17MHz läuft

Nein. Die 17MHz sind ein typischer Wert und nicht garantiert.

Garantiert ist, daß du mindestens bis 8.1MHz kommst. Praktisch wird da 
sicher noch ordentlich Luft sein.


m.n. schrieb:
>> Aber wie groß ist die Streuung der rellen Taktfrequenz?
>
> Wenn ich nachgemessen hatte, waren die beiden ersten Stellen immer 17.

Und wie groß war deine Stichprobe?

Einen 8MHz Mikrocontroller mit 12 laufen lassen geht meistens noch. Aber 
mehr als das doppelte ist wohl gewagt.

Andererseits hat Texas auch lange ihre MSP430 im JTAG-IF mit 24 
betrieben, während das Datenblatt für genau diesen 16MHz als absolute 
max auswies.
Ganz so eng sah man das wohl dort auch nicht.

Roland E. schrieb:
> Einen 8MHz Mikrocontroller mit 12 laufen lassen geht meistens noch. Aber
> mehr als das doppelte ist wohl gewagt.

Das ist nicht das Thema: der Tiny841 läuft nach DB bei 5V bis 16MHz. 
Aber eben mit einem externen Quarz.

Andreas B. schrieb:
> Möglich wäre ja ein nicht Anschwingen oder ein instabiler Takt.
Erscheint mir für einen RC-Oszillator technisch unplausibel.

Andreas B. schrieb:
> Für mich ist das EEprom Argument schon das ausschlaggebende, da ich
> während des Programmlaufs auf das EEprom schreiben möchte.
Du müsstest dann zum EEPROM schreiben den µC eben heruntertakten. 
Allerdings darfst du das nicht auf einmal von 255 auf 25 machen, sondern 
immmer nur in Schritten kleiner 10, denn sonst kann es Laut Datenblatt 
beim Umschalten einen Glitch auf der Taktleitung geben und das Ding sich 
verstolpern...

Lothar M. schrieb:
> Du müsstest dann zum EEPROM schreiben den µC eben heruntertakten.

Das ist eine gute Idee. Aber ich werde doch zu einem einem Quarz 
greifen, da auch noch eine serielle Schnittstelle ansteht. Das kann man 
zwar beim Tiny841  auch mit OSCCAL gut in den Griff bekommen, aber in 
Verbindung mit den Einwänden von Bernd K. wird ein Quarz wohl das Beste 
sein. 14.746MHZ war das eigentliche Ziel, aber ich wollte nicht noch ein 
Faß wg. der Baurate aufmachen.

Andreas B. schrieb:
> 14.746MHZ war das eigentliche Ziel
Naja, auf 10ppm genau ist der RC-Oszillator sowieso niemals nicht 
stabil...  ;-)

Lothar M. schrieb:
> Andreas B. schrieb:
>> 14.746MHZ war das eigentliche Ziel
> Naja, auf 10ppm genau ist der RC-Oszillator sowieso niemals nicht
> stabil...  ;-)

Ja,ja. ;-)
Obwohl mir gerade auffällt, daß Du das Gegenteil schriebst was Du 
vermutlich meintest. ;-)

Arduino Fanboy D. schrieb:
> Youtube-Video "Altbayerisch für Einsteiger - Die doppelte Verneinung
> 2006"

Auch wenn ich mich jetzt als Preißn oute: Ich habe es mehr mit der 
Logik. ;-)

Was uebrigens sehr gut geht ist das Kalibrieren/Synchronisieren des RC 
Oszillators auf einem 32kHz Quarz. Sofern denn ein 32kHz Quarz da ist. 
Was also erst bei den Megas moeglich ist. Damit erreicht man zwar keine 
so hohe Aufloesung wie 14.746MHZ aber eben doch besser wie die 2% 
welches ein UART benoetigt. Die Kalibrierung macht man da mindestens bei 
jedem Einschalten.

Das einfachste Hausmittel ist, in einer Schleife ins OSCCAL 0-255 
reinzuschreiben und seriell auszugeben. Von den Werten, die in einem 
Terminalprogramm lesbar sind, sucht man sich den mittleren raus.
Das habe ich nämlich gerade gemacht.

Ich habe jetzt 2 Prozeduren, eine um OSCCAL auf default zu stellen (den 
Wert, den ich beim starten ausgelesen habe) und eine andere, um den 
OSCCAL Wert wie oben bestimmt aus den EEprom auszulesen (für 14.7 MHz).
Ich mache das einfach so, daß wenn an dieser Stelle im EEprom 0xFF steht 
(-> neuer Tiny), dann loopt er mit der Ausgabe wie oben beschrieben. 
Dann kann man an diese Stelle in die .eep Datei den entsprechenden Wert 
reinschreiben und die auf den Tiny laden. 0xFF kann man so für OSCCAL 
aus den EEprom nicht verwenden, aber das kann ich verkraften.
Lothars Idee mit den runtertakten für das EEprom hat mir irgendwie 
gefallen.

Alternativ ist auf der Platine ein Quarz vorgesehen. So ist alles 
abgedeckt: Für die Billigheimer und die Angsthasen. ;-)

digger schrieb:
> Müssen dann bei 8 bit Breite die einzelnen Stufen nicht viel zu gross
> sein ?

Das soll ja auch kein Quarzersatz sein. Microchip gibt dabei 1% 
Genauigkeit an. Für serielle Ausgaben reicht das.

Roland E. schrieb:
> Einen 8MHz Mikrocontroller mit 12 laufen lassen geht meistens noch. Aber
> mehr als das doppelte ist wohl gewagt.

auch wenn ich jetzt vielleicht verrissen werde,

im AtariST werkelte ein Floppy Controller WD1772 mit 8 MHz so 
spezifiziert, der wurde durch CB auf 12 MHz getrimmt für mehr als DD 
Disketten.
Ich hatte schon den WD1772-2 im ST und mal probehalber 16 MHz angelegt.
Es funktionierte prächtig, meine technische Erklärung ist, im Laufe der 
Waferfertigung wurden die Strukturen verkleinert was höhere Takte 
ermöglichte, aber nicht immer wurde das spezifiziert, es wurden 
weiterhin dieselben "Chips" gefertigt, mit kleineren Strukturen für mehr 
output aus den Wafern ohne zwingend die neuen Spez. zu veröffentlichen.

Alle Nachbauten meiner 16 MHz Schaltung funktionierte mit dem WD1772-2 
wie von Usern bestätigt wurden, damit konnte der ST HD Disketten mit 18 
Sektoren pro Track lesen und schreiben, HD LW vorausgesetzt, als 
Umschaltung 8/16 MHz diente das HD Loch.

m.n. schrieb:
> Der TO hat allerdings einen ATtiny841 und daß er die UART verwenden
> möchte, hätte er gleich sagen sollen!

Das habe ich bewußt nicht getan, um beim Thema zu bleiben.

c-hater schrieb:
> Falsche Einstellung, denn die Lösung für UART liegt doch auf der Hand:
> Statt auf 14,xx auf 7,xx tunen.

Das sehe ich anders: Ich wollte den uC auch schneller haben. Ich weiß 
schon warum ich das UART nicht angesprochen habe.
Ich merke schon: Die Diskussion geht jetzt gerade dahin, wo ich sie 
eigentlich nicht haben wollte. Aber da für mich ja schon alles geklärt 
ist, sehe ich das locker.

m.n. schrieb:
> Für die ist
> der interne Oszillator für USART tabu. Für mich übrigens auch ;-)

Tja, dann solltest Du Dich mal mit den neueren Tinys beschäftigen. Die 
Genauigkeit des RC Oszillators wird da nämlich mit 1% angegeben. 
Zusätzlich zum OSCCAL0 gibt es auch noch OSCTCAL0A und OSCTCAL0B mit 
denen man eine Temperaturkompensation einstellen kann.
Den Quarz habe ich nur vorgesehen, falls man die 15MHz nicht mehr mit 
OSCCAL0 erreichen kann (Einwand von Bernd K.). Der UART ist nicht der 
Grund dafür.

Andreas B. schrieb:
> c-hater schrieb:
>> Falsche Einstellung, denn die Lösung für UART liegt doch auf der Hand:
>> Statt auf 14,xx auf 7,xx tunen.
>
> Das sehe ich anders: Ich wollte den uC auch schneller haben.

Ach. Und wäre dir jetzt ein ScheiXX Zacken aus deiner ScheiXX Krone 
gebrochen, wenn du einfach beide Anforderungen genannt hättest?

Diese Salamitaktik geht mir dermaßen auf den Sack, daß ich wohl langsam 
damit anfangen muß, alle Accounts, die ich dabei erwische, auf eine 
Blacklist zu packen.

Axel S. schrieb:
> Diese Salamitaktik geht mir dermaßen auf den Sack, daß wohl langsam
> damit anfangen muß, alle Accounts, die ich dabei erwische, auf eine
> Blacklist zu packen.

Nochmal für Dich: Es gib mir nicht um den UART! Das sollte nicht das 
Thema dieses Threads sein.

RTFM schrieb:
> Alles darüber hinaus wird nicht vom Hersteller garantiert. Kannst du
> eventuell zum Basteln nutzen, erwarte aber nicht, dass das zuverlässig
> funktioniert.

Falsch gelesen.
Da steht "Calibration is not guaranteed", nicht "functon ist not 
guaranteed".
Also auf Deutsch: Es kann möglich sein, das du höher oder niedriger 
kalibrieren kannst, aber es ist nicht garantiert.
Eine funktion (oder nichtfunktion) ist weder garantiert, noch genannt 
oder ausgeschlossen.

Wenn der Chip auch mit externem Takt mit 16MHz spezifiziert ist, läuft 
er auch mit internem auf 16MHz (abgesehen von der vom internen Takt 
abhängigen EEPROM-Zeit).
Die Frage ist also nur, ob du die erreichen kannst...

Aha. Du willst den Controller einfach maximal schnell laufen lassen weil 
der Algorithmus schon Schrott ist... der interne RC setzt allerdings ein 
Limit. Allenfalls geht's schneller mit einem externen Oszillator. Unter 
geeigneten Bedingungen, natuerlich nicht garantiert, kannst du den 
Controller allenfalls sogar doppelt so schnell laufen lassen.

Das Uebertakten beginnt mit der maximalen Spannung. Das waere also die 
Maximal zulaessige Spannung, 6V, minus 100mV. Andere wuerde nun 
probieren plus 100mV. Und dann den Clock einfach hochdrehen solange es 
geht. dann 5% zurueck. Bedeutet allerdings die Temperatur sollte auch so 
kuehl bleiben.

Weil die Taktspezifikationen bei allen spezifizierten Bedingungen 
gelten. Bedeutet wenn die Bedingungen optimiert werden kann man hoeher 
takten.

Desgleichen mit tiefer Spannung. Wie hoch darf der Takt noch sein, wenn 
die Spannung immer kleiner wird. Das Problem bei kleiner Spannung ist 
allerdings in erster linie das EEPROM.

Ich persoenlich halte nichts von Uebertakten. Ich nehm aus EMV Gruenden 
lieber einen langsameren Takt. Denn mit dem Algorithmus kann man immer 
wieder einmal Faktor 2 schneller werden.

Es steht im Abschnitt über den Oszillator nirgends, das er nicht in die 
Extreme kalibriert werden darf oder bestimmte Werte oder Frequenzen 
verboten wären, nur das eine Kalbrierung auf Werte außerhalb 7,x-8,x 
nicht möglich sein kann. Nicht weil "219 und mehr nicht geht" sondern 
weil "255 schon das Maximum ist und da rennt er nunmal nur mit 8,2 wenn 
du ein schlechtes Teil hast".

Selbst der Timing-Abschnitt enthält nur den Hinweis, das bestimmte 
interne Hardware, die vom Timing des RCO abhängig ist, diesen in einem 
bestimmten Wertefenster benötigt.
Das heißt für mich, das es technisch keine Einschränkung gibt, den RCO 
frei schnauze zu kalibrieren, sofern man ein zwei Dinge beachtet:
- Keine Teile verwenden, die ihn benötigen (z.B. EEPROM/Flashwrite)
- Kein Overclocking (Betriebsspannung und Takt beachten)

D.h. sollte der Baustein 16MHz mit Quarz schaffen, kannst du ihn mit 
16MHz RC betreiben, wenn du nichts speichern musst.
Klar, powerst du einfach voll rein und er läuft mit 22MHz, ist das 
overclocking, das klappt nicht.
Aber mit o.g. Umständen beachtet und auf fMax kalibriert (also das was 
er lt. DaBla darf, nicht was der RCO hergibt) ist das Teil voll im 
Nennbetrieb und problemlos nutzbar.

Jens M. schrieb:
> s steht im Abschnitt über den Oszillator nirgends, das er nicht in die
> extreme kalibriert werden darf oder bestimmte Werte oder Frequenzen
> verboten wären, nur das eine Kalbrierung auf Werte außerhalb 7,x-8,x
> nicht möglich sein kann. Nicht weil "219 und mehr nicht geht" sondern
> weil "255 schon das Maximum ist und da rennt er nunmal nur mit 8,2".

So isses. Es darf der der ganze Wertebereich des Registers genutzt 
werden. Zugesichert werden damit Frequenzen zwischen 7.3Mhz und 8.1Mhz 
erreicht.

Laut Diagramm werden aber "typical" > 16Mhz erreicht.

Oliver

Arduino Fanboy D. schrieb:
> Im Datenblatt nennt sich das Dingen:
> Calibrated Internal 8MHz Oscillator
>
> Nirgendwo im Datenblatt sehe ich die Empfehlung damit was anderes
> anzustellen.
> Im Gegenteil!
> Es finden sich klare Ansagen, ab wann Flash und EEPROM Zugriffe versagen
> können.

Ja. und?
Calibrated ist das Teil, wenn du den Werkswert in OSCCAL schreibst. 
Check.
Internal? Check.
8MHz? Wenn man die einstellt: check.

Wo geht aus dieser Bezeichnung hervor, das man nicht auf 16MHz 
kalibrieren darf?
Das mag nicht funktionieren, aber es ist nicht verboten.
Und die Funktionseinschränkungen sind bekannt.
Der Witz ist ja: ich würde dir zustimmen, wenn da stände: "Do not use 
above 8.5MHz, the processor will be damaged".
Tut es aber nicht, da steht "EEPROM Write may fail".
Also lies genau und verstehe... :)

Joggel E. schrieb:
> Aha. Du willst den Controller einfach maximal schnell laufen lassen weil
> der Algorithmus schon Schrott ist.

Aha, Du kennst also meine Software.

> der interne RC setzt allerdings ein
> Limit. Allenfalls geht's schneller mit einem externen Oszillator. Unter
> geeigneten Bedingungen, natuerlich nicht garantiert, kannst du den
> Controller allenfalls sogar doppelt so schnell laufen lassen.

Doch das ist garantiert. Der Tiny841 läuft bis 16MMHz.

Joggel E. schrieb:
> Ich persoenlich halte nichts von Uebertakten.

Wo ist hier von Übertaken die Rede?

Arduino Fanboy D. schrieb:
> Nirgendwo im Datenblatt sehe ich die Empfehlung damit was anderes
> anzustellen.

Du wirst auch in keinem DB eine Empfehlungen finden, was man mit den uC 
alles machen kann.
Im DB ist die Kurve des RC Oszillator bis 17MHz gezeichnet. Dieser Tiny 
läuft auch bis 16MHz. So liegt ja auch die Schlussfolgerung nahe, daß 
man dies auch ausnutzen kann. Das mit den EEprom wußte ich vor Urzeiten 
mal, habe es aber mittlerweile wieder vergessen und auch überlesen. 
Insofern waren einige nützliche Hinweise hier im Thread zu finden.

Arduino Fanboy D. schrieb:
> Nirgendwo im Datenblatt sehe ich die Empfehlung damit was anderes
> anzustellen.

Dann lies nochmal den ganzen Abschnitt, hier mal ein Ausschnitt:

1

The application software can write this register to change the oscillator frequency.

2

... 

3

The lowest oscillator frequency is reached by programming these bits to zero. Increasing the register value increases the

4

oscillator frequency. A typical frequency response curve is shown in Figure 26-77 on page 293.

Die "typical frequency response curve" geht von ca. 6Mhz bei Wert 0 bis 
ca. 17Mhz beim Wert 255.

Und nicht ohne Grund wird darauf hingeweisen, nicht über 8.8Mhz zu gehen 
wenn Flash oder Eeprom genutzt werden sollen.

Empfohlen wird da zu Recht gar nichts, es wird schlich beschrieben, was 
dieses Register tut, und in welchen Grenzen.

Oliver

Stefan ⛄ F. schrieb:
> Ist nur eine Vermutung, nichts genaues weiß man nicht.

Das ist keine Vermutung, sondern steht im DB (ist oben verlinkt). Im 
Kapitel Clocksystem S.25 (fig. 6.1 clock distribution) ist es 
beschrieben.

Oliver S. schrieb:
> Und nicht ohne Grund wird darauf hingeweisen, nicht über 8.8Mhz zu gehen
> wenn Flash oder Eeprom genutzt werden sollen.

Und was zum Teufel soll man mit einem Controller anfangen, der das Flash 
(Programmspeicher!) nicht nutzen kann??? Damit ist doch das ganze 
Ansinnen, die Frequenz bis Ultimo zu ziehen, für die Tonne!
Gruß Rainer

Sorry, mag ja sein, aber im schon weiter oben zitierten Auszug

RTFM schrieb:
> Table 239 sagt genauer das hier:
> "Fixed freq. within:7.3 – 8.1 MHz"

steht weiter, dass Flash und EEprom außerhalb nicht genutzt werden kann 
(sinngemäß übersetzt).
Kommt mir jetzt aber auch komisch vor, denn mit einem 16MHz-Quarz läuft 
ja auch alles! Sehr merkwürdig...
Gruß Rainer

Rainer V. schrieb:
> (sinngemäß übersetzt)

Da musst du deinen Sinn nochmal nachkalibrieren lassen.
Da steht "write access", was jeder Sechstklässler mit "Schreibzugriff" 
übersetzen kann.

Nicht das Flash als Programmspeicher, das flash als Datenspeicher...

Oben wurde gefragt, wie man die RC Oszillatorfrequenz mit einem 32kHz 
Quarz genau einstellt, dH quasi frequenzlockt.

Bei einem Mega, welcher einen T2, dh 32kHz Kristall Oszillator fuer 
lowpower hat.
Der Timer2, getrieben vom 32kHz (Async Mode) produziert 1Hz und der 
Timer0 getrieben vom RC produziert bei Nennfrequenz 10ms Increments. Dh 
man such einen OscCal, welcher 100 Timer0-Ticks waehrend einem Timer2 
produziert. So etwa.

Mit einer  Binaersuche geht das sehr schnell die 8 Bits zu bestimmen.


Beschrieben unter : https://www.ibrtses.com/embedded/avrosccal.html

OK, sorry, habe ich überlesen...und ich will jetzt auch nicht mit meinen 
eigenen Fragen weitermachen. Werde das in einem neuen Faden fragen.
Gruß Rainer

Stefan ⛄ F. schrieb:
> Die Screenshots der Doku zeigen, dass der Flash bei Schreibzugriffen vom
> R/C Oszillator getaktet wird.

Das habe ich Dir am 7.2. aber schon geschrieben.

Ist denn RTFM so schwer? Da steht alles drin.

Oliver

Stefan ⛄ F. schrieb:
> Die Screenshots der Doku zeigen, dass der Flash bei Schreibzugriffen vom
> R/C Oszillator getaktet wird.

Ja, für mich ist es momentan sehr unübersichtlich! Auch wenn alles 
irgendwo klar steht...meine persönliche Ausgangsfrage war übrigens, ob 
der USART mit dem internen Oszillator funktioniert. Dabei bin ich über 
diese ganzen Geschichten und über diesen Faden gestolpert. Wenn der Osz. 
also bis über 16MHz gezogen werden kann, dann müßte man vor 
EEprom-Schreiben den Takt also so lange runtersetzen. Flash-Schreiben 
ist in einer Anwendung ja nicht so üblich oder? Dann bleibt da noch das 
Fuse-Bit, das den Takt durch 8 teilt. Bei 16MHz würde die CPU dann also 
mit 2MHz laufen. Wenn ich den Teiler disable, dann sollte die CPU mit 
"echten" 16MHz laufen und ich müßte die USART-Tabelle für 16MHz 
anwenden?
Hoffe, dass diese Fragen jetzt doch zu diesem Faden passen...
Gruß Rainer

Arduino Fanboy D. schrieb:
> Evtl solltest du mal über die neuen Tinys nachdenken....
> Die können intern 20MHz.
> Ganz offiziell.

Danke. Das wird wohl besser sein...aber es ist halt immer ärgerlich, 
wenn man plötzlich über Verständnissteine stolpert, die einen völlig 
überraschen :-)
Ich könnte...ob der TO das auch will...muß er selbst wissen.
Ich will eine UART-Verbindung von mindestens 38Baud und zwischen den 
empfangenen Bytes muß noch etwas gerechnet werden!
Gruß Rainer

Arduino Fanboy D. schrieb:
> über die neuen Tinys nachdenken

Bitte verzeih die Frage, aber was sind neuere Tinys?
Gruß Rainer

Hi, danke. Bin immer irgendwie bei ATtiny25/V / ATtiny45/V / ATtiny85/V 
hängen geblieben...
Gruß Rainer

Stefan ⛄ F. schrieb:
> Kommt halt auf die Anwendung an. Ich hab's noch nie genutzt. Das EEPROM
> ist aber auch betroffen.

Meine ich ja auch, aber auf EEprom zu verzichten, wäre schon bitter. Und 
Forth macht von Schreiben in Flash schon Gebrauch...aber meine Frage 
bleibt, mit internem Osz. UART zu betreiben und "zwischendurch" noch 
ordentlich rechnen zu können. Was der TO da für Anwendungen im Sinn hat, 
weiß ich natürlich nicht. Vielleicht hat ihn ja auch nur das 
"Hochtakten" an sich interessiert! M;it eindeutiger Anwort: Ja.
Gruß Rainer

Rainer V. schrieb:
> Stefan ⛄ F. schrieb:
>> Die Screenshots der Doku zeigen, dass der Flash bei Schreibzugriffen vom
>> R/C Oszillator getaktet wird.
>
> Ja, für mich ist es momentan sehr unübersichtlich! Auch wenn alles
> irgendwo klar steht...meine persönliche Ausgangsfrage war übrigens, ob
> der USART mit dem internen Oszillator funktioniert.

Tut er. Und zwar ganz hervorragend wenn man den Oszillator vorher 
kalibriert. Allerdings braucht man dazu keinen Uhrenquarz, sondern macht 
das einfach so, daß man ein Programm laufen läßt, das OSCCAL hochzählt 
und dabei USART Ausgaben macht (oben schon beschrieben)

> Wenn der Osz.
> also bis über 16MHz gezogen werden kann, dann müßte man vor
> EEprom-Schreiben den Takt also so lange runtersetzen.

So ist es, und zwar in kleinen Stufen. 16MHz ist aber eine schlechte 
Frequenz für UART Ausgaben. (-> Baudratenquarz)

> Flash-Schreiben
> ist in einer Anwendung ja nicht so üblich oder?
Normalerweise nicht, außer bei Bootloadern

> Dann bleibt da noch das
> Fuse-Bit, das den Takt durch 8 teilt. Bei 16MHz würde die CPU dann also
> mit 2MHz laufen. Wenn ich den Teiler disable, dann sollte die CPU mit
> "echten" 16MHz laufen und ich müßte die USART-Tabelle für 16MHz
> anwenden?
Ja, abgesehen davon daß 16MHz eine schlechte Frequenz für den USART ist. 
Wenn man einen Quarz einsetzt und den UART verwendet, sollte man einen 
14,746MHZ einsetzen. Hochdrehen auf 16MHz mittels OSCCAL macht hier auch 
keinen Sinn.

> Hoffe, dass diese Fragen jetzt doch zu diesem Faden passen...

Einigermaßen, aber den kompletten Thread hast Du nicht gelesen sonst 
wären manche Fragen von Dir hier so nicht aufgetaucht.

Andreas B. schrieb:
> Einigermaßen, aber den kompletten Thread hast Du nicht gelesen sonst
> wären manche Fragen von Dir hier so nicht aufgetaucht.

Doch, habe alles brav gelesen :-)
...aber wie schon gesagt, Bäume und Wald und die Frage des TO gegen die 
in meinem Kopf! Und meine Anforderung für mein derzeitiges Bastelprojekt 
ist eben "kein Quarz". Habe ich bisher noch nicht gemacht und es tauchen 
Fragen auf, die ich vorher nicht hatte...ist eben so...
Danke und Gruß Rainer

Andreas B. schrieb:
> So ist es, und zwar in kleinen Stufen. 16MHz ist aber eine schlechte
> Frequenz für UART Ausgaben. (-> Baudratenquarz)

Ideal ist 16 MHz nicht für UART aber doch schon mehr als ausreichend, je 
nach gewünschter Übertragungsrate.

Andreas B. schrieb:
> Hochdrehen auf 16MHz mittels OSCCAL macht hier auch
> keinen Sinn.

Würde beim Einsatz eines Quarzes auch keinen Sinn machen da OSCCAL eh 
nur auf den internen RC-Oszilator wirkt (der beim Atmega328P nur bis 8 
MHz geht) ;)

M. K. schrieb:
> Ideal ist 16 MHz nicht für UART aber doch schon mehr als ausreichend, je
> nach gewünschter Übertragungsrate.

Ja klar...dafür gibts ja die Tabellen...und ich möchte so 38Baud und 
dazwischen muß ich ein paar Takte rechnen :-)
Gruß Rainer

Oh, 38 Baud ist aber nicht viel, das dürfte eng werden für einen 16 MHz 
Quarz, in erster Linie aber weil das UBRR-Register nur 12 bit breit ist 
beim Atmega 328P wenn ich mich recht entsinne. Oder meinst du die eher 
typischen 38.4 kBaud? Die macht man problemlos mit einem 16 MHz Quarz am 
Atmega 328P.

M. K. schrieb:
> typischen 38.4 kBaud?

Ja...habe nur etwas lax geschrieben. Mich interessiert jetzt wirklich, 
ob ich das ohne Quarz hinkriegen kann. Habe mir eben noch die 
ATtiny416/816 Sheets runtergeladen. Da gehts ja offensichtlich mit 
intern und 20MHz! Würde mir reichen :-) muß gleich erst mal lesen...
Gruß Rainer

Beitrag "Re: ATMEGA 16 Crystal"

trotzdem nimmt man dafür einen Baudratenquarz. Dann hast Du freie 
Auswahl zwischen üblichen Baurate.

Eigentlich wollte ich hier gerade nicht diese Baudratengeschichten 
diskutieren. Das lief schon gefühlte 100.000x im uC net.
Bemühe doch mal die Suchfunktion.

Rainer V. schrieb:
> Ja...habe nur etwas lax geschrieben. Mich interessiert jetzt wirklich,
> ob ich das ohne Quarz hinkriegen kann. Habe mir eben noch die
> ATtiny416/816 Sheets runtergeladen.

Geht auch mit dem Atmega328P und dem internen Oscilator. Soll ein 
Einzelstück werden, oder?
Der Atmega328P kann 8 MHz mit dem internen Oszilator. Du solltest aber 
OCSCAL auf jeden Fall einen passenden Wert geben. Das geht mit wenigen 
Zeilen Code (Beispiel am Ende des Posts). Man zählt dabei das 
OSCCAL-Register hoch und sendet den Wert des Registers via UART an einen 
PC. In diesem Beispiel (vgl. Bild) würde ich OSCCAL auf 109 setzen, das 
ist der mittlere Wert, bei dem sich die Zeile gut lesen lies.

1

### Programm zur Bestimmung von OSCCAL ohne Frequenzgenerator ###

2

3

#include <stdlib.h>

4

#include <avr/io.h>

5

6

#include "uart.h"

7

8

int main(void) {

9

    uartSetup(9600); //UART auf 9600 Baud einstellen, keine Paritaet, ein Stoppbit

10

    char valueToSend[5];

11

    for (uint8_t i=0x00; i<0x7f; i++) {

12

        OSCCAL = i;

13

        uartSendString("OSCCAL is now: ");

14

        itoa(OSCCAL,

15

             valueToSend,

16

             10);

17

        uartSendString(valueToSend);

18

        uartSendString("\r\n");

19

20

    }

21

  for (;;) {

22

  }

23

  return 0; // never reached

24

}

M. K. schrieb:
> i<0x7f;

Warum läßt Du den nicht bis 0xFF gehen?
Diese Methode wurde übrigens schon 2x in diesem Thread erwähnt.

Andreas B. schrieb:
> Warum läßt Du den nicht bis 0xFF gehen?

Weil das von der Takt-Frequenz abhängt von wo bis wo man OSCCAL laufen 
lassen sollte. Steht IMO in der Application Note zur Kalibrierung des 
OSCCAL-Registers von Atmel/Microchip. In meinem Falle waren das 1 MHz 
und da sollte OSCCAL in diesem Wertebereich liegen. Lässt man es von 
0x00 bis 0xff laufen bekommt man zwei passende Werte.

Andreas B. schrieb:
> Diese Methode wurde übrigens schon 2x in diesem Thread erwähnt.

Erwähnt ja, aber Beispielcode sah ich dazu jetzt nicht und da ich den 
hier grade zur Hand hatte, dachte ich er sei hilfreich. Und obige Frage 
warum ich OSCCAL nur bis 0x7f laufen lasse zeigt IMO auch, dass nicht 
jeder in die erwähnte App-Note geschaut hat ;)

EDIT: wurd eigentlich die App--Note erwähnt? Ich meinte die AVR053/054 
;)

M. K. schrieb:
> Lässt man es von
> 0x00 bis 0xff laufen bekommt man zwei passende Werte.

Das mag sein. Aber wenn Du den nur bis 0x7F laufen läßt, kannst Du nicht 
sicher sein, die 8MHz hier zu erwischen. Das war ja gerade der 
(berechtigte) Einwand von Bernd K. daß man sich eben nicht auf die 
typische Frequenzkurve verlassen kann. Wenn Du also Pech hast, werden 
die 8MHz erst bei OSCCAL 230 erreicht.

M. K. schrieb:
> Erwähnt ja, aber Beispielcode sah ich dazu jetzt nicht und da ich den
> hier grade zur Hand hatte, dachte ich er sei hilfreich.

OK, für die C&P Leute nicht so schlecht. ;-)

Andreas B. schrieb:
> Das mag sein. Aber wenn Du den nur bis 0x7F laufen läßt, kannst Du nicht
> sicher sein, die 8MHz hier zu erwischen.

Ich verweise hier noch mal explizit auf die Application Note. Bei 8 MHz 
Zielfrequenz ist 0x7f die untere Grenze. Dein Hinweis ist zwar richtig 
aber er hinterlässt den Eindruck, dass du meinen Post nicht richtig 
verstanden hast.

M. K. schrieb:
> Ich verweise hier noch mal explizit auf die Application Note. Bei 8 MHz
> Zielfrequenz ist 0x7f die untere Grenze.
Du meintest vermutlich die obere Grenze. Trotzdem steht auch dort 
(http://ww1.microchip.com/downloads/en/appnotes/doc7653.pdf) keine 
Garantie daß mit OSCCAL < 0x7F die 8MHz erreicht werden.


m.n. schrieb:
> Wer das glaubt, sollte besser bei seinen "Bastel-Baudratenquarzen"
> bleiben.
> Ein flüchtiger Blick ins Datenblatt zeigt das Gegenteil!

(X) Du hast diesen Thread nicht gelesen. Wo steht im DB daß 8Mhz mit 
OSCCAL < 0x7F garantiert werden?

Andreas B. schrieb:
> Du meintest vermutlich die obere Grenze.

Nein, ich meinte tatsächlich untere Grenze, vergleiche dazu auch 
Diagramm "Figure 2: RC Oscillator Frequency vs OSCCAL value" aus der von 
dir verlinkten App-Note. ;)

M. K. schrieb:
> Andreas B. schrieb:
>> Du meintest vermutlich die obere Grenze.
>
> Nein, ich meinte tatsächlich untere Grenze, vergleiche dazu auch
> Diagramm "Figure 2: RC Oscillator Frequency vs OSCCAL value" aus der von
> dir verlinkten App-Note. ;)

Damit stimmt aber Dein Programm nicht überein. Dort läufst Du von 
0-0x7f.
Aber Du bleibst mir aber noch die Antwort schuldig wo im DB garantiert 
ist, daß mit <0x7f oder auch >0x7f die 8 MHz garantiert werden. Im Graph 
ist nur die Rede davon, daß OSCCAL 2 Bereiche hat, aber wo diese 
Bereiche liegen wird nur in einem typischen Diagramm dargestellt.
Das war ja die Diskussion davor. Lies das mal.

Andreas B. schrieb:
> Damit stimmt aber Dein Programm nicht überein. Dort läufst Du von
> 0-0x7f.

Zur Erinnerung:

M. K. schrieb:
> In meinem Falle waren das 1 MHz

Andreas B. schrieb:
> Aber Du bleibst mir aber noch die Antwort schuldig wo im DB garantiert
> ist, daß mit <0x7f oder auch >0x7f die 8 MHz garantiert werden.

Das habe ich zum einem nie behauptet, dass das DB das garantiert und b. 
klärt das die von dir verlinkte App-Note.

Irgendwie habe ich den Eindruck wir reden aneinander vorbei. Lassen wir 
das. Das gibt noch ein ewiges hin und her.

Arduino Fanboy D. schrieb:
> z.B. der ATTiny416 und seine Brüder

Super...danke...genau das, was ich gesucht habe!
Gruß Rainer

Hole das Thema jetzt noch mal nach vorn, weil es mich z.Z. brennend 
interessiert. Und es geht natürlich nicht immer nur darum, 1€ sparen zu 
wollen! Es kann auch schlicht um Platz gehen...
Also, "hochziehen" des RC-Oszi geht wohl bis an die individuelle Grenze 
des jeweiligen Chips. Allerdings braucht das EEprom und der Flash ein 
RC-Oszi von 8Mhz, zumindest bei Write-Operationen. Bei Auslieferung ist 
die "-/-8 Fuse" gesetzt. D.h. das System läuft erst mal mit 1Mhz, bis 
das Programm geflasht ist.

Wenn ich dann den "8-Teiler" wegnehme - die System-clock also 8Mhz 
beträgt - sollte EEprom und Flash-Write weiterhin möglich sein. Kann das 
jemand bestätigen? Finde darüber nichts in den diversen Datenblättern.

Weiterhin haben die neueren Attiny (die mir weiter oben empfohlen 
wurden) nun eine PLL-Einheit zur Erzeugung des Systemtakts. Das heißt 
für mich, ich habe den RC-Oszi auf 8Mhz und kann den Systemtakt über die 
PLL auf 16 oder 20Mhz einstellen. Leider finde ich dazu auch nichts in 
den Datenblättern. Was mir das ungute Gefühl gibt, dass ich das mit der 
PLL nicht verstanden habe :-)

Leider kann ich nach einem elenden Hardware-Crash momentan nicht mal 
schnell an einem Controller "herumspielen". Deshalb würde ich mich (so 
lange) über weitere Anregungen von euch freuen!
Gruß Rainer

Rainer V. schrieb:
> Und es geht natürlich nicht immer nur darum, 1€ sparen zu
> wollen! Es kann auch schlicht um Platz gehen...

oder um 2 I/O, die durch den Quarz verlorengehen

> Wenn ich dann den "8-Teiler" wegnehme - die System-clock also 8Mhz
> beträgt - sollte EEprom und Flash-Write weiterhin möglich sein. Kann das
> jemand bestätigen?

Ja

> Was mir das ungute Gefühl gibt, dass ich das mit der
> PLL nicht verstanden habe :-)

Die erzeugte PLL Frequenz ist nur für die CPU. Solange also die 
Grundfrequenz nicht geändert wird ist für das Eeprom alles gut

c-hater schrieb:
> Unsinn. Es gibt in JEDEM AVR8-DB eine Art Übersichtsschaltplan zur
> Verteilung der Takte. Und aus dem ist ganz klar zu entnehmen, dass der
> NVMC vom puren Takt es internen RC-Oszillator getimed wird, also
> logischerweise eventuelle Teiler (oder PLLs, auch die gibt's bei einigen
> Typen) in Richtung zum Systemtakt keine Rolle spielen.

Wie so oft hast gerade du die Frage nicht verstanden!

Andreas B. schrieb:
> Die erzeugte PLL Frequenz ist nur für die CPU. Solange also die
> Grundfrequenz nicht geändert wird ist für das Eeprom alles gut

Ja...es ging mir aber darum, ob die "Grundfrequenz" eben durch das 
FUSE-BIT "unzulässig" geändert wird!
Nun wird auch c-hater verstanden haben, was ich will :-)
Immerhin ist es schon ein kleiner Unterschied, ob ich mit 1Mhz oder mit 
8Mhz rechne!
Gruß Rainer

c-hater schrieb:
> U.a. eben diese Frage beantwortet dieses verdammte Schema aus dem
> verdammten Datenblatt, welches du mit einer rotzfrechen Ignoranz einfach
> nicht zur Kenntnis nehmen willst.

Hi Bubi, dort ist eben nicht zu sehen, was mit dem RC im Zusammenhang 
mit dem Systemtakt und der Fuse passiert!

Arduino Fanboy D. schrieb:
> Die hängen am 8MHz Takt des internen Oszilators-

Und genau das war meine Frage...wenn die Fuse für /8 nicht gesetzt ist, 
funktioniert das!!! Weiß gar nicht, ob die tausend ! ausreichen...oder 
bin ich jetzt völlig daneben?
Gruß Rainer

Stefan ⛄ F. schrieb:
> Die CLKDIV8 Fuse steuert den Prescaler des Systemtaktes. Beim Schreiben
> auf den Flash wird aber nicht der Systemtakt sondern der R/C Oszillator
> verwendet.

Ja, das sehe ich auch so. Also wird EEprom und Flash immer mit 8Mhz 
intern behandelt?!
Danke und GRuß Rainer

Also bei allem Respekt...Lese- und Schreibzugriffe auf Flash und EEprom 
gehen doch offensichtlich nicht über den Systemtakt! Sonst wäre die 
ganze Fragerei hier doch nicht nötig!
Gruß Rainer

Rainer V. schrieb:
> Also bei allem Respekt...Lese- und Schreibzugriffe auf Flash und
> EEprom
> gehen doch offensichtlich nicht über den Systemtakt! Sonst wäre die
> ganze Fragerei hier doch nicht nötig!
> Gruß Rainer

Guck nochmal ins DB (Bsp. Tiny841): 6.6.3. OSCCAL Oscillatior 
Calibration Register.

Ansonsten ist das hier:

Stefan ⛄ F. schrieb:
> Dann erkläre mir mal, wie der Mikrocontroller mit 16 oder 20 Mhz seine
> Befehle aus dem Flash lädt, wenn dieser mit nur 8 MHz getaktet ist.

ein sehr einleuchtendes Argument.

Solltest Du es immer noch nicht glauben, dann schick mal folgendes zum 
Tiny:
avrdude -p attiny841 -c usbasp -U eeprom:r:test.eep:i
das liest das EEprom aus und schreibt es als Datei.
Und dann:
avrdude -p attiny841 -c usbasp -U eeprom:w:test.eep:i
schreibt die Datei wieder zum Eeprom als Vergleich.
Was glaubst Du was schneller ist?

Rainer V. schrieb:
> c-hater schrieb:
>> U.a. eben diese Frage beantwortet dieses verdammte Schema aus dem
>> verdammten Datenblatt, welches du mit einer rotzfrechen Ignoranz einfach
>> nicht zur Kenntnis nehmen willst.
>
> Hi Bubi, dort ist eben nicht zu sehen, was mit dem RC im Zusammenhang
> mit dem Systemtakt und der Fuse passiert!

Aha. Du hast also die Funktion der CLKDIV8 Fuse nicht verstanden. Diese 
Fuse ändert nichts am RC-OSzillator, sondern setzt den 
Default-Teilerfaktor des PRESCALER Blocks (unten rechts im Bild).

Rainer V. schrieb:
> Also wird EEprom und Flash immer mit 8Mhz intern behandelt?!

Eine klare Ausdrucksweise wäre wünschenswert. Was zum Teufel meinst du 
mit "behandelt"?

Lesezugriffe auf den Flash werden selbstverständlich durch den CPU-Takt 
gesteuert. Die CPU braucht ihre Daten ja so schnell, wie sie gerade 
läuft. Und AVR haben im Gegensatz zu z.B. STM32 keine 
Einstellmöglichkeit von Waitstates beim Zugriff auf den Flash. Brauchen 
sie auch nicht, weil der Flash beim Lesen immer die Geschwindigkeit der 
CPU schafft (bis 20MHz je nach Typ und Betriebsspannung).

Nur: es geht bei der Einhaltung des 8MHz RC-Taktes gar nicht um 
Lesezugriffe auf das Flash. Es geht um die interne Realisierung von 
Schreib-/Löschvorgängen von Flash/EEPROM. Dafür wird der Takt des 
RC-Oszilators verwendet. Und zwar einerseits um das Timing zu steuern. 
Andererseits vermutlich auch, um eine Ladungspumpe zur Erzeugung der 
benötigten Spannung anzutreiben. Details nennt der Hersteller hier 
nicht, aber wenn man weiß wie Flash/EEPROM arbeitet, erschließt sich das 
von selbst.

Und nochmal: die ganze Diskussion wäre nicht nötig gewesen, wenn du 
einfach mal sprachlich sauber formuliert hättest.

Ja, saubere Formulierung...fällt halt schwer, wenn man etwas zu 
verstehen versucht. Also nur Schreib-Operationen laufen mit dem RC-Oszi 
und der sollte bei 8Mhz liegen. Das Teiler-Fuse-Bit wirkt nur auf den 
CPU-Takt. Ist es nicht gesetzt, läuft die CPU auch mit 8Mhz und 
Schreiben auf Flash und EEprom und Lesen ist uneingeschränkt möglich.
Danke für die Geduld und Gruß, Rainer

Ja, klar. Die Frage des TO und auch meine bezog sich aber auf den 
Betrieb mit dem RC-Oszi...
Gruß Rainer