115200baud mit 19.6608Mhz

Claudio Hediger schrieb:

> Doch es ist doch ein Baudratenquarz also sollte es doch möglich sein
> oder?

Der Quarz ist zwar ein Baudratenquarz, aber 115200bd passt nicht in die 
klassische Verdopplung 75-150-300...9600-19200-38400-76800-... sondern 
ist ein Artefakt der in PCs verwendeten Baudratenerzeugung. Der Quarz 
lässt ab 75bd nur Zweierpotenzen als Teiler zu und in 115200 steckt ein 
zusätzlicher Faktor 3.

Danke...

Was ist somit die höchst mögliche Baudrate welche auch vom PC 
"empfangen" werden kann?

> Doch es ist doch ein Baudratenquarz
Wie kommst du darauf?
19660800 / 115200 = 170,666
Die Nachkommastellen sagen:
das kann kein Baudratenquarz für 115200 sein...
http://www.hanneslux.de/avr/tipps/baudratenquarz.html

Ein anderes Beispiel:
11059200 / 115200 = 96,000 das geht gut.

Lothar Miller schrieb:
> Wie kommst du darauf?

Schau mal hier
http://www.mikrocontroller.net/articles/Baudratenquarz#Beispiele_f.C3.BCr_Baudratenfrequenzen

>> Wie kommst du darauf?
> Schau mal hier
Trau, schau wem ;-)

>> Was ist somit die höchst mögliche Baudrate welche auch vom PC
>> "empfangen" werden kann?
Das kommt auf den PC, den darin verbauten UART und die verwendete 
Software an. Es muß ja "nur" das Reload-Register des UARTs im PC 
entsprechend eingestellt werden (können)...

Lothar Miller schrieb:
> Das kommt auf den PC, den darin verbauten UART und die verwendete
> Software an. Es muß ja "nur" das Reload-Register des UARTs im PC
> entsprechend eingestellt werden (können)...

Ich dachte da an einen Standard.
Als Software hTerm

Es kommt auf den Prozessor an.

Wenn Du einen LPC2xxx oder STM32 nutzt, dann kann anhand der Mul/Div 
Register nahezu jede Baudrate aus nahezu jedem Quarz gemacht werden.

z.B. aus 8MHz sind 115KBaud mit 0,16% Fehler möglich.

Schreibe mal was Du nutzt.

Claudio Hediger schrieb:

> Als Software hTerm

Dann schau nach, was sich da einstellen lässt.

A. K. schrieb:
> Dann schau nach, was sich da einstellen lässt.

Dort kann ich manuell die baudrate eintippen

Somit alles...


Die frage ist, was ist das höchst mögliche mit dem AVR

Claudio Hediger schrieb:
> A. K. schrieb:
>> Dann schau nach, was sich da einstellen lässt.
>
> Dort kann ich manuell die baudrate eintippen
>
> Somit alles...
>
>
> Die frage ist, was ist das höchst mögliche mit dem AVR

Du drehst dich im Kreis :-)
Die höchst mögliche auf dem AVR ergibt sich aus der maximalen 
Taktfrequenz, dir der AVR noch mitmacht und dem kleinstmöglichen Wert 
(also 1) den man noch in die UBRR Register laden kann.

Wenn deine Gegenstelle diesen, wahrscheinlichen krummen, Wert einstellen 
kann, hast du die höchstmögliche Baudrate.


Du siehst schon, wenn du so fragst, drehst du dich im Kreis.
Du musst dich fragen: Auf welcher Seite habe ich das Problem, dass ich 
nur aus einem Vorrat vorgefertigter Baudraten auswählen kann? Welches 
ist dort die höchste Baudrate, die ich auch auf dem AVR ohne allzuviel 
Fehler noch produzieren kann.

Markus Müller schrieb:
> Schreibe mal was Du nutzt.

Ich nutze einen Attiny2313-20PU

Offiziell kann der Win32-API die Parameter
CBR_110   CBR_19200
CBR_300   CBR_38400
CBR_600   CBR_56000
CBR_1200  CBR_57600
CBR_2400  CBR_115200
CBR_4800  CBR_128000
CBR_9600  CBR_256000
CBR_14400

Wobei deine 1,5% Abweichung noch im Rahmen dessen sind, was die 
Schnittstelle notfalls abkann.

Aeh ... 19660800 / 115200 = 170,666 .. sind nur 0.2% Fehler wenn man 171 
als Teiler einstellt.

Danke...

Bei 128000 Baud komme ich auf einen Fehler von 0.943% Das ist meiner 
Meinung nach Ideal

Hey noch Was schrieb:

