Hallo, ich möchte hier eine Idee diskutieren, die mir gekommen ist und ich hoffe ja schon fast, dass ich nicht der erste bin und dass es das schon fertig gibt. Also folgende Situation: Ich möchte gerne eine Stück Hardware bauen mit folgenden Anforderungen: A1: Lauffähig unter Windows, Linux und Mac A2: In der zugehörigen Software soll der Benutzer NICHT auswählen oder raten müssen, an welchem COM-Port das Gerät hängt. A3: Der Benutzer soll nicht explizit irgendwo refresh drücken müssen, wenn man das Gerät ansteckt, sondern das Gerät soll auftauchen, wenn angesteckt wird. A4: Ich möchte mich mit Treibersignierung nicht beschäftigen müssen. A5: Möglichst treiberlos Bisher hab ich den FT232RL als USB-UART-Wandler benutzt, der kollidiert aber meiner Meinung nach erstmal mit der Anforderungen A2. Wenn ich den Chip nicht über einen virtuellen COM-Port ansprechen will, sondern über die D2XX-Library werde ich die Device-ID ändern müssen und muss den Treiber dann neu signieren. Nun kam die Idee auf, anstatt eines virtuellen COM-Ports auf einem Mikrocontroller ein virtuelles Ethernet-Device zu implementieren. Das hätte weitere Vorteile: - Alles über Userspace-Libs abzufrühstücken - Migrationspfad bei der Software, falls man später mal eine richtige Ethernetschnittstelle drann an das Gerät baut. Da kommt natürlich die Frage auf: Warum nicht gleich Ethernet? Ich hätte gerne, dass das Gerät direkt an einem Notebook betrieben und auch darüber mit Strom zu versorgen ist. PoE wäre da ne Option, aber ich hab noch kein Notebook gesehen, was PoE am Netzwerkport speist. Ich freue mich nun über eine Diskusion über die Vor- und Nachteile dieser Idee, möglicher Realisierungen sowie Prüfung meiner Annahmen über die anderen Lösungen.
Ethernet hat halt den Nachteil, dass da nix mit Plug&Play ist und man das gerät erst mal auf eine IP konfigurieren muss. Sicherlich kann man mit DHCP und uPNP einiges machen, aber das ist ziemlich aufwendig und nervig zu implementieren. USB ist schon das Mittel der Wahl für direktes Anstecken und loslegen. Wieso nicht LibUSB? Das ist auf Linux, Windows, Mac verfügbar und der Treiber für Windows x64 ist signiert, also kein Ärger damit. WinUSB ist zumindest unter Windows ein ähnliches Modell, der Treiber ist seit XP SP2 im Windows integriert. Und mit Windows 8 kann man einen OS descriptor in USB anlegen, dann erkennt Windows gleich, dass man WinUSB nutzen will, da brauchts nicht mal mehr die Inf Datei.
Meine Idee: Das Gerät simuliert einen USB Massenspeicher. Die Kommunikation läuft über spezielle Dateien. Man könnte damit auch gleich die Software zur Verfügung stellen. Das wäre echtes Plug&Play: einstecken, Software vom Gerät starten, läuft. Leider habe ich keine Ahnung ob und wie man das umsetzen kann. Wer weiß mehr?
Christian R. schrieb: > Wieso nicht LibUSB? Das ist auf Linux, Windows, Mac verfügbar und der > Treiber für Windows x64 ist signiert, also kein Ärger damit. Meiner Meinung nach geht die Treibersignierung kaputt, wenn ich die Device-ID ändere. Außerdem wüsste ich nicht, wie ich auf Mac und Windows Events bekomme, wenn ich ein Gerät eingesteckt hab, weil ich da ja keinen HAL-Daemon zur Verfügung habe. Oder irre ich hier? Wie sieht denn die Situation mit WinUSB bezüglich Events aus? Bei der Netzwerklösung habe ich schon an so Sachen wie Bonjour oder Universal Plug and Play gedacht, um solche Events zu bekommen. Zu der Idee mit dem Massenspeicher: Es gibt doch Geräte, wo man so ein Firmwareupdate macht? Als Nachteil der Lösung sehe ich, dass man das Gerät im Explorer sieht und das den Benutzer verwirren könnte.
Axel Jäger schrieb: > A1: Lauffähig unter Windows, Linux und Mac > A5: Möglichst treiberlos > A4: Ich möchte mich mit Treibersignierung nicht beschäftigen müssen. Also müssen auf der Plattform schon generic-Treiber vorhanden sein. > A2: In der zugehörigen Software soll der Benutzer NICHT auswählen oder > raten müssen, an welchem COM-Port das Gerät hängt. Jegliche Konfiguration fällt also aus. > A3: Der Benutzer soll nicht explizit irgendwo refresh drücken müssen, > wenn man das Gerät ansteckt, sondern das Gerät soll auftauchen, wenn > angesteckt wird. Mit anderen Worten: Du suchst eine Schnittstelle, mit der man ohne jegliche Useraktion Aktionen auf dem PC ausführen können soll. Praktisch für einen Virus ... aber nicht gewollt. Und Stromversorgung wolltest Du ja auch ... Die einzige Schnittstelle, die mir dazu einfällt, ist die für die Tastatur - egal ob USB, PS/2 oder DIN. Aber ob damit die Daten dort landen, wo sie hin sollen ... Gruß Jobst
Axel Jäger schrieb: > Also folgende Situation: Ich möchte gerne eine Stück Hardware bauen mit > folgenden Anforderungen: > A1: Lauffähig unter Windows, Linux und Mac > A2: In der zugehörigen Software soll der Benutzer NICHT auswählen oder > raten müssen, an welchem COM-Port das Gerät hängt. > A3: Der Benutzer soll nicht explizit irgendwo refresh drücken müssen, > wenn man das Gerät ansteckt, sondern das Gerät soll auftauchen, wenn > angesteckt wird. > A4: Ich möchte mich mit Treibersignierung nicht beschäftigen müssen. > A5: Möglichst treiberlos > > Bisher hab ich den FT232RL als USB-UART-Wandler benutzt, der kollidiert > aber meiner Meinung nach erstmal mit der Anforderungen A2. Wenn ich den > Chip nicht über einen virtuellen COM-Port ansprechen will, sondern über > die D2XX-Library werde ich die Device-ID ändern müssen und muss den > Treiber dann neu signieren. Du willst also ein HID Device bauen. Kein Problem. Jedes Betriebssystem kennt HID (A1), Dein Device ist durch VID/PID oder den Device String eineindeutig identifizierbar (A2), das Gerät wird ohne Zutun automatisch erkannt (A3), Du brauchst Dich mit Treibersignierung nicht beschäftigen (A4), und Du musst keine Treiber mitliefern (A5). > Da kommt natürlich die Frage auf: Warum nicht gleich Ethernet? Ich hätte > gerne, dass das Gerät direkt an einem Notebook betrieben und auch > darüber mit Strom zu versorgen ist. PoE wäre da ne Option, aber ich hab > noch kein Notebook gesehen, was PoE am Netzwerkport speist. Das gibts auch nicht. Baue einen Akku ein, den Du an einem Netzteil wieder aufladen kannst. Das ist die sinnvollste Lösung und wird auch so gemacht (UMTS/WLAN Router z.B.)
Axel Jäger schrieb: > A2: In der zugehörigen Software soll der Benutzer NICHT auswählen oder > raten müssen, an welchem COM-Port das Gerät hängt. Mache ich immer so das das PC Tool an alle verfügbaren COM-Ports einen "Info-Befehl" oder "Ping" schickt. Antwortet das Gerät auf diesen speziellen Befehl mit der richtigen Antwort, ist der richtige Com-Port gefunden.
Jörg S. schrieb: > Mache ich immer so das das PC Tool an alle verfügbaren COM-Ports einen > "Info-Befehl" oder "Ping" schickt. Antwortet das Gerät auf diesen > speziellen Befehl mit der richtigen Antwort, ist der richtige Com-Port > gefunden. den Fehler haben schon andere gemacht (MS) und wenn an dem COM-Port z.b. eine USV angeschlosse ist damit irgendwelcher Aktionen ausgeführt. Wenn überhaupt sollte da gerät etwas senden, und bei abfragen der Com-Port lauscht man nur.
Jobst M. schrieb: > Mit anderen Worten: Du suchst eine Schnittstelle, mit der man ohne > jegliche Useraktion Aktionen auf dem PC ausführen können soll. Praktisch > für einen Virus ... aber nicht gewollt. Es ist ausreichend, wenn mein Programm schon läuft und dann meldet, dass jetzt die Hardware angeschlossen wurde. Also das Programm muss nicht durch das Anstecken gestartet werden. Frank K. schrieb: > Du willst also ein HID Device bauen Hab ich mir auch schon überlegt. HID wäre eine Möglichkeit, aber da sind die Datenraten meines Wissens nach nicht so hoch, auch wenn es dazu bisher keine Anforderung gibt.
Axel Jäger schrieb: > Meiner Meinung nach geht die Treibersignierung kaputt, wenn ich die > Device-ID ändere. Außerdem wüsste ich nicht, wie ich auf Mac und Windows > Events bekomme, wenn ich ein Gerät eingesteckt hab, weil ich da ja > keinen HAL-Daemon zur Verfügung habe. Oder irre ich hier? Wie sieht denn > die Situation mit WinUSB bezüglich Events aus? Die Signierung geht weder bei WinUSB noch LibUSB kaputt. WinUSB ist immer signiert, LibUSB nutzt den spziellen Modus, die Signatur in die sys direkt einzubauen, da ist die VID/PID egal. Events gibts nicht direkt über LibUSB/WinUSB, sondern im Falle von Windows über die WinAPI. Unter Mac und Linux gibts garantiert ebenfalls Systemfunktionen, die dir ein neues Gerät melden. Einen 100% generischen Code wirst du eh nicht schreiben können. HID wäre aber bei niedrigen Datenraten wirklich noch eine Überlegung.
Axel Jäger schrieb: > Frank K. schrieb: >> Du willst also ein HID Device bauen > Hab ich mir auch schon überlegt. HID wäre eine Möglichkeit, aber da sind > die Datenraten meines Wissens nach nicht so hoch, auch wenn es dazu > bisher keine Anforderung gibt. Wie hoch muss denn die Datenrate sein? fchk
Zur Datenrate: Aktuelles Zielprojekt ist ein DMX-Interface. Das hab ich schon sowohl mit FTDI, als auch als USB-HID-Device. Ich würde aber gerne diese Lösung da mit USB-Ethernet evaluieren, um sie für zukünftige Projekte zur Verfügung zu haben, wenn sich denn hier in der Diskussion rausstellt, dass das sinnvoll ist.
Wäre es nicht zweckmäßiger, dann gleich ein Artnet-Gerät zu bauen? Dann hast du alle Treiberprobleme los und Artnet beherrschen die meisten Programme für Lichtsteuerungen eh. Und von Artnet auf DMX umsetzen ist keine große Sache mehr, das haben andere auch schon gemacht, z.b. mit ATmega644 und dem ENC-Ethernet-Chip. _.-=: MFG :=-._
Vollkommen richtig, nur fehlt mir dann noch die Stromversorgung und deswegen hatte ich mit USB-Ethernet geliebäugelt. Was braucht man denn so technisch für USB-Ethernet? Gibts irgendwas, was man an einen AVR ranstecken kann? Vermutlich gibts Haufen ARMs, die das drinn haben?
Axel Jäger schrieb: > Zur Datenrate: > Aktuelles Zielprojekt ist ein DMX-Interface. Das hab ich schon sowohl > mit FTDI, als auch als USB-HID-Device. Ich würde aber gerne diese Lösung > da mit USB-Ethernet evaluieren, um sie für zukünftige Projekte zur > Verfügung zu haben, wenn sich denn hier in der Diskussion rausstellt, > dass das sinnvoll ist. Warum schreibst Du das nicht gleich? Damit hättest Du die Diskussion früher in eine sinnvolle Richtung gelenkt. Bei DMX sollte HID kein Problem sein. Als zweites USB-Standardprotokoll gibts CDC, das Microsoft aber ein wenig vermurkst hat, weil Windows da ein .inf-File sehen will (der usbser.sys ist aber bei Windows dabei). Dafür ersetzt Du den FTDI einfach durch einen Microchip MCP2200, der CDC und HID macht. USB Ethernet ist mit einiger Sicherheit nicht treiberlos über Betriebssystemgrenzen realisierbar, d.h. Du brauchst (a) einen Treiber und musst (b) das Ethernet konfigurieren bzw einen DHCP-Server bereitstellen und hoffen, dass der nicht mit der vorhandenen Netzwerkinfrastruktur kollidiert. Das ist irgendwie Murks. Dann lieber richtiges Ethernet. Dafür brauchst Du einen Microchip PIC18F67J60 (der hat gleich Ethernet MAC+PHY und den UART für RS485 bzw DMX drin, Du brauchst also nur noch die Ethernet-Buchse und etwas Kleinzeug anzuschließen), einen RS485-Transceiver (am Besten sowas wie TI SN75HVD08/SN65HVD08 mit 3.3V Versorgungsspannung, weil der PIC auch mit 3.3V arbeitet), und die Stromversorgung (z.B. LM1117-3.3V). Obendrein ist das Interface dank des in der RJ45-Buchse verbauten Übertragers galvanisch isoliert, sofern Du UTP-Kabel nimmst, d.h. Masseschleifen über Deinen PC können nicht auftreten. fchk
Frank K. schrieb: > Warum schreibst Du das nicht gleich? Damit hättest Du die Diskussion > früher in eine sinnvolle Richtung gelenkt. Weil ich erstmal diskutieren wollte, ob es außer für Arnet und DMX, wo ein Ethernet-Device absolut naheliegend ist, sinnvoll ist, diese Deviceklasse zu benutzen. Das wird ja nicht das letzte Gerät sein, was ich baue. Im Moment hab ich den Eindruck, die Standardlösung ist der Virtual COM-Port und der geht mir sowohl bei der DMX-Geschichte, als auch bei anderen Geräten auf die Nerven. Hier in dem Thread sind so schon einige interessante Informationen zusammen gekommen. Die Sache mit Ethernet konfigurieren sehe ich nicht so kritisch, mit Universal Plug & Play/Bonjour und APIPA-Adressen geht da schon einiges denke ich.
Axel Jäger schrieb: > Die Sache mit Ethernet konfigurieren sehe ich nicht so kritisch, mit > Universal Plug & Play/Bonjour und APIPA-Adressen geht da schon einiges > denke ich. und was mit mit installierten Firewalls und doppelte IPs bzw netzen?
Firewall hab ich bisher nicht betrachtet, doppelte IP sollte bei APIPA-Adressen nicht vorkommen.
Axel Jäger schrieb: > doppelte IP sollte bei APIPA-Adressen nicht vorkommen. aber dann hast du ein doppelltes netz und das BS weiss nicht mehr wohin es packete schicken soll wenn das echte netzwerk die gleichen adressen verwendet.
Axel Jäger schrieb: > Frank K. schrieb: > Im Moment hab ich den Eindruck, die Standardlösung ist der > Virtual COM-Port und der geht mir sowohl bei der DMX-Geschichte, als > auch bei anderen Geräten auf die Nerven. Das muss nicht sein. Schau Dir unter Windows die SETUPAPI an. Damit kannst Du durch den USB Device Tree durchiterieren und Dein Gerät finden, entweder über VID/PID, oder bei Verwendung einer Standard VID/PID unter Zuhilfenahme der Seriennummer und der Manufacturer/Product Device Deskiptoren (die kannst Du beliebig ändern, ohne dass das .inf nicht mehr funktioniert und neu signiert werden muss). Wenn Du im SETUPAPI Dein Gerät gefunden hast, bekommst Du auch raus, auf welchem COM-Port es liegt. Das steht irgendwo in der MSDN Doku drin, hab ich schon mal gesehen. Und um das Anstecken/abstecken zu registrieren, musst Du die WM_DEVICECHANGE Window Messages auswerten, die Dein Main Window bekommt. fchk
Peter II schrieb: > Jörg S. schrieb: >> Mache ich immer so das das PC Tool an alle verfügbaren COM-Ports einen >> "Info-Befehl" oder "Ping" schickt. Antwortet das Gerät auf diesen >> speziellen Befehl mit der richtigen Antwort, ist der richtige Com-Port >> gefunden. > den Fehler haben schon andere gemacht (MS) und wenn an dem COM-Port z.b. > eine USV angeschlosse ist damit irgendwelcher Aktionen ausgeführt. Das spricht wohl eher gegen die Programmierer der USV die nach erhalt irgendwelcher Daten irgendwas macht :)
Jörg S. schrieb: > Peter II schrieb: >> Jörg S. schrieb: >>> Mache ich immer so das das PC Tool an alle verfügbaren COM-Ports einen >>> "Info-Befehl" oder "Ping" schickt. Antwortet das Gerät auf diesen >>> speziellen Befehl mit der richtigen Antwort, ist der richtige Com-Port >>> gefunden. >> den Fehler haben schon andere gemacht (MS) und wenn an dem COM-Port z.b. >> eine USV angeschlosse ist damit irgendwelcher Aktionen ausgeführt. > Das spricht wohl eher gegen die Programmierer der USV die nach erhalt > irgendwelcher Daten irgendwas macht :) Hm, dann kannst du die Schnittstelle auch gleich weglassen, wenn sie auf keine Daten die darüber kommen reagiert...
Wieso auf keine Daten? Auf IHRE Befehle kann die USV ja reagieren.
Axel Jäger schrieb: > Außerdem wüsste ich nicht, wie ich auf Mac und Windows > Events bekomme, wenn ich ein Gerät eingesteckt hab, weil ich da ja > keinen HAL-Daemon zur Verfügung habe. Bei beiden Systemen können Programme über das entsprechende API Callbacks einrichten, über die Benachrichtigungen über derartige Ereignisse versendet werden. Wie soll es auch sonst funktionieren? Denkst Du, unter Mac OS und Windows müssen alle interessierten Parteien ständig den USB-Port pollen, um über dessen Zustand auf dem Laufenden zu bleiben? Christian
Jörg S. schrieb: > Wieso auf keine Daten? Auf IHRE Befehle kann die USV ja reagieren. Und, wenn die zu "Testzwecken" gesendeten Daten zufälligerweise aus Sicht der USV legal sind? Alle Schnittstellen aufmachen und was 'rausblasen macht man nicht. Punkt.
Rufus Τ. Firefly schrieb: > Jörg S. schrieb: >> Wieso auf keine Daten? Auf IHRE Befehle kann die USV ja reagieren. > > Und, wenn die zu "Testzwecken" gesendeten Daten zufälligerweise aus > Sicht der USV legal sind? > > Alle Schnittstellen aufmachen und was 'rausblasen macht man nicht. > Punkt. genau! Es gibt andere Möglichkeiten! Ausrufezeichen!
Christian Gudrian schrieb: > Denkst Du, unter Mac OS und > Windows müssen alle interessierten Parteien ständig den USB-Port pollen, > um über dessen Zustand auf dem Laufenden zu bleiben? Ich weis, dass bei MacOS die Situation überaus komfortabel ist und man da über DeviceKit solche Events bekommt. Wie die entsprechende API unter Windows heißt, wusste ich bisher nicht, aber ist ja im Rahmen dieser Diskusion rausgekommen. Ich wundere mich aber ein bisschen, dass libusb zwar den Zugriff auf USB-Geräte abstrahiert, nicht aber diese HotPlug-Events, da es meiner Meinung nach keinen guten Grund gibt, das nicht zu tun. Jede Anwendung, die libusb benutzt, wird doch auf solche Events reagieren können wollen? Zu der Diskusion mit der USV: Wenn man es sauber machen würde, würde man die Datenpakete auf der seriellen Schnittstelle kryptografisch signieren und so sicherstellen, dass zufällig gesendete Daten nicht interpretiert werden.
Rufus Τ. Firefly schrieb: > Und, wenn die zu "Testzwecken" gesendeten Daten zufälligerweise aus > Sicht der USV legal sind? Genauso zufällig kann auch ein UDP/TCP Paket bei Ethernet "missverstanden" werden. Immerhin sind etliche Ports doppelt und dreifach belegt. Oder Übertragungen im 2,4GHz Band, da senden alle quer durcheinander. Oder der User weiß nicht was am welchen COM-Port hängt und stellt zufällig den Port der USV ein und sendet quatsch. > Alle Schnittstellen aufmachen und was 'rausblasen macht man nicht. Bei einem komerziellen Gerät würde ich auch erst was anderes versuchen, aber privat sehe ich kein Problem.
> > Alle Schnittstellen aufmachen und was 'rausblasen macht man nicht. > Bei einem komerziellen Gerät würde ich auch erst was anderes versuchen, > aber privat sehe ich kein Problem. warum sollte man es bei einem Privaten gerät nicht auch richtig machen? Wenn das gerät sich selber meldet und in ping sendet dann ist das der gleich aufwand und es ist gleich richtig.
Axel Jäger schrieb: > Jede Anwendung, die libusb benutzt, wird doch auf solche > Events reagieren können wollen? Die meisten Anwendungen startet man nach dem Anschließen des Geräts, oder habene einen "Refresh" Button den man nach Anstöpseln betätigen muss...
... weil die Entwickler keinen Plan haben, wie man es richtig macht. fchk
Peter II schrieb: > Wenn das gerät sich selber meldet und in ping sendet dann ist das der > gleich aufwand und es ist gleich richtig. Das ist genauso blöd. Ein Gerät hat nicht einfach so loszuquasseln. Dann wird gerne mal eine serielle Maus erkannt. Es ist doch kein Problem anhand der Registry den richtigen COM Port zu finden.
Axel Jäger schrieb: > Ich weis, dass bei MacOS die Situation überaus komfortabel ist und man > da über DeviceKit solche Events bekommt. Wie die entsprechende API unter > Windows heißt, wusste ich bisher nicht, aber ist ja im Rahmen dieser > Diskusion rausgekommen. Ich wundere mich aber ein bisschen, dass libusb > zwar den Zugriff auf USB-Geräte abstrahiert, nicht aber diese > HotPlug-Events, da es meiner Meinung nach keinen guten Grund gibt, das > nicht zu tun. Jede Anwendung, die libusb benutzt, wird doch auf solche > Events reagieren können wollen? Seit wann sind Events über neue Geräte spezifisch nur für USB ? Sind sie nicht also hat das nichts mit einer Lib zu tun die nur USB macht.
tz schrieb: > Seit wann sind Events über neue Geräte spezifisch nur für USB ? Sind sie > nicht also hat das nichts mit einer Lib zu tun die nur USB macht. Nun der Sinn von von Cross-Plattform-Abstraktionslibraries ist ja, den Anteil von plattformspezifischem Code zu minimieren. Wenn ich mich also ohnehin mit dem nativen Code dererlei APIs beschäftigen muss, fällt die Rechtfertigung für libusb weg. Ich wünsche mir mit so einer lib ein Rundum-Sorglos-Paket für einen gewissen Usecase, nämlich mit USB-Geräten schaffen. Ich wüsste aber grad auch nicht, was man an einem modernen PC neben USB großartig an anderen Hotplug-Events bekommen könnte.
USB Sticks oder Express Cards benutzt du nicht? Auch die sind voll Hotplug fähig. Übrigens gibts die SetupAPI Events nicht nur, wenn ein Hotplug Gerät angestekt/abgezogen wird, sondern auch wenn im Gerätemanager manuell nach neuen Geräten gesucht und diese gefunden wurden. Außerdem für uPNP Geräte usw. das ist also keineswegs auf USB beschränkt. Es ist aus der Sicht der User-Lib schlicht nicht die Aufgabe. Solche Aufgaben sind system-spezifisch und demnach in den Systemfunktionen des jeweiligen OS zu finden. Den Traum von OS-unabhängigem Code träumen viele, der platzt spätestens beim Zugriff auf Hwrdware.
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.