I am trying to find out how I should go about making my own gamepad compatible with windows based games. I have used some time to read up on windows drivers but I feel kind of lost and unsure about how I should solve my problem. What i am asking for is some guidance toward what kind of solution or approach I should take.
So I have made a Arduino based GamePad which communicates with the computer over serialport(usb). From here I assume I need to make a driver which identifies itself as a GamePad(Device driver, Plug and Play driver)? I am not sure if I am done at this point or if I have to be compatible with DirectInput somehow?
-Michael
Forum thread about arduino and ppJoy virtual joystick.
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1210699098
Related
I have just begun a new project. I'd like to make my own simplistic computer mouse, since i'd like to learn how to program hardwear drivers and understand the protocols the hardwear uses. I have experience in both desktop and microcontroller programming. However, I haven't got a clue about how to write drivers. I'm working on a mac with OS X and the mouse only needs to be able to talk with OS X. I expect to use a MSP430 microcontroller from TI. I intend to connect my mouse via USB. I simply want to be directed in the right direction not specific help with the coding, yet. :)
I therefor have a couple of questions:
Should I write my own driver or is it possible to use a standard one?
If yes, what kind of driver should be written and where do you begin?
What kind of data should be sent to the mac to say, "Hey, I'm a computer mouse"?
Which protocols should I read about?
You can check USB HID articles for OSX side and if there exists for MSP430.
I think that you can use any other driver, if you emulate same behavior of the target device on your MSP side.
I'm trying to implement an AVRCP/A2DP connection between my Android phone and my car PC. The A2DP bit basically works out of the box so no issue there. I want the PC to be the AVRCP CT (controller) and the A2DP sink. The phone is the AVRCP TG (target) and the A2DP source.
Where I'm having trouble is getting any sort of AVRCP connection that I can use. Windows 7 comes with a toolbar application that at least provides the basic play/pause/skip/stop type functions. So it definitely works with the software I have without any extra drivers or otherwise. However my searching has produced little results on any way to do this or documentation on creating an L2CAP connection which I believe I need.
The 32feet.NET libraries don't support L2CAP connections unless you use a Broadcom/Widcomm stack. Buying a new BT USB device may be a viable solution but at the moment I'm trying to do this all in software :). i.e. like this although there a problems noted there that weren't solve (or reported as solved)
link: How can I establish an AVRCP connection from Windows 7 (controller) to phone (target) using L2CAP on Widcomm SDK?
I'd prefer to do it C# if possible but if I had some kind of library to interface with my code, that would be fine (like the 32feet.NET library which works quite well for the things it does work on.)
This is about the closest I've got but is all a bit Greek to me and not quite enough to get me started (I'm an embedded guy):
http://msdn.microsoft.com/en-us/library/windows/hardware/ff536674(v=vs.85).aspx
Is Bluetooth really such a mess on Windows that it seems to be from my searching? There are multiple different stacks that all seem to be significantly different in terms of the API etc.
Can anyone point me in the right direction? I've done a lot of searching/reading other posts here and elsewhere and not really made any progress.
Thanks
Christian
I'm working with various (mostly Bluetooth) development boards (ConnectBlue, Ubertooth, USRPs etc.) in order to research about Bluetooth communication behaviour at PHY level. In order to get some more insights I'm looking for a way to debug the Bluetooth stack on a Windows 7 Desktop computer. My use-case is relatively simple: I have custom baseband implementations, which establish connections with the Windows computer. I'd like to see everything the Bluetooth hardware/driver does.
I'm not sure how to approach this: I'd like to see when the Bluetooth Chip/Windows driver receives a Signal, and how it (the message) gets interpreted/formatted/passed through the various APIs concerned. Mostly this relates to kernel debugging.
Is there a way to display the state of the attached hardware in Windows in WinDBG? Maybe to perform (Kernel) API logging on the Bluetooth kernel service?
I hope somebody more familiar with device driver debugging and Windows Kernel services can give me some pointers here.
Since you don't appear to have gotten any hits on this, I'll post what I can.
I don't have any definite answers, but on the NTDebugging blog they often do hardware level debugging in windbg.
I.e.
http://blogs.msdn.com/b/ntdebugging/archive/2007/06/22/where-the-rubber-meets-the-road-or-in-this-case-the-hardware-meets-the-probe.aspx
To be honest this is going to require extensive knowledge not only of your hardware, but also of the deep internals of windows, and how the bluetooth stack is written, but the WDK would probably be a good place to start for understanding the bluetooth stack. I would also check out the blog for tips and tricks.
The other place to check and ask questions is http://osronline.com/ It's one of the better communities about device drivers, so they should have some reasonable tips on doing what you're trying to do.
I am planing to spend few days a week writing a driver for a Greenpacket USB WiMax modem. Greenpacket only provides Windows driver with it and as I am fond of Linux and Mac I feel very bad not having driver for them.
I have experience writing C++ programs so I think it won't be hard for me. Even I like C++ programming very much. I have never written drivers but I know some concepts. I have PDF of the device specification from the company's website.
I would like to ask if I can write driver with that provided specifications? If yes what would be my starting point assuming I would like to write it for MAC first and then Linux. I am reading this article right now but your experiences would be of great help.
The product specifications sheet does not provide enough data to write a device driver. You are going to need low-level information about how to speak with the WiMax device via USB. You are probably also way out of your depth of you think a product sheet is enough information to write a device driver.
My application needs to behave as a virtual joystick (imagine dragging a square with the mouse and translating that to the output of an analog joystick) and send some keystrokes over the network to another computer where the driver would receive that input.
I only need to support XP, Vista and Win7.
Maybe it can be done without writing a driver. I tried sending keystrokes with SendKey() which seemed to work but don't know how to emulate an analog joystick.
I've downloaded the VDK and been reading everything I can find on the subject but there are lots of things I still don't understand. Can you please point me in the right direction?
Should I build a kernel-mode or user-mode driver?
Can my driver act as a server for an app on the network?
Do you know good tutorials / books / samples that can help me with this.
Thanks
First of all you will have to have some kind of interface between your computer (or the network) and the joystick device that is being controlled.
If it involves making custom hardware to control the analog joystick (like it controls pneumatics or hydraulics or something, not just a pc game joystick type thing), then yes, you will almost certainly need a driver to allow a network app to move (the robot arm, or whatever) will move that joystick.
If you are able to remove the physical joystick from the equation, maybe you can write software that emulates the input of wherever the joystick used to plug into (a joystick/serial port?), or emulates it completely (a reasonably simple driver could do this). You could do it completely without writing a driver if the joystick used a standard communication interface (like RS232) because libraries exist that will handle all that and you can set up virtual COM ports that will be indistinguishable to whatever you are trying to communicate with.
The best book you can buy on driver development at the moment is Developing Drivers with the Windows Driver Foundation
Rootkits: Subverting the Windows Kernel is another great book, but doesn't cover a lot of the newer WDF stuff. It has more of a security focus but has a few awesome chapters on device drivers with fully spoonfed examples, breaking it down in a really accessible way.
If it is only over the network, probably simple socket programming should be enough.