Hi, ich überlege mir, wie ich durch USB und Windows meine Daten druchbringen kann, so dass ich diese in ein geschriebene Aplikation verwenden kann. z.B Tmperatur. Ich kann uC ja in USB dies als Maus deklarieren. Beim Plug und Play wäre das dann einfach eine Maus und hätte nicht das Treiberproblem. Dartaus ergeben sie aber Fragen. Wie kann ich Daten schicken, ohne dass das der eigentliche wirkliche Mauszeiger übernimmt? Wie kann ich, wenn das dann geht. die Daten abholen. Warscheinlich irgendwie über Handel.Nur wie. Oder man schreibt einen Treiber, bzw. es gibt einen Open Souce Treiber. Weis da jemand was? Welche Programmiersprache würdet Ihr heute verwenden. Ich kann halt C und C++ und von früher Turboüpasca. Ein wenig Java ist auch da.
Einfach ein generisches HID auf dem µC implementieren, nicht explizit eine Maus. Die Daten kannst du dann mit deinem Programm auslesen und es stört sonst nichts im System. Machen die IOWarrior auch so. Vorteil: Kein Treiber nötig, wird alles vom Windows/Linux/MacOS verwaltet.
Ahh, danke, das hört sich fein an. Jetzt müst ihr mir nur noch etwas auf die Sprünge helfen. Also meine Aplikation wartet auf Tastendrücke, oder Werte. Das ist mir klar. Und umgekehrt kann man warscheinlich dann auch Rückmeldungen irgendwie senden. Erkennt Windows dann, wann ich von der richtigen Tastatur aus was schreibe und es nicht der Kontroller sein soll? Was ist wenn ich über die normale Tastatur was eingeben muss in die Aplikaion? Kommt es da durcheinander? Gruß Ralf
das ist der falsche Ansatz. was passiert denn, wenn deine Applikation nicht den Eingabefokus hat. Dann läuft deine Pseudomaus Amok und formatiert vielleicht noch die Festplatte. schau dir die libusb an und Projekte, die sie benutzen, zB USBsp oder Rfm12usb Denutzte deren Code als Basis.
Was spricht dagegen, ein CDC zu implementieren? Für dessen Installation braucht das strunzdumme Windows zwar eine *.inf-Datei, aber mehr auch nicht, der grundlegende CDC-Treiber ist bei Windows dabei. Und so ein CDC kann ohne irgendwelche Wirrungen mit Tastaturen oder Mäusen problemlos bidirektional angesprochen werden. Beispiele für CDCs mit AVRs gibt es ebenfalls bei obdev.at, die Gegenstelle auf dem PC ist nichts anderes als die Ansteuerung einer seriellen Schnittstelle. Alles keine Raketenwissenschaft.
Hier ist sowas umgesetzt: http://www.obdev.at/products/vusb/easylogger.html HID-Tastatur, wenn aktiv wird jede Sekunde <Messwert> <enter> ausgegeben. Tabellenkalkulation/Texteditor auf, Fokus rein, Taste am Logger gedrückt, zuschauen, wie sich die Tabelle füllt.
ah interessant. Es werden also Zeichen gesendet. Der Texteditor, der gerade im vordergrund aktiv ist empfängt. Also jede Aplikation, die gerade offen ist empfängt die Zeichen,egal welche. Kann das nicht gefährlich sein? zB. wenn gesendet werden format c: :-) wird warschenlich nicht so krass vorkommen, dennoch kann schon bei beliebigen Datenübersendung alles mögliche doch passieren, oder doch nicht ? Bzw, wird das nicht überlagert mit der eigentlichen Tastatur?
Ralf Hellener schrieb: > Kann das nicht gefährlich sein? Doch, das wurde ja schon behandelt. Also entweder HID-Klasse mit generischem Treiber verwenden oder, wie von Rufus vorgeschlagen, die CDC. Eine HID-Tastatur wird jeder Anwendung, die den Fokus hat, seine Daten senden - da kann eigentlich nur Murks rauskommen wenn man das nicht permanent überwacht. Für den Labortisch ok, in deinem Konzept aber unbrauchbar.
aja. cdc: also re232 simulieren. Setzt wohl vorraus, dass die Datenmenge klein ist. was ist von libusb zu halten? ist glaube ich ein open souce Projekt eines Treibers. weis aber nicht ob das mit visual Basic oder visuall c++ einbindbatr ist.
Ralf Hellener schrieb: > cdc: also re232 simulieren. Setzt wohl vorraus, dass die Datenmenge > klein ist. Das ist bei HID erst recht der Fall. Was heißt "kleine Datenmenge"? libusb kann selbstverständlich mit Visual C++ genutzt werden -- wenn damit echtes C++ programmiert wird. Ob das auch mit der auf dem .Net-Geraffel aufsetzenden Microsoft-Perversion "Managed C++" bzw. "C++/CLI" funktioniert, entzieht sich meiner Kenntnis. Mit C++ hat das mehr als den Namen nicht gemeinsam. Ohne Dir zu nahe treten zu wollen: Damit versteigst Du Dich. Mit CDC lassen sich etliche kByte pro Sekunde übertragen und Du kannst so ein CDC mit jeder Programmiersprache ansteuern, die serielle Schnittstellen ansteuern kann. Und anders als bei den echten Onboard-Schnittstellen normaler PCs sind mit USB-CDC auch deutlich höhere Datenraten als 115200 Baud möglich.
Scheint plausiebel. RS232 ist ein alter Standard. Damit könnete man auch älter API´s wieder zum löaufen bringen lassen. Auch könnte man damit besser eine galvanische Trennung machen, was ja nicht ohne ist. Bei großen Datenmengen, also z.b video, oder bildverarbeitung, wirds wohl aber schwieriger werden, denke ich. eine Möglichkeit fällt mir noch ein. Was haltet ihr davon. Man kann ja eine Scheinfestplatte simulieren. Und man holt die Daten einfach ab. Man müsste dann aber überlegen wie man Zugriffskollisionen in den Griff bekommt.
Ralf Hellener schrieb: > Bei großen Datenmengen, also z.b video, oder bildverarbeitung, wirds > wohl aber schwieriger werden, denke ich. Die sind aber mit HID noch weniger abzuwickeln als mit CDC. Ralf Hellener schrieb: > Man kann ja eine Scheinfestplatte simulieren Bei MSD (mass storage device) gibt es das Problem, daß zwei Geräte gleichzeitig versuchen, ein darauf befindliches Dateisystem zu verwalten, aber nichts voneinander wissen. Das geht in die Hose.
Ralf Hellener schrieb: > Bei großen Datenmengen, also z.b video, oder bildverarbeitung, wirds > wohl aber schwieriger werden, denke ich. Davon ist jetzt zum ersten mal die Rede, wolltest du urprünglich eine "Maus" zum Videoplayer umrüsten oder wie darf man diesen Thread nun verstehen? ;) > eine Möglichkeit fällt mir noch ein. Was haltet ihr davon. > > Man kann ja eine Scheinfestplatte simulieren. Und man holt die Daten > einfach ab. Man müsste dann aber überlegen wie man Zugriffskollisionen > in den Griff bekommt. Schau dir doch einfach mal an, welche Geräteklassen zu welchem Zweck vom USB spezifiziert worden sind. Sound (UAC) und Video (UVC) wurden da auch berücksichtigt, es gibt also eigentlich keinen Anlass eine Geräteklasse im Zweck zu entfremden. Such mal nach "USB Audio Class" bzw. "USB Video Class".
Die Frage mit Mausimitation und Geschwindigkeit ist natürlich berechtigt. Meist hat man ja nur Schlater, Signale oder Daten, was bei mir auch der Fall ist. Da würde natürlich RS232 dicke reichen. Ich habe mir aber auch schon Dinge überlegt, wo die Dantenmenge sehr groß sein wird. Aber man muss ja erst überhaupt mal rein kommen. Das Lernen ist doch recht steil. D.h. mann muss sehr viel erst wissen, können, dass überhaupt mal was läuft. Dann wird das Lernen flacher. MSD: könnte man das so funktionieren. Verreigelungen: Host, Device hat Priorität. Verreigelungsfile: Knowledgehost, Knowledgedevice. vor dem Zugriff auf Datenfile erst Prüfen, ob je,o jemand gerade will. kann passieren sein beide Knoweldege sind da. dann hat Device vorrang. Host löscht Knowledgehost und wartet. Wenn Host am lesen, wartet Device. Beim Beednen jeweiliger, löschen jweiliges KnowledgeXX
Ralf Hellener schrieb: > muss ja erst überhaupt mal rein kommen. Das Lernen ist doch recht steil. > D.h. mann muss sehr viel erst wissen, können, dass überhaupt mal was > läuft. Dann wird das Lernen flacher. Ja, ist klar und auch keine Schande. Aber nutze doch deine Zeit effektiver und lese dich in USB ein bevor du anfängst unspezifisch Geräteklassen vergewaltigen zu wollen. > MSD: könnte man das so funktionieren. Lass es, das macht so keinen Sinn. Du willst die "großen Datenmengen" ja bestimmt in-time weiterverarbeiten können, da sind zusätzliche Dateizugriffe zwischendurch keine gute Idee. Abgesehen von weiteren Problemen, die diesem Ansatz anhaften.
Ralf Hellener schrieb: > Verreigelungen: > Host, Device hat Priorität. > > Verreigelungsfile: Knowledgehost, Knowledgedevice. Funktioniert so nicht, es sei denn, Du bekommst den Host dazu, das Dateisystem überhaupt nicht zu cachen, also auch nicht die FAT und Directories.
Wegen des ganzen Treibergedönses baue ich solche Input-Devices nur noch mit Netzwerk-Anschluss (Arduino & Ethernet-Shield, zusammen ca. 40 Euro). Jeder Rechner hat heute einen Netzwerkanschluss und die IP-Kommunikation ist mit nahezu jeder beliebigen Skript- oder Programmiersprache auf dem PC/Mac/Linux zu erledigen. Ich weiss, im ersten Moment klingt das maßlos übertrieben, aber angesichts der gefallenen Preise und der unkomplizierten Handhabung in der Praxis hat das nur Vorteile - klick und geht, immer und überall. USB verwende ich bestenfalls für die Stromversorgung ...
und dein Rechner hat genauso viele Ethernetports, wie USB-Anschlüsse? Man könnte natürlich auch Usb-Ethernet-Adapter benutzen. Allerdings braucht man ja noch einen USB-Anschluss für den Strom
Man könnte ja auch über USB statt einer Maus einen Netzwerkadapter...
Vlad Tepesch schrieb: > und dein Rechner hat genauso viele Ethernetports, wie USB-Anschlüsse? Nö. Aber mein HP Procurve Switch hat noch hinreichend Ports frei, um einiges an Ideen zu realisieren. Und 40Euro für einen Netzwerkknoten sind viel. Ich nehme für kleine Sachen immer den PIC18F67J60, damit ist eine Ein-Chip-Lösung für weniger als 10 Euro drin. fchk
Die kann man sich frei ausdenken. Kollisionen sind recht unwahrscheinlich, denn MAC-Adressen verlassen das lokale Netzwerk nie. Und wenn man ganz genau sein will, holt man 'ne alte Netzwerkkarte aus dem Schrott und verwendet deren MAC-Adresse.
für Krten, die gewerlich verkauft werden, ist das aber schwierig. Es kann doch passiern, oder der Anwender benötigt mehrere Geräte. Gut man kann da auch mit Dip-Schalter was machen. Wie machst du das mit den Ansteuerungen und Abholung der Daten. Apache Server im Microntroller ist sicher nicht immer sinnvoll. in der Regel willst du ja was steuern. ev. vom pC aus
Ralf Hellener schrieb: > für Krten, die gewerlich verkauft werden, ist das aber schwierig. Es > kann doch passiern, oder der Anwender benötigt mehrere Geräte. Dann verwendet man MAC-Adressen von Herstellern, die es nicht mehr gibt oder gibt dem Benutzer die Möglichkeit, die MAC-Adresse gegebenenfalls zu ändern. > Wie machst du das mit den Ansteuerungen und Abholung der Daten. Apache > Server im Microntroller ist sicher nicht immer sinnvoll. > in der Regel willst du ja was steuern. ev. vom pC aus Ist das eine Frage? Apache ist sowieso nicht auf µCs nutzbar (allenfalls auf sehr großen ARMen, auf denen dann auch Linux o.ä. läuft), aber kleinere Webserver wie der allseits bekannte AVR-Webserver können da verwendet werden. Und darüber --genauer über deren CGI-Funktionalität-- lässt sich sehr wohl auch etwas an den µC übertragen, was zu Steuerungszwecken verwendet wird.
Rufus Τ. Firefly schrieb: > Ob das auch mit der auf dem .Net-Geraffel aufsetzenden > Microsoft-Perversion "Managed C++" bzw. "C++/CLI" funktioniert, entzieht > sich meiner Kenntnis. Mit C++ hat das mehr als den Namen nicht > gemeinsam. Das ist so nicht richtig. Der C++/CLI Compiler kann genauso viel C++ wie der Native-C++ Compiler und die normale C/C++ Runtime kann man auch benutzen, weil der Compiler beliebig managed und unmanaged Code mixen kann. Du kannst dein ganzes Programm auch ohne CLI Erweiterungen schreiben. Die libusb.lib aus der libusb-win32 Distribution kann man einfach linken.
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.