Hallo Ist es möglich, mit einem 19.6608Mhz Quarz eine UART Baudrate von 115200 zu erreichen? Bei den Fehler Berechnungen komme ich auf einen Fehler von 1.49% Doch es ist doch ein Baudratenquarz also sollte es doch möglich sein oder? Danke schonmal
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.
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.
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.
Die Frage welche Baudrate maximal möglich ist kannst Du Dir leicht ausrechnen. Du mußt in der Zeit die ein Zeichen zur Übertragung benötigt das zuvor empfangene Zeichen aus dem Uart auslesen und z.B. Anspeichern. Ggf. muß Du noch Zeit für die Weiterverarbeitung der Daten berücksichtigen. Ein Zeichen besteht z.B. aus 10 Bit: Das Zeichen selber 8 Bit plus Start und Stopp-Bit- ggf. kommen noch ein Parity-Bit und ein weiteres Stopp-Bit hinzu. Mit diesen Angaben sollte es doch möglich sein das zu berechen.....
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.
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.
So ich hab nochmal ne Frage Wie viele baud sind 3Mbit / sekunde? 3MBaud?
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.
A. K. schrieb: > 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. An das habe ich auch bereits gedacht... Für etwas gibt es ja Version 2.0 :)
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.