| |
|
|
E.T. | Ach ja, ich traue mich noch mal dranne, mir den direkten Zugriff auf die (Standard-) USB-Funktionen zu wünschen Und damit meine ich den Zugriff auf "richtiges" USB, nix Adapter von COM zu USB So in der Art wie @ReadCom$(N1,N2) , nur das halt N1 auch als z.B. "USB023" angegeben werden kann... |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 01.06.2015 ▲ |
|
|
|
|
| Hm das Ergibt imho keinen Sinn.
Du kannst auch eine USB-Maus nicht per WriteCom dazu bewegen über den Tisch zu hüpfen. Schließlich sind es nur die Gerätetreiber die mit dem jeweiligen Microcontroller des Gerätes kommunizieren und wiederum für den Usermode Befehle für die Programmierer bieten. Es gibt also keine solche Schnittstelle die Du ansprichst, ausgenommen der jeweilige Gerätetreiber bietet sie und dann ists wiederum keine Standard-Sache für XProfan sondern auch nur wieder "DLL-Befehle" eines speziellen Treibers. |
|
|
| |
|
|
|
GDL | Träum,
- ein Xprofan Atmel USB Treiber mit Atmel USB.asm Libary - ein Xprofan PIC USB Treiber mit PIC USB.asm Libary
Ist nur ein Traum. Grins.
Grüßle Georg |
|
|
| |
|
|
|
E.T. | iF (01.06.15)
Hm das Ergibt imho keinen Sinn. ...
Was ergibt dabei keinen Sinn bzw. warum soll ich nicht mit einer USB-Schnittstelle (bzw. dem Garät daran) reden können ? Klar wird eine Maus keine Befehle empfangen. Aber meine Wetterstation (Problemkind) meldet sich bei Windows als "HID-konformes USB-Eingabegerät" an, ohne irgendwelche Treiber zu installieren. Diese schickt einfach regelmäßig Daten an den Anschluss, und wenn ich diese lesen könnte, wäre ich ja schon froh (geschweige Befehle zu schicken wie "Speicher löschen" etc.). Spezielle Sachen muss wohl ein Treiber machen, aber ein simples lesen wäre schon ganz gut. Klar ist das nicht so einfach wie bei einer "festen" COM-Schnittstelle mit der ganzen "Nummerierung" über Hub 1,2,... aber irgendwie ist da über XProfan absolut kein rankommen. |
|
|
| XProfan X2Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 01.06.2015 ▲ |
|
|
|
|
Peter Max Müller | Hi. Keinen Schimmer ob du da was mit anfangen kannst.
Die mcHID.dll und, in LibertyBasic, [...]
Ja, Ja ich weiß...eine dll.....
Gruß |
|
|
| |
|
|
|
| E.T. (01.06.15)
Was ergibt dabei keinen Sinn ... Aber meine Wetterstation (Problemkind) meldet sich bei Windows als "HID-konformes USB-Eingabegerät"
Davon spreche ich doch: Das Gerät ist danach sowas wie eine Tastatur, nichts womit Du direkt per USB zu sprechen hättest - der Treiber dieser Tastatur bringt Dir die Funktionen in den UserModus.
Es gibt einen "Standard" der USB<>Gerätekommunikation und das sind die Treiber. Was Du meinst macht eventuell ja nur Sinn wenn Du einen eigenen USB-Microcontoller (FTDI?) programmieren möchtest. Dann könntest Du einen Treiber schreiben der wiederum für den Usermode (also für gemeine Prozesse) eine Schnittstelle bietet die dann meinetwegen Bytes sendet oder empfängt. Dies ist dann aber wiedermals proprietär was wiederum den Ruf nach "direkt mit USB sprechen" inhaltlich widerspricht. |
|
|
| |
|
|
|
| Nachtrag: Schau mal, gibts hier Input für Dein HID? [...] |
|
|
| |
|
|
|
E.T. | Hm, wie drück ich's denn am besten aus...
...der Treiber dieser Tastatur bringt Dir die Funktionen in den UserModus.
Jo, das macht Windows alleine. Ebenso vergibt Win irgendwelche Ports und / oder ID's an die USB-Geräte... macht Windows auch alleine. Und genau darauf will ich zugreifen, man bekommt ja nicht einmal heraus, welchem Gerät welcher "Port" zugeordnet ist. Das muss man doch irgendwo per API (oder besser im XProfan ) auslesen können.
Hab jetzt schon ewig im I-Net gelesen, damit haben wohl alle Programmier-Sprachen ihre Probleme |
|
|
| XProfan X2Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 02.06.2015 ▲ |
|
|
|
|
| Moin!
Sowas lässt sich doch meist gut per WMI auslesen,
mal per WMI Code Creator browsen: [...]
Die wmi.inc: [...] |
|
|
| |
|
|
|
| Habe Dir mal was rausgesucht:
|
|
|
| |
|
|
|
GDL | Hallöle,
ich weiß, was E.T. meint. Ich habe ja auch eine USB Programmiersoftware die ohne zusätzliche Treiberinstallation auf die Atmel interne Controler USB Schnittstelle zugreift. Allerdings, geht die Software nur, wenn winavr mitinstalliert ist. Also liegt der Schlüssel bei winavr.
[...]
Oder soweit war ich auch schon: [...]
Nur das letzte Glied in der Kette finde ich nicht. Die USB Übergabeschnittstelle Programm nach Treiber. Und da gibt es bestimmt wie bei den alten Schnittstellentypen auch ein genormtes Interface.
[OFFTOPIC]Ich habe es bei mir nun so gelöst - Verwenden von FTDI Schnittstellenbausteine - in einer Schleife von 1 bis 50 wird geprüft ob es den virtuellen COMport gibt - Wenn es diesen Port gibt, wird eine Kennung gesendet - Kommt vom Controler die richtige Antwort, habe ich den richtigen virtuellen Port gefunden und das PC Programm beginnt seine richtige Aufgabe.[/OFFTOPIC]
Hilft zwar dem Threadersteller nicht, aber vielleicht gibts für so manchen Atmega-Anwendern die zündende Idee.
Grüßle Georg |
|
|
| |
|
|
|
| GDL (02.06.15)
ich weiß, was E.T. meint. Ich habe ja auch eine USB Programmiersoftware die ohne zusätzliche Treiberinstallation auf die Atmel interne Controler USB Schnittstelle zugreift.
Naien! On Linux and MacOS X no kernel driver is needed. Windows requires a driver for USBasp: usbasp-windriver.2011-05-28.zip (70 kB)
Du redst nie direkt mit der Hardware unter Windows ohne Treiber, jedenfalls nicht seit Windows NT. |
|
|
| |
|
|