F_CPU umschalten, gibt es etwas zu beachten?

Eine zu lange Taktpause wird ihn kaum ausser Tritt bringen. Ein zu 
kurzer Abstand zweier Taktflanken könnte das hingegen schon.

A. K. schrieb:
> Eine zu lange Taktpause wird ihn kaum ausser Tritt bringen. Ein zu
> kurzer Abstand zweier Taktflanken könnte das hingegen schon.

D.h. eine kleine garantierte Pause zwischen "aus" und "ein" notwendig?

Maxim B. schrieb:
> Wird funktionieren, wenn ich mit einem Portpin einfach zwei
> Quarzoszillatoren  durch Enable-Pin umschalte?
Was sagt denn das Datenblatt dazu?
1. du darfst keinen Zyklus mit < 62ns haben
2. du darfst keine Glitches mit < 25ns haben
3. du darfst die Taktfrequenz pro Zyklus nicht um mehr als 2% ändern.
Kannst du diese 3 Anforderungen mit deiner Schaltung garantieren?

> Z.B. 18,432 MHz und 20 MHz.
Auch dazu solltest du vor dem Einbau dieser Quarze unbedingt das 
Datenblatt ansehen. Der von dir ausgewählte Controller ist nur bis 
maximal 16MHz spezifiziert...

Lothar M. schrieb:
> du darfst die Taktfrequenz pro Zyklus nicht um mehr als 2% ändern.

Was für eine Mimose :( Dann hilft nur eine gute, langsame PLL.

Oder ein STM32G031J6M. Der hat einen internen RC-Oszillator, der sich in 
Schritten von 0.3% trimmen lässt. 20MHz und 18.432MHz sind ja in 
Wirklichkeit 19.2MHz ±4.17%. Man erzeugt also nominelle 38.4MHz 
STM32-CPU-Takt, teilt den durch 2 für exaktes Tastverhältnis und speist 
über den MCO-Pin den AVR. Je nach Bedarf wird der RC um + oder - 4% 
verstimmt.

Bonus: wahrscheinlich braucht man keinen Quarz, der interne RC ist mit 
max. ±1% von 0..85°C angegeben. Wenn das nicht reicht, kann man als 
externe Referenz z.B. den 1Hz-Takt einer RTC benutzen.

Endlich eine sinnvolle Anwendung für einen STM32 im SO-8 Gehäuse :)

Lothar M. schrieb:
>> Z.B. 18,432 MHz und 20 MHz.
> Auch dazu solltest du vor dem Einbau dieser Quarze unbedingt das
> Datenblatt ansehen. Der von dir ausgewählte Controller ist nur bis
> maximal 16MHz spezifiziert...

Ja, das ist traurig. ATMega2560 ist überhaupt nur für 4,5 - 5,5 Volt 
spezifiziert... Trotzdem arbeitet ganz gut auch mit 3,3 Volt.
Ich meine, wenn ich nichts für Militär oder Weltraum entwickle, ist 
alles nicht so streng.

Also, ich dachte, jemand hat schon praktische Erfahrungen mit 
Quarzumschalten... Dann muß ich einfach selber experimentieren...

Bauform B. schrieb:
> Oder ein STM32G031J6M. Der hat einen internen RC-Oszillator...

Ja, wenn STM32G031J6M mit AVR JTAGICE XPII und AVR Studio arbeiten 
könnte, so würde ich auch so machen. Aber vor dem ich Controllerfamilie 
wechsele, möchte ich aus dem Vorhandenen alles mögliche im Sinn Lehre 
herausschöpfen. Deshalb bleibe ich zuerst bei AVR.

Bauform B. schrieb:
> 20MHz und 18.432MHz sind ja in
> Wirklichkeit 19.2MHz ±4.17%. Man erzeugt also nominelle 38.4MHz
> STM32-CPU-Takt, teilt den durch 2 für exaktes Tastverhältnis und speist
> über den MCO-Pin den AVR. Je nach Bedarf wird der RC um + oder - 4%
> verstimmt.

Dann vielleicht einfach von ATMega selbst AD9835 als Taktquelle 
bedienen?

Ich habe übrigens schon auch gedacht, ob es was bringt, Quarze für 
Doppelfrequenz zu wählen und mit einem Trigger zu teilen. Mich 
interessieren z.Z. nicht die bestimmten Frequenzen sondern Prinzip 
selbst.

