Forum: Mikrocontroller und Digitale Elektronik µC, der sich als virtueller COM port ausgibt?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Borislav B. (boris_b)


Lesenswert?

Hallo,
ich würde gerne eine kleine Schaltung bauen, die sich per USB an den 
Rechner anschließen lässt. Dort soll sie als virtueller COM Port im 
System auftauchen, so dass sie mit einer Desktop-Anwendung kommunizieren 
kann.

Was für Möglichkeiten gibt es da?
 - Ein kleiner AVR (Tiny) mit einem FTDI Chip dazu?
 - Ein µC, der sowas schon eingebaut hat (gibt es das?)?
 - Ein AVR, auf den V-USB geflasht wird?
 - Ein Arduino?
 - ?

Besonders schön wäre es, wenn das ganze OHNE SPEZIELLEN TREIBER ginge. 
Also quasi echtes Plug & Play ;-)
(was bietet Windows/OSX/Linux da von Haus aus an?)

Danke für eure Tipps!

von 4toTakoe (Gast)


Lesenswert?

Boris P. schrieb:
> - Ein µC, der sowas schon eingebaut hat (gibt es das?)?

STM32 mit USB OTG ... die VCP implementation ist sehr einfach und gibt 
es zu hauf als Beispiele

von Oliver R. (orb)


Lesenswert?

Boris P. schrieb:
> - Ein µC, der sowas schon eingebaut hat (gibt es das?)?

Wenn Du bei AVR bleiben willst die MEGAxxUx oder die AT90USBxxxx, PICs 
gibt es da auch einige, eigenlich hat inzwischen jeder bekannte Anbieter 
USB mit im Angebot.
Wenn es mal schnell gehen soll nehm ich nen Arduino Micro, MEGA32U4, 
6Pin-ISP, MicroUSB-Buchse und in Fernost fertig für unter 5€ zu 
bekommen.

von Daniel F. (df311)


Lesenswert?

Boris P. schrieb:
> Was für Möglichkeiten gibt es da?

jeder x-beliebige controller mit einem FT232

Boris P. schrieb:
> OHNE SPEZIELLEN TREIBER ginge.
> (was bietet Windows/OSX/Linux da von Haus aus an?)

also unter windows und linux hatte ich (soweit ich mich erinnern kann) 
mit dem ft232 keine probleme (x86 und x64).

von Borislav B. (boris_b)


Lesenswert?

4toTakoe schrieb:
> STM32 mit USB OTG ... die VCP implementation ist sehr einfach und gibt
> es zu hauf als Beispiele

Oliver R. schrieb:
> Wenn es mal schnell gehen soll nehm ich nen Arduino Micro, MEGA32U4,
> 6Pin-ISP, MicroUSB-Buchse und in Fernost fertig für unter 5€ zu
> bekommen.

Danke so weit!
Wie sieht es denn da mit den Treibern aus? Erkennst Windows die ohne 
Weiteres? Oder braucht es einen speziellen Atmel/Arduino USB/Seriell 
Treiber?

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Einen Treiber braucht es immer, zumindest die INF Datei damit Windows 
weiß dass die PID/VID als USB/Seriell Wandler gilt. Die Hersteller 
liefern zu den VCP Demos den natürlich mit.

Wenn man die Daten nur intern im µC weiter verwendet dann ist die 
eingestellte Baudrate unwichtig, der Datenaustausch erfolgt immer mit 
der maximal möglichen USB Geschwindigkeit.

: Bearbeitet durch User
von Borislav B. (boris_b)


Lesenswert?

Markus Müller schrieb:
> Einen Treiber braucht es immer, zumindest die INF Datei damit Windows
> weiß dass die PID/VID als USB/Seriell Wandler gilt. Die Hersteller
> liefern zu den VCP Demos den natürlich mit.

Klar, ohne Treiber geht nichts. Aber es könnte ja sein, dass Windows die 
Treiber der gängigsten Chips (FTDI, Prolific etc.) schon an Bord hat 
(bzw. diese automatisch aus dem Netz nachladen kann).

