FT2322R an einem USB-Hub Trust HU-5540 - Übertragunjgsfehler

Henry Kiefer schrieb:

In dem genannten Beispiel wird der RC-Oszillator regelmäßig gegen den _Quarz_oszillator kalibriert. WIMRE ist das bei den MSP430 das Standardverfahren.

_Ich_ hatte das Ziel, den Stromverbrauch zu senken. Samstag und Sonntag verstehen die geöffneten Läden hier weder "Quarz" noch "MHz". Bit könnte ich da kaufen, brauche ich aber nicht ;-) Und 1,8... MHz sind aus, ich bitte um Absolution.

Falk

Gegen einen mit lächerlichen 32kHz. Und das mit einem Kalibrierungsmechanismus, der exakt 256 verschiedene Werte für den Abgleich erlaubt (und die sind nichtmal optimal verteilt).

Und damit willst du einen Takt synchronisieren, der rund 60 mal höher ist als der Takt des Normals?! Bitte rechne doch einfach mal den Fehler durch!

Und das dann auch noch über einen längeren Zeitraum hinweg, denn "regelmäßige Kalibrierung" bedeutet ja nix anderes, als daß zwischen den Zeitpunkten der "regelmäßigen Kalibrierung" der Tochtertakt freilaufend ist, oder?

Schon bei ständiger Synchronisation hast du bei einem derartig hohen Taktverhältnis ganz erhebliche Probleme, die beiden Takte über einen längeren Zeitraum hinweg in Phase zu halten, denn die Zeitkonstante deiner Software-Regelstrecke ist verdammt groß im Verhältnis zum zu synchronisierenden Takt und dem zu erwartenden Fehler.

Das ist OK und das verwendete Mittel kann dafür durchaus nützlich gewesen sein. Du darfst halt bloß nicht die Grenzen des Verfahrens vergessen oder verdrängen. Es ist definitiv nicht gut genug, um zuverlässige serielle Kommunikation bei 115.2kbps sicherstellen zu können. Das ist schon alles.

Falk Willberg schrieb:

Nicht erteilt: Schlachte den nächstbesten defekten Videorecorder. Mindestens einen Keramikschwinger wirst du dort finden!

- Henry

Heiko Nocon schrieb:

Viel wahres... ...

^^^^^^^^^^^^

Ich widerspreche nicht. Ich hatte sogar angenommen, daß es für 9k6 viel zu ungenau ist. (Bei geringen Baudraten sind eher mehr Fehler zu erwarten) In meiner Anwendung schadet es auch nicht, wenn mal ein Datenpaket verloren geht.

Meistens schläft der uC, wacht alle paar Sekunden auf, Kalibriert, hält ein Schwätzchen via UART, protokolliert das und geht wieder schlafen.

Falk

Henry Kiefer schrieb:

...

Defekt habe ich nicht und meine Frau hat schon das Wort "absolut" gebraucht, als ich meinte, im VCR wäre ein Teil, das ich.....

Falk

Die krummen Quarzfrequenzen sind mir schon gel=E4ufig. Mein Problem ist, das der =B5C ein AT90CAN128 ist. Und der CAN-Teil ben=F6tigt auch die Quarzfrequenz. Ich muss 125kBaud am CAN-Bus erzeugen . Die Tabellen im Manual geben nur Register-Werte f=FCr 12 und 16 MHz an. Insofern w=E4re es sch=F6n die Geschwindigkeit von 38400 auf 115200 oder gar 250000 hochzusetzen.

F=FCrs 'Grobe' benutze ich HiTerm, das kann wohl nicht 250000, jedenfalls taucht in der Auswahlliste nur 25000 auf (Druckfehler ?)

Die eigentliche Kommunikation erfolgt =FCber ein VB.NET-programm. Ob die SerialPort-Control 250000 kann wissen die G=F6tter.

Gruss Nico

Hi Nico,

und dessen Teiler kann nur Ganzzahlen? Alles, was ich bisher gesehen hatte hat noch ein "fractional divider". Damit macht man dann die krummen Teiler.

Marte

Marte Schwarz schrieb:

Ja.

Was denn? Ausser dem FTDI232 und dem MSP430 kenn ich keinen.

MfG Falk

Es wird doch wohl außer den Tabellen auch eine Berechnungsvorschrift für die Teilerregister geben, oder? Notfalls muß man sie halt aus den Tabellenangaben rekonstruieren.

Dazu nimmt man dann die entsprechenden Vorschrift für den UART, die zulässigen Bitratenfehler der beiden "Busse" (RS232 ist natürlich keiner, sondern P2P) und die maximal mögliche Quarzfrequenz und dann beauftragt man einen Computer, alle möglichen Varianten durchzurechnen und mit einer Liste beschaffbarer Quarze abzugleichen.

Am Ende der Operation steht dann entweder die Erkenntnis: "Geht nicht" oder eine Liste von Quarzen mit denen es gehen würde und die für beide "Busse" dann jeweils einzustellenden Werte für die Teilerregister und die sich jeweils ergebenden Bitratenfehler. Aus dieser Liste brauchst du dann bloß noch das kleinste Übel auszuwählen.

So einfach ist das. Ein heute üblicher PC rechnet dir das komplette Problem weit schneller durch, als du die Eckwerte für die Berechnung eingetippt hast. Naja, zumindest solange die höchste zulässige Quarzfrequenz nicht allzu hoch ist...

Der typische Com-port im PC benutzt einen 1.8432 Takt und kann damit maximal 115200 Baud. Alles was mehr kann ist non-Standard.

Gerrit

Schon richtig ..... aber: Ich habe ja einen FT232R (STichwort virtueller COM-Port) und an dessen TxD und RXD-Leitung hängt der AT90CAN128 ....

Gruss Nico

"Gerrit Heitsch" schrieb im Newsbeitrag news:fpcfil$1oi$ snipped-for-privacy@news.bawue.net...

HTerm ? Benutze ich auch. Weil es die Daten gut darstellt (Asc, Bin, Hex. Dez).

In dessen Auswahlliste steht aber nur '25000'. Immerhin kommt es nach 115200 und 128000. Möglicherweise ist 250000 gemeint.

Gruss Nico "Falk Brunner" schrieb im Newsbeitrag news: snipped-for-privacy@mid.individual.net...

Nicolas Nickisch schrieb:

Genau das.

Na und? Einfach 250000 (zweihundertfünfzigtausend) eintippen und ab geht die Post! Been there, done that.

MfG Falk

Hi Falk,

Spontan ADuC702x von Analog, ansonsten hätte ich Dir noch den MSP430 genannt. Und Deiner kennt das wirklich nicht, auch nicht unter einem anderen Namen? Das wäre ja wirklich schräg, wenn das bisher noch niemandem aufgefallen wäre.

Marte

Natürlich ist das aufgefallen, jeder AVR-Bastler weiß das und wählt die Quarzfrequenz dementsprechend. Atmel hat sogar Tabellen in seinen Datenblättern mit den prozentualen Abweichungen für übliche Baudraten und Quarzfrequenzen.

Gruß Henning