Hallo, ich möchte eine größere Datenmenge per USB über den CP2102 zu meinem XMega128 schicken. Den CP2102 habe ich zum USBxpress Device konfiguriert und mir eine kleine C# Anwendung geschrieben welche die Baudrate wie folgt festlegt: SI_SetBaudRate(def_handle, 576000); Laut der Baudratendefinition von SiLabs ist das mit eine 576000er UART Baudrate möglich. http://www.silabs.com/Support%20Documents/TechnicalDocs/an205.pdf für einen ersten Test habe ich mich mit dem AVR1307 Using UART tutorial und interruptgesteuerter Übertragung versucht. In der dort beiliegenden Excel-Datei wird mir ein BSCALE Wert von -7(0b1001) und ein BSEL Wert von: 761 -> -0,01% Error mit CLK2X 316 -> -0,10% Error ohne CLK2X Beide Einstellungen führen merkwürdigerweise zu keiner Übertragung. Im Netz habe ich folgenden Calculator gefunden: http://prototalk.net/forums/showthread.php?t=188 dieser hat mir BSCALE Wert von -6 und BSEL 158 errechnet mit dem es mir gelungen ist, 524288 Bytes fehlerfrei in 9,9018803(ca. 53kb/s) sec vom XMega zum PC zu übertragen. Nun mehrere Fragen. 1.) Macht es einen Unterschied ob ich Interruptgesteuert oder Polled vorgehe um hohe datenübertragungsraten zu erreichen? 2.) Welche Datenübertragungen sind realistisch/überhaupt machbar? Excel-Tabelle hat eine Spalte für 921600. 3.) Und noch wichtiger. Was hat es mit dem CLK2X(Double Speed) auf sich. Ich finde in der beiliegenden PDF und in dem Beispiel-Code keine nützlichen Informationen wie ich diesen Modus nutzen kann. 4.) Aus welchem Grund funktioniert der Calculator und die Excel-Tabelle von Atmel nicht? Gruß Max
Max schrieb: > Nun mehrere Fragen. > 1.) Macht es einen Unterschied ob ich Interruptgesteuert oder Polled > vorgehe um hohe datenübertragungsraten zu erreichen? "Polled" ist schneller, ist "pfui", ist unnötig und du kannst nichts anderes nebenbei erledigen. > 2.) Welche Datenübertragungen sind realistisch/überhaupt machbar? > Excel-Tabelle hat eine Spalte für 921600. 1 MBaud bei 32 MHz CPU-Clock macht ca. 320 Takte pro Byte. Das ist noch Luft und du kannst dir aussuchen, wie du die Daten aus dem Empfänger holst. Was spricht gegen DMA? > 3.) Und noch wichtiger. Was hat es mit dem CLK2X(Double Speed) auf sich. > Ich finde in der beiliegenden PDF und in dem Beispiel-Code keine > nützlichen Informationen wie ich diesen Modus nutzen kann. Bei CLK2X gibt es nur noch 8 "Zeitslots", in denen nach dem Startbit gesucht wird, normalerweise sind es 16. Lies dazu "21.8.1 Asynchronous Clock Recovery" im "XMEGA A MANUAL". > 4.) Aus welchem Grund funktioniert der Calculator und die Excel-Tabelle > von Atmel nicht? Hab ich noch nie verwendet.
Also ich habe es gerade mal getestet. Ebenfalls Atxmega (Atxmega32A4) bei 32 MHz internen Oszillator. Ebenfalls CP2102 Baudrate: 921600 Bsel = 150 Bscale = -7 Ergibt 0.08% Abweichung. Bisher keine Übertragungsfehler. Allerdings wird es vermutlich schwierig größere Datenemengen so schnell zu verarbeiten bei 32 MHz. Mehr als erstmal nur entgegennehmen und im Speicher ablegen würde ich vermutlich nicht machen. Hier würde ich mit Interrupts arbeiten. Der Interrupt schreibt einfach nur die empfangenen Daten in einen Speicher und parallel kannst du in einer anderen Routine die Daten schonmal abarbeiten. Mit der DMA-Maschine habe ich mich noch nicht beschäftigt.
Erschlagt mich bitte nicht wenn ich mich irre aber 921600 macht bei 8 datenbits und einem stopbit ca. 100kb/s aus. Sehe ich das richtig? Dann habe ich eine andere frage. Das mit dem UART ist nur um Daten von Außen 'rein' zu bekommen. Eigentlich soll der xmega 2 SPI Geräte + microSD handeln. Eines der Geräte ist datenempfänger und die microSD bzw. das andere Spi gerät stellen wahlweise die Datenquelle mit ca. 200kb/s. Ist mein xmega überhaupt in der Lage das zu bewerkstelligen?
max schrieb: > Erschlagt mich bitte nicht wenn ich mich irre aber 921600 macht bei 8 > datenbits und einem stopbit ca. 100kb/s aus. Sehe ich das richtig? Jo, genau wären es, da 10 bits pro byte übertragen werden, maximal 92160 bytes/sec. Die Zeit zum Empfang des nächsten Bytes muss dann allerdings reichen, um das eine Byte wegzuspeichern und den Rest des Programms zu beackern. Übrigens warens oben noch 57600 bytes/sec, warum denn jetzt doppelt so schnell ? max schrieb: > Ist mein xmega überhaupt in der Lage das zu bewerkstelligen? Tja, wenn das alles gleichzeitig passieren soll und währenddessen die UART ihn auch noch beschäftigt, kann es eng werden. SPI ist allerdings nicht so zeitkritisch in Bitdauer und clocklänge usw. SD Karten können aber etwas unvorhersehbar reagieren, ein RDY Signal nch dem Schreiben kann mal früher, mal später kommen.
Die USB -> UART -> Xmega- Verbindung ist im Endstadium nurnoch zur Steuerung gedacht was sehr selten vorkommen wird da die Applikation i.d.R. getrennt von einem PC seinen Job verrichten wird. Die hohe Datenübertragung von USB dient nur zur erleichterung der Entwicklung da ich mit ihr gezielt daten an das empfangende SPI-Gerät schicken kann. Im Alltag werden somit nur daten von SPI-Sender oder SD-Card zum SPI-Empfänger geschickt. Ergo: 200kb/s rein und wieder raus ohne manipulation der daten oder dergleichen. Besonders wünschenswert wäre das Senden der Daten vom SPI-Sender zum SPI-Empfänger und zur SD-Card als eine Art logging aber das ist keine Pflicht. Das sollte doch mein Xmega hinbekommen ohne dabei unbrauchbar für die ausführung von Steuerungssignalen von UART zu werden oder muss ich mir dafür schon einen stärkeren µC zulegen? Gruß Max
Max schrieb: > oder muss ich mir > dafür schon einen stärkeren µC zulegen? Ich sag mal nee, das schafft er schon, vor allem wenn du mit den Interrupts geschickt umgehst. Ein Cortex M3 mit 24 Mhz ist da keineswegs schneller :P Ich zumindest bin bei Vergleichen zwischen den XMegas mit 32 Mhz und den STMs mit 24 Mhz von den XMegas überzeugter. Will aber jetzt keinen Thread über Performance lostreten :-)
Der Xmega sollte das schaffen, Von SPI Empfänger zu sender einen DMA Kanal, bzw. einen zweiten als Rückkanal, aufmachen, dann ist das dem Prozessor erstmal egal und erzeugt keine Last. (ok nicht ganz, es belastet die Datenbus, aber da der Prozessor ja nicht nur laden und speichert ist das egal) Mittels Interrupt die Daten vom SPI noch auf die SD-Karte schicken. Hier spielen die Timings der SD-Karte eine Rolle, könnte vllt. nicht mit jeder klappen, fehlt mir aber die Erfahrung dafür. Und USART Befehle auch über Interrupt annehmen.
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.