Hallo Miteinander Bei einem "kleinen" Projekt muss ich ca 1,44M Bit/s Nutzdaten übertragen. Daher fällt RS232 leider ganz weg. Bis jetzt ist mir nur USB als Alternative eingefallem, nur ist das ganze Neuland für mich. Nur das Problem ist, bei den Dokumanten, sie ich bis jetzt studiert habe, komme ich nicht ganz mit: http://www.sprut.de/electronic/interfaces/usb/usb.htm http://interface.centraltreasure.com/files/pdf/usb_standart_in_a_nutshell_pdf.pdf Und hier habe ich noch eine Firmware gefunden, aus deren Code ich nicht schlau werde: http://www.obdev.at/products/vusb/index-de.html kennt jemand von euch eine wirklich informativ und praxisorientierte Seite, wo USB gut erklährt ist, auf der MCU und auf der PC Seite, die alles schön erklährt ist. Anschliessend muss ich wohl auch noch eine entsprechende Applikation mit GUI schreiben. Ausserdem habe ich noch eine Frage: was würdet ihr für ein MCU empfehlen? bis jetzt habe ich mich nur mit AVR beschäftigt, weil die ersten Versuche mit PIC mir nicht so gut gefallen haben. Selbst mit dem C18 Compiler habe ich mich nicht so anfreunden können. Die Register un Bits sind nicht so schön definiert. Danke für eure Hilfe P51D
:
Verschoben durch Moderator
Wie wäre es mit einem FTDI Chip http://www.ftdichip.com/Documents/DataSheets/DS_FT232R_V204.pdf Der schafft 3MBaud also 3Mbit bei RS232 mit TTL-Pegeln siehe Seite 1 gleich. Gruß John
den FT232 kenne ich schon, nur habe ich bis jetzt angenommen, dass man beim MCU die Baudrate einstellen muss, und mir ist bis jetzt keiner bekannt, der über 1M Baud geht. Zudem muss man auf der PC Seite auch die Baudrate einstellen, da der FTDI "nur" eine RS232 über USB Simuliert. Kenne kein Terminal das über 500k Baud schafft. Ich arbeite mit Docklight und das schafft auch nur 256k Baud Oder habe ich etwas übersehen? Aber Danke für die Antwort
Wenn du eine eigene Software schreibst, kannst du den SerialPort mit beliebigen Baudraten einstellen. Ich arbeite mit dem FTDI bei 921.600 Baud, das klappt wunderbar. Das kann man der DCB eifach so übergeben. Klar, die meisten "Terminal" Programme erlauben maximal 115.200, aber das liegt rein an der Software. Aber wenn du 1,44 MiBit/s kontimuierlich übertragen willst, brauchst du bei USB einiges mehr an Geschwindigkeit, sonst machen die die Übertragungspausen einen Strich durch die Rechnung. Die nächst einfachere Stufe wäre der FT245, der schafft im FIFO Modus 1 MiByte/s, das könnte reichen. Oder halt der neue FT2232H, der schafft über 20 MiByte/s dank USB 2.0 und ist genauso einfach anzzsprechen (FIFO Modus und D2XX DLL).
> den FT232 kenne ich schon, nur habe ich bis jetzt angenommen, > dass man beim MCU die Baudrate einstellen muss, und mir ist bis > jetzt keiner bekannt, der über 1M Baud geht. Der Atmega8 schafft laut Datenblatt bei 20 Mhz Takt bis zu 2,5Mbit/s.
ok um etwas Verwirrung zu vermeiden muss ich wohl noch was wiederholen und ergänzen: Bei so einer Geschwindigkeit würde ich mir dann ein Protokoll erstellen, dass bei der Übertragung nicht viel schief gehen kann. und das ganze dann 30'000 mal pro Sekunde SOH (1 Byte) Command (1 Byte) Number of Bytes (1 Byte) Parameter (6 Byte) CRC (1 Byte) EOT (1 Byte) würde demnach 11 Bytes sein und dies würde einer Baudrate von 3,3M Bit entsprechen. das mit dem FT2232H werde ich mir genauer ansehen. PC-seitig kann ich die baudrate einstellen wie ich will, aber beim mcu nicht. Kennt jemand ein mcu der die Baudrate wenn möglich voll ausschöpft? wenn möglich ein avr, da ich bei diesen die meisste erfahrung habe.
Also bei http://www.der-hammer.info/terminal/ kann man auch andere Baudraten eintippen. Habe einen Atmega128 mit 500KBaud betrieben um einen Eprom zu programmieren.
Patrick B. schrieb: > den FT232 kenne ich schon, nur habe ich bis jetzt angenommen, dass man > beim MCU die Baudrate einstellen muss, und mir ist bis jetzt keiner > bekannt, der über 1M Baud geht. Dann nimm einen FT245, der benutzt den gleichen Treiber auf der PC- Seite, weil er das gleiche Protokoll spricht, aber die eingestellte Baudrate ist schnuppe, da er zum µC hin parallel angebunden wird. Ansonsten kannst du noch über AT90USBxxx nachdenken, wenn du bei einer reinen AVR-Lösung bleiben willst. Als Firmware würde sich dann wohl was auf der Basis von Dean Cameras LUFA anbieten.
Jörg Wunsch schrieb: > Dann nimm einen FT245, der benutzt den gleichen Treiber auf der PC- > Seite, weil er das gleiche Protokoll spricht, aber die eingestellte > Baudrate ist schnuppe, da er zum µC hin parallel angebunden wird. • Data transfer rate to 1 Megabyte / second - D2XX Direct Drivers. • Data transfer rate to 300 kilobyte / second - VCP Drivers. beim vcp treiber wären das 2.4M Bit /sec wenn ich die software auf einem terminal aufbaue reicht das nicht der d2xx treiber ist auf usb standart? ok, generelle frage: würdet ihr bei so hohen baudraten auf einen anderen prozessor umsteigen? mit schnellerem quarz?
Patrick B. schrieb: > Jörg Wunsch schrieb: >> Dann nimm einen FT245, der benutzt den gleichen Treiber auf der PC- >> Seite, weil er das gleiche Protokoll spricht, aber die eingestellte >> Baudrate ist schnuppe, da er zum µC hin parallel angebunden wird. > > • Data transfer rate to 1 Megabyte / second - D2XX Direct Drivers. > • Data transfer rate to 300 kilobyte / second - VCP Drivers. > > beim vcp treiber wären das 2.4M Bit /sec > wenn ich die software auf einem terminal aufbaue reicht das nicht Leider sind das alles Burst-Transfer-Raten. > der d2xx treiber ist auf usb standart? Das ist eine FTDI Implementierung und erfordert deren DLL. > ok, generelle frage: würdet ihr bei so hohen baudraten auf einen anderen > prozessor umsteigen? mit schnellerem quarz? Naja, der Prozessor muss deine Daten schon anliefern können. Wenn du das FIFO Interface des FT245 nutzt, brauchst du auch keinen Baudratenquarz, der sonst bei so hohen Baudraten schon vorteilhaft wäre. Wie oben geschrieben, ich arbeite mit 921.600 Baud und da hängt ein MSP430 mit 7,3728MHz Quarz dran.
bei maximal 3.6MBit/sec wäre das 450kByte, was durchaus noch im Möglichen Bereich vom FT245 liegt. das mit dem c wird dann warscheinlich noch ne knacknuss, aber ich denke das ich das hinkriege. Um den d2xx treiber zu nutzen müsste dann die gui darauf zugreifen? Aber erstmals geht es um das board, und die pc applikation kommt später noch. da werden wahrscheinlich sicher noch fragen auftauchen. danke nochmals für die Antworten
Wie Christian es schon gesagt hat: "Leider sind das alles Burst-Transfer-Raten." Folgende Daten sind Werte aus einem reellen Projekt: Atmega324P @11.0592 MHz (da Batterie-Betrieb) mit einem FT245RL Ich erreiche nur einen Durchsatz von 80kB/s, weil: -Lesen der SD-Karte braucht seine Zeit -Berechnung des CRC braucht seine Zeit -Die Uebertragung zum FT245 braucht seine Zeit Ich beabsichte den Quarz auf 16,667 MHz zu erhöhen und die CKDIV8 Fuse zu setzen. Dann habe ich die Möglichkeit, im Batteriebetrieb mit 8,33Mhz zu takten und bei angeschlossener USB (min. 4,2V) den Takt auf 16Mhz zu erhöhen. Hoffe, dass ich dann zumindest die 100KB/s Grenze knacke.
Wo kommen denn deine Daten her? Kommen die wirklich kontinuierlich? Lassen die sich stoppen? Wenn nicht, musst du noch geschickt puffern. Wir haben bei Messungen hier festgestellt, dass Windows, selbst wenn es nichts anderes zu tun hat, bis zu 30ms Pause einfach so einlegt, bei kontinuierlicher USB Übertragung. Im Mittel erreichen wir mit dem cypress FX2 zwar knapp 40MB/s, aber eben nur im Mittel. Geht man von den 30ms aus, dann noch etwas Reserve, müsstest du 50ms puffern können, das sind bei deinen 1,44MiBits/s (180 kiByte/s) dann etwa 9kiByte, die du als Puffer-Speicher brauchst.
Christian R. schrieb:
> Wo kommen denn deine Daten her? Kommen die wirklich kontinuierlich?
Nein, nicht kontinuerlich. Die PC-Software fordert nonstop Daten in der
Grössen von ca. 40kB an. Für 5 MBytes brauch ich über eine Minute dafür.
Auf MCU-Seite habe ich einen Buffer, der 512 Bytes gross ist. Hab' mich
auch schon gefragt, ob ein grösser Buffer was nützen würde. Müsste aber
dann auf den Atmega644P wechseln.
In diesem Fall ist der FT245 genau das richtige. Die Begrenzung bei der Geschwindigkeit liegt vor allem beim µC, mit einem flotten Controller sind im Mittel >500kByte/s möglich. Puffern braucht man die Daten auf dem µC nicht wirklich, dazu hat der FT245 einen eigenen Puffer. Schaden tut es aber auch nicht, um möglichst schnell neue Daten nachliefern zu können, wenn der FT245 seinen Pufferinhalt an den PC übertragen hat.
Benedikt K. schrieb:
> Die Begrenzung bei der Geschwindigkeit liegt vor allem beim µC
Dem kann ich nur beipflichten.
Ich hab das jetzt mal nur so überflogen. Zwei Sachen: - wenn Du einen virtuellen COM-Port erstellst (wie das die FTDI ja machen), dann musst Du keine Baud-Raten einstellen. Das USB-Protokoll verwendet bei der Übertragung der Daten die schnellste Rate - und zwar automatisch. - ich glaube auch, dass Dein Protokoll auf uC-Seite der Flaschenhals sein wird. Daten generieren, aufbereiten und in den USB-Puffer schreiben braucht seine Zeit. Es wird also sehr viel vom Controller-Takt und der Qualität Deiner Firmware abhängen. Gruß Potter68
> Ralf H. schrieb >- wenn Du einen virtuellen COM-Port erstellst (wie das die FTDI ja >machen), dann musst Du keine Baud-Raten einstellen. Das USB-Protokoll >verwendet bei der Übertragung der Daten die schnellste Rate - und zwar >automatisch. Was meinst du damit? Wenn ich den MCU über den virtuellen COM-Port verbinde, und dann Daten mmittels einem Terminal sende brauche ich doch die Baudrate. Bei einem c++ Programm muss man doch auch angeben, wie die rs232 Schnittstelle läuft (Bitanzahl, Parität, Stoppbit...) Wenn das ganze interrupt gesteuert ablaufen lasse und wie schon erwähnt ein grosser puffer benutze, sollte doch bei einem 20MHz Quarz das programm nachkommen, oder? schön mit switchs programmiert um möglichst einen schnellen durchlauf zu erreichen
Patrick B. schrieb: >> Ralf H. schrieb >>- wenn Du einen virtuellen COM-Port erstellst (wie das die FTDI ja >>machen), dann musst Du keine Baud-Raten einstellen. Das USB-Protokoll >>verwendet bei der Übertragung der Daten die schnellste Rate - und zwar >>automatisch. > > Was meinst du damit? Wenn ich den MCU über den virtuellen COM-Port > verbinde, und dann Daten mmittels einem Terminal sende brauche ich doch > die Baudrate. Bei einem c++ Programm muss man doch auch angeben, wie die > rs232 Schnittstelle läuft (Bitanzahl, Parität, Stoppbit...) Das zielte wohl eher auf den FT245 ab. Den kannst du auch als virtuellen COM port auf der PC_Seite betrachten, auf der MCU Seite hast du dann ein FIFO-Interface. Da ist die Baudrate dann egal. Wenn du mit dem FT232 eine virtuelle serielle machst und auch zwischen FT232 und der MCU seriell bist, musst du die Baudrate usw. natürlich passend einstellen. > Wenn das ganze interrupt gesteuert ablaufen lasse und wie schon erwähnt > ein grosser puffer benutze, sollte doch bei einem 20MHz Quarz das > programm nachkommen, oder? schön mit switchs programmiert um möglichst > einen schnellen durchlauf zu erreichen Das weißt nur du, denn wir kennen weder das Programm nich die Quelle der Daten....mit einem 512 Byte Puffer wirst du aber sowieso keine kuntinuierliche Datenrate im MBit-Bereich hinbekommen, vermute ich. Da macht dir der Windows Scheduler einen Strich durch die Rechnung.
Christian R. schrieb: > Patrick B. schrieb: >> Wenn das ganze interrupt gesteuert ablaufen lasse und wie schon erwähnt >> ein grosser puffer benutze, sollte doch bei einem 20MHz Quarz das >> programm nachkommen, oder? schön mit switchs programmiert um möglichst >> einen schnellen durchlauf zu erreichen > > Das weißt nur du, denn wir kennen weder das Programm nich die Quelle der > Daten....mit einem 512 Byte Puffer wirst du aber sowieso keine > kuntinuierliche Datenrate im MBit-Bereich hinbekommen, vermute ich. Da > macht dir der Windows Scheduler einen Strich durch die Rechnung. Momentan habe ich die Hardware auch noch nicht, bin am Anfang der Planung. Was ist der Windows Scheduler? Von sowas habe ich noch nie gehört.
Patrick B. schrieb:
> Was ist der Windows Scheduler? Von sowas habe ich noch nie gehört.
Das ist das Stück Software, welches den einzelnen Programmen die
Rechenzeit/Hardwareressourcen zuteilt und auch wieder wegnehmen kann
damit andere Programme auch noch zum Zuge kommen.
>> Ralf H. schrieb >>- wenn Du einen virtuellen COM-Port erstellst (wie das die FTDI ja >>machen), dann musst Du keine Baud-Raten einstellen. Das USB-Protokoll >>verwendet bei der Übertragung der Daten die schnellste Rate - und zwar >>automatisch. > > Was meinst du damit? Wenn ich den MCU über den virtuellen COM-Port > verbinde, und dann Daten mmittels einem Terminal sende brauche ich doch > die Baudrate. Bei einem c++ Programm muss man doch auch angeben, wie die > rs232 Schnittstelle läuft (Bitanzahl, Parität, Stoppbit...) Kleine Korrektur: Das Terminal-Programm übergibt bei einem virt. COM-Port die Daten an den USB-Host. Der hat natürlich keine Zeit, mehrere MBytes mit einer Baudrate von 1200 (Beispiel) zu übertragen. Deshalb geht er her und schickt das Zeug schnell raus (MBit/s) und legt sich dann wieder schlafen. Genau das passiert auch beim FTDI. Allerdings ist es so, das der ja über UART an den uController angeschlossen ist, und hier wiederum wird dann die vorgegeben Baudrate verwendet, also 1200. Wenn Du jetzt aber her gehst, und die USB-Schnittstelle selbst programmierst (also Mikrocontroller mit USB und kein FTDI), dann fällt die Drossel mit den 1200 Baud weg, da dann keine UART mehr im Spiel ist. Das verwendete USB-Protokoll (CDC-Klasse) weiss dann durchaus immer noch, welche Baudrate zu Grunde liegt (das muss aus Kompatibilitätsgründen ja auch so sein [siehe FTDI]), aber sie spielt bei einer Übertragung ausschliesslich über die USB-Leitungen keine Rolle.
Hallo Patrick, > Bei so einer Geschwindigkeit würde ich mir dann ein Protokoll erstellen, > dass bei der Übertragung nicht viel schief gehen kann. und das ganze > dann 30'000 mal pro Sekunde > würde demnach 11 Bytes sein und dies würde einer Baudrate von 3,3M Bit > entsprechen. Ich denke Dein Protokoll ist der falsche Ansatz um hohe Datenraten bei USB zu erzielen. Wenn ich mich richtig erinnere wird der Slave-Endpoint maximal alle 1ms gepollt. und dann der Endpoint-Buffer mit entsprechendem Füllgrad übertragen. D.h. für maximale Übertragungsrate würde ich ein Protokoll wählen bei dem die Endpoint-Buffer-Größe (z.B. 128 Bytes) bei jedem 1ms-Transfer maximal ausgenutzt wird. Bei 11 Bytes / Übertragung kommst Du maximal auf 11000 Bytes/sec.
Mehmet Kendi schrieb: > Ich erreiche nur einen Durchsatz von 80kB/s, weil: > -Lesen der SD-Karte braucht seine Zeit > -Berechnung des CRC braucht seine Zeit > -Die Uebertragung zum FT245 braucht seine Zeit Ich habe jetzt ein paar Aenderungen vorgenommen und komme auf eine Rate von 170kB/s. - Die Frequenz wurde von 11,052 Mhz auf 16,667 MHz erhöht. - Die Daten von der SD-Karte werden direkt zum FT245 gesendet und nicht erst über den Umweg eines Buffers. - Auf die CRC-Berechnung wurde verzichtet, da a) es in der Vergangenheit nie zu einem CRC-Fehler gekommen ist b) die Daten nicht sicherheitsrelevant sind
So, erstmals danke für die Antworten noch nachträglich Jetzt hatte ich mal wieder etwas freie Zeit gefunden, mich wieder dem Problem widmen zu können. Anja schrieb: > Ich denke Dein Protokoll ist der falsche Ansatz um hohe Datenraten bei > USB zu erzielen. > Wenn ich mich richtig erinnere wird der Slave-Endpoint maximal alle 1ms > gepollt. und dann der Endpoint-Buffer mit entsprechendem Füllgrad > übertragen. > > D.h. für maximale Übertragungsrate würde ich ein Protokoll wählen bei > dem die Endpoint-Buffer-Größe (z.B. 128 Bytes) bei jedem 1ms-Transfer > maximal ausgenutzt wird. Bei 11 Bytes / Übertragung kommst Du maximal > auf 11000 Bytes/sec. Sorry, aber von diesen wenigen Zeilen verstehe ich nur ein Bruchteil, da ich leider immer noch nicht viel weiter bei dem "wie funktioniert USB beim MCU"-Problem bin. Ich werde mal Probeweise den MCU mit 2,5Mb/s füttern und sehen ob das reicht, da ich jetzt mal alles soweit gekürzt und zusammengefast habe, reicht diese Rate aus.
Patrick B. schrieb: >> D.h. für maximale Übertragungsrate würde ich ein Protokoll wählen bei >> dem die Endpoint-Buffer-Größe (z.B. 128 Bytes) bei jedem 1ms-Transfer >> maximal ausgenutzt wird. Bei 11 Bytes / Übertragung kommst Du maximal >> auf 11000 Bytes/sec. > > Sorry, aber von diesen wenigen Zeilen verstehe ich nur ein Bruchteil, da > ich leider immer noch nicht viel weiter bei dem "wie funktioniert USB > beim MCU"-Problem bin. > > Ich werde mal Probeweise den MCU mit 2,5Mb/s füttern und sehen ob das > reicht, da ich jetzt mal alles soweit gekürzt und zusammengefast habe, > reicht diese Rate aus. Ist ja auch nicht schlimm, wenn du das nicht verstehst, denn USB ist relativ(!) kompliziert. Die Specs sind aber frei verfügbar und deswegen solltest du, ehe du dich an das Programmieren begibst mal entsprechende Lektüre lesen und dich informieren wie das bei USB abgeht.
Hi ich das ehemals auf meiner USBisp Hardware (M8@8MHz + FT245) mal getestet. Maximal erreichte Datenrate mit VCP-Treibern und einer kleinen Java-Applikation dahinter die die Daten in eine Datei geschrieben hat waren 600kB/s -> 4,8MBit/s (Nutzdatenrate) Geht also. Matthias
ok, hab jetzt mal den FT232 ausprobiert: Laut Datenblatt unterstützt der ATmega644 eine maximale Baudrate von 2.5MBit bei einem 20MHz Quarz Beim Test hat das ganze aber nur bis 500kBit funktioniert. Bei 2.5MBit hat der MCU zwar Daten empfangen, aber nicht das, was ich gesendet habe... jetzt ist die Frage, wieso läufts nicht: Die UART habe ich so gesetzt:
1 | UBRR0H = 0; // Baud = 2,5Mbps |
2 | UBRR0L = 0; // |
3 | UCSR0A |= (1<<U2X0); // RS232 Settings: double speed |
4 | UCSR0B |= (1<<RXCIE0)|(1<<RXEN0)|(1<<TXEN0); // Complete Interrupt, RX und TX einschalten |
5 | UCSR0C |= (1<<UCSZ01)|(1<<UCSZ00); // Asynchron, 8-Bit |
Als Terminal habe ich Docklight und Hterm versucht, bei mit dem gleichen Resultat. Ich habe auch schon gelesen, dass zum Teil Probleme mit dem Mainboard des PC's auftreten könne, aber da weiss ich nichts weiteres. Funktioniert das ganze überhaupt mittels Terminal oder muss ich da eine Windows-Applikation schreiben? MFG P51D
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.