von Mr. K. (kaktus-)


Lesenswert?

Ich empfehle Arduino Nano 3.0

alles drauf was man braucht und sehr preiswert

http://www.ebay.de/itm/251540558891?_trksid=p2055119.m1438.l2648&ssPageName=STRK%3AMEBIDX%3AIT

Wenns aber der FTDI Chip sein soll, dann wirds etwas teurer

http://www.ebay.de/itm/251494917400?_trksid=p2055119.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

: Bearbeitet durch User
von Borislav B. (boris_b)


Lesenswert?

Mr. Kaktus schrieb:
> Ich empfehle Arduino Nano 3.0
> alles drauf was man braucht und sehr preiswert
> Ebay-Artikel Nr. 251540558891

Boah, ist der günstig! Für das Geld lohnt es sich ja nicht mal die Maus 
über das Eagle-Icon auf meinem Desktop zu bewegen ;-)

Von diesem CH340 USB Chip höre ich allerdings zum ersten mal...

von GB (Gast)


Lesenswert?

TUSB3410

von GuidoL (Gast)


Lesenswert?

Boris P. schrieb:
> Danke für eure Tipps!

Wenn Dein Microcontroller einen seriellen TTL-Port hat, koenntest Du ihn 
einfach per Bluetooth anbinden mit
http://www.exp-tech.de/Shields/Wireless/Bluetooth/Bluefruit-EZ-Link-Bluetooth-Serial-Link-Arduino-Programmer.html

oder direkt einen FTDI-USB-seriellen Port nehmen.

Der USB-Anschluss muss ja nicht direkt vom Microcontroller kommen, so 
bist Du unabhaeniger.

von Axel S. (a-za-z0-9)


Lesenswert?

Boris P. schrieb:
>> Ebay-Artikel Nr. 251540558891
>
> Boah, ist der günstig!

Angesichts von "keine Lieferung nach Deutschland" ist das ziemlich egal.

von Stephan B. (matrixstorm)


Lesenswert?

Hallo.

Wie waere es mit http://matrixstorm.com/avr/avrstick/.
Im Speziellen mit der Beispielfirmware: 
http://matrixstorm.com/avr/avrstick/examples/USBtoUARTs/

Bzw. zum (sogar online!) selbst modifizieren: 
http://matrixstorm.com/avr/avrstick/#bideavr

MfG


Nachtrag:
Boris P. schrieb:
> Dort soll sie als virtueller COM Port im
> System auftauchen,


In Windows wird fuer CDC eine INF Datei benoetigt. Linux geht vollig 
automatisch.

: Bearbeitet durch User
von GB (Gast)


Lesenswert?

Der LPC11U2x und 3x beherrschen von Haus aus CDC

von Frank M. (frank_m35)


Lesenswert?

Wenn bei USB du keine extra Treiber verwenden willst, dann darfst du 
keinen virtuellen COM Port emulieren wollen, stattdessen kannst du das 
HID Protokoll verwenden, für das keine extra Treiber benötigt werden und 
über das auch Daten gesendet werden können, nur halt ein bisschen 
anders:
http://www.engscope.com/pic24-tutorial/14-5-usb-debugger-protocol-design/

von Lars R. (lrs)


Lesenswert?

Stephan B. schrieb:
> Hallo.
>
> Wie waere es mit http://matrixstorm.com/avr/avrstick/.
> Im Speziellen mit der Beispielfirmware:
> http://matrixstorm.com/avr/avrstick/examples/USBtoUARTs/
>
> Bzw. zum (sogar online!) selbst modifizieren:
> http://matrixstorm.com/avr/avrstick/#bideavr

Sehr interessant, aber:
http://matrixstorm.com/avr/bideavr/simple.html

Firmware.bin liefert bei mir 0 Bytes.

von matrixstorm (Gast)


Lesenswert?