Pappsack schrieb:
> 14.7456 MHz / U2Xn=1
>
> Damit kannst Du beide Baudraten fahren und hast eine Abweichung von
> <0.1%.
> Abweichungen bis 2% können die meisten Anwendungen verkraften.

Danke!
diese Idee habe ich schon in Visier. Wenn ich nichts Besseres finde... 
Aber es wäre doch interessant, eine Möglichkeit zu finden, Quarze 
umzuschalten?

Vielleicht geht das doch, mit bestimmten Beschränkungen. Schließlich muß 
Mega während der Umschaltung weder in EEPROM schreiben ider noch etwas 
kritisches machen. Sie sollte eigentlich nur nach einem Tastendruck 
entsprechende Quarz ber Pin wählen, alles Andere kommt erst nach etwas 
Zeit...

Das ist aber komisch: Mega wirbt mit Taktfrequent bis DC. Von anderer 
Seite Beschränkung 2% pro Takt. Wie lange wird es dauern, von 16 MHz mit 
2% pro Takt bis DC zu gehen? Eine Unendlichkeit, nicht wahr? :)

Also, bleiben wir lieber bei der Frage. Ich möchte keine "modernen" 
Controller, ich möchte keine FPGA. Ich möchte nur Taktfrequenz für Mega 
umschalten und danach sollte alles auch arbeiten. Mehr nicht. :)

Um für alles mehr Klarheit zu geben:
ich habe Lust, einen Monitor zu machen, der alles Mögliche mit allen 
möglichen Frequenzen nehmen und zeigen kann: MIDI, USART, TWI, SPI... 
Deshalb kommen auch Baudraten in Frage, die nicht in Standartreihe 
passen: 31250 für MIDI, 200k, 250k, 500k und 1M für interne Zwecke.

Maxim B. schrieb:
> Ich möchte nur Taktfrequenz für Mega
> umschalten und danach sollte alles auch arbeiten.

ich möchte auch so viel bekomme es aber nicht, ausserdem widersprichst 
du dir selbst!

mal schreibst du:

Maxim B. schrieb:
> Ich brauche für ATMega2560 umschaltbare Baudraten für USART, die mit
> einem Quarz nicht möglich sind (31250 und 57600 bod)

dann wiederum

Maxim B. schrieb:
> Ich möchte nur Taktfrequenz für Mega
> umschalten und danach sollte alles auch arbeiten.

das sind 2 Paar Schuhe und von F_CPU leitet sich vieles ab als wird 
F_CPU umschalten nichts nutzen und ist falsch wenn der Takt so bleibt!

Dann mache doch lieber etwas was funktioniert, schalte die BAUDRATE um!

und bleibe in den sicheren Grenzen!

Joachim B. schrieb:
> Dann mache doch lieber etwas was funktioniert, schalte die BAUDRATE um!

Ich habe bisher gedacht, hier sind die Menschen, die etwas suchen und 
nicht diejenigen, die Standartlösungen etwa wie Smartphon und Arduino 
bevorzugen...

Maxim B. schrieb:
> Das ist aber komisch: Mega wirbt mit Taktfrequent bis DC. Von anderer
> Seite Beschränkung 2% pro Takt.

Das liegt daran, daß da im Verborgenen eine Art PLL/Taktgenerator 
werkelt, der auf größere Periodendauersprünge allergisch reagiert. Das 
wurde auch schon praktisch nachgewiesen.

> Controller, ich möchte keine FPGA. Ich möchte nur Taktfrequenz für Mega
> umschalten und danach sollte alles auch arbeiten. Mehr nicht. :)

Nö, du musst das gar nicht. Dein Problem ist sehr einfach mit der 
richtigen Quarzfrequenz lösbar. Mach es so und sei glücklich. Der Rest 
der Welt muss auch keine Quarze umschalten.

> ich habe Lust, einen Monitor zu machen, der alles Mögliche mit allen
> möglichen Frequenzen nehmen und zeigen kann: MIDI, USART, TWI, SPI...
> Deshalb kommen auch Baudraten in Frage, die nicht in Standartreihe
> passen: 31250 für MIDI, 200k, 250k, 500k und 1M für interne Zwecke.

Jaja, die eierlegende Wollmilchsau. Mach mal, viel Spaß!

Falk B. schrieb:
> Mach mal, viel Spaß!

