F_CPU umschalten, gibt es etwas zu beachten?

[Maxim B. (max182)]

Guten Abend!
Ich habe eine Frage:
Ich brauche für ATMega2560 umschaltbare Baudraten für USART, die mit 
einem Quarz nicht möglich sind (31250 und 57600 bod). Deshalb möchte ich 
F_CPU umschalten. Die Frage ist: wie mache ich das korrekt?
Wird funktionieren, wenn ich mit einem Portpin einfach zwei 
Quarzoszillatoren  durch Enable-Pin umschalte? Z.B. 18,432 MHz und 20 
MHz. D.h. von dem Mikrokontroller selbst, der getacktet wird?
In Datasheet für CB3 steht: Enable Time 200 ns. D.h. ca. 4 Cycle für 20 
MHz. Kann so eine Pause F_CPU Programm zum Sturz bringen oder ist das 
unbedenklich?
Danke im voraus für Tipps!

[Thosch (Gast)]

nimm einfach einen moderneren uC, dessen UARTs das Feature
"fractional baud rate generator" beinhalten.
Dann geht jede Baudrate von einem Standardquarz mit z.B. 16MHz oder 
32MHz mit hinreichend kleinem Restfehler.

Z.B. die XMEGAs können das.

[(prx) A. K. (prx)]

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

[Maxim B. (max182)]

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?

[Pappsack (Gast)]

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).

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.

[Stefan F. (Gast)]

Maxim B. schrieb:
> Wird funktionieren, wenn ich mit einem Portpin einfach zwei
> Quarzoszillatoren  durch Enable-Pin umschalte?

Ich bezweifle dass das so einfach geht, denn zwischen den Taktflanken 
müssen gewisse Mindestabstände eingehalten werden. Ich meine mich zu 
erinnern, dass zudem viele Mikrocontroller außerdem ein gewisses 
Tastverhältnis (High-Zeit versus Low-Zeit) verlangen. Das wirst du im 
Umschaltmoment nicht so einfach einhalten können.

Die klassischen ATmega haben teilweise ein CLKPR Register, dass du 
problemlos zur Laufzeit umschalten kannst. Aber ich schätze, damit 
kommst du auch nicht exakt auf die gewünschten Frequenzen.

@Pappsack: Daumen hoch für deinen Tipp zur passenden Quarz-Frequenz.

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

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...

[Bauform B. (bauformb)]

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 :)

[Maxim B. (max182)]

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...

[Maxim B. (max182)]

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...

[Programmierer (Gast)]

Nimm eine  FPGA mit eingebauten Clock Manager Blocks zum Glitch freien 
Umschalten. Oder einfach 2 AVRs für die 2 UARTs mit unterschiedlichem 
Takt. Oder halt einen STM32.

Maxim B. schrieb:
> möchte ich aus dem Vorhandenen alles mögliche im Sinn Lehre
> herausschöpfen. Deshalb bleibe ich zuerst bei AVR.

So lernst du aber nur Frickel-Krücken-Lösungen die dir bei moderneren 
Controllern auch nichts bringen.

[Maxim B. (max182)]

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.

[Joachim B. (jar)]

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!

[Maxim B. (max182)]

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...

[Falk B. (falk)]

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ß!

[Programmierer (Gast)]

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

Das ist halt ein großes "nur". Clock Gating ist halt nicht so einfach. 
Du musst aufpassen dass keine Takte "abgehackt" werden und zu kurze 
Pulse/Glitches durchkommen. Dazu kommt dass die Programmierung ganz 
schön lästig wird weil alle Peripherie mit anderen Takt-Teilern neu 
konfiguriert werden muss.

Dass den meisten Teilnehmern hier nicht sofort eine Lösung für einen 
derart komplizierten Ansatz einfällt, ist verständlich; die meisten 
präferieren einfachere Ansätze.

Am Ende ist deine Takt-Umschalt-Schaltung größerer und teurer als der 
AVR. Da wäre es in jeder Hinsicht besser, 2 AVRs zu nehmen, dann du 
kannst sogar den altmodischen Controllertyp behalten.