Lars R. schrieb:
> Firmware.bin liefert bei mir 0 Bytes.

Ja, das ist normal so.
Die Firmware wird dem Browser als Stream gesendet - die Groesse kennt 
der Browser als nicht im Vorraus.

Downloade einfach mal die Datei und gugg dann rein - es sollte alles OK 
sein.

MfG

von matrixstorm (Gast)


Lesenswert?

matrixstorm schrieb:
> und gugg

Jaja, sorry  -  </slangmode>

von Lars R. (lrs)


Lesenswert?

0 Bytes auf der Platte

von Stephan B. (matrixstorm)


Lesenswert?

Lars R. schrieb:
> 0 Bytes auf der Platte

Das ist seltsam. Welcher Browser?

Bei mir (Firefox):
1
stephan@thinkrat /tmp $ ls -lsa FIRMWARE.BIN 
2
8 -rw-r----- 1 stephan stephan 6574 Aug 29 14:15 FIRMWARE.BIN
3
stephan@thinkrat /tmp $ hexdump -C FIRMWARE.BIN 
4
00000000  0c 94 a6 01 0c 94 b2 01  0c 94 b2 01 0c 94 b2 01  |................|
5
00000010  0c 94 b2 01 0c 94 b2 01  0c 94 b2 01 0c 94 b2 01  |................|
6
*
7
000001f0  0c 94 b2 01 0c 94 b2 01  0c 94 b2 01 6e 61 6e 00  |............nan.|
8
00000200  69 6e 66 00 63 64 69 6e  6f 70 73 75 78 58 5b 65  |inf.cdinopsuxX[e|
9
[...]

: Bearbeitet durch User
von Stephan B. (matrixstorm)


Lesenswert?

Ich hatte eigentlich viele Browser (unter Windows XP) getestet:

Firefox
Opera
Chrome
Maxthon

Internet Explorer
Safari

Mit den letzteren beiden hat es NICHT funktioniert, wohl aber wegen den 
hoffnunglos veralteten Versionen fuer XP.
Zudem war nie der Fehler, dass 0-Byte ankommen. Stattdessen hat sich der 
Browser am Editor aufgehangen, weil vermutlich die JS-Engine zu alt war.

MfG

: Bearbeitet durch User
von Lars R. (lrs)


Lesenswert?

Firefox 31. Windows7.
Firefox 30. Ubuntu 14.
Compile -> OK
Firmware.bin -> OK -> Fenster geht auf -> speichern -> 0 Byte.

: Bearbeitet durch User
von matrixstorm (Gast)


Lesenswert?

Ich werde es testen, hoffentlich rausfinden was da los ist und dann 
fixen.

Danke dir.

von Frank K. (fchk)


Lesenswert?

Boris P. schrieb:
> Markus Müller schrieb:
>> Einen Treiber braucht es immer, zumindest die INF Datei damit Windows
>> weiß dass die PID/VID als USB/Seriell Wandler gilt. Die Hersteller
>> liefern zu den VCP Demos den natürlich mit.
>
> Klar, ohne Treiber geht nichts. Aber es könnte ja sein, dass Windows die
> Treiber der gängigsten Chips (FTDI, Prolific etc.) schon an Bord hat
> (bzw. diese automatisch aus dem Netz nachladen kann).

Alle Betriebssysteme haben Treiber für die Standard USB Deviceklassen 
dabei: Hubs, HID, Printer, Mass Storage, AVC, CDC. Letzteres ist das 
Äquivalent für eine serielle Schnittstelle. Der Microchip MCP2200 ist 
ein USB-Seriell-Wandler, der ein CDC und HID Device implementiert und 
damit ohne jegliche proprietären Devicetreiber auskommt. Das Teil kannst 
Du an einen Mac oder einen OpenBSD Server anklemmen, und es wird sofort 
funktionieren. Nur Windows will ein INF-File sehen (aber auch nur das, 
der Treiber ist bei jedem Windows ab W2K mit dabei, und ab XPSP3 
funktioniert er auch richtig, Microsoft halt).

Der MCP2200 ist ein vorprogrammierter PIC18F14K50. Du kannst Dir aber 
auch einen leeren PIC kaufen und die USB CDC Demoapplikation aus den 
Microchip Application Libraries darauf programmieren, wenn Du etwas 
ändern möchtest.

Eine Desktop-Anwendung kann auch mit einem Custom HID Device 
kommunizieren. Das ist noch idiotensicherer als über CDC, denn dann muss 
der User keinen COM-Port auswählen und braucht kein INF-File anzugeben. 
Einfach anstecken, und der Rest geht von alleine. Auch dafür gibts 
Beispiele in den Microchip Application Libraries. Nachteil von HID 
gegenüber CDC: eine etwas geringere maximale Datentransferrate. Für 
große Datenmengen (sprich: Megabytes) ist HID nicht gedacht.

fchk

fchk

von W.S. (Gast)


Lesenswert?

Boris P. schrieb:
> Was für Möglichkeiten gibt es da?

Nimm einen LPC13xx oder 17xx oder 40xx oder sonst einen, der ne 
USB-Device-Schnittstelle eingebaut hat. Ich hatte hier in diesem Forum 
schon mal ne Quelle für sowas als virtueller COM Port gepostet, suche 
einfach mal danach.

Die USB-Cores von NXP sind ganz OK und auch nicht allzu schwer zu 
programmieren - wenn man mal von den falschen Stellen in den Manuals zu 
älteren LPC's absieht. Die USB-Cores von ST hingegen sind stellenweise 
die blanke Krätze, insbesondere die Statusänderungen der SIE, die man 
nur per XOR hinkriegt.

Tja, eigentlich ist das alles kein schwieriges Thema, es sind nur die 
Infos dazu sehr zerstreut.



Frank K. schrieb:
> Eine Desktop-Anwendung kann auch mit einem Custom HID Device
> kommunizieren...

.. und das ist OBERBOCKMIST.
Die HID-Klasse sollte man besser den echten HID-Geräten überlassen. Jede 
sonstige Verwendung ist eigentlich ein idiotischer Mißbrauch, denn man 
hat damit eben KEIN allgemein benutzbares Gerät, sondern eines, was 
ursprünglich NUR zum Kommunizieren mit dem OS vorgesehen ist.

Also: ein virtueller COM-Port ist da eine wesentlich sauberere Sache. Da 
hat man ein allgemein benutzbares Gerät, das von jedem Programm benutzt 
werden kann, welches zu irgendeiner Kommunilkation fähig ist.

W.S.

von bluppdidupp (Gast)


Lesenswert?


von Karl (Gast)


Lesenswert?

Hallo,

ich verwende u.a. ein atmega32u2 als USB-CDC - Uart (TTL) Wandler.

http://www.ehajo.de/baus%C3%A4tze/smd-baus%C3%A4tz...

Die Lufa CDC kann man hier finden:

http://www.fourwalledcubicle.com/LUFA.php

von Frank K. (fchk)


Lesenswert?

W.S. schrieb:

> Frank K. schrieb:
>> Eine Desktop-Anwendung kann auch mit einem Custom HID Device
>> kommunizieren...
>
> .. und das ist OBERBOCKMIST.
> Die HID-Klasse sollte man besser den echten HID-Geräten überlassen. Jede
> sonstige Verwendung ist eigentlich ein idiotischer Mißbrauch, denn man
> hat damit eben KEIN allgemein benutzbares Gerät, sondern eines, was
> ursprünglich NUR zum Kommunizieren mit dem OS vorgesehen ist.

... und diese Behauptung ist falsch. Das OS kümmert sich nur um HID 
Devices, mit denen es etwas anfangen kann: Keyboard, Maus, Touch, 
Gamepad,... Custom HIDs werden vom Betriebssystem selber nicht angefasst 
- außer dass man die Betriebssystemdienste wie HID.DLL und SETUPAPI.DLL 
für die Kommunikation nutzen kann.

Die Nutzung von Custom HID ist (a) gängige Praxis und (b) durch den USB 
Standard abgedeckt und (c) bei allen Betriebssystemen problemlos 
möglich.

Was Dich dabei vielleicht stört, ist, dass ein Custom HID nur mit der 
zugehörigen Software verwendet werden kann und nicht mit irgend einem 
Terminalprogramm oder Perl-Skript. Das ist mitunter beabsichtigt, weil 
es das ganze idiotensicherer macht und ein 08/15-User letztendlich nicht 
irgendwo rumfummeln kann, wo er nichts zu suchen hat. Das spart 
letztendlich Supportkosten.

> Also: ein virtueller COM-Port ist da eine wesentlich sauberere Sache. Da
> hat man ein allgemein benutzbares Gerät, das von jedem Programm benutzt
> werden kann, welches zu irgendeiner Kommunilkation fähig ist.

...vorausgesetzt, das Kommunikationsprotokoll ist bekannt, dokumentiert 
und am Besten noch standardisiert - wie bei Modems (auch 
GSM/UMTS-Modems).

von W.S. (Gast)


Lesenswert?

Frank K. schrieb:
> Was Dich dabei vielleicht stört, ist, dass ein Custom HID nur mit der
> zugehörigen Software verwendet werden kann und nicht mit irgend einem
> Terminalprogramm oder Perl-Skript.

Ja, genau DAS ist es. Du hast es auf den Punkt gebracht.

Kein HID-Eigenbau ist in der Lage, mit irgend einer üblichen 
Standard-Anwendung verwendet zu werden - ein virtueller COM-Port 
hingegen sehr wohl. Deshalb ist "Die Nutzung von Custom HID ist (a) 
gängige Praxis und (b) durch den USB Standard abgedeckt und (c) bei 
allen Betriebssystemen problemlos
möglich" und d) eben Oberbockmist, man könnte auch Pfusch dazu sagen.

Du kennst gewiss den Spruch von den Milliarden Fliegen...

W.S.

von Stefan F. (Gast)


Lesenswert?

> Aber es könnte ja sein, dass Windows die Treiber der
> gängigsten Chips (FTDI, Prolific etc.) schon an Bord hat.

Leider nicht. Unter Windows kommst Du nicht drum herum, eine 
Treiberinstallation durchzuführen.

Linux enthält hingegen Treiber für alle gängigen Chips.

Weiss jemand, wie Mac OS sich in dieser Hinsicht verhält?

von Frank K. (fchk)


Lesenswert?

Stefan us schrieb:
>> Aber es könnte ja sein, dass Windows die Treiber der
>> gängigsten Chips (FTDI, Prolific etc.) schon an Bord hat.
>
> Leider nicht. Unter Windows kommst Du nicht drum herum, eine
> Treiberinstallation durchzuführen.
>
> Linux enthält hingegen Treiber für alle gängigen Chips.
>
> Weiss jemand, wie Mac OS sich in dieser Hinsicht verhält?

Wie Windows: CDC (also der Microchip MCP2200) funktioniert out of the 
box, alles andere nicht.

fchk

von Oliver R. (orb)


Lesenswert?

W.S. schrieb:
> Kein HID-Eigenbau ist in der Lage, mit irgend einer üblichen
> Standard-Anwendung verwendet zu werden

Gut daß mein RFID-Reader das nicht weis. Der meldet sich als 
HID-Keyboard an ist somit sogar in Excel ohne Zusatzsoftware brauchbar.
Andererseit bringt mir bei einer Videokamera die serielle Umsetzung 
nichts, da die Übertragung nicht im Klartext stattfindet und ich eh die 
passende Software brauche. In diesem Fall bräuchte ich bei HID-Custom 
keine Rechte den Com-Porttreiber zu installieren.
Du siehst, es lassen sich immer Gegenbeispiele für Deine 
Verallgemeinerungen finden. Und welcher Standard-User greift auf seine 
Hardware mit Hyperterm zu?

W.S. schrieb:
> d) eben Oberbockmist, man könnte auch Pfusch dazu sagen.

