AVR128DA28 9600Baud mit 24MHz

NARX schrieb:
> Ab 24Mhz empfange ich nur noch fehlerhafte Zeichen.
> Muss ich die Formel anpassen oder geht das einfach nicht?

Ich empfehle Dir dringend die genaue Frequenz nachzuprüfen und ggf.
nachzujustieren. Wo kommen die +0,5 im Quotienten der Formel her?

NARX schrieb:
> Muss ich die Formel anpassen oder geht das einfach nicht?

Wo hast du die Formel her? Was soll der cast auf (float)?

1

#define F_CPU 24000000UL

2

#define BAUDRATE0 9600L    //Baudrate

3

#define USART0_BAUD_RATE ((F_CPU * 64 + 8) / (16 * BAUDRATE0))

Wenn man es manuell rechnet, kommt exakt 10.000 raus. Was für ein 
Wunder, bei der riesigen CPU-Frequenz. Aber das löst nicht das Problem 
des ungenauen RC-Oszillators im IC. Damit der genau genug ist, muss er 
kalibriert werden. Dazu gibt es diverse Register. Das muss man im 
Programm selber machen.

beo bachta schrieb:
> Selbst
> wenn man die Frequenz kalibriert kann sie einem durch Spannungs-
> schwankungen und Temperatureinflüsse davonlaufen. Da ist auf
> nix Verlass.

Naja ganz so wie im Wilden Westen ist es zum Glück nicht. Der interne 
OSC dieser neuen AVRs ist 1. präziser als der älterer Typen und 2. kaum 
spannungsabhängig (interne Spannungsregelung). Der Temperatur-Einfluß 
ist natürlich gegeben doch könnte man die intern messen und bei großen 
Schwankungen wie im Außenbereich ggf. nachjustieren. So eingestellt sind 
auch 24MHz definitiv machbar, zumal bei nur 9600 Baud. Schließlich gibt 
es dann noch das Autotune-Feature mit 32kHz Quarz.

S. Landolt schrieb:
> Vielleicht funktioniert ja die Umschaltung auf 24 MHz nicht, wie sieht
> diese denn aus?

Warum sollte die Umschaltung Probleme machen? Einfach in OSCHFCTRLA 
einstellen und gut ist. Das ist ja nicht mit einer 
Taktquellenumschaltung verbunden deren Erfolg man im Clock Status 
nachprüfen müsste.

Ein Tipp noch zum Controller: Wenn Auswahl besteht lieber die 
fehlerbereinigteren DB/DD Typen nehmen.

_PROTECTED_WRITE (CLKCTRL.OSCHFCTRLA, CLKCTRL_FREQSEL_24M_gc);

https://ww1.microchip.com/downloads/en/Appnotes/Int-HF-Osc-Calib-Using-Auto-Tune-Feature-DS90003234C.pdf

S. Landolt schrieb:
> So, tatsächlich so einfach, Ron T.? Siehe die Anmerkung von c-hater.

Nun ja, das setzt man voraus ;-)

Daß der Code des TO nicht vollständig ist das ist ja offensichtlich. Den 
Protected Write hat er aber offensichtlich überwunden.

c-hater schrieb:
> Wie ich immer sage: C ist Dreck...

Naja soweit würde ich mich nicht versteigen obwohl ich selber Asm 
bevorzuge.

S. Landolt schrieb:
> Und allgemein, wie immer, so gilt auch hier: man reduziert seinen
> Problemfall auf ein Minimalprogramm - meistens klärt sich dann bereits
> alles, und erst falls nicht, stellt man dieses Programm (vollständig)
> hier im Forum vor.

Genau.

S. Landolt schrieb:
> Und "offensichtlich" - Ihre hellseherischen Fähigkeiten möchte ich
> haben.

Am Takt muß er doch erfolgreich gedreht haben wenn

NARX schrieb:
> Ab 24Mhz empfange ich nur noch fehlerhafte Zeichen

Oder etwa nicht?

S. Landolt schrieb:
> Zugegeben, es hat den Anschein.

Nein das muß so sein. Ein Problem mit der "configuration change 
protection" können wir glaube ich ausschließen. Was desweiteren zu tun 
wäre wurde schon gesagt. Ob es den TO noch interessiert?

NARX schrieb:
> Auf meinem ATmega4809 funktionieren 20MHz mit 9600b, möchte das später
> auch mal probieren.

Ob die Kommunikation funktioniert hängt von der Gegenstelle ab, die ja 
auch einen rechnerischen Fehler bei der Baudrate hat. Bei gleichem 
Mikrocontroller und F_CPU kommt da diesselbe tatsächliche Baudrate raus.

Siehe z.B. hier: 
https://github.com/nospam2000/ch341-baudrate-calculation#with-the-new-driver-my-application-no-longer-works

Es gibt eine praktische Möglichkeit, die Baudrate so exakt wie möglich 
an die Gegenstelle anzupassen, wenn man den internen Oszillator 
verwenden:
Man tuned den internen Oszillator so, dass die Abweichung vom der 
empfangenen Baudrate minimal wird.

siehe hier: 
https://github.com/nospam2000/Arduino-BlueController/tree/master/bluecontroller/examples/Calibrate_BlueController_OSCCAL_by_UART