Maxim B. schrieb:
> ich habe Lust, einen Monitor zu machen, der alles Mögliche mit allen
> möglichen Frequenzen nehmen und zeigen kann: MIDI, USART, TWI, SPI...

Also ein Logic Analyzer? Oder ein Bus Pirate?

Maxim B. schrieb:
> Deshalb kommen auch Baudraten in Frage, die nicht in Standartreihe
> passen: 31250 für MIDI, 200k, 250k, 500k und 1M für interne Zwecke.

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?

[Maxim B. (max182)]

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?

[Maxim B. (max182)]

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.

[Joachim B. (jar)]

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.

[Maxim B. (max182)]

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.

[Joachim B. (jar)]

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 (Gast)]

Maxim B. schrieb:
> Ich fürchte, ich werde in viel zu kompliziertem Inneren eines ARM
> ertrinken.

Du wärst der Erste.

Maxim B. schrieb:
> Schließlich komponieren die Studenten zuerst immer ein Preludium
> und eine Fuge, nie gleich eine Sinfonie.

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.

Maxim B. schrieb:
> Zuerst möchte ich besser elementare Stufe absolvieren

Und versuchst direkt etwas derart anspruchsvolles? Ich z.B. habe zwar 
viel Erfahrung mit ARM-Programmierung, aber an einen solchen 
Clock-Multiplexer würde ich mich nicht so einfach herantrauen. Das ist 
was für HF-Analog-Experten.

Maxim B. schrieb:
> 1x für das Leben
> außerhalb von Standartbaudraten.

Das ist dann aber auch nur wieder nur eine sehr begrenzte Anzahl.

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

Klar, die Leute welche FPGAs und moderne Mikrocontroller mit 
integrierter Takt-Umschaltung bauen. Nur die willst du ja nicht nutzen.

Maxim B. schrieb:
> Womit riskiere ich?

Zeit zu verschwenden ohne etwas verwertbares zu lernen.

[Maxim B. (max182)]

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.

[Maxim B. (max182)]

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.

[Andreas B. (bitverdreher)]

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 (Gast)]

Maxim B. schrieb:
> Für ARM habe ich solch Schaufenster nicht gefunden. Nicht in solchem Maß
> wie AVR hat.

Hä? Alle ARMs haben JTAG/SWD-Unterstützung, mit welcher du mit sehr 
günstiger Debugging-Hardware alles Schritt-für-Schritt nachvollziehen 
kannst. Den Assembler-Code kann man sich natürlich auch immer ansehen. 
Dazu gibts Instruction Tracing, Hardware-Breakpoints und 
-Data-Watchpoints - hat der AVR das auch alles?

Nur vollständige Peripherie-Simulation ist bei komplexen µC eher rar; 
die braucht's aber kaum, weil man es auch direkt auf der Hardware machen 
kann. Algorithmen ohne Hardware-Ansteuerung kann man z.B. per qemu auf 
dem PC emulieren.

[Maxim B. (max182)]

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...

[Joachim B. (jar)]

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!

[Programmierer (Gast)]

Maxim B. schrieb:
> 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.

Was ist denn eine grafische Darstellung von Registern? Mit kleinen 
Glühbirnchen statt Binärzahlen? 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.

Maxim B. schrieb:
> Dazu noch nur 3 Volt, das ist weniger günstig,
> als 5 Volt, wenn man gleich MOSFET am Ausgang hat...

Dann nimm halt Logic-Level-FET's. Außerdem gibt es 5V-ARMs.

[Maxim B. (max182)]

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...

[Programmierer (Gast)]

Maxim B. schrieb:
> Irgendwann geht mein Computer mit Windows XP in Ewigkeit, dann mache ich
> alles mit Linux. Und dann... und dann...

Aha? ARMs kannst du mit Windows, Linux und Mac programmieren. Wobei 
Windows XP schon allgemein lästig wird wg. Treiberverfügbarkeit usw.