Nur weil Du es nicht magst ist es nicht gleich Teufelswerk ;-)

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Frank K. schrieb:
> Wie Windows: CDC (also der Microchip MCP2200) funktioniert out of the
> box,

Wirklich "out of the box" funktioniert CDC unter Windows nicht, da immer 
noch eine *.inf-Datei erforderlich ist. Was auch immer die "Entwickler" 
bei Microsoft sich dabei gedacht haben mögen ...

(Man stelle sich vor, so eine *.inf-Datei bräuchte man auch für Mäuse, 
Tastaturen oder USB-Sticks)

von Grendel (Gast)


Lesenswert?

Also bei neueren Windows Versionen (7) werden die FTDIs automatisch 
erkannt und sogar der aktuellste Treiber runtergeladen und installiert.
Unter Linux funktionieren sie direkt.


Die internen USB Controller sind nett wenn man hohe Geschwindigkeit 
braucht und mit etwas Software Aufwand auch sicher gut nutzbar, aber 
auch bei CDC braucht man ja noch eine VID/PID.
Die bekommt man bei FTDI kostenlos dazu.
Bei Bastelprojekten egal - wenn man aber als kleine Firma nur wenige 
Produkte damit realisieren will nicht. Eine eigene VID kostet 
mittlerweile mal eben 5000$.
Da muss man dann schon einige tausend Geräte verkaufen bevor sich das 
überhaupt lohnen würde.

