Forum: Mikrocontroller und Digitale Elektronik USB Signal über 2 µCs seriell Übertragen


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.
von Dominik L. (kimonid)


Bewertung
1 lesenswert
nicht lesenswert
Hallo erstmal

Ich habe schon oft Beiträge hier gelesen die bei diversen Aufgaben sehr 
geholfen habe, doch nun stehe ich vor einem größeren Problem wofür ich 
noch keine Lösung gefunden habe.
Im Zuge meiner Ausbildung zum Dipl. Ing. muss ich in Zusammenarbeit mit 
einer internationalen Firma eine USB Übertragung via LWL realisieren.
Ich arbeite mit 2 Freunden gemeinsam an diesem Projekt und Ich bin für 
die Software zuständig.

Das Ganze sollte "wie ein Adapterkabel" funktionieren,  also ohne dass 
die angeschlossenen Geräte etwas von den µC mitbekommen.
Die USB-Daten werden über eine serielle Schnittstelle des µC via LWL auf 
den 2. µC übertragen und dort wieder an der USB Schnittstelle 
ausgegeben.
Die Geschwindigkeit muss USB 2.0 High Speed (480 MBit/s) sein.
Dazu noch Fehlermeldung in Form von LED's (LWL Verbindung Ok, USB 
Verbindung Ok, etc..).
Dafür verwenden wir den AT32UC3A3256 von Atmel, dieser hat bereits ein 
USB interface für Device und Host. Er kann wahrscheinlich viel mehr als 
wir brauchen, aber unsere Lösung muss nicht perfekt sein, es muss nur 
funktionieren.

Ich habe mich schon mit den USB Spezifikationen beschäftigt, kenne mich 
auch ein wenig mit dem USB Protocol aus (welche daten so gesendet 
werden).
Ich habe auch grundsätzlich eine Idee wie alles funktionieren könnte.

Das Problem liegt eher in der Praxis als in der Theorie. Ich kann mir 
alles genau überlegen, doch ich habe soetwas noch nie programmiert.
In der Schule haben wir Arduinos mit fertigem USB Bootloader auf denen 
wir programmieren. Die einzige Übung mit serieller Datenübertragung 
bisher war Zeichen zu senden und auf LED Balken die ASCII Werte 
anzuzeigen.
Zum Programmieren verwende Ich Atmel Studio 7.0, ich habe mir schon 
einige examples durchgelesen und versucht zu verstehen, doch irgendwie 
is mir das zu viel...

Meine Frage an euch ist also:

Gibt es Anwendungen hier die genau das oder etwas Ähnliches können? Hat 
jemand schonmal so etwas gemacht?
Oder könnt ihr mir Bibliotheken empfehlen die ich verwenden sollte, oder 
examples von Atmel die mir weiterhelfen?
Ich arbeite nun seit 2 Wochen intensiev daran und habe noch keine 
konkreten Ergebnisse, drum frage ich mich ob ich das einfach nicht kann 
oder ob so ein Projekt wirklich so viel Zeit braucht um alles zu 
verstehen.
Zu den Fehler-LED's: Wenn der Rest fertig ist schaff ich die 
wahrscheinlich leicht noch hinzu zu fügen.

Vielleicht mache ich mir das alles selbst zu schwer und es gibt eine 
einfache Lösung, doch ich finde sie einfach nicht. Wie gesagt, ich bin 
neu beim Thema USB und serieller Kommunikation, also habe ich keinen 
Plan womit ich anfangen soll...deshalb wende ich mich ja an euch.

Ich hoffe ich habe die wichtigsten Details geschrieben.
Ich werde in den nächsten Wochen täglich mehrmals online sein um auf 
Antworten zu reagieren, sollte das Thema länger dauern bin ich nach den 
2 Wochen auch täglich abends da.

Danke im Voraus und fürs Lesen ^^
MfG Dominik

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
> [USB transparent über LWL]

Dir ist aber schon klar daß auch dabei die Gesamtlänge immer noch nicht 
mehr als 5m (Laufzeit!) betragen darf?

Was willst Du am anderen Ende betreiben? Vielleicht gibts ja ne andere 
Lösung als die gesamte Strecke mit USB zu fahren?

: Bearbeitet durch User
von Stephan (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
da wirst Du wohl um einen LWL - Ethernetumsetzer wohl kaum drum rum 
kommen.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Das dürfte ein verdammt schwer umzusetzender Ansatz sein. Dein µC muss 
sich auf der Deviceseite simultan wie alle auf seiner Hostseite 
angeschlossenen USB-Geräte verhalten.

Ich glaube kaum, daß das möglich ist, der µC hat nur eine endliche 
Anzahl von Endpoints etc.

Obendrein: Welche serielle Schnittstelle dieses µC soll bitte mit einer 
Datenrate von einem halben GBit/sec arbeiten können?

Das passt nicht.


Dein Projekt - Optoisolator einer USB2.0 High-Speed-Verbindung - dürfte 
sinnvoll nur mit FPGAs umsetzbar sein, und da solltest Du Dir ansehen, 
wie ein USB-Hub aufgebaut ist.

Zur Isolation musst Du die Datenpakete je nach Richtung voneinander 
isolieren, und genau diese Isolation findet in einem USB-Hub statt. Wenn 
Du also nach "ip core usb2.0 hub" suchst, könntest Du was finden.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ich bin ein bisschen erstaunt, dass du dich einerseits mit USB auskennst 
aber dann an der simplen UART Schnittstelle scheiterst.

Die Sache ist die: Wenn ein USB Gerät an den PC angesteckt wird, muss es 
sich mit einer Geräte-ID Melden. Dementsprechend lädt das Betriebssystem 
den zugehörigen Treiber.

Da dein Kabel wie ein transparentes Verlängerungskabel wirken soll, muss 
es also zuerst die Geräte ID des Gerätes am anderen Ende ermitteln und 
diese dann dem Betriebssystem vorgaukeln.

Dazu wiederum brauchst du ein USB Host Interface. Laut Beschreibung kann 
der Chip aber nur "Device" und "OTG" Modi, das ist soweit ich vermute 
kein Host.

Nimm es mir bitte nicht übel, aber ich denke: wenn du schon an der 
Programmierung der UART Schnittstelle scheiterst, dann liegt USB für 
Dich in unerreichbarer Ferne. USB ist um Welten komplexer, und die 
Dokumentation ist nicht frei verfügbar.

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Was willst Du am anderen Ende betreiben? Vielleicht gibts ja ne andere
> Lösung als die gesamte Strecke mit USB zu fahren?

Um der LWL Verbindung kommen wir nicht rum, da es um die Elektro 
Magnetische Ausstrahlung geht. Anschließen sollte man alles können, USB 
Stick, Computer, Smartphone, SPS, Industrie-Roboter, Messgeräte, etc.

Welche Übertragungslänge wir brauchen weiß ich momentan garnicht, aber 
ich werde mich noch erkundigen. Sind die 5m das absolute Maximum oder 
ginge anders auch mehr? wenn ja, wie?

: Bearbeitet durch User
von Flo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wäre ja vom Aufbau her so:

USB Host  -> USB_Device ---LWL--- USB_Host   -> USB Device

Man könnte das LWL Kabel plus Wandler als USB Hub implementieren.
Schau mal in die Richtung USB Repeater.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> Um der LWL Verbindung kommen wir nicht rum, da es um die Elektro
> Magnetische Ausstrahlung geht.

Die USB Schnittstelle arbeitet symmetrisch. Die USB Kabel sind im 
Idealfall nach außen hin elektromagnetisch neutral und sie reagieren 
auch nicht auf Störfelder.

Für gute Kabel muss man natürlich schon ein bisschen mehr Geld als im 
Euro-Shop ausgeben. Aber es ist durchaus machbar und Praktikabel.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Laut Beschreibung kann der Chip aber nur "Device" und "OTG" Modi, das
> ist soweit ich vermute kein Host.

Das ist Host. O-Ton Datenblatt "High-Speed USB 2.0 (480Mbit/s) Device 
and Embedded Host"

Allerdings ist nicht sichergestellt, daß dieser Host wiederum mit zig 
Geräten gleichzeitig kommunizieren kann (was er müsste, wenn z.B. ein 
USB-Hub mit diversen Geräten daran angeschlossen wird und diese 
transparent durchgereicht werden sollen).

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Vielleicht hilft es, ein fertiges Produkt auszuprobieren und davon 
abzugucken:
https://www.blackbox.com/en-us/Store/Detail.aspx/USB-Ultimate-Extender-over-Multimode-Fiber-4-Port/IC404A

Da kannst du zumindest schonmal ein par IC's identifizieren, die dazu 
geeignet sind.

von Stephan (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Das dürfte ein verdammt schwer umzusetzender Ansatz sein. Dein µC
> muss
> sich auf der Deviceseite simultan wie alle auf seiner Hostseite
> angeschlossenen USB-Geräte verhalten.
>
> Ich glaube kaum, daß das möglich ist, der µC hat nur eine endliche
> Anzahl von Endpoints etc.
>

Wenn nur ein Gerät (am 'Backend') angeschlossen ist, kann der Backend-uC 
ja den Descriptor an den 'Frontend' auf der Host-Seite des LWL 
weiterleiten. Der muss dann nur in der Lage sein, ein Neueinstecken des 
USB-Ports zu simulieren (wie die Cypress FX2, das können nicht alle 
Käfer).
Aber das on-the-fly zu machen und noch robust zu halten bedeutet einen 
gehörigen Protokollaufwand, mal ganz abgesehen von der Entwicklung des 
Handling für alle möglichen USB-Transfers.
Aber: Wenn das Projekt runterskaliert wird auf genau ein HID-Device oder 
USB2serial könnte der TO so schon ein Proof of Concept hinlegen, was 
grade noch auf nem AVR läuft.

> Obendrein: Welche serielle Schnittstelle dieses µC soll bitte mit einer
> Datenrate von einem halben GBit/sec arbeiten können?
>
> Das passt nicht.
>
> Dein Projekt - Optoisolator einer USB2.0 High-Speed-Verbindung - dürfte
> sinnvoll nur mit FPGAs umsetzbar sein, und da solltest Du Dir ansehen,
> wie ein USB-Hub aufgebaut ist.
>

Ich würde da auch diesen pragmatischen Weg gehen. Das geht aber auch 
komplett ohne FPGA mit einer rein physikalischen Umsetzung. Da braucht 
man aber für die analoge Seite wieder deutlich was an Erfahrung.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Die Ein- oder Auskopplung in eine Glasfaser ist bei der Problemstellung 
hier nachrangig und kaum wichtiger wie die Entscheidung über die Farbe 
des Lötstoplacks.

Das demgegenüber riesige Problem ist das Zerlegen des USB-Datenstroms in 
Sende- und Empfangsdaten mit minimaler Verzögerung.

Der Rest ist demgegenüber nahezu trivial.

von Erwin D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Wenn nur ein Gerät (am 'Backend') angeschlossen ist, kann der Backend-uC
> ja den Descriptor an den 'Frontend' auf der Host-Seite des LWL
> weiterleiten.

Sooo einfach ist es nun auch wieder nicht. Der TO hat geringfügig höhere 
Ansprüche:

Dominik L. schrieb:
> Anschließen sollte man alles können, USB
> Stick, Computer, Smartphone, SPS, Industrie-Roboter, Messgeräte, etc.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Das demgegenüber riesige Problem ist das Zerlegen des USB-Datenstroms in
> Sende- und Empfangsdaten mit minimaler Verzögerung.

Da muss nix zerlegt werden..die Daten werden 1:1 getunnelt. Wird so des 
öfteren in Geräten gemacht, wo galvanische Trennung für USB rein muss.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Erwin D. schrieb:
> Martin S. schrieb:
>> Wenn nur ein Gerät (am 'Backend') angeschlossen ist, kann der Backend-uC
>> ja den Descriptor an den 'Frontend' auf der Host-Seite des LWL
>> weiterleiten.
>
> Sooo einfach ist es nun auch wieder nicht. Der TO hat geringfügig höhere
> Ansprüche:
>
> Dominik L. schrieb:
>> Anschließen sollte man alles können, USB
>> Stick, Computer, Smartphone, SPS, Industrie-Roboter, Messgeräte, etc.

Aber nicht alle gleichzeitig. Denk doch nochmal drüber nach.

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Irgendwie ist mir die Idee dahinter völlig unklar. Es gäbe doch 
mindestens folgende Interprätation:

1) vollständig transparente "Kabelverlängerung" bzw. "Kabelersatz".
Das wäre hinsichtlich der angeschlossenen Gerät*E*(!) quasi unsichtbar.
Das ist aber mit den zwei Controllern dazwischen schwierig bis 
unmöglich:
Die max. round trip time bei USB 2.0 ist 1.5 us. Die Controller müssten 
das Handshaking in Software erledigen und durchreichen. Die USB-Host 
bzw. -Device-Blöcke sind dazu NICHT brauchbar.

2) Der eine Controller (auf "Empfänger"-Seite) spielt den USB-Host für 
alle dort angeschlossenen Gerät*E*(!). Soweit so gut. Aber auf der 
anderen Seite müsste der andere ja EIN USB-Device gegenüber seinem 
Host emulieren?!
Wie soll der transparent mehrere Geräte gegenüber seinem Host 
simulieren???
Natürlich könnte man so etwa Endpoints 1-4 dem ersten, 5-8 dem zweiten 
Gerät zuordnen usw. Aber gegenüber dem ursprünglichen Host gegenüber 
würden immer alle Geräte zu einem "gebündelt".

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Die USB Kabel sind im Idealfall nach außen hin elektromagnetisch
> neutral und sie reagieren auch nicht auf Störfelder.
Der USB ist bei meinen Steuerungen regelmäßig der Bus, der bei EMV 
Einkopplung als erster austickt. Und der Spezi vom Prüflabor sagt dann 
nur: wundert mich nicht, das ist bei allen so!

