mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Datenaustausch PC und µC über USB


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Ralf G. (dl5eu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf G. (dl5eu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Noch einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf G. (dl5eu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Hofbauer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf G. (dl5eu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Hofbauer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Ralf G. (dl5eu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.