Danke! Gerade um Spaß geht es mir. Mein Gehalt habe ich von Orgeln :)

Jetzt gleich kam noch eine Idee: ob Umschaltungsprozeß lockerer geht, 
wenn ich unmittelbar vor der Umschaltung interne Frequenzteiler 
aktiviere und nach der Umschaltung wieder auf 1 setze? Dann hat nur der 
Freuenzteiler alle Glitches und CPU bekommt Übergang etwas milder?

Programmierer schrieb:
> Ah, ein noch stärkeres Argument für einen modernen µC mit fraktionalem
> Teiler, welcher sehr viele Baudraten mit 3% Toleranzbereich kann, was
> für so ein Werkzeug sehr praktisch wäre. Wie viele Quarze man wohl
> bräuchte um genau so viele Baudraten per AVR hinzubekommen?

Ich fürchte, ich werde in viel zu kompliziertem Inneren eines ARM 
ertrinken. Zuerst möchte ich besser elementare Stufe absolvieren, mit 
AVR. Schließlich komponieren die Studenten zuerst immer ein Preludium 
und eine Fuge, nie gleich eine Sinfonie.

Wie viele Quarze? Nur zwei. 1x für Standartbaudraten, 1x für das Leben 
außerhalb von Standartbaudraten. Das reicht.

Maxim B. schrieb:
> Ich habe bisher gedacht

da gab es ganz früher einen Spruch,
aber gut, schalte was du möchtest, wenns klappt freu dich wenn nicht 
heul nicht.

Joachim B. schrieb:
> wenns klappt freu dich wenn nicht
> heul nicht.

Womit riskiere ich? Ein paar Euro für 5xPlatinen, noch ein paar Euro für 
SMD-Teile, mehr ist das nicht.

Ich wollte zuerst nur sehen, ob jemand das schon gemacht hat, um Fahrrad 
nicht zu entwickeln.

Maxim B. schrieb:
> Womit riskiere ich? Ein paar Euro für 5xPlatinen

ist nur Umweltmüll

Maxim B. schrieb:
> mehr ist das nicht.

klar wenn deine Zeit nichts wert ist!

Ich hatte auch schon mal 8MHz Chips mit 16MHz genutzt, wusste aber was 
ich mache und konnte es erklären, aber das hier ist ein freies Land, 
fast jeder darf fast jeden Unsinn treiben (ausser CoalTrucks fahren 
https://de.wikipedia.org/wiki/Rolling_Coal)

du drückst dich aber vor der Beantwortung warum du dir selber 
widersprichst!

Programmierer schrieb:
> Andersherum: Du versuchst direkt eine sehr anspruchsvolle Aufgabe zu
> lösen (Clock Multiplexing) welche viel Analogtechnik braucht; einen
> modernen µC zu verwenden wäre viel einfacher. Mit einem STM32 ist das
> Problem in 5 Zeilen Code gelöst; bei AVRs mit viel Hardware und
> Software-Aufwand.

AVR Studium hat Simulator, wo man zweifelhafte Code in Detail sehen 
kann, Assembler-Übersetzung schauen und auch Code selbst. Dann kann man 
das Gleiche über JTAG noch mal in Detail sehen, schon in Realität.
Für ARM habe ich solch Schaufenster nicht gefunden. Nicht in solchem Maß 
wie AVR hat.

Joachim B. schrieb:
> ist nur Umweltmüll
>
> Maxim B. schrieb:
>> mehr ist das nicht.
>
> klar wenn deine Zeit nichts wert ist!

Ich bin kein Mitglied von Grünen Partei. Ich habe ja Schule nicht 
geschwänzt.  :) Ich verdiene mit Elektronik auch kein Geld, das ist nur 
Hobby.

Maxim B. schrieb:
> Ich wollte zuerst nur sehen, ob jemand das schon gemacht hat, um Fahrrad
> nicht zu entwickeln.

Das hat bis jetzt niemand gemacht weil es absolut sinnlos ist.
Nimm den richtigen Quarz und mach es so wie oben schon beschrieben.

Programmierer schrieb:
> Hä? Alle ARMs haben JTAG/SWD-Unterstützung, mit welcher du mit sehr
> günstiger Debugging-Hardware alles Schritt-für-Schritt nachvollziehen
> kannst.

