Hallo,
ich möchte mit 24Mhz 9600Baud für die UART Übertragung nutzen. Mit
meiner aktuellen Berechnung funktionieren die 9600Baud nur mit weniger
Mhz (4MHz funktionieren). Ab 24Mhz empfange ich nur noch fehlerhafte
Zeichen.
Muss ich die Formel anpassen oder geht das einfach nicht?
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?
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.
NARX schrieb:> Nutze den internen Oszillator. Auf externe möchte ich verzichten.
Interner Oszillator und genaue Frequenzen passen einfach nicht
zusammen. Das ist schlichtweg Mist bzw. Pfusch am Bau. Selbst
wenn man die Frequenz kalibriert kann sie einem durch Spannungs-
schwankungen und Temperatureinflüsse davonlaufen. Da ist auf
nix Verlass.
> 4MHz funktionieren
Nun ja, 4 MHz ist die Standardfrequenz nach einem Reset. Vielleicht
funktioniert ja die Umschaltung auf 24 MHz nicht, wie sieht diese denn
aus?
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.
Ron T. schrieb:> 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).
Das ist so, ja.
> 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.
Auch das ist so. Man muß es dann halt aber auch tatsächlich tun. Von
allein passiert da garnix. Und im gezeigten Code war auch nix davon
enthalten.
> Schließlich gibt es dann noch das Autotune-Feature mit 32kHz Quarz.
Auch das ist so. Aber auch hier gilt: Man muß es dann halt aber auch
tatsächlich tun. Von allein passiert da garnix. Und im gezeigten Code
war auch nix davon enthalten.
> So eingestellt sind> auch 24MHz definitiv machbar, zumal bei nur 9600 Baud.
"Zumal" ist Bullshit. Der relative Fehler wirkt völlig unabhängig von
der Ziel-Baudrate. Nur auf den systematischen Fehler hat die
Zielbaudrate Einfluss. Dieser (und leider nur dieser) Einfluss ist bei
den neuen AVRs halt um den Faktor 64 geringer, dank fraktionalem 6
Bit-Teileranteil.
> Warum sollte die Umschaltung Probleme machen? Einfach in OSCHFCTRLA> einstellen und gut ist.
Diese Einstellung unterliegt der "configuration change protection". Und
muss halt unter Berücksichtigung eben dieses Sachverhalts vorgenommen
werden, um wie gewünscht wirksam werden zu können. Und schon wieder: Im
gezeigten Code war auch nix davon enthalten...
Sprich: TO hat ohne jegliche Ahnung und ohne hinreichende DB-Lektüre
versucht, alten Code per C&P zu übernehmen und ist damit gnadenlos auf
die Fresse gefallen. Also ist alles genau so gekommen, wie es kommen
musste...
> Warum sollte die Umschaltung Probleme machen? Einfach> in OSCHFCTRLA einstellen und gut ist.
So, tatsächlich so einfach, Ron T.? Siehe die Anmerkung von c-hater.
Georg M. schrieb:> _PROTECTED_WRITE (CLKCTRL.OSCHFCTRLA, CLKCTRL_FREQSEL_24M_gc);
Da fehlt noch was, was nicht unbedingt naheliegend ist: Das richtige
Include...
Wie ich immer sage: C ist Dreck...
In Asm genügt mir ein einziges Include. Das passt immer und bringt
alles, was ich brauche...
> _PROTECTED_WRITE (CLKCTRL.OSCHFCTRLA, CLKCTRL_FREQSEL_24M_gc);
Eben.
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. Ausschnitte, von denen man glaubt, der Fehler sei
dort zu finden, führen im Regelfall nur in die Irre.
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.
Also ich setze gar nichts voraus - es gibt hier Anfänger, die glauben,
es sei ausreichend, den Systemtakt im Programm per 'define F_CPU'
anzugeben.
Und "offensichtlich" - Ihre hellseherischen Fähigkeiten möchte ich
haben.
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?
Zugegeben, es hat den Anschein. Es könnte aber auch sein, dass ihm bei
dieser Programmänderung versehentlich ein anderer/weiterer Fehler
unterlaufen ist. Ohne das Programm zu sehen, möchte ich da nicht weiter
spekulieren.
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?
@Ron T.
Danke, du beschreibst es genau so wie es ist. Interesse ist noch da aber
bin noch nicht dazu gekommen mal die Kalibrierung auszuprobieren. Ich
poste später mal meinen Code das weitere Diskussion vermieden werden
kann.
Auf meinem ATmega4809 funktionieren 20MHz mit 9600b, möchte das später
auch mal probieren.
Zur Diskussion externen Quarz, ich hatte noch nie Probleme bei der UART
Übertragung mit dem internen Quarz.
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.
Ron T. schrieb:> 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.
Nachdem nun so gar nichts mehr von NARX kommt, möchte ich doch noch
einen Einwand nachreichen: es würde perfekt passen, nicht wahr - der
Controller läuft nach wie vor mit der Standardfrequenz von 4 MHz,
USART0.BAUD wird aber auf Grund von '#define F_CPU 24000000UL'
berechnet.
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.
Ich konnte nun das Problem lösen.
Gestern hat die Kommunikation mit 4MHz auch nicht mehr funktioniert.
Habe dann mal den UART USB Konverter gewechselt.
Nun kann ich Problemlos kommunizieren. 20MHz und 24MHz funktionieren
ebenfalls. Gute Frage warum der Adapter nicht mehr läuft. Nutze nun
einen Baugleichen. Ich glaube die Adapter haben den PL2303 Chip.
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 ;-)
Und was für ein Zufall auch (wieder einmal hier im Forum): just in dem
Moment, da die Frequenz umgestellt wird, fällt der davon völlig
unabhängige Adapter aus.
Aber interessant war die Diskussion schon.
NARX schrieb:> Zur Diskussion externen Quarz, ich hatte noch nie Probleme bei der UART> Übertragung mit dem internen Quarz.
Das verwundert den Fachmann dann doch sehr. Da ist nämlich die genauso
unschöne wie unbestreitbare Tatsache, dass es keinerlei "interne Quarze"
gibt...
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
Jobst M. schrieb:> 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.
Physikalische Realitäten schaun zuweilen aber anders aus als die schnöde
Mathematik. Mit steigendem Speed werden Flanken unsauberer und das
Verhältnis zwischen Anstiegs/Abfall- Zeiten und konstantem Datenpegel
ungünstiger.
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
Thread beobachten
Seitenaufteilung abschalten