Hallo an alle! Ich soll ein USB-Gerät entwickeln, mit Bedienung vom PC aus, was für mich sehr nach einer GUI richt. Mit USB geräteseitig habe ich mich schon befasst. Nun kann ich mir noch nicht recht vorstellen, wie sowas grundsätzlich PCseitig aussehen kann. Ich meine den C/C++-Text/Library, damit ich von Windows aus auf die Schnittstelle zugreifen kann. Da muß es doch schon Fertiglösungen von den uC-Herstellern geben oder nicht? Könnt Ihr mich bitte auf Möglichkeiten und Beispielprojekte stoßen, damit ich einmal eine Vorstellung bekomme, was da auf mich zukommt. Gibt es hier große Unterschiede z.B. zwischen 8051, AVR, MSP430 was diese Unterstützung angeht? Das ganze wird sehr wahrscheinlich mit einem ATmega1280 mit HID-Brücke (IC oder weiterer uC) verfasst. Werde anfänglich zum Vergleich und zur Absicherung parallel mit einem MSP430F5xx starten, um mich dann ganz schnell in eine Richtung zu orientieren. Für letzteren hängt es ja leider noch mit USB-Bpscode. Freue mich über Eure Antworten.
Hallo, die einfachste Möglichkeit sowas zu realisieren ist ein sog. virtueller COMPort. Es gibt z.B. von FTDI ICs die dir am Computer eine virtuelle Schnittstelle (COM) verschaffen. Auf die kann man wie auf jede andere serielle Schnittstelle zugreifen. Aufbau ist dann folgender Maßen: PC -> USB Kabel -> FTDI (=> UART Signal (serielles Signal)) -> Microcontroller. Vorteil: Jeder Microcontroller kann ganz einfach serielle Signale (UART) verarbeiten. Viele Microcontroller haben auch USB schon von selbst an Bord. Das ist allerdings nicht sonderlich einfach damit umzugehen. Als Anfänger scheidet sowas das erste halbe Jahr (wenn sehr fleissig) sowieso aus. Bernd schrieb: > Gibt es hier große Unterschiede z.B. zwischen 8051, AVR, MSP430 was > diese Unterstützung angeht? Tjaa das ist so eine Sache: Jeder µC hat seine Vorzüge und Nachteile. Man muss sagen, dass es gerade hier im deutschen Raum einen riesen Support (z.B. hier im Forum) für AVR gibt. Für Hobbybastler sind immer entweder AVR oder PIC zu empfehlen. (Ein kleiner Rat am Rande: Frage HIER nie nie nie nach PIC vs. AVR hier - das gibt den dritten Weltkrieg). Wie gesagt für AVR gibt es hier tausende Tutorials und Beispielprojekte. Ein Einstieg wäre hier: http://www.mikrocontroller.net/articles/AVR-Tutorial http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial Ich kann dir schweren Herzens nur AVR empfehlen. Selbst komme ich aus dem PIC-Lager =) Achja also einen FTDI IC kann man mit jedem Microcontroller ansteuern.
Bernd schrieb: > Ich soll ein USB-Gerät entwickeln, mit Bedienung vom PC aus, was für Und warum "sollst" gerade du, wenn du doch scheinbar sehr wenig Ahnung von jedem der vorkommenden Gebiete hast?
http://sourceforge.net/projects/libusb/ http://sourceforge.net/projects/libusb-win32/ http://sourceforge.net/projects/libusbdotnet/ http://sourceforge.net/projects/libusbjava/
Hallo nochmal! Scheinbar habe ich mich mißverständlich ausgedrückt. Daß man USB per externem oder internem USB-Controller realisieren kann war mir klar. (Vielen Dank Lehrmann Michael, Deine Antwort ist lobenswert!) Ich möchte ein USB mit HID-Klasse realisieren. Falls nicht möglich muß ich auf einen anderen Standartreiber umsteigen. (2EP rein, 2EP raus = 2x HID, FS) Also mit dem Mikrocontroller werde ich wohl zurechtkommen, auch wenn ich biserh noch keinen USB realisiert habe. Meine Frage hat sich viel mehr auf die Entwicklung PC-seitig bezogen. (A) Irgendwie muß man ja zum einen den Hardwarezugriff hinbekommen. (B) Zum anderen ist da ja noch die GUI selbst. Benötige ich also irgendwelche Libraries die ich in meine GUI einbinde oder gibt es bereits Lösungen von den Mikrocontroller- / USB-Brückenherstellern,... oder....? Habe bisher die Möglichkeiten .NET und QT für die GUI in Erwägung gezogen. Gibt es hier vielleicht auch schon fertiges Material, das für ein Messgerät (etwas mit Bedienelementen und Anzeigen) die Arbeit vereinfacht? ... so und jetzt schau ich mir die Vorschläge von usuru an. Vielen Dank!
Wunderbar! Usuru, vielen vielen Dank! Bleibt noch die Frage, ob es irgendwie eine Abkürzung gibt oder ob es Lösungen von den Mikrocontrollerherstellern selbst gibt, die zur entsprechenden Kommunikation vielleicht noch passender abgestimmt sind. Unter Abkürzung meine ich eine eine Entwicklungsumgebung, oder etwas bereits bestehendes, für eine "GUI" speziell für USB-Geräte. - Man darf doch Optimist sein ;)
>Unter Abkürzung meine ich eine eine Entwicklungsumgebung, oder etwas >bereits bestehendes, für eine "GUI" speziell für USB-Geräte. - Man darf >doch Optimist sein ;) So was gibt es nicht.
Ach so, ich hatte noch eine Idee, wie ich die Bedienung des Gerätes gestalten könnte, nämlich von Excel aus. Gibt es da auch schon eine fertige Software die z.B. von einem csv-File Daten entnimmt und CSV-Files / Textfiles ausspuckt, für USB? Würde die Kommunikation via CSV-File/Text-File klappen, bräuchte ich vielleicht gar nicht mehr an eine richtige GUI denken. Und mit ein paar Makros ließe sich das ganze noch ausgestalten. Vielen Dank nochmal! Freue mich schon auf Eure Antworten!
http://www.codemercs.com/index.php?id=127&L=1 Das gibts spezielle usb-controller und speziell darauf abgestimmte DLL's, zur einbindung in windows
Hallo Bernd, erstmal respakt das du dich doch schon an solchen Geschichten wagst, auch wenn ich so ein wenig rauhöre, das du eigentlich keine Ahnung von dem ganzen hast :-) Nun zu deinem Problem/Wunsch... Ich selbst hab auch jahrelang nach der Möglichkeit gesucht, ein gerät per usb anzusteuern... Meine Lösung war folgende... 1. Ich hab mir gedanken darüber gemacht 2. Hab alles geplant, von anfang bis ende (damit ich nicht unnötig arbeite.) 3. Hab mir eine virtuelle COM-Port USBzuUSART aufgebaut (fragen bei interesse) 4. Hab mich in Macromedia Flash eingearbeitet 5. Hab meine Hardware mit "ActiveCOMPort verbunden 6. Eine eigene Befehlstabelle zum "standart" gemacht :-) 7. Ich amysiere mich mit meinen Geräten :-) Beispiel einer Multimediasteuerung von mir :-) Ich schliesse mein USB 2 USART Wandler an den PC, ein COMPORT wird erstellt, mit selbstgebauten PHP und Flash Snipplets realisiere ich die kommunikation zwischen PC und USART-Wandler und der steuert dann per Befehlstabelle jede beliebige Funktion an meinem µC. Der wiederrum empfängt die Befehle und setzt diese in Funktionen um, indem er mir das licht einstellt, oder meine Rollos runter/hochfährt oder meine Lichtsteuerung und Temperaturmessung meines Terrariums übernimmt usw. Die GUI hab ich ganz einfach mit Flash erstellt, was so ziemlich kinderleicht ist :-) Also du siehst, es sind unendlich Möglichkeiten da :-) Man muss nur wissen, was man will ;-) Wenn ich dir helfen kann, einfach melden ... lg G-Crax
Hallo G-Crax, vielen Dank für Dein Angebot. Warum hast Du Dich für Makromedia Flash enschieden? Die Vorbereitungen uC-seitig sind für mich fast abgeschlossen. Wie groß muß ich hierzu den Aufwand PCseitig einschätzen? Ich bin im Prinzip an einem möglichst einfachen Weg interessiert, der sich mit Standardtreibern und Programmen realisieren läßt, die es ganz sicher noch sehr lange geben wird und die es in jeder Firma geben sollte. (Daher die Idee mit Excel, auch wenn es sicher noch sehr viel elegantere Möglichkeiten gibt.) LG zurück.
Flash wär mir zu teuer, und freie Alternativen (Ming) recht umständlich. Mein Vorschlag wäre: USB->UART (wie oben schon vorgeschlagen) QT am PC installieren. Klikibunti-Oberfläche zusammenklicken. Etwas C++-Code für die Datenübertragung, Protokoll, ... schreiben. Compilieren. Debuggen. Fertig. :) Bonus bei QT: würde dann auch mit kleinen Anpassungen am Mac, under Linux, und auf neueren Nokia-Telefonen laufen. Ansonsten gehts mit .NET genauso, den Flamewar QT vs .NET und "echtes" C++ vs C#/Managed C++ gibts per Suchfunktion.
Hallo Bernd. >vielen Dank für Dein Angebot. Warum hast Du Dich für Makromedia Flash >enschieden? naja, ganz einfach aus dem grund weil ich eh schon mit flash homepages erstelle und es die möglichkeit gibt, alles schön als eine einzige .exe datei zu erstellen, die dein komplettes ding steuert :-) >Wie groß muß ich hierzu den Aufwand PCseitig einschätzen? Naja, ich persönlich brauch nur ein paar stunden denk ich mal um dir das zu programmieren, aber du als anfänger müsstest dich ja erstmal in flash Anwendungsdesign einarbeiten :-) Vielleicht kannste mir einfach nur sagen was genau passieren sollte, dann kann ich dir evtl. näheres sagen, oder dir vielleicht ein wenig helfen... >Ich bin im Prinzip an einem möglichst einfachen Weg interessiert, der >sich mit Standardtreibern und Programmen realisieren läßt, die es ganz >sicher noch sehr lange geben wird und die es in jeder Firma geben >sollte. Das is doch jeder irgendwo :-) Ich persönlich arbeite ständig an meiner elektronik und entwickel immer weiter, also kann ich mir persönlich diese garantie auch geben :-) Wenn irgendwann ein Betriebssystem rauskommt, das kein USB mehr unterstützt, dann werd ich ein problem haben, aber ich glaube kaum, das dies der fall sein wird :-) zumindest nicht die nächsten 20 jahre... Wie gesagt, schilder mir dein vorhaben, dann kann ich dir vielleicht helfen...
Moin USB Standardtreiber für RS232 adapter gibt es meines wissens nicht. Einfach einstecken und loslegen geht nicht. es wird immer erst nach einem treiber gefragt. ob nun selbst entwickelt oder LibUSB ist da egal. ggf auch die Probleme bei W7 64 beachten, fals das von interesse ist. LibUSB muss man selber signieren. Für das von dir angesprochene HID, hat Windows eine eigene API um damit umzugehen. Hierfür ist das DDK/WDK notwendig, das man von der MS seite kostenlos runterladen kann. ggf ist noch eine anmeldung erforderlich. Codeschnipsel gibts im netz. ggf für den Anfang das tool simpel HID Writer Interresant, hier kann man auf Fast alle HID devices über eine GUI Lesend und schreibend drauf zugreifen. Nützlich um z.B. die Kommunikation mal zu testen. Bei der Nutzung des DDK / WDK ist ggf der Compiler der mitgeliefert wird zu verwenden. da der normale von Visual Studio dann irgendwelche confilikte mit seinen eigenen Headerfils bekommt. Sollte bei der HID API aber nicht der fall sein.
G. G. schrieb: > Vielleicht kannste mir einfach nur sagen was genau passieren sollte, > dann kann ich dir evtl. näheres sagen, Also eine kurze Beschreibung was ich für mein Bedienfeld benötige: - Messwertanzeige - Drücker / Schalter - ggf. Schieberegler (muß aber nicht sein) - Zahlenwerteingaben ... und etwas das mir noch Kopfzerbrechen bereiten wird: Der Anwender des Gerätes muß ein willkürliches digitales Signal beschreiben können, das aus vielen Tausend einzelnen Einsen und Nullen besteht, welches dann das Gerät ausgibt. Ein Zoom könnte hier vielleicht helfen, damit man z.B. bei Excel nicht alle Felder einzelnd anklicken (Einsen) oder nicht anklicken (Nullen) muss. Natürlich könnte man auch zur Beschreibung die Rechecksignale per Maus an bestimmten Stellen ziehen und zusammenschieben, wenn sie mit einer Linie beschrieben sind. - Zweiteres ist sicherlich nicht einfacher. Aber vielleicht fällt Euch ein passende Eingabemöglichkeit und dazu passendes Tool für mich ein. Vielen Dank Euch allen schon einmal für die vielen nützlichen Tipps!
Ach wo wir grade beim Thema sind. Kennt irgendjemand den parallel angesteuerten FT245R von besagter Firma FTDI ? Ich bin begeistert von dem, allerdings ist er mir zu langsam mit 1MB/s. Was allerdings sehr gut ist an dem chip, dass er einfach 8 datenleitungen hat und eine TRANSMIT leitung, sobald die auf logisch 1 geändert wird, wird ein byte übertragen. Die treiber für win/linux sind ebenfalls ein Traum. Weiss jemand einen Chip mit 480 Mbit/s, der ähnlich einfach zu betreibeni ist (harware sowie softwareseitig, wie eben der 245R) Ich werd aus den Datenblättern der neuen ftdi chips nicht schlau! Eventuell tuts auch ein CYPRESS microcontroller?
ah hat sich erledigt. ftdi waren fleissig und haben das datasheet verfollständigt. jetzt steht auch was zum fifo modus des FT2232H drin, oder ich hatte es vorher einfach übersehen.
Hallo Bernd also ganz ehrlich, aus deiner beschreibung bin ich nicht wirklich schlauer, aber ich erklär dir einfach mal wie es bei mir funzt, vielleicht is es ja das was du brauchst... also ich mach das alles so... beispiel an einer simplem steuerung per usb, die einfach nur zb. drei lampen ein und ausmacht... also. 1. ich hab ein USB>USART Converter mit COM1 (oben beschrieben). Darauf kann ich befehle senden oder empfangen(egal was, ich mach das mit einer eigen entwickelten Befehlstabelle)... 2. ich hab in flash ne GUI erstellt die einfach nur Text und buttons hat... Lampe 1 Status = |BUTTON ON/OFF| Farbfeld(zum signalisieren rot/grün) Lampe 2 Status = |BUTTON ON/OFF| Farbfeld(zum signalisieren rot/grün) Lampe 3 Status = |BUTTON ON/OFF| Farbfeld(zum signalisieren rot/grün) so... diese FlashGUI macht nix anderes als mittels eines PHP Script die befehle L1on, L1off, L2on, L2off, L3on, L3off also insgesamt 6 befehle an die COM1 zu übergeben... 3.Hinter der USB>USART steckt ein µC der diese Befehle abgreift und verarbeitet und dementsprechend auch L1, L2 oder L3 ein oder ausschaltet. Das is eine ganz simple anwendung die ich dir realisieren kann... Nun zu deinem Auftrag... Es is auch möglich signale und werte aus der USART-ST vom µC oder vorhandenen Schaltung abzugreifen und sie dann in der Software zu verarbeiten, ganz egal ob das nun zahlen sind, texte oder sonstwas... Hauptsache sie kommen als lesbarer String über den USART anschluss vom µC, oder du erstellst dir dafür eine eigene Befehlstabelle wie ich ... Was du letztendlich hinter den µC anschliesst, spielt in dem Fall keine Rolle...hauptsache, die Daten kommen per USART an... so nun du wieder :-) ich hoffe ich konnte helfen...
Hallo G.G., ich nehme an, daß Du diese kurzen Befehle wegen der HID-Übertragung verwendest, also wegen den kurzen ASCII-Zeichen. Oder ist Deine Puffergröße und Verarbeitungszeit der Grund? Leider muß ich bei mir auch längere Zahlenkollonen übertragen, wofür ich einen extra Endpoint vorgesehen hatte. Für kürzere Befehle (Hin und Zurück) und Rückmeldungen hatte ich drei weitere Endpunkte vorgesehen, z.B. für den Befehl, daß diese Zahlenkollone losgeschickt werden soll. Nun, es scheint mir, als ob HID vielleicht nicht ausreicht und damit trifft es auch Deine Entwicklung, zumindest für ein Teil meiner Kommunikation. Ich werde mir hier wohl noch einmal Gedanken machen müssen. Denke aber, daß Fragen hierzu in einem getrennten Thread gestellt werden sollten. Hier möchte ich mir erst einmal über mögliche GUI einen Eindruck verschaffen und erfahren, wie stark die beiden Seiten (Gerät und PC) miteinander fürs Konzept verwurzelt sind, oder ob ich sie getrennt angehen kann. Gibt es eigentlich auch gute Literatur oder Links zu dem Thema hardwareverbundene GUI auf Windows(XP...7), so daß ich auch etwas zum Lesen dazu habe? Danke G.G., vielleicht komme ich noch einmal auf Dich zurück.
freut mich das ich deine ideen irgendwie anregen konnte :-) also ich hab soeben spaßhalber mal versucht mit meinem aufbau auch längere datensätze zu übermitteln und siehe da, er hat sogar einen kompletten text mit 1559 wörtern (per copy & paste von einer .doc-datei) über diese serielle stelle übermittelt und das auch ohne fehler :-) wusste ich selbst nicht, aber du hast mir nun auch noch eine idee zum weiterbauen gegeben :-) wie gesagt bei mir is das so, das ich alle meine geräte und mashinen in meinem büro damit steuern kann und das auch von überall aus auf der welt :-) wenn ich dir helfen kann, gerne per pn oder so... ansonsten, weiterhin dir guten erfolg :-)
Moin Für die Verbindung PC / MCU gibt es für USB verschiedene möglichkeiten. 1. COM implementierung Variante a Realisierung über einen RS232 / USB adapter oder IC (z.B. FDTI) Variante b Software implementierung in einer USB fähigen MCU Vorteile: einfaches ansprechen von der steuersoftware, da es sich nur um einen ganz gewöhnlcihen COM Port Handelt. Nachteil: es ist ein passender Treiber notwendig / Signierung des Treibers für Win64Bit notwendig. / Geräht wird über einen COM Port angesprochen ggf verwechslungsgefahr 2. HID Implementierung eigentlich wie Variante 1b nur die Software implementiert eine andere classe. Paketgrössen und maximale Bandbreite können probleme machen. wobei die Paketgrösse definierbar ist. Eine API zum Ansprechen und suchen des USB Devices existiert. Vorteile: Windows benötigt keine Treiber für das device. HID ist ein Standard treiber. Nachteil: Paketgrösse und Bandbreite sind eingeschränkt. 3. Eigenes USB Protokoll Vorteile: volle bandbreite von USB lässt sich ausschöpfen. Nachteil: keine Standard treiber, abhilfe ggf USBLib / Signierung des Treibers für Win64Bit notwendig / komplizierter software seitig anzusprechen.
Hi 123, für mich kommt zunächst nur HID in Betracht. Zum einen will ich ganz bestimmt keinen eigenen Treiber schreiben. Zum anderen benötige ich einen Standardtreiber. Und ich denke MSD ist dann schon wieder ein deutliches schwieriger. Bleibt für mich der IO-Warrior oder ein USB-Controller im uC selbst. Frage: Wie groß ist die Packetgröße? Ist sie abhängig vom Puffer oder hat sie andere Grenzen? Vielen Dank!
123 schrieb: > Moin > > USB Standardtreiber für RS232 adapter gibt es meines wissens nicht. > Einfach einstecken und loslegen geht nicht. es wird immer erst nach > einem treiber gefragt. ob nun selbst entwickelt oder LibUSB ist da egal. > > ggf auch die Probleme bei W7 64 beachten, fals das von interesse ist. > LibUSB muss man selber signieren. > > Für das von dir angesprochene HID, hat Windows eine eigene API um damit > umzugehen. Hierfür ist das DDK/WDK notwendig, das man von der MS seite > kostenlos runterladen kann. ggf ist noch eine anmeldung erforderlich. Nein, dazu reicht bspw. http://www.florian-leitner.de/index.php/projects/usb-hid-driver-library/ oder http://www.codeproject.com/KB/cs/USB_HID.aspx bzw. http://www.developerfusion.com/article/84338/making-usb-c-friendly/ andere Möglichkeit wäre WinUSB d.h. ein Usermode-Treiber http://msdn.microsoft.com/en-us/library/ff540196.aspx oder eben die "fertigen" Bausteine von FTDI oder http://www.firmwarefactory.com/Docs/USB-SPI%20HW144.pdf
Interesant für C# hat sich dann wohl schon jemand die mühe gemacht eine lib zur verfügung zu stellen. Somit eine Alternative wenn GPL Code kein Problem ist Ich hab das damals noch in C selber schreiben dürfen, daher die Aussage HID API und der verweis auf das DDK / WDK zu winusb, ist vom prinzip nichts anderes als ein eigener Treiber. man muss sich nicht mehr um die implementierung kümmern. Sicher ein sehr sehr grosser vorteil. man braucht imer noch eine eigene INF datei, und muss diese mit seiner HW ausliefern.
Ok, mußte erst mal nachschlagen: API = Applikation Programming Interface -> Ich stelle es mir als Variablen- und Konstantenübersetzung zwischen verschiedenen Softwares vor. WDK = Windows Driver Kit DDK = Driver Development Kit INF = Textfile für Treiber = Setup Information File Na, das kann noch lustig werden. Aber so leicht lass ich nicht locker. ;) -Was ist HW?
Bernd schrieb: > zu winusb, ist vom prinzip nichts anderes als ein eigener Treiber. man > muss sich nicht mehr um die implementierung kümmern. Sicher ein sehr > sehr grosser vorteil. man braucht imer noch eine eigene INF datei, und > muss diese mit seiner HW ausliefern. Die .inf wäre noch das kleinste Problem. Aber für die x64 Versionen ab Vista muß das Ganze dann auch wieder signiert werden. :( Oder anders gesagt, um WinUSB unter x64 nutzen zu können brauchst Du trotzdem ein Code-Signing Certificate von einer der 6 dafür zugelassenen CAs.
hallo, eine gui kannst du auch mit labview erstellen. auf usb kannst du mit dem treiberpaket visa (ebenfalls von national instruments) zugreifen, damit kannst du auch die notwendige inf datei erstellen. ich bin gerade dabei soetwas zu implementieren. auf dem at90usb1287 habe ich ein sample von lufa (hid generic) genommen und angepasst, auf dem rechner mittels labview und zubehör eine gui gezaubert. der µc misst fleißig und die messwerte lass ich mir im rechner anzeigen. funzt eigentlich wunderbar.
... schrieb: > Die .inf wäre noch das kleinste Problem. Aber für die x64 Versionen ab > Vista muß das Ganze dann auch wieder signiert werden. :( Was kostet das? Und welche guten oder schlechten Nebeneffekte sind daran mitverknüpft? Anmerkung: Bei meinem Projekt handelt es sich um ein Einzelstück.
Bernd schrieb: > ... schrieb: >> Die .inf wäre noch das kleinste Problem. Aber für die x64 Versionen ab >> Vista muß das Ganze dann auch wieder signiert werden. :( > > Was kostet das? > Und welche guten oder schlechten Nebeneffekte sind daran mitverknüpft? > > Anmerkung: Bei meinem Projekt handelt es sich um ein Einzelstück. Dann wird's zu teuer... 1. USB Vendor ID ab 2000 USD http://www.usb.org/developers/vendor/ 2. Passendes Zertifikat (falls sich nichts geändert hat, ist Globalsign immer noch am günstigsten) 99 USD pro Jahr 3. Inf-Datei erzeugen, mit inf2cat eine Katalogdatei erzeugen, diese signieren Der Treiber lässt sich so zwar problemlos auf 64-Bit-Systemen installieren, allerdings mit einer Warnung, ob man der Firma vertrauen möchte. Will man auch die umgehen 4. WHQL-Prozedere und Signierung durch MS afair 250 USD
Arc Net schrieb: > USB Vendor ID ab 2000 USD Ich dachte die Vendor ID wäre nur von Interesse wenn ich das Gerät weiterverkaufen wollte. Ist dem nicht so der Fall?
Ok, also nochmal langsam, damit ich es auseinanderhalten kann. Bei einigen ICs (z.B. FTDI) kann man doch die VendorID vom Chip mitbenutzen. Ist dies grundsätzlich bei einer HID-Lösung oder bei bestimmten Mikrocontrollern nicht so?
Oder bezieht sich jetzt die VendorID von der wir jetzt reden einzig auf die GUI??
Ok dann kann die Vendor ID ja wegfallen. Code / Driver Signing der DLLs ist zwar prinzipiell vorgeschrieben, aber man mus ja keins verwenden, das von einem Trustet Publischer stamt, und denen MS vertraut. Mann kann W7 und Vista 64 dieses Driver Signing auch agbewöhnen. Wie steht in einem der Dokumente von MS zum Thema Treibersignierung. Bzw mann kann sein eigenes Trustet Cetificat Windows verfüttern, und den Treiber dagegen signieren. Da einzelstück, werden auch die adfür verwendeten PCs begrenzt sein. WHQL ist dann wohl auch kein Thema.
Was ändert sich am Umgang für den Nutzer mit einem Gerät ohne VendorID ect., mit Standardtreiber?
Ohne venderID geht bei USB erst mal garnichts. Diese muss vom USB protokoll her immer übertragen werden. nur ob du eine eigene beantragst; immer dann notwendig, wenn man das gerät auch verkaufen will. Auch für eine Zulasssung und Zertifiezierung notwendig. oder ob man sich irgend eine "klaut" und riskiert treiber kollisionen zu generieren, ( eher unwarscheinlich aber möglich ) ist hier eigentlich die Frage. wenn du dummer weise genau die ProduckID + VenderID kombination erwischt, für die Windows schon einen Treiber mitlierfert, versucht WinDoof natürlich auch diesen dafür zu Installieren. Da dein Geräht natürlich nicht dem Vermuteten entspricht, kann das natürlich zu problemen führen.
123 schrieb: > oder ob man sich irgend eine "klaut" und riskiert treiber kollisionen zu > generieren, ( eher unwarscheinlich aber möglich ) Ok, aber bekommt man nicht i.d.R. durch über den uC-Hersteller, sofern mit USB, oder über den USB-Controller-IC-Hersteller eine VendorID? Wozu sollte ich zunächst davon ausgehen mir eine zu klauen? Gibt es keine legalen Wege? Ich schaue mir gerade die Datenblätter der I/O-Warriors an. Finde irgendwie hier das Thema VendorID nicht. Kann mir vielleicht hier jemand zuvor kommen? Vielen Dank nochmal!
Bernd schrieb: > 123 schrieb: >> oder ob man sich irgend eine "klaut" und riskiert treiber kollisionen zu >> generieren, ( eher unwarscheinlich aber möglich ) > > Ok, aber bekommt man nicht i.d.R. durch über den uC-Hersteller, sofern > mit USB, oder über den USB-Controller-IC-Hersteller eine VendorID? Bei einigen ja (s.u.), bei vielen nicht. Microchip, TI (Luminary), SiLabs, FTDI, Atmel (u.U. VID und PID http://support.atmel.no/bin/customer?=&action=viewKbEntry&id=186) Oder diese Variante http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&category_id=20&option=com_phpshop&Itemid=1 > Wozu sollte ich zunächst davon ausgehen mir eine zu klauen? > Gibt es keine legalen Wege? > > Ich schaue mir gerade die Datenblätter der I/O-Warriors an. Finde > irgendwie hier das Thema VendorID nicht. Kann mir vielleicht hier jemand > zuvor kommen? Die haben afaik eine eigene. > Vielen Dank nochmal!
Bernd schrieb: > Ich schaue mir gerade die Datenblätter der I/O-Warriors an. Finde > irgendwie hier das Thema VendorID nicht. Kann mir vielleicht hier jemand > zuvor kommen? Kapitel 7.2 Die IO-Warrior haben fest eingestellte VendorID und ProductID.
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.