So bequem habe ich das nicht gefunden, wie für AVR. Immer schwarze 
Bildschirm und Textzeilen, keine grafische Darstellung von Register und 
Speicher... Das nervt. Dazu noch nur 3 Volt, das ist weniger günstig, 
als 5 Volt, wenn man gleich MOSFET am Ausgang hat...

Maxim B. schrieb:
> das ist nur
> Hobby.

dann darfst du natürlich deine Restlebenszeit verschwenden und auch mal 
zu keinem Ergebnis kommen, es ist deine Restlebenszeit!

Joachim B. schrieb:
> dann darfst du natürlich deine Restlebenszeit verschwenden und auch mal
> zu keinem Ergebnis kommen, es ist deine Restlebenszeit!

Immer doch besser als saufen, nicht war? :)
Manchmal bin ich nach einer Gruppe abends so genervt, hier hilft nur 
Lötkolben :)

Programmierer schrieb:
> Also eigentlich ist Tooling ein Argument
> für ARM, denn es gibt eine riesige Menge an Software dafür, von
> einfach+gratis bis extrem mächtig+sehr teuer.
>
> µVision ist ziemlich komfortabel und hat sogar Peripherie-Simulation für
> STM32; ist mir nur zu proprietär und Windows-lastig.

Irgendwann geht mein Computer mit Windows XP in Ewigkeit, dann mache ich 
alles mit Linux. Und dann... und dann...

Maxim B. schrieb:
> Immer doch besser als saufen, nicht war? :)

Das stimmt. Noch besser wäre es allerdings, vorher nachzudenken.
Ich mache das auch hobbymäßig. Trotzdem (oder gerade deshalb) ist mir 
meine Zeit für solch unsinnige Versuche zu schade.

Maxim B. schrieb:
> Standartbaudraten
Schreib bitte nicht ausdauernd immer "Standart" dort, wo "Standard" 
hingehört. Das tut dem Auge weh...

Maxim B. schrieb:
> Das ist aber komisch: Mega wirbt mit Taktfrequent bis DC. Von anderer
> Seite Beschränkung 2% pro Takt. Wie lange wird es dauern, von 16 MHz mit
> 2% pro Takt bis DC zu gehen? Eine Unendlichkeit, nicht wahr? :)
Viel alltäglicher wäre doch die andere Richtung: wie lange dauert es 
nach dem Einschalten, von 0 Hz auf 16 MHz zu kommen, wieviel sind 
0Hz+2%?
Also schon wieder so ein Fall von "Datenblatt nicht gelesen" und/oder 
"Datenblatt nicht verstanden". Denn diese 2% beziehen sich darauf, dass 
währenddessen der Controller samt sämtlicher Peripherie vom Timer bis 
zur seriellen Schnitte ganz "normal" und fehlerfrei weiterläuft.
Wenn dich das normale, fehlerfreie Weiterlaufen nicht interessiert (oder 
wenn du z.B. den Reset aktiviert hast), dann kannst du am Takteingang 
herumfrickeln, was du willst.

Maxim B. schrieb:
> Dazu noch nur 3 Volt, das ist weniger günstig, als 5 Volt, wenn man
> gleich MOSFET am Ausgang hat...
Aber viel günstiger für alle anderen ICs, die heutzutage oft ebenfalls 
auch nur 3,3V können. Nicht umsonst kommen hier ständig welche um die 
Ecke und suchen nach Pegelwandlern für ihren Andruiden.

Maxim B. schrieb:
> Ich möchte keine "modernen" Controller
das verlangt ja auch niemand, nur einen modernen Oszillator ;)
> ich möchte keine FPGA.
du hast selbst so neumodische DDS-Chips ins Spiel gebracht...
> Ich möchte nur Taktfrequenz für Mega
> umschalten und danach sollte alles auch arbeiten. Mehr nicht. :)

Dann nimm einen 4046 mit einem langsamen Filter, zwei einstellbare 
Frequenzteiler und einen Quarz (Frequenz ist ziemlich egal). Je mehr 
FlipFlops, umso mehr mögliche Frequenzen. Wenn der Frequenzbereich 
größer als 1:2 werden soll, spendier einen dritten Teiler.

Läuft mit 5 Volt, braucht keine IDE und keinen Simulator, kommt mit ICs 
aus dem vorigen Jahrtausend aus und funktioniert normalerweise mit dem 
ersten Layout. Welcher Komparator besser spielt und die 3 bis 5 
Filterbauteile kann man nachträglich noch optimieren.