Martin S. schrieb:
> Da muss nix zerlegt werden..die Daten werden 1:1 getunnelt.
Dann darf "in der Mitte" aber kein USB-Device sitzen, sondern das Signal 
muss auf unterster Ebene Bit für Bit getunnelt werden.

Ich könnte mir vorstellen, dass man das "Zwischenkabel" als USB-Hub 
anmelden und die Daten so irgendwie tunneln könnte. So ähnlich, wie die 
blackbox-Teile das auch machen.

> wo galvanische Trennung für USB rein muss.
Ich kenne da nur solche Isolatoren wie den LTM2894. Da wird gar nichts 
getunnelt, das Signal wird auf physikalischer Ebene rein elektrisch 
entkoppelt...

Beitrag #5121162 wurde von einem Moderator gelöscht.
von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Abseits vom eigentlichen Thema kurz, ich finde es bemerkenswert wie 
schnell hier Antworten kommen, da einige Beiträge sogar von 2008 sind 
hatte ich echt nicht erwartet hier überhaupt noch jemanden zu sehen, 
respekt dafür.

Flo schrieb:
> USB Host  -> USB_Device ---LWL--- USB_Host   -> USB Device

Genau so sollte es aussehen.

Es wird immer nur ein Device angeschlossen, also jeder µC verwendet nur 
eine USB Schnittstelle.
Eine Lösung wäre:
Der µC-Host nimmt alle wichtigen Daten vom Device und sendet sie an den 
anderen. Dieser stellt dann die USB Verbindung zum Host her und 
antwortet mit den Daten die er bekommen hat. Somit sieht der Host nur 
die Daten vom Device. Danach werden alle Daten einfach hin und her 
gesendet und ausgegeben.
Einerseits ist die Frage ob das so möchlich ist.
Andererseits habe ich keine Ahnung wie man sowas dann programmiert?

Lothar M. schrieb:
> Dann darf "in der Mitte" aber kein USB-Device sitzen, sondern das Signal
> muss auf unterster Ebene Bit für Bit getunnelt werden.

Gibt es eine Möglichkeit den µC genau das machen zu lassen?

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Da muss nix zerlegt werden..die Daten werden 1:1 getunnelt. Wird so des
> öfteren in Geräten gemacht, wo galvanische Trennung für USB rein muss.

Äh, nein. Oder zeigst Du mir einen bidirektionalen Optokoppler?

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Vielleicht hilft es, ein fertiges Produkt auszuprobieren und davon
> abzugucken:
> 
https://www.blackbox.com/en-us/Store/Detail.aspx/USB-Ultimate-Extender-over-Multimode-Fiber-4-Port/IC404A


Grundsätzlich keine schlechte Idee, leider haben wir nicht das Budget um 
ein fertiges Teil zu kaufen.
Der Sinn der Sache ist quasi ein teures Gerät aus relativ billigen 
Einzelkomponenten zu bauen. Immerhin könnte man sonst das Teil ja 
einfach kaufen und fertig.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Der Sinn der Sache ist quasi ein teures Gerät aus relativ billigen
> Einzelkomponenten zu bauen.

Wenn es so einfach wäre, gäbe es mehr bezahlbare 
USB2.0-HighSpeed-Isolatoren.

Um so etwas zu konstruieren, muss man die gleichen Probleme lösen wie 
bei Deinem Vorhaben. Ob der Optokoppler nun ein kleiner achtbeiniger 
Krümel im Geräteinneren oder eine Glasfaserstrecke mit Sender/Empfänger 
an den jeweiligen Enden ist, ist da nur ein nachrangiger Unterschied.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Lothar M. schrieb:
>> Dann darf "in der Mitte" aber kein USB-Device sitzen, sondern das Signal
>> muss auf unterster Ebene Bit für Bit getunnelt werden.
> Gibt es eine Möglichkeit den µC genau das machen zu lassen?
Nein. Du bekommst dort "nur" (oder eher "zum Glück") bereits 
aufbereitete Datenpakete.

> Somit sieht der Host nur die Daten vom Device.
Aber das Device hat sich bis dahin ja schon irgendwie enumeriert. Und 
zwar eben nicht als Sony-Handy oder IPhone oder USB-Stick oder 
RS232-Koppler...

Dominik L. schrieb:
> Der Sinn der Sache ist quasi ein teures Gerät aus relativ billigen
> Einzelkomponenten zu bauen.
Geht halt nicht immmer. Z.B. bei einem Atomkraftwerk oder einer Rakete.

> Immerhin könnte man sonst das Teil ja einfach kaufen und fertig.
Das wäre mein erster Schritt: das Ding kaufen und mal reinschauen, wie 
die das gelöst haben. Und dann entscheiden, ob ich das mit vertretbarem 
Aufwand auch hinbekommen könnte...

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
>> Somit sieht der Host nur die Daten vom Device.
> Aber das Device hat sich bis dahin ja schon irgendwie enumeriert. Und
> zwar eben nicht als Sony-Handy oder IPhone oder USB-Stick oder
> RS232-Koppler...

Also das Device meldet sich beim einem µC an, der sendet die Daten an 
den zweiten, der meldet sich dann (mit den Daten vom Device) beim Host 
an, danach steht die verbindung eigentlich. Alles was der Host sendet 
wird einfach ans Device geleitet und die Antwort davon zurück an den 
Host.

Mein Problem ist aber nach wie vor, dass ich mit dem programmieren nicht 
zurecht komme...
Den genauen Ablauf bekomm ich schon irgendwie hin, falls nicht frage ich 
einfach nochmal ^^
Gibt es also irgendwo gut beschriebene Beispielprogramme zum Thema USB 
und Serielle Schnittstelle aus denen ich das Programm das ich brauche 
zusammen bauen kann? oder gibt es "Lernhilfen" damit ich das Programm 
selbst schreiben kann?
Ich möchte nur verstehen wie ich den µC konfigurieren muss, dass das 
Zeug funktioniert.
Was muss man im µC programmieren, damit er die USB Signale ordentlich 
verarbeitet.
1
SignalUSB = SignalSerial
Wird ja nicht einfach so funktionieren.

Oder gibt es irgendwo gute "Kurse" um sich das Wissen zur 
USB-Datenverarbeitung mittels µC anzueignen?
Grundkenntnisse in C habe ich, I/O Pins ansteuern, Interrupts 
verarbeiten, Schleifen und ähnliches zu verwenden ist kein Problem.
USB und Serielle Datenverarbeitung, grundsätzlich Kommunikation zwischen 
Geräten ist ein ganz neues Thema für mich...

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn tatsächlich immer nur EIN Gerät angeschlossen und nicht auf 
Bit-Ebene getunnelt werden soll, ist das theoretisch recht einfach:

Der Controller, den den Host spielt, fragt beim neu angesteckten Device 
nach Vendor, Product, Endpoints usw., und schickt diese Infos an den, 
der das Device spielen soll. Der veranlasst eine Re-enumeration bei 
seinem Host und spult dann die Infos ab.

Danach müssen nur noch die Pakete, die bei den einzelnen Endpoints 
ankommen, 1:1 weiter gegeben werden. Wie das zwischen den beiden 
Controllern übermittelt wird, ist dabei ziemlich egal, man braucht nur 
einen transparenten bidirektionalen Kommunikationskanal.
"Endpoint" in USB-Notation heißt ja nichts anderes als "Pipe" in 
Unix-Notation.

Die Tücke steckt da im Detail. Manche Geräte können die Betriebsart 
(oder Zahl der Endpoints etc.) einfach so mal wechseln (GSM-Modems, 
Kartenleser), und das muss natürlich ebenfalls weiter gereicht werden. 
Falls das für "beliebige" Auswahl von Geräten funktionieren soll, 
wünsche ich viel Spass beim Testen ...

Allerdings sollte man sich auch sonst keinen Illusionen hingeben: Von 
der Brutto-Datenrate 480 MBps wird da nicht viel übrig bleiben. Und die 
Latenz wird auch beträchtlich zunehmen, denn jedes Paket muss erst 
komplett eingetrudelt und verdaut sein, bevor sein Aussenden gestartet 
werden kann.

Außerdem: Wenn ein Paket korrekt empfangen wurde (und automatisch 
bestätigt wurde), es aber beim weiter Leiten von der nächsten Station 
nicht bestätigt wird, hat man ein Problem.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> Alles was der Host sendet
> wird einfach ans Device geleitet und die Antwort
> davon zurück an den Host.

Klingt palusibel und einfach, wenn da nicht dieses Problem wäre:

> Das demgegenüber riesige Problem ist das Zerlegen des USB-Datenstroms
> in Sende- und Empfangsdaten mit minimaler Verzögerung.

Du kannst ja mal versuchen, diese Frage zu klären und dann darauf 
aufbauend ein Proof of Concept probieren. Eventuell ist das sogar ganz 
ohne Mikrocontroller machbar.

> Grundsätzlich keine schlechte Idee, leider haben wir nicht das
> Budget um ein fertiges Teil zu kaufen.

Aber ihr habt das Budget, ein ähnliches Produkt von Null auf neu zu 
entwickeln? Dann überlege doch mal, warum man diese Geräte nicht längst 
im Euro-Shop Made in China kaufen kann. Bedarf ist sicher genug 
vorhanden.

: Bearbeitet durch User
von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
A. B. schrieb:
> Der Controller, den den Host spielt, fragt beim neu angesteckten Device
> nach Vendor, Product, Endpoints usw., und schickt diese Infos an den,
> der das Device spielen soll. Der veranlasst eine Re-enumeration bei
> seinem Host und spult dann die Infos ab.


Genau so sollte es funktionieren.

Wie viel von der Datenrate real übrig bleibt ist ja nicht wirklich 
beeinflussbar, aber theoretisch sollte das Ganze für USB High Speed 
verwendbar sein. Selbst wenn nur 1/10 übrig bleibt (48 Mbit/s) ist das 
trotzdem noch 4 Mal so schnell wie USB Full Speed (12 Mbit/s) und ich 
denke recht viel langsamer wird es wohl nicht werden, oder?

Die Frage ist nun, gibt es schon Ähnliche frei zugängliche 
Programm-Codes die ich als Vorlage oder Hilfe nehmen kann? Gibt es 
Anleitungen für die einzelnen Teile die ich nur zusammen fügen muss? 
Oder gibt es ein paar andere Threads aus denen ich alles was ich 
vielleicht brauche lernen kann?
Wie gesagt, es ist gut zu wissen DASS es funktionieren kann, es fehlt 
mir dennoch das Wissen WIE ich es so hinbekomme.

Einige examples von Atmel habe ich bereits durchgelesen und versucht zu 
verstehen, doch ich habe keine Ahnung wie die funktionieren. Vielleicht 
gibt es dafür irgendwelche Erklärungen oder Ähnliches.

: Bearbeitet durch User
von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Martin S. schrieb:
>> Da muss nix zerlegt werden..die Daten werden 1:1 getunnelt. Wird so des
>> öfteren in Geräten gemacht, wo galvanische Trennung für USB rein muss.
>
> Äh, nein. Oder zeigst Du mir einen bidirektionalen Optokoppler?

Nein. So wird's auch nicht gemacht :-) Hin und Rückkanal sind separat, 
optisch ist das ne Vollduplex-Geschichte. Gibt dafür auch fertige ASICs, 
über die gleichzeitig mal noch eben i2c und DVI getunnelt wird. Nur 
kommt unsereiner an die Käfer nicht ran, man muss sich's also rel. 
diskret aufbauen und die entsprechenden Lasermoden fürs Handshaking 
nutzen. Aber DAS ist dann nicht trivial.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Aber ihr habt das Budget, ein ähnliches Produkt von Null auf neu zu
> entwickeln? Dann überlege doch mal, warum man diese Geräte nicht längst
> im Euro-Shop Made in China kaufen kann. Bedarf ist sicher genug
> vorhanden.

Es gibt die fertige Lösung vom Koreaner umme Ecke, die deutlich billiger 
als eine Neuentwicklung ist...

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Es gibt die fertige Lösung vom Koreaner umme Ecke, die deutlich billiger
> als eine Neuentwicklung ist...

Angenommen wir hätten ein fertiges Gerät von dem wir abschauen können, 
kann man das Programm auf dem Controller überhaupt noch ändern? Sind die 
nicht irgendwie verschlüsselt um genau diesen Software-Diebstahl zu 
verhindern?
Immerhin muss ich ja trotzdem das Programm für unseren Zweck ein wenig 
abändern, wegen den LED's usw. und ein fertiges Gerät zu kaufen ist wie 
gesagt nicht der Sinn des Projekts.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> optisch ist das ne Vollduplex-Geschichte.

Ja schon, aber die USB Schnittstelle überträgt Daten bidirektional. Das 
Signal vom USB Bus muss in die beiden Richtungen aufgesplittet werden, 
sonst kommt es zu einer Rückkoppelung.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> Es gibt die fertige Lösung vom Koreaner umme Ecke

Wo denn? Zeige mal einen Link auf das Produkt, dann kann der Dominik ja 
dvon abgucken.

> kann man das Programm auf dem Controller überhaupt noch ändern?
> Sind die nicht irgendwie verschlüsselt

Du sollst ja nicht das Programm kopieren, sondern von der Hardware 
abgucken.

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Anschließen sollte man alles können, USB
> Stick, Computer, Smartphone, SPS, Industrie-Roboter, Messgeräte, etc.

Das ALLES geht was es unter USB gibt schaffen nicht mal die führenden 
Spezialisten, z.B. bei Wiesemann & Theis. Dass ein Anfänger in der 
Ausbildung denen zeigt wie's geht glaube ich eher weniger, aber ab und 
zu werden ja doch Genies geboren, also viel Glück.

Als fertige Lösungen gibt es USB-Deviceserver mit USB über Ethernet, da 
kann man natürlich mit Standardkomponenten auch LWL installieren. Eine 
Durchsatzrate von 0,5 Gbit/s halte ich trotzdem für illusorisch. Noch 
viel illusorischer, wenn das denn geht, ist es bei serieller 
Übertragung, mit allem Overhead bräuchte man da ja ein USART mit einer 
Taktrate von 2 GHz oder mehr.

Am besten gehst du mit der gleichen Zuversicht an die Sache wie 1899 
Hoffenheim...

Georg

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Aber das Programm müsste ich trotzdem noch selbst schreiben, oder?

Übrigens, denkt ihr reicht es example Programme im Simulator 
durchzugehen um zu verstehen wie es funktioniert? Und in weiterer folge 
Teile davon in ein anderes Programm einzubauen?


Und nochmal abschließend:
Das Konzept
Host - µC - LWL µC - Device
würde funktionieren, oder gibt es noch irgendwelche Bedenken? Oder 
sonstiges was ich beachten sollte?

Auch nochmal zum Mikrocontroller, würde der AT32UC3A3256 mit der 
Anwendung zurecht kommen, angenommen das Programm und die restliche 
Hardware passen?
Das muss heute feststehen, damit wir morgen Bestellen können.

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Georg schrieb:
> Das ALLES geht was es unter USB gibt schaffen nicht mal die führenden
> Spezialisten

Ok dann werden wir uns auf ein paar Anwendungen spezialisieren müssen, 
was ein PC halt auch so kann, USB Sticks, Sensoren, Kameras, HID, 
natürlich auch PCs. Nichts exotisches, nur Dinge die häufig verwendet 
werden.

Georg schrieb:
> Noch
> viel illusorischer, wenn das denn geht, ist es bei serieller
> Übertragung, mit allem Overhead bräuchte man da ja ein USART mit einer
> Taktrate von 2 GHz oder mehr.

Gibt es eine andere Übertragungsart die man über LWL übertragen kann?
Solange der µC das kann und die LWL Übertragung damit funktioniert bin 
ich für alles offen, USART war halt das einzige mit dem ich mal minimal 
gearbeitet hatte...

Das wäre der LWL Transceiver:
http://at.rs-online.com/web/p/faseroptik-transceiver/7140225/

: Bearbeitet durch User
von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Noch eine Info

Sollte es tatsächlich nicht möglich sein das alles zu realisieren, 
können wir immer noch die Anforderungen minimieren.
Ich möchte einfach nichts unversucht lassen, kann ja nicht sein, dass 
das so nicht geht ^^

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Anschließen sollte man alles können, USB Stick, Computer,
> Smartphone, SPS, Industrie-Roboter, Messgeräte, etc.

Wenn "alles" auch einen USB-Hub mit 12 USB-Sticks einschließt, wird das 
ein Problem. Du kannst einmal die Bits tunneln, dann hast du tatsächlich 
eine volltransparente Verbindung, mit der alles geht. Ohne FPGA kannst 
du das aber vergessen, und weite Strecken ebenfalls, weil die 
Reaktionszeiten sehr kurz sind.

Du kannst auch die Pakete tunneln, die durch die Endpoints laufen, aber 
dann muss dein Controller diese Pakete auch verstehen, was Zeit kostet 
und dich auf wenige Geräte(klassen) beschränkt. Du kannst 
Übertragungsfehler auch verbieten, dann wird das einfacher.

Damit bist du trotzdem auf ein einzelnes Gerät beschränkt, welches nicht 
mehr Endpoints benutzen darf, als dein Controller verarbeiten kann, und 
das Zeitverhalten deines Geräts ändert sich deutlich. Manche Geräte 
werden also garnicht oder nur instabil funktionieren, weil alle Pakete 
verzögert werden. Isochrone Endpoints (für Echtzeit, wie Audio, Video) 
wirst du vermutlich nicht hinbekommen (zumindest nicht in der verlangten 
Garantie). Zu Interrupt-Transfers kann ich nichts sagen.