[Andreas B. (bitverdreher)]

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.

[georg (Gast)]

Maxim B. schrieb:
> Ich fürchte, ich werde in viel zu kompliziertem Inneren eines ARM
> ertrinken

Na und, das wird sicher als Berufskrankheit anerkannt.

Georg

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

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.

[Stefan F. (Gast)]

georg schrieb:
> Ich fürchte, ich werde in viel zu kompliziertem Inneren eines ARM
> ertrinken

Vielleicht. Für einen ersten Eindruck kannst du dir ja mal das angucken: 
http://stefanfrings.de/stm32/index.html

[Bauform B. (bauformb)]

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.

[Stefan F. (Gast)]

Lothar M. schrieb:
> Nicht umsonst kommen hier ständig welche um die
> Ecke und suchen nach Pegelwandlern für ihren Andruiden.

Es war ein Fehler, die Dinger standardmäßig mit 5V zu betreiben.

Als die ersten Arduinos vermarktet wurde, war schon klar dass alles auf 
3,3V (und weniger) wechselt. Man hätte sie problemlos mit 3,3V betreiben 
können, wenn man einen 7,3728 Mhz Quarz verwendet hätte.

[Andreas B. (bitverdreher)]

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?

[Bauform B. (bauformb)]

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.

[(prx) A. K. (prx)]

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.

[Maxim B. (max182)]

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.

[Maxim B. (max182)]

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 +...

[Maxim B. (max182)]

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.

[c-hater (Gast)]

Maxim B. schrieb:

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

Ja, das ist wahr.

Die AVR8 waren halt nicht als Eierlegende Wollmilchsauen gedacht, 
sondern sind relativ stark auf gewisse Zielanwendungsklassen 
zugeschnitten, das betrifft ganz besonders die Tinys.

Vieles davon dürfte eine reine Marketingentscheidung gewesen sein, die 
damals vermutlich finanziell sinnvoll war, aber heute völlig abstrus 
anmuted. So z.B. die Tatsache, dass die Tiny24/44/84 sehr eng mit den 
Tiny25/45/85 verwandt sind, aber halt bestimmte Features der "kleineren" 
Reihe nicht haben. Das ergibt technisch absolut keinen Sinn. Also waren 
die Gierigen am Werk, anders ist das einfach nicht zu erklären...

Damals(tm) war wohl allgemein vor allem das Ziel, die Tinys nicht zu 
attraktiv und universell zu machen, denn dann hätte ja niemand mehr die 
deutlich teureren Megas gekauft...

[Maxim B. (max182)]

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.

[Bauform B. (bauformb)]

Noch ein Versuch...

[Programmierer (Gast)]

Zum Vergleich, den Aufwand der bei Nutzung eines STM32 nötig wäre:

https://github.com/STMicroelectronics/STM32CubeF1/blob/master/Projects/STM32F103RB-Nucleo/Examples/UART/UART_Printf/Src/main.c#L88

In dieser Zeile die 9600 durch die gewünschte Baudrate ersetzen. Fertig.


Beide Baudraten 31250 und 57600 sind exakt erreichbar bei Verwendung 
des üblichen Systemtakts von 72 MHz, mit einem Quarz und ohne externe 
ICs und Umschaltung. Du kannst sogar die 3 UARTS mit diesen 
unterschiedlichen Baudraten gleichzeitig laufen lassen. Der STM32F1 + 
Grundschaltung dürfte kleiner und billiger sein als der ATmega+ATtiny+ 
2x4046.

Was ist hier die Sinfonie und was die Fuge...

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

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

[Falk B. (falk)]

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"

[Bauform B. (bauformb)]

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 ;)

[Maxim B. (max182)]

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.

[Maxim B. (max182)]

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

Danke! Das gefällt mir auch.

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

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... ;-)

[Maxim B. (max182)]

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...

[Franz M. (elmo64)]

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

[Maxim B. (max182)]

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.

[Franz M. (elmo64)]

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.

[Franz M. (elmo64)]

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.

[Maxim B. (max182)]

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...