Bauform B. schrieb:
> und funktioniert normalerweise mit dem
> ersten Layout.

Nö, leider nicht, weil (3):

Lothar M. schrieb:
> Was sagt denn das Datenblatt dazu?
> 1. du darfst keinen Zyklus mit < 62ns haben
> 2. du darfst keine Glitches mit < 25ns haben
> 3. du darfst die Taktfrequenz pro Zyklus nicht um mehr als 2% ändern.
> Kannst du diese 3 Anforderungen mit deiner Schaltung garantieren?

Andreas B. schrieb:
> Bauform B. schrieb:
>> und funktioniert normalerweise mit dem
>> ersten Layout.
> 3. du darfst die Taktfrequenz pro Zyklus nicht um mehr als 2% ändern.

Wenn das mit dem PLL-Filter alleine tatsächlich nicht zu schaffen ist, 
kann man immer noch den Sollwert in kleinen Schritten verstellen. Der 
Teiler zwischen VCO und AVR ist allerdings problematisch.

Falk B. schrieb:
> Das liegt daran, daß da im Verborgenen eine Art PLL/Taktgenerator
> werkelt, der auf größere Periodendauersprünge allergisch reagiert. Das
> wurde auch schon praktisch nachgewiesen.

Gibts die bei allen AVRs, oder nur bei manchen? Es gibt ja z.B. Tinys 
mit einer PLL für 64 MHz Timer-Takt.

Lothar M. schrieb:
> Wenn dich das normale, fehlerfreie Weiterlaufen nicht interessiert (oder
> wenn du z.B. den Reset aktiviert hast), dann kannst du am Takteingang
> herumfrickeln, was du willst.

Danke. Das ist eine gute Idee. Wenn anders nicht geht, dann kann nach 
F_CPU-Wechsel Programmreset kommen, Menu vorher in EEPROM, so sollte das 
gehen, denke ich... Oder wenn mit Programmreset nicht geht, dann nach 
F_CPU-Wechsel Reset-Pin kurz zu Erde und in Init vorherige Zustand aus 
EEPROM abfragen. Sowieso ist Frequenzwechsel etwas ganz 
außerordentliches und kommt nicht zu oft vor.

Bauform B. schrieb:
> Dann nimm einen 4046 mit einem langsamen Filter, zwei einstellbare
> Frequenzteiler und einen Quarz (Frequenz ist ziemlich egal).

Hier sehe ich nur ein Problem: Frequenz zu finden, um mit ganzzähligen 
Teiler beide Frequenzreihen zu schaffen... Hoffentlich nicht in 
100-Hz-Bereich? So würde Taktfrequenz zu lange brauchen, um in 
Stabilität zu kommen...
Außerdem denke ich, zwei Quarzgeneratoren brauchen weniger Platz auf der 
Platine, als 4046 + 4x IC-Teiler + Quarz +...

A. K. schrieb:
> Es gibt ja z.B. Tinys
> mit einer PLL für 64 MHz Timer-Takt.

Die leider PLL nur von internen RC-Takt haben können. Das entwertet PLL 
dort sehr.

Bauform B. schrieb:
> Dann nimm einen 4046 mit einem langsamen Filter, zwei einstellbare
> Frequenzteiler und einen Quarz (Frequenz ist ziemlich egal). Je mehr
> FlipFlops, umso mehr mögliche Frequenzen. Wenn der Frequenzbereich
> größer als 1:2 werden soll, spendier einen dritten Teiler.

Diese Idee gefällt mir mehr und mehr. Als einstellbarer Frequenzteiler 
kann Timer1 von ATMega dienen. So bleibt zusätzlicher Aufwand im Rahmen: 
SO-16 und SO-8.

Noch ein Versuch...

Bauform B. schrieb:
> Noch ein Versuch...
Da gefällt mir unter allen vorgeschlagenen Lösungen der Ansatz mit den 
14.7456 MHz am Besten. Besonders, weil diese Frequenz im Gegensatz zu 
den 18 und 20MHz auch noch mitten in der Spec des µC liegt.

Diese Lösung erfüllt wirklich die Forderung, von der
Maxim B. schrieb:
> So bleibt zusätzlicher Aufwand im Rahmen