Alles in allem wird das ein übler Hack, der aber mindestens für 
USB-Sticks und ein bisschen Kleinkram funktionieren wird, wenn du es 
richtig machst. Fange erstmal damit an, aus dem Nichts ein USB-CDC zu 
entwickeln, um ein Gefühl zu bekommen, wie die USB-Hardware auf deinem 
Controller funktioniert. Dann entwickelst du aus dem Nichts einen 
USB-Host, der mit einem USB-CDC (oder -M kommunizieren kann (= das 
gleiche für die andere Seite). Statt CDC kannst du auch MSC machen 
(wichtig sind Control und Bulk transfers).

Viel Glück. Und erwarte keine High-Speed-Performance.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Aber das Programm müsste ich trotzdem noch selbst schreiben, oder?

Hätte ich diese Frage vorher gesehen, hätte ich mir die letzte Antwort 
gespart. Wenn du schon so naiv fragst, fehlen dir vermutlich massive 
Grundlagen. USB ist deutlich komplexer als "LED blinken" und "serielle 
Schnittstelle".

Aber ja, du musst DAS GESAMTE USB-PROTOKOLL (außer Hubs) verstehen und 
implementieren können.

: Bearbeitet durch User
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Nein. So wird's auch nicht gemacht :-) Hin und Rückkanal sind separat,

Siehst Du, und genau das ist der Knackpunkt. USB hat keinen separaten 
Hin- und Rückkanal, die muss man erst mal herstellen. Bei USB1.1 mit 12 
MBit ist das noch langsam genug, daß man durch intelligentes Mithören 
die Richtung 'rausfinden kann, aber bei USB2.0 mit 480 MBit/sec ist das 
nicht mehr so einfach möglich.

Wie man es umsetzen könnte, habe ich bereits beschrieben.

Der vom Threadstarter anscheinend immer noch angedachte Versuch, das 
ganze dann über eine UART eines µC zu übertragen ist davon aber sehr, 
sehr weit entfernt.

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Dominik L. schrieb:
>> Aber das Programm müsste ich trotzdem noch selbst schreiben, oder?
>
> Hätte ich diese Frage vorher gesehen, hätte ich mir die letzte Antwort
> gespart.

Ja eigentlich war es unnötig das zu fragen, aber man weiß ja nie was 
alles möglich ist ^^
Mit dem USB Protokoll habe ich mich schon intensiv beschäftigt, 
natürlich weiß ich noch nicht alles, dafür ist es viel zu komplex, aber 
wir haben grundsätzlich noch 4 Monate Zeit um das ganze fertig zu 
bekommen.

S. R. schrieb:
> Alles in allem wird das ein übler Hack, der aber mindestens für
> USB-Sticks und ein bisschen Kleinkram funktionieren wird, wenn du es
> richtig machst.

Das klingt doch vielversprechend, zumindest für mich als Anfänger
Vorallem, das von jemandem zu hören der sich offensichtlich auf dem 
Gebiet gut auskennt.

S. R. schrieb:
> Du kannst
> Übertragungsfehler auch verbieten, dann wird das einfacher.

Das heißt, keine Fehlererkennung während der Übertragung, sondern darauf 
vertrauen, dass keine Fehler auftreten?
Grundsätzlich möglich, die Umgebung ist eigentlich immer die gleiche, 
weshalb man Fehler relativ leicht vermeiden kann.

von uwe (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> kann ja nicht sein, dass
> das so nicht geht ^^

Klar: die Amerikaner waren auf dem Mond, das beweist doch, dass man das 
mit einem Schweissbrenner und einer Handbohrmaschine ohne weiteres 
selbst schaffen kann. Man muss sich das nur zutrauen.

USARTs laufen mit 115 000 Baud, wenn man sich grosse Mühe gibt und was 
davon versteht, auch mit 1 MBaud. Da fehlen zu deinen Anforderungen ja 
nur noch 3 Grössenordnungen, und das ist nur ein kleiner Teil der 
Probleme.

Georg

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Der vom Threadstarter anscheinend immer noch angedachte Versuch, das
> ganze dann über eine UART eines µC zu übertragen ist davon aber sehr,
> sehr weit entfernt.

Wie gesagt, es war nur mein erster Gedanke und mir hat nie jemand gesagt 
(noch habe ich es wo gelesen), dass UART nicht für meine Anwendung 
geeignet ist.
Ich bin gerne für andere Lösungsvorschläge offen, solange man die 
Signale über LWL übertragen kann.

S. R. schrieb:
> Du kannst
> Übertragungsfehler auch verbieten, dann wird das einfacher.

Das wäre ja möglich um die Übertragundsgeschwindigkeit zu erhöhen

von Hans M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn es nicht unbedingt der Atmel sein muss:

Schau dir mal USP/IP an (http://usbip.sourceforge.net/)
An jedem Ende z.B. n RasPi und fürs Netzwerk gabs/gibts Ethernet/LWL 
Umsetzer.
Ohne LWL nutze ich das gern um Geräte, vom Büro aus, direkt beim Kunden 
zu debuggen. Der kriegt n Pi mit U-Link Pro geschickt und ich kann von 
überall direkt mit Keil drauf.

MfG Hans

von Thomas H. (flaretom)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Vielleicht habe ich ja einen Denkfehler, aber kann man nicht auf 
Bitebene bzw. Spannungslevel übertragen? Evt, 2 getrennte Wellenlängen 
für D+ und D-, das ganze natürlich bidirektional.

BG, Tom

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Angenommen wir hätten ein fertiges Gerät von dem wir abschauen können,
> kann man das Programm auf dem Controller überhaupt noch ändern? Sind die
> nicht irgendwie verschlüsselt um genau diesen Software-Diebstahl zu
> verhindern?
> Immerhin muss ich ja trotzdem das Programm für unseren Zweck ein wenig
> abändern, wegen den LED's usw. und ein fertiges Gerät zu kaufen ist wie
> gesagt nicht der Sinn des Projekts.

Nee, da gibts seltenst ein Programm drauf, und wenn, dann nur ne 
einfache Hub-Logik. Such mal nach USB 2.0/3.0 Fibre Optic Extender, oder 
so. Da gibt's z.B. von IDS was industriefähiges.
Also wenn ihr ein Produkt entwickeln wollt, was in nem Jahr fertig 
werden soll, würde ich noch mal ein Gespräch mit dem Auftraggeber 
führen, damit der sich nochmal im Kopf die Kosten durchgeht. Auch 
Uni-Abgänger als 'kosteneffektive' Entwickler sind nicht kostenlos..



Rufus Τ. F. schrieb:
> Siehst Du, und genau das ist der Knackpunkt. USB hat keinen separaten
> Hin- und Rückkanal, die muss man erst mal herstellen. Bei USB1.1 mit 12
> MBit ist das noch langsam genug, daß man durch intelligentes Mithören
> die Richtung 'rausfinden kann, aber bei USB2.0 mit 480 MBit/sec ist das
> nicht mehr so einfach möglich.

Tja, man braucht nicht mithören. Das geht mit ner relativ einfachen 
Logik. Man muss nur die richtigen Transceiver nehmen, da lässt sich die 
Richtung einfach codieren (ich erwähnte ja schon die Moden...)

von Dieter W. (dds5)


Bewertung
0 lesenswert
nicht lesenswert
Wie läuft das denn bei I2C, da ist ja auch (mindestens) die Datenleitung 
bidirektional und es gibt galvanische Trenner mit Optokopplern.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> und mir hat nie jemand gesagt (noch habe ich es wo gelesen), dass UART
> nicht für meine Anwendung geeignet ist.

Den Hinweis, daß Deine UART keine Datenrate von einem halben GBit/sec 
hinbekommt, den hab' ich Dir schon gegeben.

Mit Deiner UART-Lösung schaffst Du bestenfalls die 12 MBit/sec, die 
Full-Speed-USB (USB1.1) benötigt.

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas H. schrieb:
> Vielleicht habe ich ja einen Denkfehler, aber kann man nicht auf
> Bitebene bzw. Spannungslevel übertragen? Evt, 2 getrennte Wellenlängen
> für D+ und D-, das ganze natürlich bidirektional.

Das macht keinen Sinn, D+/D- ist ein differenzielles Paar, bei LWL 
braucht man (wegen der Einstrahlfestigkeit eines LWL) das genau nicht. 
Man benötigt dazu sogar nur EINEN Kanal, der ABWECHSELND nur in 
EINER Richtung verwendet wird.

Und klar, das geht prinzipiell schon, aber das hat gar nichts mit der 
vom TO vorgesehenen Idee zu tun. Deshalb hatte ich ja gleich die 
entsprechende Frage gestellt.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dieter W. schrieb:
> Wie läuft das denn bei I2C

Da ist die Datenrate ganz erheblich geringer als bei USB. I2C arbeitet 
meistens mit 400 kBit/sec, im Extremfall mit 1 MBit/sec. Hier geht es um 
etwa das 500fache davon.

von npn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Hier geht es um etwa das 500fache davon.

Dazu kommt noch, daß das Protokoll, das bereitgestellt und ausgewertet 
werden muß, ebenfalls wesentlich umfangreicher als das von I²C ist...

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
npn schrieb:

> Dazu kommt noch, daß das Protokoll, das bereitgestellt und ausgewertet
> werden muß, ebenfalls wesentlich umfangreicher als das von I²C ist...

Außerdem war I2C mal für gaaaannnzzz kurze Verbindungen gedacht, für 
eine Handvoll fest verdrahtete Bausteine (also kein fliegender Wechsel), 
die auch bei Schaltungsentwurf fest standen. Und eine 
Übertragungssicherung gibt's da bis auf das ACK auch nicht. Wenn man in 
ein EEPROM schreibt und ein Bit falsch ankommt, wird's halt auch falsch 
abgelegt ...

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> wir haben grundsätzlich noch 4 Monate Zeit um das ganze
> fertig zu bekommen.

Haha, hahahaha.

Spaß beiseite, in der Zeit wirst du nichtmal die USB Spezifikationen 
lesen können. Nutze die Zeit lieber, um diverse fertige Produkte 
auszuprobieren, damit ihr am Ende etwas funktionierendes gefunden habt.

von npn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hier ist mal ein Link zur USB2.0-Spezifikation.
Sind nur 650 Seiten.
Schaffst du das in 4 Monaten durchzuarbeiten (und auch zu verstehen)?
http://sdphca.ucsd.edu/lab_equip_manuals/usb_20.pdf
Oder du machst dich gleich über USB3.0 her.
Ist auch kürzer (nur 482 Seiten).
https://www.usb3.com/whitepapers/USB%203%200%20(11132008)-final.pdf

Viel Spaß beim Lesen!

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> aber wir haben grundsätzlich noch 4 Monate Zeit um das ganze
> fertig zu bekommen.

Fragen wir mal anders: Was kannst du denn?
- Wie lange hast du dich mit USB befasst?
- Wie gut kennst du dich mit Microcontrollern aus?
- Wie lange hast du dich mit deinem Wunschcontroller befasst?
- Wie gut kannst du C?
- Kannst du Assembler lesen?

> Vorallem, das von jemandem zu hören der sich offensichtlich auf dem
> Gebiet gut auskennt.

Hahaha. Du überschätzt mich. Ich kann einschätzen, was realistisch ist 
(wie viele andere hier auch).

Ich hab einmal USB-Host (für HID auf nem STM32) und einmal USB-Device 
(für CDC auf nem Atmega32U4) gemacht, beides lief einigermaßen 
gebrauchbar. Du willst ne Größenordnung komplizierter als das.

>> Du kannst Übertragungsfehler auch verbieten, dann wird das einfacher.
>
> Das wäre ja möglich um die Übertragundsgeschwindigkeit zu erhöhen

Es geht hier nicht um die Übertragungsgeschwindigkeit, sondern um die 
Korrektheit.

> Das heißt, keine Fehlererkennung während der Übertragung, sondern darauf
> vertrauen, dass keine Fehler auftreten?

Es geht nicht um Fehlererkennung, sondern um den simplen Fakt, dass du 
auf Übertragungsfehler nicht reagieren kannst. Wurde hier schon 
genannt.

> Grundsätzlich möglich, die Umgebung ist eigentlich immer die gleiche,
> weshalb man Fehler relativ leicht vermeiden kann.

Äh, nein.

Dominik L. schrieb:
> Ich bin gerne für andere Lösungsvorschläge offen, solange man die
> Signale über LWL übertragen kann.

Du willst ungefähr 500 Mbps übertragen (480 Mbps USB-Daten plus ein 
bisschen Zusatzinformationen zu den Daten). Welche Schnittstellen hat 
dein Wunschcontroller denn, die auch nur ansatzweise in die Nähe dessen 
kommen?

Kann der USB-Teil deines Controllers überhaupt Full-Speed mit voller 
Geschwindigkeit? Kriegst du überhaupt 500 Mbps durch die CPU? (Das wird 
mit den 84 MHz Maximaltakt nicht klappen... auch nicht mit DMA.)

Ich hab so das dumpfe Gefühl, dass du da an einem Projekt arbeitest, was 
für dich eine Nummer zu groß ist. Oder auch fünf.

von Tilo L. (katagia)


Bewertung
1 lesenswert
nicht lesenswert
Für USB FS gibts fertige isolatoren von Analog (ADUM).
Es gibt fertige USB HS isolatoren. Die sind deutlich teurer.
USB HS zu isolieren ist nicht trivial.
Der von der gewählte Controller ist dafür völlig ungeeignet. Zum einen 
schafft der den Datendurchsatz nicht. Zum anderen willst du eine 
"transparente" Lösung. Wenn du die vorhandenen USB-Schnittstellen 
verwenden willst, wird der angeschlossene PC davon etwas mitbekommen.

Das Problem ist nicht nur die Praxis sondern auch die Theorie.
Wie schon andere geschrieben haben, ist es nicht so ohne die Timings 
einzuhalten.

Dee "transparenten" Lösungen die ich kenne "lauschen" auf dem USB, um zu 
erkennen, ob Daten gesendet oder empfangen werden. Danach wird 
entschieden, ob empfangen oder gesendet wird. Das wird dann aber eher 
Richtung FPGA hinauslaufen.

4Monate .... lasst euch nicht verheizen. Da kommt nichts raus und der 
Aufwand ist enorm.

Fertige Isolatoren gibt es. Die haben zwar nicht eure Status-LEDs jedoch 
sollte man sich überlegen, ob die nur Wünsch-Dir-Was sind oder ob die 
wirklich notwendig sind.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
npn schrieb:
> Hier ist mal ein Link zur USB2.0-Spezifikation.
> Sind nur 650 Seiten.

Wenn er nur die physikalische Schicht durchswitchen will ohne sie 
anzufassen muss er weniger lesen.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Um der LWL Verbindung kommen wir nicht rum, da es um die Elektro
> Magnetische Ausstrahlung geht. Anschließen sollte man alles können, USB
> Stick, Computer, Smartphone, SPS, Industrie-Roboter, Messgeräte, etc.

Würd mich ja brennend interessieren was das für eine Apparatur sein soll 
an deren einem Ende ein PC steht, in deren Innern die EMV-Hölle siebten 
Grades lodert und an deren anderem Ende ein beliebiges Consumergerät 
beliebiger Funktion angestöpselt werden soll. Was ist das für ein 
Apparat?

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Fragen wir mal anders: Was kannst du denn?
> - Wie lange hast du dich mit USB befasst?
> - Wie gut kennst du dich mit Microcontrollern aus?
> - Wie lange hast du dich mit deinem Wunschcontroller befasst?
> - Wie gut kannst du C?
> - Kannst du Assembler lesen?

 - Die letzten 2 Wochen ca. 40 Stunden, Spezifikationen überflogen, 
Teile die interessant schienen genau gelesen.

 - Grundkenntnisse, Wir haben seit 2 Jahren Mikrocontroller 
programmieren in der Schule, klingt weniger als es wirklich ist.

 - Nicht wirklich, nur oberflächlich. Laut Datenblatt kann er USB 2.0 
HS, damit war die Auswahl getroffen. Ich hatte ja keine Ahnung worauf 
man noch achten hätte sollen...

 - Ich hätte mal gesagt ganz gut, bisher konnte ich alle Aufgaben ohne 
Probleme lösen, in Informatik hatte ich immer nur 1. Ich habe aber auch 
keinen Vergleich was "alles können" wirklich heißt und wie gut ich im 
Vergleich zu euch wirklich in C bin.

 - Nein, war noch nie nötig.

S. R. schrieb:
> Welche Schnittstellen hat
> dein Wunschcontroller denn, die auch nur ansatzweise in die Nähe dessen
> kommen?
>
> Kann der USB-Teil deines Controllers überhaupt Full-Speed mit voller
> Geschwindigkeit? Kriegst du überhaupt 500 Mbps durch die CPU? (Das wird
> mit den 84 MHz Maximaltakt nicht klappen... auch nicht mit DMA.)

Wie gesagt, laut Datenblatt kann er USB 2.0 HS, ich habe mich auch 
gefragt wie genau des gehen soll, dachte dann aber das wird schon gehen 
wenns da steht, immerhin sind Datenblätter vertrauenswürdig...

Bernd K. schrieb:
> Würd mich ja brennend interessieren was das für eine Apparatur sein soll
> an deren einem Ende ein PC steht, in deren Innern die EMV-Hölle siebten
> Grades lodert und an deren anderem Ende ein beliebiges Consumergerät
> beliebiger Funktion angestöpselt werden soll. Was ist das für ein
> Apparat?

Also es geht um die Verbindung für eine EMV Messhalle. Z.B. wenn neue 
Geräte auf Störaussendung getestet werden, dürfen die Messgeräte selbst 
quasi keine Störungen aussenden. Um den Kontroller kommt dafür noch ein 
geeignetes Gehäuse, und die Übertragung läuft via LWL. Natürlich sollte 
jedes beliebige Gerät vermessen werden können, deshalb die USB Umsetzer.
Aber ich werde mich erkundigen, auf welche Geräte wir uns beschränken 
können, da "Alles" nicht möglich ist, wie ich jetzt weiß.

Zu dem, dass wir nur 4 Monate Zeit haben:
Sollte es nicht fertig werden, und das wird es laut allgemeiner Meinung 
nicht, reicht es zu dokumentieren, warum es nicht fertig wurde. Wir 
müssen nur daran arbeiten so gut wir können, wenn es nicht besser geht 
kann man nichts machen...

: Bearbeitet durch User
von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Übrigens, wenn ihr einen Kontroller kennt, der besser geeignet ist, noch 
können wir wechseln. Wir müssen nicht den AT32UC3A3256 nehmen, es kann 
grundsätzlich jeder sein, solange er von Atmel ist (damit wir mit der 
Programmierung nicht komplett überfordert sind, AVR kann ich wenigstens 
grundlegend) und Alles kann was wir brauchen.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Also es geht um die Verbindung für eine EMV Messhalle.

Das Problem ist also komplett anders lösbar. Es gibt keinen wirklichen 
Grund, warum kein USB-Device-Server verwendet werden kann (da muss halt 
auf dem Test-PC der zugehörige Devicetreiber installiert werden), der 
dann über eine Netzwerkverbindung mit dem Test-PC verbunden wird. Die 
Netzwerkverbindung kann über Glasfaser erfolgen, so daß die 
EMV-Anforderungen gewährleistet sind.

USB-Deviceserver wurden in diesem Thread sogar schon genannt:
Beitrag "Re: USB Signal über 2 µCs seriell Übertragen"

Das ist die einzige sinnvolle Lösung für das Problem.

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
http://www.silexeurope.com/de/home/produkte/usb-device-server3/ds-600.html

"Ein USB Device Server ist ein Netzwerk-Adapter, der Silex USB Virtual 
Link Technologie verwendet, um USB-Geräte netzwerkfähig zu machen. 
Praktisch jede erdenkliche Art USB-Geräte kann somit im und über das 
Netzwerk verwendet werden, genau so wie direkt per USB-Kabel 
angeschlossen. Vorhandene Software und Treiber können weiter verwendet 
werden."

Meine Freage hierzu ist, funktioniert das wirklich so einfach? Und kann 
ich das ungefähr nachbauen? Oder passt der vergleich "mit einem 
Schweissbrenner und einer Handbohrmaschine zum Mond fliegen" auch hier?
Denn das wäre genau das, was wir brauchen.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
>> Fragen wir mal anders: Was kannst du denn?
> ...

Heißt: Wenig Vorkenntnisse, hauptsächlich aus der Schule. Das macht es 
deutlich schwieriger.

Programmierung in der Schule soll meist nur einen Punkt illustrieren, 
d.h. die Programme sind eher kurz und schnell runtergetippt. Hier geht 
um es um ein eher komplexes Projekt. Ob das reicht...

> S. R. schrieb:
>> Welche Schnittstellen hat dein Wunschcontroller denn,
>> die auch nur ansatzweise in die Nähe dessen kommen?

Du hast diese Frage nicht beantwortet. Über USB kriegst du z.B. 40 MB/s 
in den Controller rein - wie kriegst du da sie wieder raus, um sie auf 
LWL umzusetzen? Denk mal darüber nach.

>> Kann der USB-Teil deines Controllers überhaupt Full-Speed mit voller
>> Geschwindigkeit? Kriegst du überhaupt 500 Mbps durch die CPU? (Das wird
>> mit den 84 MHz Maximaltakt nicht klappen... auch nicht mit DMA.)
>
> Wie gesagt, laut Datenblatt kann er USB 2.0 HS, ich habe mich auch
> gefragt wie genau des gehen soll, dachte dann aber das wird schon gehen
> wenns da steht, immerhin sind Datenblätter vertrauenswürdig...

Datenblätter - insbesondere die Summary - sind Werbung. Das, was da 
steht, geht nur unter bestimmten Umständen und auch nicht alles 
zusammen.

High-Speed heißt nur, dass der Controller die Bits so kurz machen kann, 
wie die Spec es verlangt. Das heißt nicht, dass er auch die maximale 
Datenrate erreicht.

> Natürlich sollte jedes beliebige Gerät vermessen werden können,
> deshalb die USB Umsetzer.
> Aber ich werde mich erkundigen, auf welche Geräte wir uns beschränken
> können, da "Alles" nicht möglich ist, wie ich jetzt weiß.

Mit Umsetzer wird sich das Gerät möglicherweise anders verhalten als 
ohne Umsetzer (weil sich das Zeitverhalten ändert). Das gilt es zu 
berücksichtigen. Ob das relevant ist, weiß ich nicht.

> Sollte es nicht fertig werden, und das wird es laut allgemeiner Meinung
> nicht, reicht es zu dokumentieren, warum es nicht fertig wurde.

Kläre das mit deinem Betreuer. Ein "wir sind nicht fertig geworden, weil 
wir inkompetent waren und die Aufgabe unterschätzt haben" ist eher 
selten wissenschaftlich genug für eine Diplomarbeit.

Dominik L. schrieb:
> Wir müssen nicht den AT32UC3A3256 nehmen, es kann
> grundsätzlich jeder sein, solange er von Atmel ist
> (damit wir mit der Programmierung nicht komplett überfordert sind,
> AVR kann ich wenigstens grundlegend) und Alles kann was wir brauchen.

Dir ist offensichtlich nicht klar, dass AVR und AVR32 zwei völlig 
verschiedene Architekturen sind, die nichts miteinander zu tun haben. 
Das steht sogar im passenden Wikipedia-Artikel. Deine AVR-Kenntnisse 
sind bei AVR32 ähnlich nützlich wie bei ARM oder MIPS. Programmer und 
Debugger kannst du nicht benutzen.

Je mehr ich von dir lese, desto mehr habe ich das Gefühl, dass das eher 
nichts sinnvolles wird. Da fehlen zu viele Grundlagen.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Meine Freage hierzu ist, funktioniert das wirklich so einfach?

Das Ding verhält sich wie eine "virtuelle USB-Karte". Ja, es ist so 
einfach. Die Dinger funktionieren. Ein USB3-Device-Server kann 
logischerweise nicht die volle USB3-Bandbreite zur Verfügung stellen 
(dazu ist halt GBit-Ethernet zu langsam), und es kann auch zu Problemen 
bei isochroner Übertragung kommen, denen man aber aus dem Weg gehen 
kann, indem man auf der Netzwerkverbindung nichts anderes macht, also 
notfalls dem steuernden PC eine zweite Netzwerkkarte spendiert.

> Und kann ich das ungefähr nachbauen?

Es gibt vergleichbare Lösungen, die das mit einem Raspberry Pi machen 
(http://www.sysrun.de/2014/01/raspberry-pi-als-usb-server/), aber mit 
"selbstbauen" hat auch das nichts zu tun.


Und, ohne Dir zu nahe treten zu wollen, auch der Selbstbau eines 
USB-Device-Servers dürfte ein paar Nummern zu groß für Deinen 
Erfahrungs-, Wissens- und Zeithorizont sein.

Vor allem:

Es wird nicht günstiger. So ein Deviceserver kostet -Hausnummer- um die 
100 EUR, der von Dir verlinkte USB3-Server kostet 150 EUR, für den Tarif 
bekommst Du definitiv keine alternative Lösung mit eigener Hardware 
(Platine layouten, herstellen lassen, bestücken, testen) zum laufen, 
selbst wenn Du die nichttriviale Softwareentwicklung als Nullsummenspiel 
ansiehst.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
>> (USB Device-Server)
> Und kann ich das ungefähr nachbauen?

Du sollst das nicht nachbauen, sondern einfach kaufen.

Zusatzfrage: Wollt ihr euch für den Controller ein Eval-Board kaufen 
oder selbst entwickeln?

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Zusatzfrage: Wollt ihr euch für den Controller ein Eval-Board kaufen
> oder selbst entwickeln?

Wir hatten vor dieses Eval Kit zu kaufen:
http://www.atmel.com/tools/uc3-a3xplained.aspx



Dadurch, dass ich bisher nur in der Schule programmiert habe, und das 
immer sehr einfach war, dachte ich wie schwer soll das denn noch werden.
Anscheinend war das das Hauptproblem hier...
Meine Vorstellung war, einfach ein fertiges Beisplei Program von Atmel 
für USB herunterladen, ein wenig abändern und fertig.
Wie sich herausgestellt hat ist das ganze nichtmal ansatzweise so 
einfach...

Gibt es irgendeine Möglichkeit wie ich das alles hinbekomme? Ich kann 
auch noch neue Dinge lernen um das einigermaßen zu schaffen, was sollte 
man können um sowas zu bauen?
"Geht nicht, gibt's nicht"
Abgesehen davon, dass die Zeit wahrscheinlich nicht ausreicht und ich 
das Alles vielleicht nicht verstehe, was müsste ich noch lernen oder 
wissen damit das Projekt nicht komplett unmöglich ist?

Ich weiß ich klinge grade sehr überschätzt, es geht mir nur darum, 
vielleicht geht es ja doch?

Oder, wie würdet ihr so einen Aufgabe lösen?

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Meine Freage hierzu ist, funktioniert das wirklich so einfach? Und kann
> ich das ungefähr nachbauen? Oder passt der vergleich "mit einem
> Schweissbrenner und einer Handbohrmaschine zum Mond fliegen" auch hier?
> Denn das wäre genau das, was wir brauchen.

Ja, du kannst das mit nem (gut ausgewählten) Linux-Embedded-System 
versuchen und über Gigabit Ethernet gehen, wenn es nur der EMV-Aspekt 
ist. Aber es wird spätestens bei Messwerterfassung mit einer gewissen 
Bandbreite oder bei isochronen Verbindungen Probleme mit verlorenen 
Frames machen (die du natürlich grundsätzlich auf deinem System auch 
haben kannst). Mal ganz abgesehen von Echtzeitproblemen, die du mit 
Linux/UDP nur bedingt löst (da müsstest du dann zum FPGA oder z.B. der 
Xenomai-Kernel-Erweiterung greifen und eigene Treiber entwickeln. No go 
für deinen Projektrahmen).
Und da die Systeme dann sehr komplex sein können, kannst du zwischen 
"Glück gehabt, funktioniert" bis "ewig Fehler suchen/an der Komplexität 
scheitern" auswählen.

Aber bevor wir uns alle hier noch mehr im Kreis drehen, würde ich mal 
ein ernstes Gespräch mit dem Vorgesetzten führen und ihm klarmachen, 
dass 4 Mannmonate gerade mal für dein anfangs erwähntes "proof of 
concept" reichen.
Du musst ja offenbar mit irgendwas anfangen. Also fang mit dem 
UART-Tunnel (ohne LWL) an, da kannst du mit etwas Effort nach 1-2 Wochen 
zeigen, dass es mit dem Konzept nicht für die TMC-Klassen (Messgeräte) 
reicht. Dann haben alle wenigstens was gelernt.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Dadurch, dass ich bisher nur in der Schule programmiert habe, und das
> immer sehr einfach war, dachte ich wie schwer soll das denn noch werden.

Hättest du privat auch programmiert, hättest du schon lange gemerkt, 
dass ein vollständiges Projekt eine Nummer komplizierter/aufwändiger 
ist, als die üblichen Übungsaufgaben ("mache eine Liste").

Dominik L. schrieb:
> Gibt es irgendeine Möglichkeit wie ich das alles hinbekomme?

Beschränke dich auf eine Geräteklasse, z.B. USB-MSC (Full-Speed) oder 
USB-HID (Low-Speed). Letzteres kriegst du sogar in Echtzeit durch eine 
UART. Verzichte auf LWL. Verzichte auf DMA und Interrupts, soweit 
möglich.

Schreibe ein Testprogramm, mit dem du eine LED blinken lassen kannst. 
Dann eins, womit du zwei Zahlen seriell (UART) einlesen, addieren und 
seriell ausgeben kannst.

Implementiere selbst(!) ein solches Gerät auf Device-Seite (nimm dir 
Beispielcode, aber keine komplizierten Bibliotheken - da steigst du eh 
nicht durch). Teste mit Windows und Linux. Letzteres gibt deutlich 
bessere Fehlermeldungen, wenn etwas nicht funktioniert.

Implementiere selbst(!) die Gegenstelle dafür (nimm dir wieder 
Beispielcode, aber keine komplizierten Bibliotheken - weil du da eh 
nicht durchsteigst). Teste mit möglichst vielen verschiedenen Geräten.

Dann denke darüber nach, welche USB-Informationen du wie austauschen 
musst, und wie du die beiden Controller passend verheiratest.

Dominik L. schrieb:
> "Geht nicht, gibt's nicht"

Ist mMn ein bescheuerter Spruch. Der Glaube kann nur metaphorische Berge 
versetzen, die Zugspitze kriegt man nur mit sehr viel Arbeit bewegt.

von Christian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Eine grundsätzliche Frage von mir noch:
Du schriebst von der Ausbildung zum Dipl.-Ing. und davon, dass du in der 
Schule programmiert hast. Meine Frage hierzu: Handelt es sich dabei um 
den Studienabschluss an einer Universität oder Fachhochschule.. ? Oder 
gab es nicht in Österreich (wenn ich nicht irre!) auch die Bezeichnung 
Dipl.-Ing. ohne Studium.. ? Dein Herangehen (nix für ungut :-) ) lässt 
mich das irgendwie vermuten..

Grüße
Christian

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christian schrieb:
> Du schriebst von der Ausbildung zum Dipl.-Ing. und davon, dass du in der
> Schule programmiert hast.

Das hat mit dem Diplom-Ingenieur, den es früher in Deutschland gab, in 
der Tag gar nichts zu tun.

https://de.wikipedia.org./wiki/Ingenieur#Ingenieursausbildung_im_Rahmen_des_Schulsystems


Das dürfte grob ein Äquivalent des Fachabiturs sein.

: Bearbeitet durch Moderator
von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Also jetz schlägts dreizehn...gilt's jetzt etwa hier auch als cool, mit 
akademischen Spitzfindigkeiten um sich zu werfen?
Die beiden letzten Beiträge sind auf jeden Fall diesbezüglich absolut 
daneben und am Thema definitiv vorbei.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ich denke, daß diese Fragen hilfreich sind, um den Know-How Stand des TO 
abzuschätzen. Dementsprechend werden dann die Hilfreichen Antworten 
sein.

Antworten, die den TO total überfordern, wären nicht hilfreich.

von Duennwandiger Troll (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Als Hochgeschwindigkeitsschnittstellen bietet ich Serdes an. Die kann 
auch auch ein gemaechlicher, was auch immer das heisst, Controller 
bedienen. Im wesentlich ist das eine paralelle Schnittstelle die Seriell 
ruebergeschoben wird. Also zB 32 Bit Breite mit 66MHz macht dann einen 
Bitclock von um die 2GBit. Damit kann man auch ueber einen LWL.

Bei USB bleibt die Laengenbegrenzung von 5m, aufgrund der geforderten 
Antwortzeit. Deshalb ist der USB auch ein klein-Buero-Bus. Fuer was 
anderes taugt der auch nicht. Da ist nichts mit industriell. Er hat auch 
andere, sehr gewichtige Nachteile. Er taugt laengerfristig nur fuer 
Massenspeicher, dh US Stick und USB-UART. Alles andere kann man in die 
Tonne werfen.

Eine sinnvolle Alternative ist Ethernet.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Duennwandiger Troll schrieb:
> Er taugt laengerfristig nur fuer Massenspeicher,
> dh US Stick und USB-UART.

Äh, nein.

Guckst du "lsusb" auf einem halbwegs modernen PC/Notebook, findest du zB 
Webcam, Mikrofon, WLAN- und Bluetooth, Cardreader, Touchpad. Stellst du 
dann fest, dass Maus, Tastatur und Grafiktablet auch nur noch per USB 
anschließbar sind. Nix Alternative.

Schlussfolgerst du, dass USB ein bisschen taugen muss.

von Christian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Also jetz schlägts dreizehn...gilt's jetzt etwa hier auch als
> cool, mit
> akademischen Spitzfindigkeiten um sich zu werfen?
> Die beiden letzten Beiträge sind auf jeden Fall diesbezüglich absolut
> daneben und am Thema definitiv vorbei.

Hallo,

es liegt mir fern, mich über Jemanden lustig zu machen, egal welchen 
Abschluss er bisher erreicht hat. Meine Frage zielte darauf ab, auf 
welchem Niveau man Vorwissen erwarten kann. Beim Diplom-Ingenieur dachte 
ich ursprünglich an einen FH- oder Uni-Absolventen und wunderte mich ein 
bisschen über die etwas naiv anmutenden Fragen.

Natürlich ist ein Abschluss keine Garantie für Wissen. Es gibt auch 
misserable Absolventen und begnadete Amateure. Aber nichts desto trotz 
hätte ein Studium zumindest Grundlagen vermittelt hinsichtlich Hardware, 
Programmierung und Messtechnik. Über letzteres Kapitel wurde 
beispielsweise noch garnicht gesprochen. Was steht denn an high-speed 
Messtechnik zur Verfügung und wird beherrscht.. ?

Und ich selbst muss für mich zugeben, dass ich kurz nach dem Abitur froh 
war, ein paar LEDs mittels Mikrocontroller zum Blinken zu bringen oder 
ein paar Messwerte per UART an den PC zu schicken. Also ebenfalls viele 
viele Größenordnungen vom hier anvisierten Ziel entfernt. Manchmal ist 
es aber eben doch auch nicht verkehrt, auf den Erfahrungen (und auch 
Misserfolgen!) Anderer aufzubauen.

"Geht nicht, gibts nicht.." ist ein recht witziger Spruch. Der mag zwar 
zutreffend sein, um ein wenig über den aktuellen Horizont hinaus zu 
extrapolieren. Aber wenn die bisherige Erfahrung um Größenordnungen 
nicht ausreicht, hilft es trotzdem leider nicht weiter. Ich vermute, 
schon allein die Frage nach der zur Verfügung Messtechnik beendet dieses 
Projekt.

Und auch eine letzte Anmerkung: Wenn es hier um eine "störungsfreie" 
Übertragung für Messzwecke geht: Wie verhindert man denn, dass das 
irgendwie entworfene und in Betrieb genommene Endstück weniger Störungen 
produziert als ein PC  USB-Server  Raspberry / 
was-hier-noch-so-vorgeschlagen-wurde.. ? Vielleicht sollte man eher dort 
ansetzen und ein funktionierendes Sytem nehmen und soweit modifizieren, 
dass es die Anforderungen erfüllt. Mit Glück (!!!) und der geeigneten 
Messtechnik muss man vielleicht nur an er Stromversorgung ansetzen sowie 
die Ein- und Ausgänge noch etwas filtern..

Ich für mich selber würde vermutliche in halbes Jahr einplanen, um die 
USB-Spec ausreichend durchzuarbeiten, die Messtechnik zu organisieren, 
ein Konzept zu erarbeiten und vielleicht ein paar Vorversuche 
durchzuführen. Von einer konkreten Implementierung reden wir hier noch 
garnicht!

Die schon weiter oben vorgebrachte Idee, I2C/TWI über einen LWL-Kanal zu 
führen, erscheint mir da schon sinnvoller. Anspruchsvoll genug allemal 
und vielleiht von einem Erfolgerlebnis gekrönt :-)

Ich hoffe, ich konnte einiges klarstellen
Christian

von Duennwandiger Troll (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>Duennwandiger Troll schrieb:
> Er taugt laengerfristig nur fuer Massenspeicher,
> dh US Stick und USB-UART.
>
>Äh, nein.
>
>Guckst du "lsusb" auf einem halbwegs modernen PC/Notebook,
>findest du zB Webcam, Mikrofon, WLAN- und Bluetooth,
>Cardreader, Touchpad. Stelst du dann fest, dass Maus,
>Tastatur und Grafiktablet auch nur noch per USB
>anschließbar sind. Nix Alternative.
>
>Schlussfolgerst du, dass USB ein bisschen taugen muss.

Das ist alles Wegwerfzeug, fliegt mit dem ausgedienten PC in die Tonne. 
Ich denke eher an industrielle Geraete. Geraete, die 10..20 Jahre 
laufen. Das Problem dann ist, den Treiber fuer Win(N+1) zu bekommen. Und 
die dazupassende Software. Denn ohne Treiber ist nichts. In die Tonne. 
Das ist der Vorteil von USB Uart. Der ist Teil des Systems, Und das 
Programmierinterface ist auch Serial Port auf beiden Seiten. Ist also 
Portabel.
Ethernet hat da etwas mehr Zukunft, ist auch weniger nah mit dem System 
verwoben. Bei einem Etherenet interface hat man entweder einen Browser 
als Interface, oder das Protokol ist dokumentiert.

von Christian R. (supachris)


Bewertung
1 lesenswert
nicht lesenswert
Das ganze Projekt ist so totaler Nonsens. Sowas gibts für etwa 
300...400€ zu kaufen. Schau mal bei www.icron.com vorbei. Komplett 
fertig, für ALLE USB Geräte und mit LEDs.
Das ist um mindestens Faktor 20 günstiger als auch nur ansatzweise was 
selbst zu entwickeln, was dann nach der Arbeit wegfliegt.
Wie kommt man darauf so eine Aufgabe einem Studenten ans Bein zu hängen? 
Oder ist das wieder so ein HTL Zeug, wo grenzenlose Selbstüberschätzung 
an der Tagesordnung ist?
Für FullSpeed könnte man noch die ADUM nehmen aber streng genommen ist 
das auch Frickelzeug und entspicht nicht mal ansatzweise dem USB 
Standard.
Die Icron Teile haben einen komplexen ASIC drin, denn die spielen Hub 
und zerlegen den kompletten USB Datenverkehr. Also Fazit: Lass es sein! 
Sag deinem Prof/Lehrer dass die Aufgabe Quatsch ist und such dir eine 
Aufgabe die für einen Azubi geeignet ist. Sorry für die harten Worte, 
aber ich bin mir wie die anderen die sich mit USB auskennen leider 
sicher dass das viele Hausnummern zu groß ist.

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Also zur Ausbildung:
Ich komme in die 5. Klasse einer HTL für Mechatronik, nach der man 
INGENIEUR ist. Habe mich dafür nochmal erkundigt, ich entschuldige mich 
für den Fehler in meinem ersten Beitrag. Weil wir an einer 
"Diplomarbeit" arbeiten, dachte ich werden wir wohl Dipl. Ing. werden.

Das ganze Projekt wird kann nicht wirklich abgebrochen oder geändert 
werden. Meine 2 Kollegen kommen mit ihrer Aufgabe ganz gut klar, 
Spannungsversorgung, Gehäuse, Schaltpläne etc. gibts teilweise ja schon 
irgendwo zu finden.
Das Problem wegen "eine andere Aufgabe suchen" geht so nicht, der ganze 
Papierkram ist schon durch und das dauert zu lange um ein neues Projekt 
zu beantragen.

Mein Lösungsansatz wäre nun, dass ich 2 Eval kits kaufe, und diese 
irgendwie mal miteinander kommunizieren lasse sodass man später USB 
Geräte anschließen kann. Natürlich nicht alles, sondern "einfache" 
Geräte, dass das Teil auch irgendwie funktionieren kann.
Als Argumentation, warum ich nur so wenig "in so viel Zeit" geschafft 
habe, würde ich vielleicht einige Argumente die hier genannt wurden, 
verwenden.
Ist das Eval Kit dafür geeignet?

Dominik L. schrieb:
> Wir hatten vor dieses Eval Kit zu kaufen:
> http://www.atmel.com/tools/uc3-a3xplained.aspx

Und wäre das für mich machbar?

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Und wäre das für mich machbar?

Wenn Du sehr viel Glück hast und an den richtigen Stellen anfängst, und 
keine Irrwege gehst.

Um wenigstens eine Minimallösung umsetzen zu können, musst Du Dir ein 
USB-Gerät bzw. eine USB-Geräte-Klasse aussuchen, die a) keine hohe 
Bandbreite benötigt und b) ein relativ einfaches, dafür aber gut 
dokumentiertes Protokoll verwendet.

Ich rate Dir zu USB-HID. Das ist Low-Speed-USB, d.h. es verwendet eine 
Datenrate von 1.5 MBit/sec, die Du mit etwas Aufwand vermutlich 
tatsächlich auch über Deine UART geprügelt bekommen können könntest.

(Erste Aufgabe: Finde anhand des Datenblatts heraus, welche maximale 
Baudrate die UART Deines µCs unterstützt)

Dann musst Du die Host-Seite davon umsetzen, d.h. auf Deinem µC mit so 
einem USB-HID-Gerät reden. Das bedeutet, daß Du die Vorgänge, die beim 
Anschließen eines USB-Geräts durchzuführen sind (Erkennen, daß eins 
angeschlossen ist, Abfragen des Devicedescriptors etc.) umsetzen musst, 
und daß Du --zu Testzwecken-- auch die Daten, die so ein Gerät senden 
kann (bei Tastaturen: Informationen über gedrückte Tasten) auch 
auswertest.

Der zweite Teil findet auf der Client-Seite statt, d.h. auf dem µC, der 
sich mit Deinem PC verbinden soll. Da kannst Du Dir auch mal eine 
USB-HID-Implementierung als Beispiel ansehen, Deine eigene Umsetzung 
davon aber wird sich in einigen wesentlichen Punkten von vorgefertigten 
Beispiellösungen unterscheiden.

Zunächst aber wirst Du schon genug damit zu tun haben, z.B. eine simple 
serielle Schnittstelle (die Du an einen PC hängst und mit einem 
Terminalprogramm à la TeraTerm bedienst) auszulesen und die darüber 
empfangenen Zeichen in das USB-HID-Protokoll zu verpacken, damit Du an 
Deinem Test-PC diese Daten empfangen kannst.

Jetzt hast Du Dich schon mal mit der seriellen Schnittstelle 
beschäftigt, aber mit sehr geringen Datenraten.

Du musst Dir nun ein Protokoll ausdenken, das die beiden µCs an den 
Enden Deiner LWL-Strecke miteinander "reden", um 
Verwaltungsinformationen und Nutzdaten zuverlässig in beide Richtungen 
zu übertragen. Ja, auch bei so etwas einfachem wie einer USB-Tastatur 
findet eine bidirektionale Kommunikation statt, die Tastatur empfängt 
auch Daten (z.B. zur Ansteuerung der Status-LEDs).

Wenn Du es geschickt anstellst, strukturierst Du dieses Protokoll aber 
nicht an den Vorgaben von HID, sondern an dem zugrundelegenden 
USB-Protokoll.

Interessant wird jetzt der Prozess des "USB-Gerät wird an Host-µC 
angeschlossen". Die verschiedenen Vorgänge (Erkennen, daß was 
angeschlossen wurde, herausfinden, was das ist, Descriptor abfragen 
etc.) werden nun nicht mehr von Deinem Host-µC gesteuert, sondern müssen 
transparent an den Client-µC übertragen werden, damit der dem 
angeschlossenen PC gegenüber das Einstecken des USB-Gerätes nachbilden 
kann.

Somit darf Dein Client-µC sich dem PC gegenüber zunächst gar nicht als 
USB-Gerät zu erkennen geben, sondern erst dann damit anfangen, wenn an 
Deinem Host-µC etwas angeschlossen wird.


Das ist schon ziemlich heftiges Holz, und ich befürchte bei allem 
jugendlichen Elan, daß auch das Dich und Deine Kumpels ziemlich heftig 
fordern, wenn nicht überfordern wird.

Und, dran denken, das ist nur Low-Speed-USB mit 1.5 MBit/sec. Aber das 
dürfte für Deine Abschlussarbeit mehr als ausreichend anspruchsvoll 
sein.

(Zum Thema Ausbildung: Die leichte Irritation, die hier bei einigen 
aufkam, hat damit zu tun, daß die Begriffe "Diplom-Arbeit", "Ingenieur" 
und "Diplom-Ingenieur" in Deutschland eine sehr andere Bedeutung haben 
als in Österreich. Die Diplom-Arbeit war vor den Bologna-Reformen ein 
Universitätsabschluss in den Ingenieurswissenschaften, den entprechenden 
Studiengang konnte man erst nach Erreichen der Hochschulreife überhaupt 
antreten. In Deutschland nennt sich das Abitur, was nach 12/13 
Schuljahren erlangt werden kann und vermutlich der Matura in Österreich 
entspricht.
Der Titel "Diplom-Ingenieur" ist ein akademischer Grad, der sehr 
deutlich oberhalb des Bologna-Titels "Bachelor" und je nach Studiengang 
auch eher oberhalb des Bologna-Titels "Master" einzuordnen ist.
Du siehst: das ist doch ein kleines bisschen was anderes, und von den 
Besonderheiten des österreichischen Bildungssystems wissen hier viele 
rein gar nichts)

von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> Und wäre das für mich machbar?

Nein definitiv nicht. Das wird nichts. Dafür ist die Aufgabenstellung 
viel zu komplex.
Es ist ja nicht nur die USB spec. die du verstehen musst. Du brauchst 
auch noch das Fiber Interface. Selbst wenn du nur HID lowspeed 
implementiert hast du auch noch die HID spec. am Bein. Deine Vorstellung 
mit zwei Eval Kids und ein bisschen Code ist naiv.
Selbst mit USB Know-how ist das nicht unter einem halben Jahr mit 
eingeschränkter Funktionalität zu machen.
Warum glaubst du dass du sowas billiger hinbekommst als z.b icron?
Nur weil USB ein serieller BUS ist bedeutet das nicht dass du nur noch 
die eine serielle Verbindung zwischen 2Controllern aufbauen musst.
Tue dir den Gefallen und zieh die Reisleine.

Thomas

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
Ich hätte einen anderen Vorschlag:

Bau einen USB Device Server. Das ist eine Kiste, die ihren USB Host Port 
einem entfernten PC über Ethernet zur Verfügung stellt. Auf dem PC läuft 
normalerweise ein Treiber, der den Device Server als USB-Karte in das 
Betriebssystem einbindet. So etwas ist technisch problemlos realisierbar 
und auch käuflich erhältlich.

Damit hättest Du überhaupt eine Chance.

Haken dabei: Der Host-USB-Treiber für den PC ist so komplex, dass die 
Entwicklung deutlich länger als ein Jahr dauert - nur alleine dafür. 
Andere Firmen wie SEH haben 5 Mannjahre an Entwicklungsarbeit da hinein 
gesteckt. Alternativen dazu gibts nicht, weil das Problem der 
Reaktionszeiten bei längeren Strecken nur gelöst werden kann, wenn die 
Low-Level Verarbeitung quasi vor Ort stattfindet.

Ersatzweise könntest Du Dich auf eine USB Deviceklasse beschränken, 
vorzugsweise Drucker (USB Printing Class) oder CDC-ACM (USB-RS232, wie 
es zB der MCP2200 und der MCP2221 implementieren - die anderen Chips 
sprechen kein USB-CDC, sondern allesamt etwas proprietäres, die sind 
also nicht nutzbar).

Dafür implementierst Du auf dem Deviceserver zB das Jetdirect Protokoll 
über TCP Port 9100 oder BSD LPD und schließt einen Drucker an.

Oder Du nimmst einen MCP2200 Seriell-USB-Adapter, schließt den an Deinen 
Device Server an und reichst die Bytes an irgendeinen TCP-Port durch.

Damit zeigst Du, dass das Prinzip funktioniert. Das rohe Durchreichen 
der USB-Frames wäre dann vielleicht etwas für spätere Projekte, die 
darauf aufbauen.

Mehr wird für Dich nicht drin sein. Vergiss es.

Als Hardware nimmst Du das hier:

http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=DM320007

Da ist alles drauf, was Du brauchst - Du kannst sofort anfangen. Der 
Prozessor hat ordentlich Wumms, Flash und RAM sind im Überfluss 
vorhanden. Schaltpläne sind in der Anleitung mit drin. Debugger ist auch 
mit auf dem Board drauf.

Den von Dir ins Auge gefasste AVR32 kann man zwar noch für eine gewisse 
Zeit kaufen, aber Microchip lässt diese Linie sterben und führt nur 
PIC32 (MIPS) und Atmel ARM weiter.

Wenn Du statt RJ45 LWL brauchst, nimmst Du fürs erste einen 
Medienkonverter oder ersetzt die Huckepackplatine mit dem 
Netzwerkanschluss. Damit man die Anbindung ersetzen kann, ist der 
Netzwerkanschluss als extra Board ausgeführt. Da kommt MII an, und da 
brauchst Du einen PHY, der 100FX LWL daraus machen kann. ZB den hier:
http://www.microchip.com/wwwproducts/en/KSZ8041

Netzwerkkarte auf dem PC wäre dann sowas hier:
https://www.amazon.de/Allied-Telesis-AT-2711FX-PCIe-Netzwerkkarte-100FX/dp/B000O78AHE

Damit wäre das Problem auch abgehakt.

fchk

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ich dachte damit soll die USB Leitung eines bestimmten Messgerätes 
verlängert werden.

Was nützt es dann, irgendeine Device Klasse zu implementieren? Sollte 
man nicht besser für dieses eine Gerät entwickeln?

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Was nützt es dann, irgendeine Device Klasse zu implementieren?

Das schlug ich vor, als einfachste Variante. Das eigentliche Ziel ist 
sowieso völlig unrealistisch und unerreichbar, auch das Gebastel mit 
einer so simplen Geräteklasse wie HID hat gute Chancen, den Bach 
runterzugehen, aber möglicherweise bringt es ein bisschen Lernerfolg, so 
daß wenigstens was hängenbleibt.

Wie das eigentliche Ziel erreicht werden kann, ist ad nauseam hier 
diskutiert und vorgeschlagen worden - nicht mit einem Selbstbau, 
sondern mit dem Einsatz fertiger und verfügbarer Technik.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Sehe ich auch so. Bei Verwendung fertiger Baugruppen mit fertigen 
Treiber wird das schon anspruchsvoll genau. Die Zeit kannst du ja 
nutzen, um zu dokumentieren, wie das Gewählte Produkt funktioniert und 
warum du dieses ausgewählt hast, anstatt was eigenes zu entwickeln.

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Ok danke für eure Hilfe.
Ich werde das morgen mit unserem Vorgesetzten klären und hoffentlich 
führt das ganze nicht zu großeren Problemen wegen dem ganzen Papierkram 
der eigentlich schon erledigt ist...

Wir haben uns mit dem Projekt wies aussieht maßlos überschätzt, da wir 
keine Ahnung hatten wie komplex die digitale Welt wirklich ist.

von Christian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dominik L. schrieb:
> [..]
>
> Das ganze Projekt wird kann nicht wirklich abgebrochen oder geändert
> werden. Meine 2 Kollegen kommen mit ihrer Aufgabe ganz gut klar,
> Spannungsversorgung, Gehäuse, Schaltpläne etc. gibts teilweise ja schon
> irgendwo zu finden.
> [..]

Es ist natürlich schon interessant, wie einerseits das Aufgaben-Niveau 
verteilt ist und wie andererseits schon an Stromversorgung und Gehäuse 
entwickelt werden kann, wenn noch gar nicht feststeht, was überhaupt 
benötigt wird und wie groß das Konstrukt wird ;-)

