250 kByte/s mit UART?

Hallo!

Ich bräuchte mal eine Einschätzung von Euch. Ich möchte eine Schnittstelle zwischen einem AVR und einem FoxBoard (http://www.acmesystems.it/?id=4) realisieren, über die ich Datenraten bis zu 250 kByte/s schieben kann. Weil ich das ganze so straight forward wie möglich machen möchte, hatte ich folgenden Gedanken: könnte ich nicht bei AVR und FoxBoard den UART dafür verwenden, also im Prinzip eine RS232 Verbindung, nur eben mit TTL-Leveln? Es ist mir schon klar, dass ich da in der Größenordnung von 2000 kBaud (2 Mbit/s) und mehr lande – etwas untypisch für UART, oder? Sowohl der AVR als auch das FoxBoard erlauben mir allerdings ja prinzipiell so hohe Taktungen. Ist es prinzipiell denkbar, problemlos so hohe Taktungen mit dem UART zu verwenden, oder kann man das von vorn herein vergessen? Was ich noch ergänzen sollte: das ganze läuft natürlich nicht über ein langes Kabel, sondern direkt auf einer Platine, also über eine Strecke von 10-20 mm.

Bin für alle Tipps und Hinweise sehr dankbar!

Gruß,
Malte

hm leider hab ich auf die schnelle keine spezifikationen für den i2c bus zu deinem foxsystem gefunden, aber vll. findest folgenden link interessant, dann kannste per i2c mit deinem AVR reden ?!

http://www.acmesystems.it/?id=10

Hallo!

Die Variante hatte ich verworfen, weil I2C meiner Ansicht nach beim AVR nur bis 400 kHz möglich ist.

Gruß,
Malte

für derartige uart übertragungsraten solltest du dann aber schon einen sehr genauen qiarz mit diesen etwas krummen MHz zahlen verwenden, um die fehler minimal zu halten, ausserdem solltest du dann kontrollieren welches pegelwandler du benutzt, einige der max232 kapitulieren bei solchen datenrate, allgemein musst du mit den verwendeten bauteilen und den tolleranzen aufpassen ... ich selber habs aufgegeben und bis bei 57600kBaud geblieben, alles drüber brachte keine brauchbaren ergebnisse mehr ...

Hallo!

Wie gesagt: einen MAX232 will ich garnicht verwenden, weil ich mich nicht an den rs232-Standrad halten muss. Ich würde TTL-Pegel verwenden. Deine Bemerkung mit dem Quarz ist mir unklar. Natürlich muss die Baudrate auf beiden Seiten so gleich wie möglich sein. Aber ob sie krumm oder grade ist, ist doch um Endeffekt egal.

Gruß,
Malte

nicht ganz, schau mal ins datenblatt des avr, da steht ne sausfühliche liste mit welchem quarz und welcher baudraet welche abweichung entsteht ...
hat was mit den prescalern zu tun wegen binärsystem und dezimalsystem ... lieder hab ich seit dem letzen update ein problem PDFs aufm PC zu öffnen, sonst könnt ichs dir genau sagen

Hallo Malte,

also 250kByte/s wird ziemlich eng mit den AVR's

250*1024Byte = 256000Byte * 10Bit (Start/stopzeichen no Parity) = 2,56MBit

Der ATMega128 kann mit einem 20Mhz Quarz, 2,5MBit. Wobei dieser eigentlich nur bis 16MHz spezifiziert ist.

Da die Gegenseite das auch können muß wäre es zudem Sinnvoll noch ein Protokoll drüber zu fahren, dann kommst Du bei weitem nicht mehr hin.

Grüße

Hallo!

Nur nochmal nachgefragt: Also so lange ich mit der Bandbreite hinkäme, spräche aber nichts dagegen, so eine schnelle UART-Kommunikation zu verwenden?

Vielen Dank!
Malte

Hallo Malte,

wie Radio Eriwan sagt, im Prinzip ja.

Solche Übertragungsraten sind machbar, ohne Frage, nur werden die Probleme mit Schirmung, Übersprechen usw. natürlich größer.

Zudem muß (sollte man) bei diesen Übertragungsraten CRC-Prüfungen vorsehen, was zusätzlich Bandbreite benötigt.

Hast Du keine Möglichkeit die Daten vielleicht schon vor zu verarbeiten, um die Bandbreite geringer zu halten?

Ansonsten nur los und halt uns auf dem laufenden wie es geklappt hat.

Grüße

Eigentlich spricht nicht viel gegen die hohen Datenraten. Auf die gleiche Baudrate muß man auch bei hohen Taktraten nicht mehr achten als bei niedrigen, sofern die eigentlich Übertragung ungestört ist. Wenn man beide Seiten selber kontrolliert muß man auch keine genormte Baudrate nehmen, ein Quar mit spezieller Frequenz ist also nicht nötig.
Eine CRC Prüfung sollte auch eher unnötig sein. Man muß aber eventuell aufpassen ob die Daten auch so schnell verarbeitet werden können, sodass keine Daten verloren gehen.

naja es sieht nicht so aus als ob er die baudrate oder frequenz des foxboard (ab von irgendwelchen standards)manipulieren kann und deshalb geh ich mal davon aus das es sehr exakt arbeitet !
wenn der avr dann nciht präzise genug ist, kann es schon problematisch werden ?! ist doch dasselbe wie ein PC im prinzip und der macht bei steigender datenrate auch mehr zicken

Hallo nochmal!

Gut, ich bin so weit im Bilde :) Vielen Dank! Wie ich das Problem jetzt tatsächlich angehe, weiss ich noch nicht. Wenn ich etwas von Interesse zu Wege gebracht habe, werde ich gerne hier berichten.

