Hallo Forumgemeinde, nachdem ich schon seit ein paar Jahren immer wieder in dieses Forum schaue und hier schon viele nützliche Informationen gefunden habe benötige ich nun etwas Hilfe bei der Realisierung des Datenaustauschs zwischen einem PC und einem µC über USB. Ich zerbreche mir seit ein paar Wochen den Kopf, wie ich den Datenaustausch zwischen PC und dem hinter einem FT245 sitzenden ATmega8515 im Detail realisieren soll. Die Datenübertragung funktioniert grundsätzlich; einzelene Bytes kann ich bereits in beiden Richtungen übertragen. Wichtig: als Treiber auf dem PC wird der D2XX-Treiber verwendet, kein virtueller COM-Port. Zunächst wollte ich ein Protokoll impelementieren das sicher stellt, dass die Daten auf beiden Seiten immer richtig ankommen. Jetzt habe ich aber gelesen, dass das USB-Protokoll dies bereits tut, mit CRC usw., in Blöcken fester Größe, wenn ich richtig verstanden habe. Das heißt doch, dass ein Datenbyte, das auf der einen Seite abgeschickt wird, immer richtig auf der anderen Seite ankommt, solange die Verbindung zwischen PC und FT245R besteht und dass ein weiteres Protokoll zur sicheren Datenübertragung damit überflüssig ist. Habe ich das richtig verstanden? Dies ist nämlich mein erstes Projekt zum Anschluss eines Gerätes über USB an den PC und mir fehlt hier noch jede Erfahrung. Vielen Dank für Eure Hilfe, Ralf
Hallo, hast Du Dir schon mal VUSB angesehen?(http://www.obdev.at/products/vusb/index-de.html) Benötigt nur 2KB Flash und implementiert das USB Protokoll, inkl CRC. Das Projekt ist schön beschrieben und der Code ist leserlich und einfach anzupassen. Der Speed ist USB1.1, was aber für nen µC reichen sollte... Gruß Johann
Der einfachste Weg sollte doch sein, ein serielles Protokoll zu verwenden, also FT232 und nicht parallel über FT245? Johann's Variante hat natürlich auch seine Vorteile, doch denke ich USB<->seriell ist am zielführendsten. Die Daten kommen dann immer an; sofern keine äußere Störgrößen auftreten, kann man sich auch CRC oder andere Fehlerentdeckung sparen - aber das kommt natürlich auf Deine Anforderungen an.
Hallo und Danke für die schnelle Antwort. Vielleicht habe ich mich nicht klar genug ausgedrückt. Es geht mir nicht um die Implementierung des USB-Protokolls im µC, denn das erledigen schon der PC und der FT245. Die können das besser als ich :-) Ich will es mal in einer Frage (für USB-Spezialisten) ausdrücken. Kann ich davon ausgehen, dass Daten, die ich vom PC zu einem USB-Gerät schicke und umgekehrt, immer korrekt am anderen Ende ankommen? Konkret: ich schicke an einem Ende ein 'X' auf den USB und am anderen Ende kommt 'X' an oder gar nichts. Wenn das zwischen USB-Host (PC) und USB-Device (FT245R) implementierte Protokoll bereits die Datenpakete mit einer Prüfsumme versieht und im Fehlerfall keine (positive) Quittung sendet sondern das fehlerhalfte Paket nochmals anfordert, sollte das doch eigentlich so sein. Oder habe ich etwas falsch verstanden? Wie bereits geschrieben habe ich mit USB noch keinerlei Erfahrung. Es handelt sich beim USB ja nicht um eine serielle Schnittstelle (COM-Port) mit zwei oder drei Leitungen, auch wenn viele USB-Geräte über einen virtuellen COM-Port angesprochen werden können. Ich verwende aber keinen VCP sondern die D2xx-Treiber von FTDI und Funktionen wie FT_Read, FT_Write usw. Ich habe übrigens absichtlich einen FT245R und keinen FT232 verwendet weil die Verwendung des FT232 in meinem speziellen Fall m.E. keinen Vorteil bringt (die Daten mehrerer Peripheriebausteine werden parallel eingelesen, einer davon ist der FT245). Viele Grüße, Ralf
:
Bearbeitet durch User
Wir Hobbybastler verlassen uns alle darauf, dass USB entweder korrekte Daten oder eine Fehlermeldung liefert. Willst du aber eine Zulassung für medizinische Geräte, sieht es ganz anders aus.
Hallo nochmal, habe den Teil des FT245R überlesen:-) CRC wird voll unterstützt ist. Das heisst, dass Du tatsächlich "richtige" Daten bekommst und Dich nicht weiter kümmern musst... Gruß Johann
Hallo und nochmals Danke. Es ist also so, wie ich vermutet habe. Das vereinfacht mir die Sache doch wesentlich. Und keine Angst, es wird kein medizinisches Gerät :-) Viele Grüße, Ralf
Das einzige, was sein kann, ist dass Du irgendwann Probleme mit der Synchronisation bekommst, wenn auf dem Weg zwischen FT245 und AVR ein Byte verloren geht. Du bekommst ja nur einen unstrukturierten Datenstrom, den Du selber in Pakete einteilen musst. Wäre Dein Gerät beispielsweise ein HID, würdest Du immer ganze Pakete schicken, und der AVR würde auch die Pakete als solche empfangen. Hier ist durch das USB eine Struktur vorgegeben, eine Fehlsynchronisation kann daher nicht vorkommen. Mit den FTDI-Chips ist so etwas aber nicht machbar. Das hier erwähnte VUSB ist übrigens Bastelkrempel. Ja, es funktioniert irgendwie, aber die USB 2.0 Konformitätstest bestehst Du damit nicht. fchk
Hallo! Über USB erscheinen die Daten gespiegelt auf der anderen Seite. Das ist keine Schnittstelle im alten Sinn, sondern ein Bus. Wenn neue Daten "ankommen" kann der Empfänger dies nicht erkennen wie bei der RS232. Die Software muß selber dafür sorgen, z.B. mit ein entsprechendes sich änderndes Byte. Übertragungsfehler korregiert USB selber. Ausnahme sind die obersten Baudarten, da ist es nicht vorgesehen. Gruß Peter
Hallo zusammen, Die Strukturierung der Daten ist eine andere Geschichte aber wieso kann der FT245 nicht erkennen, wenn neue Daten ankommen? Laut Datenblatt des FT245 wird RXF# low wenn Daten im Puffer ankommen. In diesem Moment wird eine Interruptanforderung bei meinem AVR ausgelöst (RXF# hängt an INT0), das Datenbyte wird gelesen und in einen Puffer geschrieben. RXF# wird dann high. Mit dem nächsten eintreffenden Byte wird RXF# wieder low. Sind alle Daten im Puffer und verarbeitet, schicke ich eine Quittung raus. Solange die Interrupts schnell genug beantwortet werden und die Pakete klein genug sind sollte doch alles gut sein, oder? Zur Sicherheit könnte ich meine Pakete ja auch mit einer Prüfsumme (CRC) versehen. Wenn dann etwas fehlt sollte es bemerkt werden. Der ATmega8515 läuft übrigens mit 16 MHz. Was meinst Du übrigens mit gespiegelt? Der FT245 ist doch ein FIFO, d.h. first in - first out. Der AVR wird die meiste Zeit sowieso mit Warten zubringen, da sehe ich momentan das Problem nicht. Viele Grüße, Ralf
Hallo, wenn der FT245 ein "angekommen"-Signal liefert, wird das in diesen Generiert. Im USB-Protkoll ist das nicht enthalten. Den FT245 kenn ich nicht. Mit gespiegelt meine ich: die Daten sind auf beiden Seiten identisch. In einer meiner USB-Anwednungen habe ich einen Zähler mit übertragen müssen, um neue Daten zu erkennen. Gruß Peter
> Die Strukturierung der Daten ist eine andere Geschichte
Aber eigentlich die wichtigere. Denn alleine ob ein Byte korrekt
gesendet wird, bringt dir erstmal nichts, und ist, durch die verwendeten
Protokolle auf unterster Ebene bereits sichergestellt. Viel
wahrscheinlicher ist jedoch ein Fehlerhaftes Paket, ein Paket zur
falschen Zeit usw usw.
In dem du deine Pakete gegen Fehler absicherst, sicherst du im Endeffekt
auch einzelne Bytes ab.
gruß cyblord
Hallo und guten Abend, natürlich ist die Strukturierung der Daten wichtig. Was ich sagen wollte ist, dass ich keine Maßnahmen ergreifen muss, wie sie z.B. beim BSC-Protokoll erfolgen mit PAD- und SYN-Bytes, Nachsynchronisierung usw. Wenn ich die Pakete nummeriere, die Paketgröße und noch eine Prüfsumme (CRC) mitsende, müssten fehlerhafte und fehlende Pakete eigentlich zuverlässig erkannt werden. Doppelte Pakete dürften normalerweise ja nicht vorkommen, oder? Der FT245 ist ein "USB to parallel FIFO"-Baustein ähnlich dem FT232, mit 8 Datenleitungen Richtung µC und ohne die Steuerleitungen der seriellen Schnittstelle. Die Geschwindigkeit ist maximal ca. 1 MB/s. Einen schönen Abend wünscht Ralf
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.