> Aeh ... 19660800 / 115200 = 170,666 .. sind nur 0.2% Fehler wenn man 171
> als Teiler einstellt.

Dummerweise hast du den Faktor 8 vergessen, den dir die UART mindesten 
einbringt.

Auch die 1,5% sind allerdings noch drin.

Claudio: Die 128000 stehen da zwar drin, aber wie die intern zustande 
kommen weiss ich auch nicht. Ich hatte grad nachgesehen und CBR_128000 
hat den Wert 128000, der Parameter wird also uncodiert direkt 
durchgereicht und diese CBR_ Werte sind Augenwischerei. Daher macht das 
hTerm auch nicht anders und reicht den Wert auf Gedeih und Verderb 
durch.

@Claudio Hediger (hedie)

>Ist es möglich, mit einem 19.6608Mhz Quarz eine UART Baudrate von 115200
>zu erreichen?

Nein.

>Bei den Fehler Berechnungen komme ich auf einen Fehler von 1.49%

Ich komme auf 3,1%, wenn man mit der klassichen /16 Teielung im UART 
arbeitet. Bei /8, wie sie die AVRs und andere beherrschen, komt man auf 
1,56%. Das ist zwar etwas viel, geht auber noch, wenn die Gegenstelle 
(meist PC) mit 0% Fehler arbeitet.

MFG
Falk

A. K. schrieb:
> Daher macht das
> hTerm auch nicht anders und reicht den Wert auf Gedeih und Verderb
> durch.

Das bedeutet man hat kein garant das der Uart diese baud auch erzeugen 
kann?

> Aeh ... 19660800 / 115200 = 170,666 .. sind nur 0.2% Fehler wenn man 171
> als Teiler einstellt.
Das greift deutlich zu kurz. Aus diesem Ergebnis kann man nur ableiten, 
dass der angegebene Quarz garantiert keine ideale Lösung erlauben 
wird. Was letzlich dabei herauskommt, hängt noch von den internen 
Zählerregistern des uCs ab. Denn es sollte ja auch das Oversampling von 
8 berücksichtigt werden...

Edit:
ich komme auch auf den Wert, den Falk angegeben hat: 0,195% * 8 = 1,56%

Lothar Miller schrieb:
> ich komme auch auf den Wert, den Falk angegeben hat: 0,195% * 8 = 1,56%

Somit kann ich 115200baud verwenden?

Die gegenseite ist ein PC

Ja.

Siehe

http://pdfserv.maxim-ic.com/en/an/AN2141.pdf

im Artikel Baudratenquarz. 3% sind theoretisch tolerierbar.

MFG
Falk

Falk Brunner schrieb:

> wenn die Gegenstelle (meist PC) mit 0% Fehler arbeitet.

Denkste!

Neugierig geworden habe ich grad mal ins Datasheet des erstbesten 
LPC-SuperIO Bausteins reingesehen, so ein Ding mit dem PCs den ollen 
Kleinkram wie PS/2, UART, Floppy usw. abwickeln.

Der Baustein hat genau 3 Taktanschlüsse:
32768Hz
14,xMHz ISA-Bus Takt
PCI Bustakt.

Einen Baudratenquarz sucht man vergeblich. Tatsächlich leitet die UART 
die Baudrate aus intern per PLL hochgehetzten 96MHz/24MHz ab, mit 
wählbaren Vorteilern 6.5, 13 und 12 (wg. MIDI). Die Tabelle gibt daher 
bereits für 38400 einen Fehler von 0,03% an, bei den darüber liegenden 
PC-typischen Raten 0,16%. Das ist nicht dramatisch, aber von wirklich 
quarzgenauen Raten sollte man bei hohen Baudraten nicht unbedingt 
ausgehen.

A. K. schrieb:
> Einen Baudratenquarz sucht man vergeblich. Tatsächlich leitet die UART
> die Baudrate aus intern per PLL hochgehetzten 96MHz/24MHz ab, mit
> wählbaren Vorteilern 6.5, 13 und 12. Die Tabelle gibt daher bereits für
> 38400 einen Fehler von 0,03% an, bei den darüber liegenden PC-typischen
> Raten 0,16%. Das ist nicht dramatisch, aber von wirklich quarzgenauen
> Raten sollte man bei hohen Baudraten nicht unbedingt ausgehen.

Sehr spannend...

Danke für deine Hilfe...

Ich denke am besten isses, wenn ich einfach mal 115200 oder 128000 
ausprobiere und berichte wies herausgekommen ist.

Das ganze ist für einen Simplen LogicAnalyzer...

Attiny2313 liest den PORTX komplett ein und sendet diesen an den PC zur 
visualisierung.

