Is there any way to capture device state when it's connected and than emulate it in Windows?
I bought some PCI Express devices that need to be present in slots to make software working. But I have only one slot and software not fully works, searching for another 2 cards in slots.
Any ideas? Thanks!
Sounds like a hardware dongle for licensing?
The answer is no, this isn't possible if the dongle designers had any clue whatsoever about security (using nonce to protect against replay attacks, using asymmetric encryption to produce authentication codes without disclosing the private key).
You might have better luck with a bus extender (bridge chip). For example here is one that turns a PCIe device into a USB peripheral. Whether the software can still talk to it is anyone's guess, I should think that if the bridge identifies itself to Windows as a PCIe bus then it would. There are also plenty of PCIe-PCIe bridges that would take your single internal PCIe slot and give you multiple PCIe slots in an external chassis.
Related
I am curious about the different ways windows drivers interact with the hardware. For example, some drivers might use a function, others a macro, and others might hard-code the register addresses directly into their code. There are probably other ways as well.
Can someone please let me know about the different ways of interaction.
Also, I would like to know, given a particular driver, How can we find out how is it interacting, if we have all the source files including the .vcxproj and other binaries. ?
Any help is really appreciated.
TIA. :-)
It depends on the type of device. for example, if it is a generic PCI Device then the access to the hardware is done "directly" to the HW, meaning Windows map the PCI MMIO to some virtual address and the driver interacts with it.
Microsoft recommended using HAL Function in order to prevent issues with compiler optimization, e.g. to use READ_REGISTER_UCHAR() macro to read BYTE from a device register.
USB, for example, is a subsystem that has a big stack and there is a USB controller that manages access to the device. so, in this case, you will need to use a function to access the device register.
You can find a lot of Microsoft driver samples in GitHub
I want to create hardware accessory for iPhone and iPad but there is very less resources out there. I am not a programmer or engineer. My concept is very simple building a number pad connected through lightning cable. It will have 6x4 keys layout, in this 4 keys can be customize as per need means key a will work as copy(command+c)key b will work as paste(command+v) this keys can be customised in diffrent kind of shortcuts. I dont want a blueetoth connectivity.
Do I need a arduino or raspberry pi kind of device to program and test run a functional prototype?
What kind of cable do I need to sue to communicate with the device?
What kind of programming langauge do i need to learn?
Do I need to first register for Mfi program or I can do it after I develop the product?
As far as I'm aware, you'll need to join MFI for developing Lightning accessories.
However, you don't need Apple's permission for designing and building your own Bluetooth LE (Bluetooth 4.0) accessories. You should be able to do what you want by programming a Bluetooth LE capable microcontroller to act as a HID device that sends the key events you want. I've not done this specific type of project myself and I'm far from an expert on embedded stuff, but Adafruit have a bunch of resources and development boards on Bluetooth LE using Arduinos and other dev boards. I believe they even have something that already acts as a HID device. I'd start researching in that direction.
Another option is to program a microcontroller to act as a standard USB HID keyboard device, and plug that into the iDevice using the Lightning to USB Camera adapter. iPads recognise standard USB keyboards without needing MFI approval, but you do need to use Apple's adapter. Note that the adapter allows the USB device to draw very little power (50mA I think) so it will not work with any device that requires more. The USB3 version of the adapter has an extra power input and so allows you to attach a USB device that draws more than that.
I am an embedded systems engineer and our company is planning for a USB 3.0( host and device )protocol compliance suite/ Post silicon validation covering functional test cases. Actually i have previously worked with functional validation of low speed peripherals like I2C,SPI developing bare metal(without any OS) test cases,running on a simple microcontroller. I am not sure whether i can do the same with USB,as i think the protocol by itself is complex.Does it require to develop test cases using OS or RTOS? Can the functional test cases be run on a uniprocessor system? I am aware linux kernel and U-BOOT has USB support.If it's better to use kernel,how the existing USB stack in kernel can be used to write test cases? Can anyone shed light on this ?
USB 3.0 (particularly superspeed) is not a simple block, and validation of it covers the entire gamut of hardware and software specs, plus interoperability testing. See http://www.usb.org/developers/compliance/
You really need to engage a professional services company with experience doing this if you're the person that's being relied upon for post silicon validation of this block, otherwise your company runs the risk of shipping a product that can't get the logo (or worse). You should probably engage them prior to tape out so your company can lessen the chances of very expensive mistakes. And I don't say this to insult you, but to make it plain to you that if you're asking about it stack overflow, you're not equipped to do the job in the near future.
BUT, when I did USB2.0 high speed certification for an ASIC, we had to have a functional stack on the device under test (our chip, which was an ARM with integrated USB PHY), and we ran a USB certification test on a windows pc, with a specific set of USB peripherals attached to it (the "golden tree"), plus we had to do eye diagrams, etc. to verify our waveforms were compliant. We also did testing with a Mac, but that was more a marketing decision than a compliance issue.
I know this probably is not the easiest thing to do, but I am trying to connect Microcontroller and PC using USB. I dont want to use internal USART of Microcontroller or USB to RS232 converted, its project indended to help me understand various principles.
So, getting the communication done from the Microcontroller side is piece of cake - I mean, when I know he protocol, its relativelly easy to implement it on Micro, becouse I am in direct control of evrything, even precise timing.
But this is not the case of PC. I am not very familiar with concept of Windows handling the devices connected. In one of my previous question I ask about how Windows works with devices thru drivers. I understood that for internal use of Windows, drivers must have some default set of functions available to OS. I mean, when OS wants to access HDD, it calls HDD driver (which is probably internal in OS), with specific "questions" so that means that HDD driver has to be written to cooperate with Windows, to have write function in the proper place to be called by the OS. Something similiar is for GPU, Even DirectX, I mean DirectX must call specific functions from drivers, so drivers must be written to work with DX. I know, many functions from WinAPI works on their own, but even "simple" window must be in the end written into framebuffer, using MMIO to adress specified by drivers. Am I right?
So, I expected that Windows have internal functions, parts of WinAPI designed to work with certain comonly used things. To call manufacturer-designed drivers. But this seems to not be entirely true becouse Windows has no way to communicate thru Paralel port. I mean, there is no function in the WinAPI to work with serial port, but there are funcions to work with HDD,GPU and so.
But now there comes the part I am getting very lost at. So, I think Windows must have some built-in functions to communicate thru USB, becouse for example it handles USB flash memory. So, is there any WinAPI function designed to let user to operate USB thru that function, or when I want to use USB myself, do I have to call desired USB-driver function myself? Becouse all you need to send to USB controller is device adress and the infromation right? I mean, I don´t have to write any new drivers, am I right? Just to call WinAPI function if there is such, or directly call original USB driver. Does any of this make some sense?
To make your life easier, and avoid writing your own driver, try using the HID (Human Interface Device) API on top of USB. Although it says "Human Interface", it doesn't actually have to be for devices that a human controls. The advantage is that modern OSes already come with a HID driver and you can use sample code such as what you can find here to get started. Many microcontroller manufacturers provide suitable code for the embedded of the protocol.
Because OSes already understand HID, if you build a device using the HID interface you'll find that not only can you read from it from any OS, you may also find that many applications can already talk to your device if its communication is restricted to a small enough subset of HID. (For example, I built an input device for a music app, but amazingly I found I could literally plug it straight into a 3D animation app we use at work, running on a different OS, and have it work right away without writing a single additional line of code!)
This answer might aim you in the right direction.
The first answer here might also be helpful.
The answers to this have some actual code and links to yet other resources.
USB includes a set of stock functionality, much like supporting USB flash drives (USB Mass Storage class). The two most interesting for microcontroller interfacing are HID and CDC. CDC is easiest to use as it directly emulates an old fashioned serial port.
If you configure the microcontroller to act as a CDC device, Windows will enumerate it as a serial port, and all the old serial APIs will work on it.
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.