@ceos: natürlich kann ich die Baudrate beim FoxBoard einstellen, wieso auch nicht!?

Gruß,
Malte

Mal ne Frage.

Reden wir hier über 250 kBit/s - Die sind für einen AVR mit 8MHz Quarz kein Problem, oder reden wir hier tatsächlich über 250 kByte/s was dann 2000 kBit/s wären ? Und da wirds eng.

Übertragungsraten werden üblicherweise in kBit/s angegeben - weil Du am Ende von einer Baudrate sprichst.

naja ich meinte du kannst im AVR das MCUCR register beschreibn und ne krumme baudrate einstellen die kein PC je versteht, das ginge beim foxboard nicht, und es schien mir, dass Besserwessi darauf hinaus wollte ?!

okok lassen wir das :p will ja kein offtopic disput über die auslegung von sachverhalten anderer personen im vergleich zu mir halten XP

Hallo,

ich meinte genau das, was ich geschrieben habe, also 250 kByte/s, was in der Tat ca. 2 Mbit/s sind (s.o.) :)

Um die Sache mit der Baudrate nochmal klarzustellen: die Baudrate ist die Symbolrate und wird (strenggenommen) in Symbole/s gemessen. Theoretisch davon zu unterscheiden ist die Datenübertragungsrate, die wird in der Tat in Bit/s gemessen. Aber so lange die Einheiten stimmen, sind Namen ohnehin Schall und Rauch ;)

Gruß,
Malte

ich denk 2 Megabit/s werden für nen AVR zu eng sein,
1 MBit/s sollen gehen, aber das Doppelte gleich
vermutlich nicht und wenn, dann hat er vermutlich
keine Zeit mehr für andere Geschichten dazu, dann
wird er komplett mit Datenübertragung belegt sein ...
Zähl mal die Zyklen, wieviele brauchst Du
um das UDR-Register zu beschreiben und u.U. noch
Daten aus dem RAM zu lesen bzw. Daten aus dem UDR lesen
und ins RAM zu schreiben ohne das noch n loop fürs
TXC-Register dabei wäre :(

Die Rechenzeit wird knapp, aber man hat bei 16 Mhz Takt immerhin noch 64 Zyklen pro Byte. Da kann man duchaus noch was machen, zumindest in Assembler.

Hallo Vitis und Besserwessi!

Jo, das ist dann gleich das nächste Problem. Ich kann noch nicht genau abschätzen, wieviel Zeit ich noch neben der Datenübertragung brauche. Im Prinzip soll der AVR nichts anderes tun, als die einlaufenden Daten Puffern und mit präzisem Timing per SPI an einen 8-Kanal-16-Bit-DAC weiterreichen und dabei einige Triggerkanäle setzen. Ich bin mit meiner Planung aber noch ganz am Anfang, also ggf. ändere ich konzeptionell auch noch alles.

Dank Euch!
Malte

FPGA wird die Antwort auf die Geschichte sein denke ich

Je nachdem wie Aufwendig die Triggerkanäle sind sollte das von der Geschwindigkeit gehen. Das Präzise timing könnte aber nicht ganz einfach werden, zumindestens in einer Hochsprache. Vom Umfang der Aufgabe sollte dafür wohl schon ein Mega48, Mega168 oder so reichen, da kann man dann bis 20 MHz takt gehen. Begrenzend ist da eher das RAM als das Flash.