von Frank K. (fchk)


Angehängte Dateien:

Lesenswert?

Rufus Τ. Firefly schrieb:
> Frank K. schrieb:
>> Wie Windows: CDC (also der Microchip MCP2200) funktioniert out of the
>> box,
>
> Wirklich "out of the box" funktioniert CDC unter Windows nicht, da immer
> noch eine *.inf-Datei erforderlich ist. Was auch immer die "Entwickler"
> bei Microsoft sich dabei gedacht haben mögen ...

Ja leider. Apple hat es richtig gemacht. Und mein USB-CDC-Adapter 
funktioniert dort einfach so.

fchk

von Michael S. (rbs_phoenix)


Lesenswert?

Ich für meinen Teil will sowas wie ein Terminal garnicht dauerhaft 
benutzen. Selbst wenn es nur ein externes Thermometer ist, würde ich mir 
ein kleines Fenster machen, das nur anzeigt, ob das Gerät dran ist oder 
nicht und die eigentliche Temperatur. Und das geht mit HID. Zum testen 
ist bei MikroC auch ein HID-Terminal bei, ist aber, wie gesagt, bei mir 
nur zu Testzwecken in Benutzung. Man spart sich eben die Installation 
vom Treiber. Es ist aber auch egal, ob ich jetzt die Software oder die 
Software + Treiber weiter gebe. Ist ggf auch Geschmackssache.

