Hallo, mit OSCCAL läßt sich ja bekanntermaßen an der Frequenz des RC Oszillators bei den AVRs rumschrauben. Wenn man sich z.B. das DB des Tiny841 anschaut, dann sieht man den Graphen bis ca. 17MHz hochgehen. Spricht eigentlich etwas dagegen, den Tiny bei z.B. 16MHz mittels RC Oszillator laufen zu lassen. Das DB schweigt sich dazu aus. Möglich wäre ja ein nicht Anschwingen oder ein instabiler Takt. Hat jemand da belastbare Infos darüber?
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.
Andreas B. schrieb: > Wenn man sich z.B. das DB des Tiny841 anschaut, dann sieht man den > Graphen bis ca. 17MHz hochgehen. Link zum Datenblatt? Kapitel? In meinem gibt es kein OSCCAL Register.
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.
:
Bearbeitet durch User
Andreas B. schrieb: > In den ganzen Beschreibungen steht nur wie man den OSC auf 8MHz > kalibriert. Deswegen heißt das Ding ja auch: Calibrated Internal 8MHz Oscillator Andreas B. schrieb: > Das ist es ja gerade, was mich grübeln läßt. Ich finde, da muss man nicht mehr grübeln....
Beitrag #6131631 wurde von einem Moderator gelöscht.
Beitrag #6131635 wurde von einem Moderator gelöscht.
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ß.
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
:
Bearbeitet durch User
Bernd K. schrieb: > 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ß. 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.
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.
Sebastian S. schrieb: > Aber die von Dir anvisierten 17 MHz ergeben sich nur aus einer > "linearen" Interpretation der OSCCAL-Kennlinie. Die ergeben sich auch in der Praxis, wenn man das einmal nachmisst.
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!
Jens M. schrieb: > Aber wie groß ist die Streuung der rellen Taktfrequenz? Wenn ich nachgemessen hatte, waren die beiden ersten Stellen immer 17. Das ergibt etwa die doppelte Geschwindigkeit gegenüber "normaler" Einstellung. Genaues Timing ist bei solch einem Vorhaben nicht relevant. Wenn doch, dann muß man eben zu einem ext. Quarz greifen. Bernd K. schrieb: > Ich persönlich hätte arge Bauchschmerzen Dann lasse es sein aber füttere hier nicht die Angsthasen.
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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. ;-)
:
Bearbeitet durch User
Andreas B. schrieb: > daß Du das Gegenteil schriebst Du meinst die doppelte Verneinung? https://www.youtube.com/watch?v=W-IgKVvrxzA
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. ;-)
Andreas B. schrieb: > Spricht eigentlich etwas dagegen, den Tiny bei z.B. 16MHz mittels RC > Oszillator laufen zu lassen. Nein, hab ich auch schon gemacht. Kalibriert habe ich mit einem Uhrenquarz (32,... kHz) am Timer 2 und für die UART-Übertragung wurde der Takt auf eine Baudratenfrequenz runtergedreht. Wenn natürlich ständig über UART was übertragen werden soll, kann man nicht permanent das Maximum einstellen. Bei mir lag der maximale RC-Takt bei ca. 15 MHz.
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.
:
Bearbeitet durch User
m.n. schrieb: > Bei knapp 1000 ATmega48 habe ich die OSCCAL auf 255 gesetzt, um die max. > Geschwindigkeit des int. Oszillator nutzen zu können. Ausschuss = 0! Also für ein kommerzielles Produkt? Wäre es da nicht sinnvoller einfach einen Controller zu nehmen, der so hohe Taktraten garantiert kann, z.B. via PLL? So eine Bastelei ist ja nicht alternativlos...
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. ;-)
ich wunder mich über den Sinn eines Kalibrier-registers, wenn ich mit maximalem Wert mehr als das doppelte der Grundfrequenz errreiche. Müssen dann bei 8 bit Breite die einzelnen Stufen nicht viel zu gross sein ?
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.
:
Bearbeitet durch User
Axel S. schrieb: > Und wie groß war deine Stichprobe? Das ist > 10 Jahre her und ich weiß es nicht mehr. Die genaue Frequenz war auch unerheblich. Ein paar ATmega48 (14/2015) habe ich noch bestückt auf Mustern gefunden und mit OSCCAL = 255 getestet: 1 x 15,6 MHz, 2 x > 16 MHz und 5 x > 17 MHz. Beim dem 15,6 MHz Teil habe ich mal Vcc von 4 - 5,2 V variiert. Die ersten drei Stellen blieben konstant. Für mich bedeutet das, daß der Taktgeber bei Fmax durchaus nicht "aus dem letzten Loch pfeift". Der TO hat allerdings einen ATtiny841 und daß er die UART verwenden möchte, hätte er gleich sagen sollen! Für "Bastler" hat Microchip mit seinen neueren(beispielsweise) ATtiny202 - 817 jetzt auch typ. Kurven für den Abgleich des internen 20 MHz Taktes von 12 - 29 MHz ins Datenblatt aufgenommen.
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.
Andreas B. schrieb: > 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. Falsche Einstellung, denn die Lösung für UART liegt doch auf der Hand: Statt auf 14,xx auf 7,xx tunen. Schon sind einerseits die Bedingungen für die typischen UART-Bitraten gut und andererseits bleibst du im garantierten Bereich bezüglich der mit 1% Genauigkeit erreichbaren Taktfrequenz. Das dann noch kombiniert mit einer sinnvollen Autobaud-Routine und alles ist schick.
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.
:
Bearbeitet durch User
Andreas B. schrieb: > 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). Das alles um 20 ct für einen Quarz zu sparen? Mann, mann, mann ... > Alternativ ist auf der Platine ein Quarz vorgesehen. So ist alles > abgedeckt: Für die Billigheimer und die Angsthasen. ;-) Dann gehörst Du mit Deinem "Angstquarz" zu den Angsthasen. Für die ist der interne Oszillator für USART tabu. Für mich übrigens auch ;-)
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.
Beitrag #6133926 wurde von einem Moderator gelöscht.
Beitrag #6133927 wurde von einem Moderator gelöscht.
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.
:
Bearbeitet durch User
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.
Beitrag #6133952 wurde von einem Moderator gelöscht.
Andreas B. schrieb:
>Das DB schweigt sich dazu aus.
Stimmt doch gar nicht!
Das Datenblatt sagt:
"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."
Table 239 sagt genauer das hier:
"Fixed freq. within:7.3 – 8.1 MHz"
Alles darüber hinaus wird nicht vom Hersteller garantiert. Kannst du
eventuell zum Basteln nutzen, erwarte aber nicht, dass das zuverlässig
funktioniert.
Wenn da steht <8,1MHz, dann laufen 16 nie zuverlässig. Das ist zum
justieren gedacht, nicht zum Ändern der Frequenz.
Beitrag #6133967 wurde von einem Moderator gelöscht.
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.
:
Bearbeitet durch User
Jens M. schrieb: > 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. Ohje... Der Abschnitt bezieht sich auf die erwähnte Kalibrierung. Die ist dazu gut, den internen RC um Kleinbeträge genau auf 8MHz zu ziehen. Zu justieren. Das ist nützlich, wenn man z.B. eine UART betreiben muss. Wenn etwas dazu gedacht ist, um Abweichungen von maximal (!!!!) 0,1MHz auszugleichen, dann weiß man einfach, dass das nicht das geeignete Verfahren ist, um die Frequenz zu *Verdoppeln". Dazu wäre eine Einstellung um Faktor 80 höher, als im Datenblatt steht. Niemand mit mehr als einer halben funktionierenden Gehinzelle hält das für eine gute Idee.
Joggel E. schrieb: > Ich persoenlich halte nichts von Uebertakten. Von Übertakten ist hier nirgendwo die Rede. > Ich nehm aus EMV Gruenden > lieber einen langsameren Takt. Denn mit dem Algorithmus kann man immer > wieder einmal Faktor 2 schneller werden. Gute Idee, nur wie willst Du mit einem 32 kHz Takt eine ISR in 5 µs durchlaufen? Oder zeigt mir den Algorithmus, der einen Timer unter den genannten Bedingungen mit 8 MHz laufen läßt? EMV-technisch ist der interne Oszillator sicherlich die beste Wahl.
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.
:
Bearbeitet durch User
Datenblatt schrieb: > Niemand mit mehr als einer halben funktionierenden Gehinzelle hält das > für eine gute Idee. Sorry, aber um sich selber erfolgreich verarschen zu können ist ein Anzahl von drei das Minimum. Man könnte soweit gehen: > Je intelligenter jemand ist, desto besser kann > er/sie/es sich selber hinters Licht führen. Jens M. schrieb: > Das heißt für mich, das es technisch keine Einschränkung gibt, 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.
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.
:
Bearbeitet durch User
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
Ich vermute, dass der Zugriff auf den Flash Speicher beim Flashen ebenfalls von diesem Taktgeber gesteuert wird. Womöglich darf man dabei mit der Frequenz nicht allzu hoch gehen. Ist nur eine Vermutung, nichts genaues weiß man nicht.
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.
:
Bearbeitet durch User
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
Rainer V. schrieb: > 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! Du hast nicht verstanden, dass es bei dieser Einschränkung nur um das SCHREIBEN von Flash und und EEPROM geht. Lesender Zugriff funktioniert auch bei stark überhöhtem Takt des internen RC-Osillators jederzeit problemlos. Steht übrigens alles im DB. Liest nur keiner. Wie immer...
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.
Rainer V. schrieb: > Kommt mir jetzt aber auch komisch vor, denn mit einem 16MHz-Quarz läuft > ja auch alles! Sehr merkwürdig... Schau dir einfach das Übersichtsschema zu den Takten an. Dann könntest vielleicht sogar du diese (nur scheinbare) Diskrepanz begreifen... Es ist einfach so, dass die Schreibmimik auf die langsamen Speichertypen vollkommen abgekoppelt ist vom Betriebstakt des Systems. Bei "neueren" Controllern (also "X"-Generation) ist das etwas hübscher rausgearbeitet, weil da der NVMC tatsächlich als Baugruppe beschrieben und nicht mehr verschämt versteckt wird.
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
:
Bearbeitet durch User
Joggel E. schrieb: > Nicht das Flash als Programmspeicher, das flash als Datenspeicher... Das ist dem Flash und auch dem NVMC vollkommen egal. Daten sind Daten und Code sind auch bloß Daten.
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
Rainer V. schrieb: > Kommt mir jetzt aber auch komisch vor, denn mit einem 16MHz-Quarz läuft > ja auch alles! Es kann durchaus sein, dass das Timing der Schreibzugriffe dennoch von R/C Oszillator gesteuert wird.
c-hater schrieb: >> Nicht das Flash als Programmspeicher, das flash als Datenspeicher... > Das ist dem Flash und auch dem NVMC vollkommen egal. Daten sind Daten > und Code sind auch bloß Daten. Es geht um die Zugriffsgeschwindigkeit. Das Lesen geschieht synchron zum CPU Takt. Das Schreiben von Daten aus dem laufenden Programm heraus wird womöglich vom R/C Oszillator getaktet.
Angehängte Dateien:
Die Screenshots der Doku zeigen, dass der Flash bei Schreibzugriffen vom R/C Oszillator getaktet wird.
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.
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
Rainer V. schrieb: > ..meine persönliche Ausgangsfrage war übrigens, ob > der USART mit dem internen Oszillator funktioniert. Das funktioniert. Es funktioniert besser, wenn der Takt gegen einen Uhrenquarz kalibriert wird. ca 1% Abweichung bei 8MHz intern sind erreichbar. Für 16MHz intern wird dir niemand garantieren können, dass du überhaupt an die 10% Abweichung herankommst. Das mögliche UART Kommunikationsversagen droht. Rainer V. schrieb: > den Takt also so lange runtersetzen. Da dauert, bzw. musst du langsam machen, sonst drohen Glitches. Das mögliche Versagen droht. Evtl solltest du mal über die neuen Tinys nachdenken.... Die können intern 20MHz. Ganz offiziell.
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
Andreas B. schrieb: > Das habe ich Dir am 7.2. aber schon geschriebe Ich weiß, trotzdem meinten einige, weiterhin raten und widersprechen zu müssen. Manchen Leuten helfen Bilder mehr als Worte (ich schließe mich da ein).
Rainer V. schrieb: > Flash-Schreiben ist in einer Anwendung ja nicht so üblich oder? Kommt halt auf die Anwendung an. Ich hab's noch nie genutzt. Das EEPROM ist aber auch betroffen.
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.
Angehängte Dateien:
-
OSC_Kalibration.png
1,9 KB
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.
:
Bearbeitet durch User
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 ;)
:
Bearbeitet durch User
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: > nur auf den internen RC-Oszilator wirkt (der beim Atmega328P nur bis 8 > MHz geht) ;) Andreas B. schrieb: > M. K. schrieb: > Wenn Du also Pech hast, werden > die 8MHz erst bei OSCCAL 230 erreicht. Wer das glaubt, sollte besser bei seinen "Bastel-Baudratenquarzen" bleiben. Ein flüchtiger Blick ins Datenblatt zeigt das Gegenteil!
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?
:
Bearbeitet durch User
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. ;)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Rainer V. schrieb: > 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, klar. > Finde darüber nichts in den diversen Datenblättern. 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. > 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 :-) Du bist bloß nicht in der Lage, das richtige Schema zu finden oder es zu verstehen. Dabei ist das beim AVR8 doch echt übersichtlich (insbesondere im Vergleich zu den 32-Bittern jeglicher Coleur...) > 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! Lies' einfach die verdammten Datenblätter in der Wartezeit. Da tust du wenigstens was nützliches.
Hi >Weiterhin haben die neueren Attiny (die mir weiter oben empfohlen >wurden) nun eine PLL-Einheit zur Erzeugung des Systemtakts. Nicht für den Systemtakt. Der läuft weiterhin mit 8MHz. Die PLL stellt ihren höheren Takt lediglich für IO-Einheiten zur Verfügung. MfG spess
Rainer V. schrieb: > 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
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
Rainer V. schrieb: > 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! Doch, du hast nur die Antwort nicht verstanden und insbesondere das verdammte Schema aus dem verdammten Datenblatt immer noch nicht rausgesucht oder immer noch nicht verstanden. > Ja...es ging mir aber darum, ob die "Grundfrequenz" eben durch das > FUSE-BIT "unzulässig" geändert wird! 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.
Beitrag #6150155 wurde von einem Moderator gelöscht.
Beitrag #6150177 wurde von einem Moderator gelöscht.
Angehängte Dateien:
spess53 schrieb: >>Weiterhin haben die neueren Attiny (die mir weiter oben empfohlen >>wurden) nun eine PLL-Einheit zur Erzeugung des Systemtakts. > > Nicht für den Systemtakt. Der läuft weiterhin mit 8MHz. Die PLL stellt > ihren höheren Takt lediglich für IO-Einheiten zur Verfügung. Doch, die PLL geht auch für den Systemtakt. Die richtige Einstellung für CKSEL vorausgesetzt...
Bernd schrieb: > Doch, die PLL geht auch für den Systemtakt. Aber nicht für Flash und EEPROM schreiben. Die hängen am 8MHz Takt des internen Oszilators-
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
Die CLKDIV8 Fuse steuert den Prescaler des Systemtaktes. Beim Schreiben auf den Flash wird aber nicht der Systemtakt sondern der R/C Oszillator verwendet.
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
Rainer V. schrieb: > Also wird EEprom und Flash immer mit 8Mhz intern behandelt?! Nein, Lesezugriffe werden vom Systemtakt gesteuert, das kann viel schneller sein. Ist das denn so schwer zu begreifen? Ich habe das schon vor 10 Tagen mit Bildern und Referenzen auf die Datenblätter erklärt. So langsam verliere ich echt die Geduld.
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: > Lese- und Schreibzugriffe auf Flash und EEprom > gehen doch offensichtlich nicht über den Systemtakt! 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. Nur die Schreibzugriffe werden vom R/C Oszillator getaktet. Außerdem steht das klipp und klar in den Dokumenten, auf die ich vor 10 Tagen hinwies.
Angehängte Dateien:
-
flash.png
13 KB
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
Rainer V. schrieb: > Ist es nicht gesetzt, läuft die CPU auch mit 8Mhz Nur wenn du den R/C Oszillator verwendest. Bei externer Taktquelle kann die Frequenz eine andere sein. > Schreiben auf Flash und Eeprom und Lesen ist uneingeschränkt möglich. Ist auch nur halb richtig. Es gibt Einschränkungen im unteren Bereich der Versorgungsspannung (<2V).
Ja, klar. Die Frage des TO und auch meine bezog sich aber auf den Betrieb mit dem RC-Oszi... Gruß Rainer
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.