Grüße
Christian

von Weinbauer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Schaltpläne??? Soll das ein Witz sein?

Ihr wisst noch nicht wie ihr umsetzen wollt und malt Pläne? Erst muss 
doch das Konzept stehen ...

also 480MHz aufzuträgern für eine Übertragung ist schonmal sehr 
ehrgeizig für mal eben so.
UART Datenpakete durchreichen halte ich für aussichtslos, schon das 
Delay die Pakete empfangen und wieder Ausgeben kann Euch um die Ohren 
fliegen.
Nein, um Analogtechnik werdeet Ihr nicht herum kommen.
2 LWL Duplex zu verwenden ist schonmal eine gute Idee, kann man sich die 
Flussrichtungsumschaltung schenken.

Ihr braucht (mal stark vereinfacht) eine Schaltung die Euch aus D+ - D- 
eben die Bits heraus holt, dann nen Laser, der eben mit 480MHz 
geschaltet werden kann, auf der Gegenseite einen ebensolchen Empfänger 
und eben wieder die Schaltung die Euch die Bits wieder differentiell 
rausschiebt ...

Schon die Messtechnik um da Fehler zu suchen wird "nicht billig"

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ihr braucht nicht weiter auf dem Armen herumzuhacken, die Tragweite 
seiner Idee dürfte ihm mittlerweile klargeworden sein.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Weinbauer schrieb:
> 2 LWL Duplex zu verwenden ist schonmal eine gute Idee, kann man sich die
> Flussrichtungsumschaltung schenken.