Wenn man den passenden OSCCAL Wert ermittelt hat, muss man den in seinem 
Program hinterlegen, da er bei jedem Neustart gesetzt werden muss. Ich 
habe das damals im Bootloader gesetzt, damit nicht jedes Programm sich 
mit unterschiedlichen Werten für verschiedene MCUs rumschlagen muss.

Theoretisch kann man das auch im Hintergrund nachführen, dann muss man 
den Wert nicht speichern.

Einfachere Möglichkeit: keine "Standard" Baudraten verwenden sondern 
z.B. 10000 Baud anstatt 9600 Baud. Es ist totaler Blödsinn heute solche 
krummen Werte zu verwenden die zu keinem Quarz passen und macht nur 
Ärger.
Leider kommt damit nicht jede Software zurecht.

  Michael

Der interne RC-Oszillator ist hinreichend genau für den UART. Selbst mit 
32MHz geht das prima bei der DA / DB Serie wie auch bei den neuen Tinys. 
Da braucht man wirklich nicht nach einem Fehler zu suchen.

Zwei beliebte Möglichkeiten: F_CPU ist falsch, oder der RC-Oszillator 
läuft einfach nicht auch 24MHz (die Gründe wurden schon genannt).

Einfach mal einen Pin togglen und schauen ob das zur vermeintlichen 
Taktrate passt.

S. Landolt schrieb:
> der Controller läuft nach wie vor mit der Standardfrequenz von 4 MHz

Du hast Recht. Strenggenommen können wir mangels vollständigem Programm 
und Kenntnis der Fähigkeiten des TO rein gar nichts ausschließen. Ich 
vertrau einfach mal

NARX schrieb:
> du beschreibst es genau so wie es ist

und daß er den Takt wirklich umschalten konnte denn

NARX schrieb:
> Auf meinem ATmega4809 funktionieren 20MHz mit 9600b, möchte das später
> auch mal probieren.

da hat er es ja auch geschafft und zum Thema Change Protection kam kein 
Geständnis ;-)

Michael D. schrieb:
> Einfachere Möglichkeit: keine "Standard" Baudraten verwenden sondern
> z.B. 10000 Baud anstatt 9600 Baud. Es ist totaler Blödsinn heute solche
> krummen Werte zu verwenden die zu keinem Quarz passen und macht nur
> Ärger.
> Leider kommt damit nicht jede Software zurecht.

Da könnte es aber großen Ärger mit vielerlei Gerätschaften geben die 
ihre Daten nunmal in einer solchen fixen Datenrate ausgeben.

Quarze brauchts keine mehr:

Wilhelm M. schrieb:
> Der interne RC-Oszillator ist hinreichend genau für den UART.

NARX schrieb:
> Habe dann mal den UART USB Konverter gewechselt.

Schön, daß wir wieder mal alle Aspekte des Themas beleuchtet haben 
(fernab der eigentlichen Lösung ;-)

c-hater schrieb:
> Das verwundert den Fachmann dann doch sehr. Da ist nämlich die genauso
> unschöne wie unbestreitbare Tatsache, dass es keinerlei "interne Quarze"
> gibt...

Um auch etwas klugzuscheißen: das mag zwar für eine AVR mcu gelten, eine 
DS3231 hat aber einen internen Quarz, sogar einen TXCO.

Wenn schon kleinlich, dann richtig :-)

 Michael

beo bachta schrieb:
> Selbst wenn man die Frequenz kalibriert

Justiert oder abgeglichen. Nicht kalibriert. Davon ändert sie sich 
nicht. Auch im englischen wird dies häufig falsch eingesetzt, dort heißt 
es adjustment. Woher kommt der Glaube, dass eine Kalibrierung eine 
Justage sei?


Ron T. schrieb:
> zumal bei nur 9600 Baud.

Wurde schon drauf hingewiesen: Es ist unabhängig von der Baudrate, da es 
sich um einen prozentualen Fehler handelt.
10% Geschwindigkeitsunterschied zwischen Sender und Empfänger sind die 
Grenze zum Ausfall der Kommunikation bei 8n1. Wenn man beiden Seiten 
jeweils 5% erlaubt geht es wahrscheinlich gut.


S. Landolt schrieb:
> Nachdem nun so gar nichts mehr von NARX kommt

Neee, schau mal 3 Beträge vor Deinem.


NARX schrieb:
> mit dem internen Quarz.

Michael D. schrieb:
> das mag zwar für eine AVR mcu gelten, eine
> DS3231 hat aber einen internen Quarz, sogar einen TXCO.

Geht aber um den AVR. Und nicht um den DS3231, welcher als Uhr/Zeitbasis 
mit 1-10% Genauigkeit absurd wäre.

Michael D. schrieb:
> Wenn schon kleinlich, dann richtig :-)

Eben.


Gruß
Jobst

Tom schrieb:
> Und das was beidseits an Toleranz "erlaubt" ist wird mit steigender
> Geschwindigkeit sicher nicht mehr.

Natürlich nicht. Wenn man aber weiß, dass ab spätestens 10% Unterschied 
zwischen beiden Seiten Schluss ist, sollte man es nicht mit mehr 
versuchen und sich dann wundern. Deshalb ist die graue Theorie auch hin 
und wieder ganz hilfreich.
Selbstverständlich nimmt man dann einen Takt mit weit weniger Toleranz. 
Es soll ja nicht auf Kante sein. Ob einen Quarz oder einen justierten 
RC-Oszillator ist dabei ja egal.


Gruß
Jobst