Ich weiss das dieses vorgehen relativ langsam ist.

Bei den USB/Serial-Bausteinen dürfte das ähnlich aussehen wie bei den 
PC-SuperIOs. Überall findet man 24MHz/13 oder Varianten davon als 
Basistakt der UART-Raten wieder, bei USB sowieso naheliegend. Das ist 
eben jene 0,16% von der exakten Baudrate entfernt.

Karl heinz Buchegger schrieb:
> Claudio Hediger schrieb:
>> Die frage ist, was ist das höchst mögliche mit dem AVR
>
> Du drehst dich im Kreis :-)
> Die höchst mögliche auf dem AVR ergibt sich aus der maximalen
> Taktfrequenz, dir der AVR noch mitmacht und dem kleinstmöglichen Wert
> (also 1) den man noch in die UBRR Register laden kann.
>
In UBRR kann auch eine 0 geschrieben werden. Außerdem kann noch ein Bit 
zur Verdopplung der Datenrate gesetzt werden. Mit 18,432MHz sind so 
maximal 2,304MBaud möglich.

Claudio Hediger schrieb:

> Das ganze ist für einen Simplen LogicAnalyzer...

Dann hau dem einen FTDI an Stelle des Mäxchens rein und du bist das 
Problem los und kannst in die Vollen gehen.

A. K. schrieb:
> Dann hau dem einen FTDI an Stelle des Mäxchens rein und du bist das
> Problem los und kannst in die Vollen gehen.

Ich verwende auch einen FT232RL :)

Für diesen benötige ich doch aber noch einen 12MHz Quarz richtig?

Um die Baudrate beim FT232RL einzustellen muss ich diese einfach zb mit 
hTerm einstellen und der FTDI Treiber regelt den rest oder?

Schau ins Datasheet vom FT232RL rein, da steht wie der die Baudrate 
berechnet. Wobei ein Baudratenquarz am AVR dabei nicht optimal ist. Wenn 
das kein Serienprodukt wird, dann kannst du evtl. mal ausprobieren, ob 
der AVR am 24MHz Ausgang des FT232R noch funktioniert.

A. K. schrieb:
> Wenn
> das kein Serienprodukt wird, dann kannst du evtl. mal ausprobieren, ob
> der AVR am 24MHz Ausgang des FT232R noch funktioniert.

Nein wird kein serien produkt...

Ja das klingt interessant...


Was meintest du genau mit in die Vollen gehen?

Du dachtest schon auch das ich die daten vom attiny2313 per RS232 an den 
FT232TL sende oder?

Claudio Hediger schrieb:

> Was meintest du genau mit in die Vollen gehen?

Mit einem 24MHz Takt am AVR kannst dort mit 3Mbps rausblasen. Der FTDI 
kann das ebenfalls.

A. K. schrieb:
> Mit einem 24MHz Takt am AVR kannst dort mit 3Mbps rausblasen. Der FTDI
> kann das ebenfalls.

Sehr gut... wird ausprobiert...

Danke!

Und die 24MHz holt sich der AVR aus einem entsprechend konfigurierten 
Ausgang vom FT232. Ein Quarz weniger. Kann sein, dass der AVR das nicht 
packt, aber das wirst du sehen.

