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
> [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
da wirst Du wohl um einen LWL - Ethernetumsetzer wohl kaum drum rum kommen.
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.
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.
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
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.
> 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.
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).
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.
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.
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.
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.
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.
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.
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".
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.
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?
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?
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.
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.
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...
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...
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.
> 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.
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
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.
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...
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.
> 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.
> 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.
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
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.
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
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 ^^
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.
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
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.
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.
USB server https://www.wut.de/e-53642-w3-dade-000.php http://www.silexeurope.com/de/home/produkte/usb-device-server3/uebersicht.html ... Und 2x media converter https://www.netzwerkartikel.de/netzwerktechnik-shop/RJ45-to-SC-Managed-Fast-Ethernet-Media-Converter-Single-Mode-Fiber-20km.htm?gclid=Cj0KCQjw8vnMBRDgARIsACm_BhItSPCW5NnePQqXqfh2XBKq0vY1ESQBpmS4Ur2reGK35ZY6tVXio_gaAg0GEALw_wcB usw. Oder gleich http://www.klarsicht-it.de/pc-server/kabel-u.-adapter/usb-kabel-u.-adapter/usb-adapter/99926/lindy-usb-2.0-mm-lwl/fibre-optic-extender-usb-erweiterung-bis-zu-200-m?sPartner=google&gclid=Cj0KCQjw8vnMBRDgARIsACm_BhKmh04nED1j60bmnyB2GEANWN5cVfZ_qIN9lFMH4_ZfdEHz1xX9yQIaAsrSEALw_wcB oder http://www.lindy.de/USB-3-1-3-0-LWL-Fibre-Optic-Extender-400m.htm?websale8=ld0101&pi=42707
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
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
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
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
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...)
Wie läuft das denn bei I2C, da ist ja auch (mindestens) die Datenleitung bidirektional und es gibt galvanische Trenner mit Optokopplern.
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.
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.
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.
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...
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 ...
> 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.
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!
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.
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.
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.
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?
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
Ü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.
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.
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.
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.
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.
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?
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?
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.
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.
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
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 User
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.
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.
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.
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.
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
>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.
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.
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?
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)
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
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
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?
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.
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.
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.
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
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"
Ihr braucht nicht weiter auf dem Armen herumzuhacken, die Tragweite seiner Idee dürfte ihm mittlerweile klargeworden sein.
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.
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
Weinbauer schrieb: > was studieren die Jungs eigentlich?? Gar nichts, das haben wir aber schon geklärt.
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
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.
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.