Kann man eigentlich mit CDC auch im Programm kontinuierlich abfragen, ob 
das spezielle Gerät angeschlossen ist? Also kann man die VID und PID 
rausbekommen oder ist das fürs Programm nur ein normaler COM-Port? Dann 
müsste man ja quasi eine Anfrage hinschicken und hoffen, dass das Gerät, 
was dahinter steht, auch wie gewünscht antwortet. Mich z.B. würde es 
stören, wenn es nicht geht. Zudem muss man ja den COM-Port wählen, was 
man sich bei HID auch sparen kann.

Wie ist das eigentlich mit VID und PID bei privater Verwendung. Ich kann 
ja 0x1111 als PID und VID nehmen. Ist es warscheinlich, dass man diese 
Kombination auch bei einem gekauften Gerät bekommt? Oder sowas wie 
0x1234 oder 0x1337?

von Oliver R. (orb)


Lesenswert?

Michael Skropski schrieb:
> Wie ist das eigentlich mit VID und PID bei privater Verwendung.

Wenn es nur für Dich ist kannst Du ja so frech sein und die vom 
LUFA-Projekt nehmen: 
http://www.fourwalledcubicle.com/files/LUFA/Doc/130303/html/_page__v_i_d_p_i_d.html
Dann kollidierst Du höchstens mit anderen Eigenentwicklungen.