PS: Eine andere Frage ist, ob hTerm damit zu Rande kommt. Das 
Bray-Terminal macht jedenfalls schon bei 38400 manchmal schlapp und 
verliert Daten. :-(

Kann auch sein, dass du Raten wie 3Mbps nur mittels der FTDI Library 
gebacken kriegst, nicht mit hTerm. Aber so schnell kannst du ohnehin 
nicht gucken und wenn's ein LA wird, dann wirst du wohl letzlich ein 
PC-Programm im Sinn haben.

RS232 ist nicht unbedingt die beste Lösung.
Mit RS485 (bis 10Mbit) hast du störsichere Übertragung... dagegen ist 
RS232 lächerlich.
Treiber-ICs brauchst du sowieso, also was soll der Geiz ?
USB und Ethernet wären auch vielverspechend, aber für Microcontroller 
ist das Protokoll zu aufwändig, so dass die Übertragung enttäuschend 
langsam wird.

Ohforf Sake schrieb:

> RS232 ist nicht unbedingt die beste Lösung.
> Mit RS485 (bis 10Mbit) hast du störsichere Übertragung... dagegen ist
> RS232 lächerlich.

Noch nicht gemerkt, dass hier nirgends RS232 übertragen wird, sondern in 
Wahrheit USB über die Strippe geht? Und für die paar Zentimeter zwischen 
AVR und FT232R tut's auch CMOS/TTL-Pegel.

A. K. schrieb:
> Kann auch sein, dass du Raten wie 3Mbps nur mittels der FTDI Library
> gebacken kriegst, nicht mit hTerm. Aber so schnell kannst du ohnehin
> nicht gucken und wenn's ein LA wird, dann wirst du wohl letzlich ein
> PC-Programm im Sinn haben.

Jahp habe ein Programm im Sinn...

Visualisierung hab ich auch bereits implementiert... es fehlen lediglich 
die Daten.

Ich programmiere in Delphi... Also meinst du mit FTDI Library den 
zugriff auf eine DLL?

Claudio Hediger schrieb:

> Ich programmiere in Delphi... Also meinst du mit FTDI Library den
> zugriff auf eine DLL?

Exakt. Gibt's bei FTDI zum Download.

A. K. schrieb:
> Noch nicht gemerkt, dass hier nirgends RS232 übertragen wird, sondern in
> Wahrheit USB über die Strippe geht? Und für die paar Zentimeter zwischen
> AVR und FT232R tut's auch CMOS/TTL-Pegel.

OK. Bin mal gespannt, wie schnell das in der Praxis ist.

A. K. schrieb:
> Exakt. Gibt's bei FTDI zum Download.

Hast du damit bereits gearbeitet?

Kann ich da Zeichen um Zeichen empfangen?
oder ists es aufwändiger?

Claudio Hediger schrieb:

> Hast du damit bereits gearbeitet?

Ja, allerdings beim FT2232 und dessen erweiterten 
Schnittstellenmöglichkeiten (SPI/I2C/Bus).

> Kann ich da Zeichen um Zeichen empfangen?

Ja, wenn dir danach der Sinn steht. Spezialfall mit Pufferlänge 1. Ist 
bei einer Datenrate von 3Mpbs aber nicht unbedingt zu empfehlen. Da wird 
es sinnvoller, wenn du einen eigenen Puffer zwischenschaltest.

A. K. schrieb:
> Ja, wenn dir danach der Sinn steht.

Was würdest du empfehlen?

Wie meinst du einen eigenen Puffer Zwischenschalten?

100 Bytes anfordern, 80 Bytes kriegen und die 80 Bytes auf Anfrage 
nacheinander abliefern. Erspart einen Rattenschwanz an unsichtbarem 
Aufwand in den Ebenen zwischen deinem Programm und dem USB-Treiber.

A. K. schrieb:
> 100 Bytes anfordern, 80 Bytes kriegen und die 80 Bytes auf Anfrage
> nacheinander abliefern.

Könntest du mir das ein bisschen genauer erklären?

Sorry, aber jetzt landen wir in einem Bereich, der mir zu sehr nach 
"Händchen halten und jeden einzelnen Schritt vormachen" riecht. Bischen 
Grundkenntnisse in Programmierung setze ich als gegeben voraus.

Ok...

Claudio Hediger schrieb:
> A. K. schrieb:

> Das ganze ist für einen Simplen LogicAnalyzer...
>
> Attiny2313 liest den PORTX komplett ein und sendet diesen an den PC zur
> visualisierung.
>
> Ich weiss das dieses vorgehen relativ langsam ist.

Für die maximale Geschwindigkeit solltest Du auf den Flaschenhals 
Seriell verzichten und einen FTDI245 und einen etwas größeren AVR 
wählen. Der FTDI245 stellt dem PC eine virtuelle serielle Schnittstelle 
über USB zur Verfügung, hat aber tatsächlich eine 8 Bit parallele. Damit 
kannst Du auf dem PC einstellen, was Du willst, es ist einfach egal. Die 
Übertragungsgeschwindigkeit wird nur durchs USB begrenzt - und Deinen 
AVR.

fchk

Wenn du an einen Tiny2313 (hierfür ohnehin etwas auf der krassen Seite) 
einen FT245 anschliesst, dann sind praktisch alle Pins weg.

A. K. schrieb:
> PS: Eine andere Frage ist, ob hTerm damit zu Rande kommt. Das
> Bray-Terminal macht jedenfalls schon bei 38400 manchmal schlapp und
> verliert Daten. :-(
460800Baud sind kein Problem mit meinem RS232->USB-Wandler von Reichelt. 
Habe einige tausend mal die Ziffernfolge 0..255 übertragen und bislang 
hat kein Byte gefehlt.

> 460800Baud sind kein Problem mit meinem RS232->USB-Wandler von Reichelt.
> Habe einige tausend mal die Ziffernfolge 0..255 übertragen und bislang
> hat kein Byte gefehlt.
Mit 460800Bit/s / 10Bit = 46kByte/s
und 1000 * 256Byte = 256kByte
gibt das 256k / 46k/s = 5,5s pro Durchlauf.

Du hast also einige 5,5 Sekunden lang Daten übertragen...
Das ist m.E. noch nicht so richtig viel  ;-)

Alle Welt stellt von Parallel auf Seriell um (PCI->PCI Express) und ihr 
von Seriell auf Parallel (FT232->FT245) ;-)