Die kann er sich nicht schenken, auf USB-Seite braucht er sie.

von Weinbauer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
klar, auf der elektrischen Seite braucht er sie ...

so oder so, frag ich mich ... was studieren die Jungs eigentlich??

Hab ja "nur" Elektroniker gelernt und selbst mir ist klar, dass 480 MHz 
bzw. 480 MBit schon ne Hausnummer ist für mal eben diskret zusammen zu 
löten.
Werden da keine Praktika veranstaltet von wegen "dies ist ein 
Transistor, er schaltet so, jetzt lass uns mal den Funktionsgenerator 
hoch drehen und schauen uns die Flanken an"

Statt dessen kommt die Frage nach Codeschnipseln und Designbeispielen, 
während die 2 anderen Nasen (die nun fein raus sind) sich schonmal n 
stylisches Design ausdenken. Der TO hat jetzt die Arschkarte, weil ER 
hat es ja nicht hin bekommen, die 2 Anderen stehen gut da.

Team ... toll ein Anderer machts

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Weinbauer schrieb:
> was studieren die Jungs eigentlich??

Gar nichts, das haben wir aber schon geklärt.

von Dominik L. (kimonid)


Bewertung
0 lesenswert
nicht lesenswert
Also abschließend nochmal vielen Dank für eure Hilfe, wir haben mit 
unseren Vorgesetzten gesprochen und soweit alles geklärt.
Sollte ich später noch Fragen haben werde ich mich wieder an euch 
wenden.

MfG
Dominik

von Guido Körber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Bau einen USB Device Server.

Korrekt. Das ist der einzig sinnvolle Ratschlag hierfür.

Ich empfehle mal sich das USB-Protokoll genau anzusehen. Dann kommt man 
recht schnell an den Punkt zu erkennen, dass die wesentliche Komponente 
für eine wirklich transparente USB-Busverlängerung eine Zeitmaschine 
ist. Ohne diese ist es nicht möglich die Spezifikation einzuhalten.

Leider gibt es sehr viele Produkte ohne diese wichtige Komponente auf 
dem Markt und die führen dann immer wieder zu "interessanten" 
Support-Anfragen.

Wir sind seit etlichen Jahren an dem Punkt, dass wir bei Verwendung von 
USB-Verlängerungen oder "intelligenten" Bus-Umschaltern nur noch den 
Ratschlag geben diesen Elektroschrott aus dem System zu entfernen und 
uns ansonsten mit solchen Fragen in Ruhe zu lassen.

Also: Entweder eine Zeitmaschine entwickeln, oder einen USB-Server. 
USB-Busverlängerungen gibt es nicht, nur Mist der Ärger bereitet.

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]
  • [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.