von c-hater (Gast)


Lesenswert?

Michael Skropski schrieb:

> Kann man eigentlich mit CDC auch im Programm kontinuierlich abfragen, ob
> das spezielle Gerät angeschlossen ist? Also kann man die VID und PID
> rausbekommen oder ist das fürs Programm nur ein normaler COM-Port?

Ja. Sogar noch viel besser: Man muss nicht dümmlich pollen, sondern kann 
die entsprechenden OS-Ereignisse genüßlich passiv abwarten. Das 
funktioniert übrigens analog auch bei HID-basierten Lösungen. 
Startpunkte für die Suche nach den einschlägigen Win-APIs wäre 
"WM_DEVICECHANGE" und "SetupAPI".

> Zudem muss man ja den COM-Port wählen

Nein, natürlich muß man das nicht tun (nur halt bei der Nutzung eines 
generischen Terminalprogramms). Als Reaktion auf o.g. OS-Ereignisse 
(aber nicht nur dort, sondern jederzeit) kann man natürlich auch 
programmatisch in Erfahrung bringen, ob und auf welchen COM-Port ein 
bestimmtes CDC-Device gemapped ist.

> Wie ist das eigentlich mit VID und PID bei privater Verwendung. Ich kann
> ja 0x1111 als PID und VID nehmen. Ist es warscheinlich, dass man diese
> Kombination auch bei einem gekauften Gerät bekommt? Oder sowas wie
> 0x1234 oder 0x1337?

Solange du das nur im privaten Bereich benutzt, kräht kein Hahn nach 
einer "illegal" verwendeten VID. Schlicht deshalb, weil es dort nicht 
illegal ist, denn 16Bit-Werte sind nichtmal über irgendein's dieser 
teils schon ganz schön perversen Gesetze zum Schutze "geistigen 
Eigentums" in irgendeiner Form schützbar.

Die kommerzielle Verwendung dieses libertären Ansatzes hingegen ist eine 
ganz andere Geschichte. Hier mußt du ganz streng darauf achten, 
nirgendwo auch nur andeutungsweise den Begriff "USB" zu verwenden. Z.B.: 
Stecker/Buchsen mit USB-Schriftzug oder -logo verwendet? Schon verloren.

In vielen Ländern mußt du darüber hinaus sogar im Sinne des 
Verbraucherschutzes in exponierter Form explizit darauf hinweisen, daß 
das Produkt nicht USB-kompatibel ist und die Verwendung an üblichen 
USB-Schnittstellen auf eigene Gefahr geschieht.

Damit bist du rechtlich einigermaßen auf der sicheren Seite. Eine Klage 
könnte es aber trotzdem noch geben, was zumindest vorübergehend Kosten 
erzeugt, die deutlich über $5000 liegen können (wenn du den Prozeß nicht 
wegen eines völlig verblödeten/nicht hinreichend motivierten Anwalts 
verlieren willst).

Das Hauptproblem ist aber: Wieviele Geräte wirst du wohl unter diesen 
Bedingungen noch verkaufen können? Genau auf dieser Zwangslage basiert 
das System der Abzocke der Industrie-Konsortien.

von W.S. (Gast)


Lesenswert?

Oliver R. schrieb:
> Gut daß mein RFID-Reader das nicht weis. Der meldet sich als
> HID-Keyboard an

Ja, eben.
Lies doch erstmal, bevor du sowas schreibst.
Würde sich dein RFID-Reader nicht als Keyboard anmelden, sondern als 
Custom-HID, dann würde er mir GARNIX kommunizieren können außer mit 
einem speziellen Programm, was du für ihn schreiben müßtest.

