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!
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
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.
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).
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?
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
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).
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
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...
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.
Boris P. schrieb: >> Ebay-Artikel Nr. 251540558891 > > Boah, ist der günstig! Angesichts von "keine Lieferung nach Deutschland" ist das ziemlich egal.
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
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/
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.
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
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
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
Firefox 31. Windows7. Firefox 30. Ubuntu 14. Compile -> OK Firmware.bin -> OK -> Fenster geht auf -> speichern -> 0 Byte.
:
Bearbeitet durch User
Ich werde es testen, hoffentlich rausfinden was da los ist und dann fixen. Danke dir.
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
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.
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
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).
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.
> 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?
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
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 ;-)
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)
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.
Angehängte Dateien:
-
usbser1.0m.jpg
190 KB
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
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?
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.
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.
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.
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.
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
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.
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.