A. K. schrieb:
> Falk B. schrieb:
>> Das liegt daran, daß da im Verborgenen eine Art PLL/Taktgenerator
>> werkelt, der auf größere Periodendauersprünge allergisch reagiert. Das
>> wurde auch schon praktisch nachgewiesen.
>
> Gibts die bei allen AVRs, oder nur bei manchen? Es gibt ja z.B. Tinys
> mit einer PLL für 64 MHz Timer-Takt.

Keine Ahnung, aber es scheint so, daß alle "moderneren" AVRs das haben, 
wobei "modern" eben die ATmega88 & Co sind.

Beitrag "Re: Atmega644 mit sich änderndem externen Clock"

Lothar M. schrieb:
> Da gefällt mir unter allen vorgeschlagenen Lösungen der Ansatz mit den
> 14.7456 MHz am Besten.

Natürlich ist das die einzige vernünftige, aber sie ist eben langweilig 
und kommt deshalb nicht in Frage. Ich glaube, es wird die maximal 
verrückte Lösung für genau diese beiden Frequenzen gesucht. Ich finde, 
da ist ein STM32 als Oszillator ganz vorne dabei ;)

Lothar M. schrieb:
> Da gefällt mir unter allen vorgeschlagenen Lösungen der Ansatz mit den
> 14.7456 MHz am Besten. Besonders, weil diese Frequenz im Gegensatz zu
> den 18 und 20MHz auch noch mitten in der Spec des µC liegt.

Das löst das Problem für den Fall MIDI (31250 Bod). Aber falls andere 
"geraden" Frequenzen gewählt werden? Z.B. wenn Megas von "üblichen" 
Quarzen getaktet sind, so wie 8 MHz oder 10, 16, 20 MHz, dann sind 
Geschwindigkeiten wie 125 kbod besser geeignet als z.B. 115200 bod.

Variante mit PLL löst das Problem. Mit F_4046 = 6400 Hz können bequem 
F_CPU wie 7,3728 MHz und 14,7456 MHz aber auch 8 MHz und 16 MHz gemacht 
werden. Somit werden alle Bodfrequenzen möglich, wie "üblichen" so auch 
"gerade".

Falls F_CPU 10 oder 20 MHz gewünscht werden, ist F_4046 = 6400 Hz 
ungeeignet, dann bleibt aber die Möglichkeit, über üblich gebliebenen 
ATTYNY25-Pins PB2/SCL und PB0/SDA und über USI andere Frequenzwunsch 
senden... Wenn das auch vielleicht schon überflüssig wird...

Hier ist eine Tabelle zum Übersicht. Brauchbare Varianten sind schwarz.

P.S. statt ATMEGA2560 möchte ich in diesem Projekt doch ATMEGA644 
benutzen. Somit sind F_CPU 18 und 20 MHz auch legitim.

Bauform B. schrieb:
> Noch ein Versuch...

Danke! Das gefällt mir auch.

Maxim B. schrieb:
> F_4046
Da musst du bei 20MHz aber schon wieder aufpassen, denn der 4046 kann 
laut den Datenblättern üblicherweise auch nicht mehr als 17..18MHz. Aber 
kein Problem: du kannst den ja gleich wieder übertakten.

> 31250 Bod .. 125 kbod ... Bodfrequenzen
Auch wenn du offensichtlich kein deutscher Muttersprachler bist: das 
sind "Baud", denn diese Rate wurde nach Herrn Baudot benannt und weil 
der Franzose war, spricht man es halt wie "boud" aus. "Baud" ist also 
ein technischer Begriff wie "Volt" oder "Ampere". Und die schreibst du 
auch nicht "Wold" umd "Apär".

> Das löst das Problem für den Fall MIDI (31250 Bod). Aber falls andere
> "geraden" Frequenzen gewählt werden? Z.B. wenn Megas von "üblichen"
> Quarzen getaktet sind, so wie 8 MHz oder 10, 16, 20 MHz, dann sind
> Geschwindigkeiten wie 125 kbod besser geeignet als z.B. 115200 bod.
Wenn ich mein Problem mit einem µC aufgrund dessen Einschränkungen 
nicht lösen kann, dann nehme ich einen µC, der das kann.

> Variante mit PLL löst das Problem.
Es gibt kein Problem. Du hast es dir selber herkaspuliert.