Hast du es jetzt begriffen?

W.S.

von W.S. (Gast)


Lesenswert?

Rufus Τ. Firefly schrieb:
> irklich "out of the box" funktioniert CDC unter Windows nicht, da immer
> noch eine *.inf-Datei erforderlich ist. Was auch immer die "Entwickler"
> bei Microsoft sich dabei gedacht haben mögen ...
>
> (Man stelle sich vor, so eine *.inf-Datei bräuchte man auch für Mäuse,
> Tastaturen oder USB-Sticks)

Ja, wenn man einige spezielle Eigenschaften von speziellen Mäusen oder 
Keyboards benutzen will, braucht man so eine *.inf und dazu auch einen 
Treiber. Eigentlich ist es nur ne recht konsequente Sache von Microsoft, 
daß sie sagen "USB ist sehr universell und deshalb machen wir das 
generell so. Es muß ja sowieso jeder, der sein USB-Gerät an einen 
Windows-Rechner dranstöpseln will, sich zuvor ne VID von uns ;-) holen - 
gegen GELD natürlich. Da kann er dann auch ne inf Datei vorhalten"

Kurzum, die Sichtweise von Microsoft ist halt etwas anders, eben eher 
kommerziell.

Ob sowas UNS als Nutzer in jedem Fall schmeckt, ist ne ganz andere 
Frage. Aber ne poplige .inf sollte keine wirkliche Hürde sein. Ich hatte 
in meinen VCP-Quellen ne passende .inf als Kommentar in die .h 
geschrieben, da hat man sie problemlos zur Hand.

W.S.

von Stephan B. (matrixstorm)


Lesenswert?

W.S. schrieb:
> Es muß ja sowieso jeder, der sein USB-Gerät an einen
> Windows-Rechner dranstöpseln will, sich zuvor ne VID von uns ;-) holen -

Das halte ich fuer totalen Unsinn.
Microsoft vergibt keine VIDs.
Noch vegeben die INFs. Der Hersteller muss diese Dateien erzeugen.

Das mit der INF ist zu einem anderen Zweck: Microsoft will keine 
(grosse) Geraetedatenbank pflegen muessen.


MfG

: Bearbeitet durch User
von Christian J. (Gast)


Lesenswert?

Mr. Kaktus schrieb:
> Ich empfehle Arduino Nano 3.0
>
> alles drauf was man braucht und sehr preiswert
>
> 
http://www.ebay.de/itm/251540558891?_trksid=p2055119.m1438.l2648&ssPageName=STRK%3AMEBIDX%3AIT
>
> Wenns aber der FTDI Chip sein soll, dann wirds etwas teurer
>
> 
http://www.ebay.de/itm/251494917400?_trksid=p2055119.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Hallo,

ich kann  nur davon abraten die Nano 3.0 über ebay zu kaufen! Ich habe 
malwelche bestellt und die hatte defekte FT232 Konverter drauf, die 
nicht erkannt wurden. Eine bestimmte Losnummer mit D glaube ich ist das. 
Windows meldet einen Fehler, muss eine alte Lib installieren, dann 
laufen aber alle neuen nicht. Das hat seinen Grund warum die so billig 
sind! Man kann sie nur über ISP programmieren aber nix über USB 
raussenden.

Es gibt auch Nanos aus China mit PL203 Interface, die gehen besser. Der 
Arduino Micro ist absolut nervtötend zu programmieren, da er dauernd die 
USB Schnittstelle wieder verliert, was ja logisc ist. Nach jedem Brennen 
kannst du abstecken und wieder anstecken ud hastjedesmal eine andere 
Nummer.


Mit USBdeview kann man sich alle USB Treiber anzeigen lassen die Windows 
kennt und auch ale die man nicht mehr braucht löschen.

Bitte 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
Noch kein Account? Hier anmelden.