Wie schon gesagt, die paar Zentimeter serielle Schnittstelle ist doch 
nicht tragisch auf einer Platine.

Ja. Bei RS232 Ist ein Bit genau ein Symbol. (Du kannst mal den Wiki 
Artikel zu "Baud" durchlesen). Ein RS232 "Paket" hat aber min. 10 Bit 
(10 Symbole) die für ein Byte übertragen werden müssen.

A. K. schrieb:
> Wenn du an einen Tiny2313 (hierfür ohnehin etwas auf der krassen Seite)
> einen FT245 anschliesst, dann sind praktisch alle Pins weg.

Wer sagt denn, dass die Datenbits DURCH den Prozessor müssen. Der FT245 
hat doch einen 8 Bit Port. Und er will 8 Bit übertragen. Dann langt es 
doch, wenn der AtTiny nur das Timing an den Handshake-Leitungen vorgibt 
und sich der FT245 die Daten direkt abgreift.

Dann wirds richtig schnell, und das ganze Gehampel mit Baudraten kann 
man dann vergessen.

fchk

Yep, das könnte man auch machen. Die Datenleitungen braucht er natürlich 
immer noch, aber nur zur Steuerung, nicht mehr für die eigentlichen 
Daten.

Lothar Miller schrieb:
>> 460800Baud sind kein Problem mit meinem RS232->USB-Wandler von Reichelt.
>> Habe einige tausend mal die Ziffernfolge 0..255 übertragen und bislang
>> hat kein Byte gefehlt.
> Mit 460800Bit/s / 10Bit = 46kByte/s
> und 1000 * 256Byte = 256kByte
> gibt das 256k / 46k/s = 5,5s pro Durchlauf.
>
> Du hast also einige 5,5 Sekunden lang Daten übertragen...
> Das ist m.E. noch nicht so richtig viel  ;-)

immerhin mehrere Minuten mit Vollgas. Bei >1Mio Zeichen und nicht einem 
fehlerhaften Byte schonmal nicht schlecht. Klar, irgendwann fängt man 
sich mal nen Bitfehler ein. Kommt dann auf die Anwendung drauf an, ob 
das kritisch ist, oder drüber hinweg gesehen werden kann.

Wieso sollte man sich mal einen Bitfehler einfangen? Doch nicht, wenn 
alles in Ordnung ist...

Hallo

Ich hab nun also Neuigkeiten

Nach vielen Stunden intensiver arbeit... klappt nun alles...

Acuh das PC Programm läuft...



Maximale Geschwindigkeit liegt bei 233kSamples / Sekunde

Was sagt ihr zu diesem Wert?

>Wieso sollte man sich mal einen Bitfehler einfangen? Doch nicht, wenn
>alles in Ordnung ist...

Stimmt, Bitfehler hab ich noch nie beobachtet. Wohl aber das 
"Verschlucken" von Bytes durch den FTDI Treiber. War bei 460800 Baud 
aber auch vom PC abhängig. Bei meinem ists passiert(2-3X/Tag bei kont. 
Senden), bei dem vom Kunden gottseidank nicht. Trotzdem irgendwie eine 
schwindlige Geschichte mit dem FTDI. Wenn der nur nicht soo praktisch 
und einfach zu verwenden wäre.

Grüße

Simon K. schrieb:
> Wieso sollte man sich mal einen Bitfehler einfangen? Doch nicht, wenn
> alles in Ordnung ist...

Es gibt keine absolut fehlerfreie Übertragung. Die Bitfehlerrate hängt 
von der Signal-to-Noise-Ratio (SNR) ab, je niedriger die SNR, desto 
höher wird die Fehlerrate. Da die SNR realer Systeme nicht unendlich 
werden kann, kann die Fehlerrate auch nicht 0 werden.

Beispiel Gigabit-Ethernet, das darf nach Spec eine Fehlerrate von max. 
10^-12 haben, also eines von 10^12 Bits darf fehlerhaft übertragen 
werden. 10^12 klingt erstmal nach viel, aber 10^12 Bits zu senden dauert 
bei 1,25Gbps (Roh-Datenrate von 1000baseT) gerade mal ca. 13 Minuten, 
statistisch gesehen darf also alle 13 Minuten ein Übertragungsfehler 
auftreten.

Andreas