Bauform B. schrieb:
> Ich finde, da ist ein STM32 als Oszillator ganz vorne dabei ;)
Wenn mich einer mit einer vorgehaltenen Pistole zwingen würde, dann 
würde ich ein FPGA nehmen, das intern mit ein paar 100MHz takten und 
dann per DDFS die paar MHz aufs Hz genau ableiten. Zumindest für mich 
würde da "zusätzlicher Aufwand" auch "im Rahmen" bleiben... ;-)

Lothar M. schrieb:
> Auch wenn du offensichtlich kein deutscher Muttersprachler bist: das
> sind "Baud"

Entschuldigung! Gleich trinke ich Kaffee, dann kein Sprachproblem mehr 
:) Leider kann ich hier Geschriebenes nicht mehr korrigieren.

Lothar M. schrieb:
> Ich würde ein FPGA nehmen, das intern mit ein paar 100MHz takten und
> dann per DDFS die paar MHz aufs Hz genau ableiten. Zumindest für mich
> würde da "zusätzlicher Aufwand" auch "im Rahmen" bleiben.
Für mich schon, da ich ein Programm dafür suchen, installieren und 
erlernen muß und dazu noch Programmiermittel kaufen.

Lothar M. schrieb:
> Wenn ich mein Problem mit einem µC aufgrund dessen Einschränkungen
> nicht lösen kann, dann nehme ich einen µC, der das kann.
Irgendwann habe ich alles gar ohne µC gemacht. Ob ich dadurch weniger 
glücklich war, bin ich nicht sicher...
Ich denke, wenn man nicht unter Druck steht wie beruflichen 
Elektroniker, so darf man sich einiges erlauben...

Maxim B. schrieb:
> Diese Idee gefällt mir mehr und mehr.

Mir gefällt diese besser:
https://www.silabs.com/documents/public/data-sheets/Si5351-B.pdf
+ Attiny 10 zum einstellen und bedienen des Resets.

Maxim B. schrieb:
> Ich brauche für ATMega2560 umschaltbare Baudraten für USART, die mit
> einem Quarz nicht möglich sind (31250 und 57600 bod).

Da es schlussendlich nur um unterschiedliche Baudraten eines UARTs 
geht, bietet sich ein SPI,I2C,etc. <-> UART Schnittstellenwandler an. Du 
kannst einen moderneren µC misbrauchen, oder einen, ähnlich diesem 
benutzen: https://www.mouser.de/datasheet/2/146/XR20M1170-1889071.pdf

Bei Si5351 gefällt mir OTP-Memory nicht. Die Fehler bei Entwicklung sind 
so gut wie unvermeindlich. Immer wieder IC umlöten (das ist ja kein DIP, 
man kann IC nicht einfach stecken!) - das gefällt mir gar nicht...

Mit XR20M1170 verliere ich XCK. Das ist nur UART, kein USART. XCK zu 
opfern bin ich nicht bereit.

Maxim B. schrieb:
> Mit XR20M1170 verliere ich XCK. Das ist nur UART, kein USART. XCK zu
> opfern bin ich nicht bereit.

Es gibt auf dem Markt sicherlich einen, der deinen Anforderungen 
entspricht.
Falls nicht, kann ein zweiter µC auch die Aufgabe übernehmen.

Maxim B. schrieb:
> Bei Si5351 gefällt mir OTP-Memory nicht. Die Fehler bei Entwicklung sind
> so gut wie unvermeindlich.

Soweit ich das verstehe, betrift das nur den Basistakt, der vor der 
Konfiguration ausgegeben wird.

Ansonsten findet sich auf dem Markt sicherlich etwas vergleichbares, das 
passt.

A. M. schrieb:
> Falls nicht, kann ein zweiter µC auch die Aufgabe übernehmen.

Dann ist einfacher PLL zu machen. Sonst kommt noch zusätzliche 
Datenübrtragung zwischen µC... PLL kann man wirklich relativ langsam 
umstimmen und angestrebte 2% Differenz pro Takt sichern.

A. M. schrieb:
> Soweit ich das verstehe, betrift das nur den Basistakt, der vor der
> Konfiguration ausgegeben wird.
>
> Ansonsten findet sich auf dem Markt sicherlich etwas vergleichbares, das
> passt.

Ja, ich suche...
Mit PLL wird F_CPU beim Start auf Max. Frequenz von 4046 gestellt. Das 
ist wichtig, bei allen Varianten zu klären, wie µC getaktet wird, wenn 
OC1A noch nicht geschaltet wird...