Hallo zusammen, ich bin auf der suche nach einem USB controller, über den ich mind 8 analoge Poti-Achsen mit dem PC verbinden kann. Ich bin leider kein Programierer. Ich komme aber mit einem Schaltplan zurecht an welchen pin ich was verlöten muss. Aber diese Microcontroller brennen und programieren sind für mich leider böhmische Dörfer. Ich bin aber wissensdurstig, mich würde interesieren: geht das überhaupt? welchen microcontroller sollte man nehmen? wie wird der programiert? mit welcher Sprache.? ( vielleicht ahnl. musterbeispiel ) Ist diese Sprache kompliziert? was braucht man an Hard und Software vieleicht gibts jemanden da draußen der ein Controller gegen Obolus machen kann. ich wäre für ein paar Anregungen echt dankbar. Viele Grüße Carsten
Nun, ich für meinen Teil würde für sowas sicherlich den C8051F320 von SiLabs ins Auge fassen. Der hat 17 analoge Eingänge, für diese Aufgabe mehr als ausreichend FLASH und eben USB (wahlweise Low-Speed oder Full-Speed). Bei der kostenlosen IDE ist eine fix und fertige in C geschriebene HID Firmware dabei, die zumindest schon mal einen analogen Eingang mißt. Das kann man ruckzuck anpassen. Und wie stellst Du Dir das Weitere vor? Ich mein, wie willst Du denn, wenn Du so gar nicht programmieren kannst, an die über USB übermittelten Daten herankommen? Der programmierte Controller ist eine Sache, die Software auf dem PC ein ganz anderer Schnack. Selbst wenn Du die Daten von irgendwo herbekommst, was machst Du dann damit? Auswertung, Visualisierung und was weiß ich mach sich auch nicht von selbst...
Ganz ohne Programmierung, dafür aber nur vier Achsen: http://www.codemercs.com/JoyWarriorD.html Musste halt zwei (oder mehr) gleichzeitig verwenden.
USB und acht analoge Eingänge, dann merke dir auch einmal PIC18F4550. Sonst schliesse ich mich René an. Der grosse Aufwand liegt in der Software.
Vielen Dank für die Anregungen!! Aber ich glaube ich muss die Sache mal anders angehen. Ich kann was und ihr könnt was. Mit Geldangeboten in Foren ist das ja immer so eine Sache. Ich biete euch ein Flug in einer Cessna 172 mit 2 Personen nach Norderney oder Juist, Wangerooge, Langeoog und zurück an, ab Münster, Hamm, Stadtlohn, Lingen, Dortmund, oder Osnabrück. Morgens hin abends zurück. Ich brauche einen USB Joystickcontroller der von Windows als Joystick erkannt wird. Der sollte 11 analoge Achsen haben und optional soviel Tasten wie möglich. Jemand muss mir sagen: Welchen Mikrocontroller oder Chip muss ich nehme. Welche Hardware muss ich zum brennen des Chips haben. Welche Software brauche ich für die Brenner Hardware. Jemand erstellt mir das File was ich auf den Chip brennen muss. Jemand erstellt ein Diagramm mit Anschlussbelegung der Pin´s, für die Potis, Tasten und USB connector Die Platine würde ich mit meiner CNC Fräse machen und löten bekomme ich auch wohl hin. Ich möchte für mich und meine Fliegerkollegen 2 Mot Verfahrenstrainer bauen, deswegen brauche ich die ganzen Achsen für: Querruder, Seitenruder, Höhenruder, Trimmruder, Landeklappen, 2x Gas, 2x Mixture, 2 x Prop, die Tasten für andere Funktionen Vielleicht erbarmt sich ja jemand, ich weiß ja wie das ist wenn jemand in solchen Foren schreibt kann mal jemand was für mich machen J Viele Grüße Carsten
Hi, wieso nimmst Du kein Gamepad? Die haben doch analoge Steuerknüppel. Je nach auslegung müßte man die Eingänge doch zweckend- fremden können. Ist bestimmt billiger als ein Cessna-Flug träum. Ich komm übrigens aus Hamm ;-) Grüße, André
Was soll denn auf dem PC laufen? WOher sollen die Treiber kommen? Wenn du einfach als Standard-Joystick von Windows erkannt werden willst, dann hast du nicht so viele Achsen zur Verfügung. Wenn du 3 Billig-USB-Joysticks nehmen würdest hättest du genug Achsen und Tasten und kannst die Standardtreiber nehmen ohne was neues zu programmieren. Das würde ich dir empfehlen! (Oder alternativ 3 USB-Gameport-Konverter?) Wenn du Controller usw. über USB an den PC schliessen willst, dann mußt du selber Windowstreiber entwickeln. Nichttrivial! Wenn es unbedingt ein eigener Controller sein soll, und USB und du keine Treiber entwickeln willst, dann nimm z.B. einen AVR und schliesse Ihn über eine USB-Serielle (FTDI-Chip oder FertigTeil) an den PC - dann mußt du ebenfalls keine extra Treiber entwickeln, sondern brauchst nur die AVR-Software, was leicht sein sollte, für viele hier. ALs Joystick wird dene Hardware dann aber nicht erkannt. jörn
Hi, mal angenommen: Er hat eine Software, die von einem HID Analogachsen auf Funktionen mappen kann. Dann: Ein oder mehr Gamepads/Joysticks ausschlachten und an die USB-Ports dranpappen. Die einzelnen Achsen sollte man dann in der Software mappen können. Aber: Wir wissen weder was über die Software, noch wie schnell die einzelnen Achsen reagieren sollen. Wenn die Software selbstgestrickt ist, könnte man echt besser einen FTDI (ich find die Teile schäbig, da gibt bessere) nehmen und mit Hilfe eines Controllers die Analogwerte einlesen und via RS232->USB übermitteln. Wenn gaaaaanz langsam erlaubt ist, auch ohne das USB-ZEugs und direkt RS232. Grüße, André
Da Ihr anscheinend meinen Wink mit dem Link nicht verstanden habt, hier noch mal: 8 Analoge Achsen + 112 Knöpfe + Hat-Switch funktioniert ohne Probleme mit AVR und Standard-Windows-Joystick-Treiber. Wer es nicht selber bauen will kann es hier (http://www.mindaugas.com/products/MJoy16-C1/) für 33 Euro kaufen. Es reicht EIN USB-Port. Es muß nix ausgeschlachtet werden. Zitat: " MJoy16-C1 does not require any software or drivers to operate. It is a true Plug-and-Play device and automatically appears in Windows as "MJ16" - an 8 axes, 112 buttons and 1 hat switch joystick."
Die von mir erwähnten JoyWarriors*, die zwar nur vier Achsen unterstützen, sind ebenso HID-Joysticks. Da man davon auch mehrere simultan betreiben kann (erfordert halt einen USB-Hub), sehe ich da durchaus eine realistische Anwendungsmöglichkeit. Mit drei Stück sind zwölf Achsen bedient. Und bis zu 16 Tasten pro Chip sind auch noch mit drin. Reicht das nicht? *) http://www.codemercs.com/JoyWarriorD.html
Muß es zwingendermaßen nen Joystick sein? Und welche Geschwindigkeit? Ich mein brauchst du das zum spielen oder so? Weil osnt könnte man ja auch nen AVR die Potis auslesen lassen (eventuell per Multiplex, man könnte sogar (je nach größe und erlaubte Kosten) belibige Taster betreiben... Man müßte halt die Auswertung am PC noch machen aber dafür gibt es ja RS -> USB Umsetzer.
<Zitat> Ich möchte für mich und meine Fliegerkollegen 2 Mot Verfahrenstrainer bauen, deswegen brauche ich die ganzen Achsen für: Querruder, Seitenruder, Höhenruder, Trimmruder, Landeklappen, 2x Gas, 2x Mixture, 2 x Prop, die Tasten für andere Funktionen </Zitat> Also eine Art "Flugsimulator" zu Übungszwecken in Verbindung mit einer (nicht weiter benannten) PC-Software, die den Anschluss von USB-Joysticks unterstützt. Da dürfte AVR mit V.24 und USB-Adapter nicht ganz kompatibel sein. ...
Hallo, also als Software dient Microsoft Flightsimulator 2004, der sogar mehr als 11 Achsen verarbeiten kann. Die Sachen von www.mindaugas.com sind im Prinzip super, der hat aber Lieferprobleme und sind nur für nicht kommerzielle Projekte wenn das gut läuft mit dem Simulatorbau, will ich vielleicht auch mal welche verkaufen. Die JoyWarriors von www.codemercs.com sind eigentlich das was ich brauche nur halt nach Möglichkeit mit 11 Achsen, die brauchen keinen Treiber und werden als Gamecontroller oder Ähnliches erkannt. Man kann da schon drei oder vier von über ein USB Hub laufen lassen, dann habe ich aber drei oder vier mal die Kosten. Ich dachte das man so was auch mit einer Einheit losen kann. Stichwort AVR oder C8051F320 von SiLabs, was ist das genau für ein Chip wie muss man daran gehen, kommt da auch ein nicht Programmierer mit Tutorials zurecht ? Diese Chips müssen ja irgendwie programiert werden, dazu braucht man Software und Hardware und natürlich muss ich hinterher wissen wie die Pins belegt werden. Mindaugas nimmt glaube ich auch AVR, da müsste man doch der Lösung irgendwie näher kommen. Und wie gesagt, das Angebot oben steht ja noch ;-) Und Angebote können ja auch irgendwie abgeändert werden.
Was Mindaugas Milasauskas gemacht hat, USB mit einem AVR, schüttelt man sich nicht so eben aus dem Ärmel. Aber ich kann mir vorstellen, dass er Dir seinen Code gegen entsprechende Bezahlung auch für kommerzielle Zwecke lizensiert. Ich finde, wenn man selber was dran verdienen will, sollte man schon bereit sein, die Mitwirkenden zu entlohnen. Mit einem uC, der USB unterstützt, wäre es schon einfacher das von Grund auf neu zu programmieren, zumal es da schon Beispiel für HIDs (USB-Geräteklasse für Eingabegeräte) und evtl. sogar für Joysticks gibt. Neben Silabs haben auch Microchip (PIC), TI (TUSB), Cypress (EZ-USB u.a.) und weitere Hersteller Controller mit USB.
Es wird IMHO schwierig werden für Mindaugas Milasauskas den Code zu lizensieren, da er ihn selbst von Igor Cesko übernommen verbessert abgeändert hat. Ohne den kommerziellen Aspekt glaube ich, dass es sehr leicht wäre, den Code abzuändern und auf die Bedürfnisse von Carsten Börger zurechtzuschneiden. Ich habe mir selbst daraus einen Gameport&C64-zu-USB-Adapter gebaut. Die Lösungen mit anderen uC mit echter USB-Unterstützung gehen natürlich auch. Aber es muß dann halt ebenfalls ein wenig an Software entwickelt werden, was bei einer späteren Kommerziellen Anwendung nicht mal so an einem Nachmittag zu machen ist. Mit einem "Freiflug" ist diese Arbeit wahrscheinlich nicht zu entlohnen.
Also jezt mal ne Idee für die tasten, könnte man nicht das PS/2 Protoloöö benutzen? Man müßte jan ur die tasten Emulieren (ist jan icht so anspruchsvoll) und hätte ne ganze menge belibig anornebar zur Verfügung, und müßte im Flightsimulator nurnoch die gewünschten Tasten zuweisen. Die Potis müßten dann dneke ich shcon mit nem AVR zu verarbeiten sein, ihr wolt ja bestimmt nicht bei MACH6 in microsekundentakt die Postione supergenau anfahren. Und vileicht könnte man wirklich den Gameport mißbrauchen? Auf jedenfall ne interessante Sache wie ich finde, besonders weil ich früher auch son bsichen mit Flightsimulator rumgespielt hatte, leider bin ich immer abgestürzt g Was mir jezt auch noch so einfiele wäre, das man einfach einen Joystick emuliert... Ich habe sowas mal für ne Tastatur gemacht da konnte ich dan eingeben: Drücke Taste x in 50 sek oder so, weiß jezt aber nicht genau ob das mit Joystick auch ginge, aber dann könnte man ja im prinzip ein belibiges Protokoll benutzen um die Positionen der Potis dem Flightsimulator vorzugaukeln! Werde mal ein bsichen rumgoogeln, das interessiert mich jezt echt mal ;) Nur fliegen ist schöner :)
Find ich ja klasse das ihr euch interesiert!! @ Läubi danke auch fürs googlen!! Also ich habe nochmal nachgeschaut Flightsimulator 2004 unterstützt 27 Achsen (mir reichen aber erstmal 12) und weitaus mehr als 200 Tasten (habe sie nicht alle gezählt) Klar bin ich auch bereit für Lizenzrechte zu zahlen, wenn der Preis halbwegs erträglich ist. Ich habe mindaugas eine Mail geschickt, bin mal gespannt was er sagt. Frage: Sehe ich das richtig (wenn falsch bitte antworten) Ich brauche den AVR Chip Einen Programmer, um ihn mit dem HEX.file (z.B. MJoy von Mindaugas)zu flashen. Matrix der Pinbelegung. Platine Fräsen, löten , Fertig viele Grüße Carsten
@noname: > Ich habe mir selbst daraus einen Gameport&C64-zu-USB-Adapter gebaut. Interessant! Ich bin nämlich auch gerade dran, die Software etwas zu ändern (für einen Spezial-Controller). Bin allerdings in AVR-Assembler nicht so fit und gerade noch dabei, mich in den Code einzuarbeiten. Sehe ich das richtig, dass während des Auslesens der ADCs und der Button-Matrix keine Interrupts auftreten? Weil ich brauche da eine kleine Zählschleife, um die Grösse eines externen Kondensators zu bestimmen. Um den von mir noch nicht ganz verstandenen Code möglichst nicht zu (kaputt-)modifizieren, würde ich das gerne in Software mit Polling in einer kleinen Zählschleife machen (also ohne einen Timer oder Interrupt zu benutzen). Das ganze Auslesen würde auch nicht mehr Takte als die ganzen ADCs-Auslese-Routinen brauchen. Gruß, Stefan
@Stefan In der Regel werden keine Interrupts währende der ADC-Auslese-Routine auftreten, da der PC hier nur ca. alle 10 ms das USB-Gerät kontaktiert und damit den externen Interrupt auslöst. Garantiert ist das aber nicht. Abschalten oder Aussetzen der Int0-Routine ist nicht zu empfehlen, da das USB-Gerät immer auf Anfragen entprechend reagieren muß. Am besten setzt Du Dir ein Flag beim Start Deiner Meßroutine, welches Du dann in der Int0-Routine wieder löschst. Ist das Flag nach dem Meßvorgang noch gesetzt, ist die Messung OK. Andernfalls nochmal messen.
Also ich habe bsiher nur ein Dokument gefunden welches sich damit beschaeftigt wie man erknne kann ob EIngaben von einem Gerät kommen oder ob sie Simuliert sind (also muß das ja möglich sein) über DirectX schnittstelle... Frage ist... nuzt Flightsimulator DirectInput? Ich denke mal scho, welche DX Version ist den "minimum" für FS2002?
> da der PC hier nur ca. alle 10 ms das USB-Gerät kontaktiert
Der PC kontaktiert das Gerät in jeder Millisekunde. Würde er das
nicht machen, würde das Gerät nach spätestens 3 Millisekunden ausgehen
(wird supended). Stichwort: Low-Speed Keep-Alive, Spezifikation
11.8.4.1
@noname: Vielen Dank, jetzt blick ich da einigermassen durch! Das mit dem Flag werd ich mal so machen, wie von dir vorgeschlagen. @René König: Klar, aber es heisst da: "every 1ms only in the absence of any low speed data" Ist nicht schon der alle 10ms gepollte Datenstrom etwas, was den Bus "ständig" belegt und deshalb keine keep-alive-Packete nötig sind? Gruß, Stefan
> Ist nicht schon der alle 10ms gepollte Datenstrom etwas, was den Bus > "ständig" belegt und deshalb keine keep-alive-Packete nötig sind? Nein, das reicht nicht. Wenn die Leitung länger als 3 ms idle ist, geht das Gerät in Suspend State. Wenn Du nur alle 10 mS pollst, ist das Gerät beim zweiten Mal schon aus. Theoretisch kann sich ein Gerät zwar bis zu 10 ms Zeit lassen bevor es sich abschaltet, aber geh mal davon aus, daß die Geräte das nicht bis zur letzten µs auskosten. Quelle: Spezifikation 7.1.7.6
@René König: Ok, tnx. Ich werde auf jeden Fall die eigentliche Einleseroutinen so gestalten, dass ein Interrupt zwischendrin nix ausmacht, bzw. mit einem Flag arbeiten, so wie es noname vorgeschlagen hat. Gruß, Stefan
@noname: Noch eine Frage, muss ich eigentlich auch die JoystickReport1Size bzw. JoystickReport2Size anpassen? Bzw. muss ich nicht genutzte Bits irgendwie mit Dummies füllen? Ich habe jetzt den ReportDescriptor (sowie dessen Grösse) meinen Wünschen nach angepasst, und zumindest das usb-Subsystem meines Systems (debian, 2.4er Kernel) erkennt das Gerät, allerdings erkennt der Joysticktreiber nichts mehr. Ich brauche für meine Anwendung "nur" 5 analoge Kanäle/8-Bit (ID1) und 6 Buttons (ID2). Also müsste ja die Länge von JoystickReport1Size = 1Byte ID + 5 Bytes Daten = 6 Bytes und von JoystickReport2Size = 1Byte ID + 1Byte Daten = 2 Byte sein, wobei ich ja gar nicht das ganze letzte Byte brauche, da ich ja nur 6 Buttons habe (<- Muss ich da irgendwie auffüllen?). Jedenfalls geht das Auslesen der Joystickdaten nun weder mit JoystickReport1Size=8 JoystickReport2Size=4 (default) noch mit meiner geänderten Version: JoystickReport1Size=6 JoystickReport2Size=2 Vielen Dank schonmal, Stefan
@Stefan Ja, ich glaube es muß aufgefüllt werden - Stichwort Padding. Die JoystickReport1Size/JoystickReport1Size müssen auch auf jeden Fall stimmen. Wenn Du nur 8 Bytes benötigst, brauchst Du übrigends keine zwei Reports, dann entfällt auch das Report-ID-Byte. Im Anhang mein Report-Descriptor (2x8bit analog und 2 Buttons)
@noname: Super, vielen Dank! Jetzt läuft es soweit. Hab jetzt auch so wie du auf den zweiten Report verzichtet. Gruß, Stefan
Das Interessante am MJoy16-C1 ist, dass es sich dabei um ein Low-Speed USB Gerät handelt, aber eine riesige Menge an Daten für die vielen Achsen und Tasten übertragen werden muss. Low Speed USB begrenzt aber die Daten pro Transfer auf 8 Byte und auf einen Transfer alle 8msec. Maximal kann ein Low Speed USB Gerät zwei Endpoints haben, also der Datendurchsatz mal 2. 8 Achsen a 10 Bit verbrauchen schon mal 16 Byte, da nicht alle Treiber mit gepackten Daten klarkommen. Dazu kommt dann das ganze Paket an Buttons, Hatswitches, Encodern etc. Also wird die Latenz von dem Ding nicht gerade berühmt sein. Was das selber Entwickeln von der notwendigen Firmware betrifft: Für einen Rundflug würde ich sowas nicht machen. Selbst wenn ein USB Stack vorhanden ist und mann weiss was man macht sind da ein paar Wochen schnell weg.
Bei MJoy wird pro 10 ms immer ein Report mit 8 Byte über einen Interrupt-In-Endpoint übertragen. Dabei geht je ein Byte für den Report-ID drauf. In den ersten Report kommen z.B. 5 Achsen (8+5*10=58 Bit), in den zweiten 3 Achsen und 26 Buttons. Abgesehen von weiteren Verzögerungen ergibt sich hier also eine Latenz von 20 ms. Je nach Wichtigkeit können auch mehrere Reports unterschiedlich oft gesendet werden (z.B. 1,2,1,3,1,2,1,3...). Übrigens kann ich mir kaum vorstellen, dass man den Steuerknüppel in 20 ms von links nach rechts bewegt. Warum sollte der Treiber nicht mit gepackten Daten klarkommen? Das ist doch im HID Standard genau so vorgesehen. Sind dir konkrete Fälle bekannt?
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.