I'm trying to connect a Glucose and Heartrate monitor LE devices using Windows 8. It is being detected just fine and default LE is used for the device. I'm trying to use the sample BLE http://code.msdn.microsoft.com/windowsapps/Bluetooth-LE-Metro-sample-a2ba1b5b but getting 80070057 error.
I have read some post that a custom driver is required. I run it using the sample in Mac and it works just fine. The sample application was able to use the device without any issues. Is there a way to access and use the device without creating a custom driver?
Thanks!
The sample is just a facade to the user. Driver is always needed in order to communicate with hardware. For some standard devices the OS might include a default driver (e.g., standard Web cam) with a predefined set of functionality but for all the rest a vendor-supplied driver is required.
Related
I am trying to talk to a MSC USB device (interface class 8, subclass 6, protocol 0x50) via a plain USB API with endpoints (all set up for me).
Provided I have a valid CDB, such as for "Test Unit Ready", how to I send that over the USB interface?
Where can I find examples or docs for how this is done?
Background: The actual platform is macOS, which doesn't provide SCSI-passthrough for block devices, and the native SCSI API is also not available in this case.
I have, however, been able to initiate communication on the USB level with the device, and am now trying to circumvent the blocked SCSI device level access by talking thru USB directly.
Most such devices implement the so-called “Bulk Only” protocol, which is specified here: https://usb.org/document-library/mass-storage-bulk-only-10
Essentially, you send a 31-byte “Command Block Wrapper”, which includes the CDB and is specified in section 5.1 of the spec, to the device via the bulk out endpoint. You then read or write the data to be transferred from the input bulk endpoint or to the output bulk endpoint and finally read the 13-byte command status wrapper from the bulk in pipe.
However, note that you’ll need to make sure the OS hasn’t already loaded a driver for the device - from user space, the system won’t give you access to the endpoints when a kernel driver has claimed them anyway, but if you were to attempt to use the same pipes as the default driver from a kext, you’d get unpredictable results.
I am modifying a monitor controller for a prototype. It would be convenient to send commands to the prototype using DDC/CI. In Windows, I can't find an obvious way to send a DDC/CI command to a "display dependent device".
The Monitor Configuration API can send virtual control panel commands, but it does not give access to display dependent devices (which would have an I2C address other than 0x6e).
Nicomsoft's WinI2C/DDC product seems to give access to a display dependent device, but it is end-of-life. I would prefer not to build a dependency on an end-of-life product.
NVIDIA's NVAPI has an I2C API, but I would like a solution that also works with Intel and AMD graphics adaptors.
A solution exists for windows which respect XDDM driver display model. Windows 8 and 10 use WDDM.
In XDDM there is a windows O.S. supplied video port driver, and the hardware vendor supplies a miniport driver. When the miniport driver call's the video port driver's edid helper api (VideoPortDDCMonitorHelper), the miniport must supply 4 i2c function pointers as arguments.
In order to utilize these interfaces however you must be acting as the video port driver. So you have to write a video port lower filter driver which just passes along all the interfaces on from the windows supplied video port driver to the miniport driver. Hook the api's and export them to a usermode driver or ioctl which an application can call.
It may be possible to simply mount an instance of the miniport driver and some how get it to call VideoPortDDCMonitorHelper. But with out the help of the actual video port driver it would be difficult to get guidance on how to do that. Also you would have 2 instances of the driver running which may be against the rules for windows.
It does not appear this solution works for windows 8 and 10 because they use a different display driver model which doesn't appear to expose low level control of i2c. It is internal to the miniport driver.
In current scenario i am using RS-232 communication for operating hardware component from PC using Micro Controller in between.Whole Application is Created in MFC.
I am thinking to connect PLC for communicating hardware component to PC. So can anyone tell me how we can done this?
That depends on what hardware interface the PLC provides. If it does not use RS-232 (or ethernet) then you need an adapter. If your PC accepts plugin cards then you can probably get an adapter and driver in that form.
You need to figure out what protocol is used to communicate with the PLC e.g. COMLI, knowing that you will give you an abstract model to work with that you can use to control the hardware.
I would like to know whether the following are possible in the current windows phone 7 SDK:
Getting the device's OS version
programmatically.
Detecting programmatically
whether the data connection is
available in the device or not
Programmatically getting the type of network
connection that the device is
currently having either wifi or LAN
You can get the OS version by doing using System.Environment.OSVersion. The numbers at the end will be the current running version. You can confirm this on your phone by going to Settings...About and seeing if the numbers match.
You can use the NetworkInterface.GetIsNetworkAvailable method to determine if there is any data connection available.
To determine the type of connection, you can use NetworkInterface.GetInternetInterfaceType. This will return a valume of enum NetworkInterfaceType. If the value is Ethernet, the user is plugged into the computer and using its data connection. (Of course, you should test the values returned to confirm that they're what you expected them to be).
So I have a bluetooth device, this device uses SPP to transfer data between the PC and itself. It connects fine through Windows as a bluetooth device. I can find it, enter the paring code and assign it to a COM port. Now I want to be able to send data through the com port using Windows API but it is refusing to do so.
I suspect that I need to setup the COMMCONFIG Structure correctly (see below)
http://msdn.microsoft.com/en-us/library/aa363188(VS.85).aspx
Unfortunately I have no idea what is the proper setting. I know SPP is supposed to emulate the RS-232 communication... so maybe I have to study up on that to figure out the right setting? Or is there some automatic way to set the COMMCONFIG structure.
I seriously doubt it. If it would be used then you'll have no chance at guessing at the custom provider data without docs from the driver author. Pay attention to the handshake signals, serial port devices routinely ignore anything sent to them when the DTR signal is turned off. And not send anything back with DTR off. A driver would emulate that. Use EscapeCommFunction() to turn them on. Also try a serial comm program like HyperTerminal or Putty to test this so you can isolate the source of the problem.
Why not use the Bluetooth sockets API? No need for troublesome (virtual) COM ports then.
If you're using managed code then see my library 32feet.NET
If using native code, use SOCKADDR_BTH with Winsock connect etc, see e.g. Bluetooth and connect (Windows) Then you can use the standard Winsock send/recv API
Ok, I found that you can use the
GetCommConfig and GetCommState functions to figure out the settings.