There are servral USB libraries out there. I have tried libusb and it won't work for me. I cannot connect my USB device with that library because my driver for that USB device is using usbser.sys driver. My USB device is a Communication Device Class (CDC).
The only USB library that works for me is QtSerialPort (I have not tested Win32 API yet) and now to the question: If QtSerialPort only works for my USB device, what API does QtSerialPort use then? Does QtSerialPort use internal Win32 API functions, or own internal API?
On Windows, QtSerialPort uses the Windows API to communicate with serial ports (CreateFile, WriteFile, ReadFile, SetCommTimeouts, etc.).
You can read the relevant source code here:
https://github.com/qt/qtserialport/blob/dev/src/serialport/qserialport_win.cpp
Related
I have a usb midi effect processor that receives midi messages is there any way I can send midi messages over usb from a qt application is there a library for midi ports ?
You can use RtMIDI to do that, which is C++ and can be used with Qt. As an alternative, I've published some open source libraries under the generic name "drumstick" for MIDI processing following Qt5 style and dependency. Some functionalities are multiplatform (Linux, macOS and Windows) like "drumstick-rt", which allows a Qt program to send realtime MIDI events to arbitrary MIDI outputs (USB MIDI devices or whatever). It is used for instance by my program VMPK. Please see the online documentation.
I'd like to connect a beagleboard-like (custom developed) omap board to a Windows PC using a virtual-com setup. That is, i'd like the board to appear to Windows as a com device and get the COM to send data to our application on the board. The main reason for that is to use virtual-com drivers on windows, since the usb drivers we use now to directly sent data over usb between the host and the board seem not to work properly.
I have done this using the FTDI driver on the past but as far as i know it worked because the device had an FTDI chip that translated the usb protocol to serial signals (am i right ?).If there's no USB to UART bridge on the board, how could i do that ?
By the way, how USB Communication Device Classes fits here ? Should develop a CDC driver for the board ? What should I use then on Windows side ?
I'm kind of confused, so any help will be greatly appreciated :)
Well, i answer myself :)
The solution lies in the Linux USB Gadget Subsystem.
Gadget API
There's a sample provided for CDC compliant USB devices here. Are vendor-specific USB devices supported too? Or are CDC compliant USB devices the only ones supported in Metro apps?
Your help is much appreciated!!
Vendor specific USB to UART bridge devices will not be supported under CDC, only a USB CDC class device would be supported in that case.
However, since Microsoft has opened up a USB API you could still access vendor specific devices. The downside here is that the devices will not look like a COM port, you would need to use the Windows.Devices.Usb namespace to access the device directly through it's USB protocol. This means that the vendor for a specific device would need to publish their protocol, or you could reverse engineer or use the Linux source as an example of what the setup packets for certain commands should look like.
Since you're using an FTDI converter you can get the device protocol information from their Linux Source (this is from 3.13 kernel) and use this to access the device through Windows RT.
FTDI might support Win RT in the future (today is 2014-Apr-15), you can ask for a beta driver here:
Windows RT Driver
For a hobby project I wish to develop some stuff for a WinCE 6.0 device. Ideally, I would have an activesync connection to debug from Visual Studio. The OS appears to have all the prerequisites in place, but I'm not sure about the transport. What are my options?
The device has a USB port which can be used to connect e.g. flash drives for mp3 playback, so this seems to be a USB host port. Can I use this to obtain an activesync connection? I guess using a usb-to-serial cable on both pc and WinCE device could work. Or is there a RNDIS way perhaps?
If possible I rather not disassemble the unit, but if my chances of finding a USB client port or wired ethernet are nonzero I could consider that. Any thoughts?
You can not use USB host port for Activesync connection.
But if it is USB OTG (Both host and client) port, you can use activesync using USB OTG or USB Client functionality.
Your BSP should support USB Serial Client functionality (Search SYSGEN_USBFN_SERIAL sysgen variable in catalog items).
Also, your USB driver (lower level driver) should support USB Client functionality.
ActiveSync will work on a serial cable, so the idea of using an USB-to-serial adapter may work. But you need to have drivers for it in the OS image. There are some CDC drivers and FTDI provides drivers for their chips. You may be able to load them on the device, copying them using a USB thumbdrive and modifying the registry using a registry editor for windows CE, but that's not granted. Windows CE also supports RNDIS compatible USB to ethernet adapter but honestly I don't know if any device of this kind is currently available on the market. If your device has wi-fi connectivity you can skip using ActiveSync and debug over the network.
I purchased a BLED 112 dongle from BlueGiga (http://www.bluegiga.com/BLED112_Bluetooth_smart_dongle). I purchased the dongle since I was trying to do a simple POC with an iPhone. I did not want to get into breakout boards or the dev kit just yet.
I am trying to get the heart rate monitor samples working and I am not sure how to load the firmware on the device. I am using the latest version of the SDK (v1.1.1) which states to use the BLE Update tool, not the TI Flash Tool.
However it looks like you need the CC Debugger with the BLE Update Tool to update the SOC. I looked at the CC Debugger and it does not appear to be designed to be used with BLED 112 USB dongle. It appears you need a breakout board to expose the pins to be able to hook the CC Debugger to a BLE 112 module, not a BLED 112.
Lastly, I am not sure if DFU will work without bricking the dongle.
Any advice on how to properly use and program the BLED 112?
Thanks,
G
From the SDK docs:
TI Flash tool should NOT be used with the Bluegiga Bluetooth Smart SDK
v.1.1 or newer, but BLE Update tool should be used instead. The BLE112
and BLE113 and BLED112 devices contain a security key, which is needed
for the firmware to operate and if the device is programmed with TI
flash tool, this security key will be erased.
It is possible to update the firmware on the BLED112 via the USB connection, and without requiring a breakout box or a CC Debugger. However, it is fairly easy to accidentally 'brick' your device in so doing. The problem is that the firmware itself needs to provide the interface to enable DFU mode; if you do an update with your own firmware, and your firmware doesn't provide this capability, you're stuck with the last thing loaded on it.
That being said, here's the process.
The BLED112 dongle is essentially just a BLE112 with an attached USB connection. The BlueGiga SDK ships with drivers that allow the device to be mapped with a simple serial interface, such that the device shows up as a simple COM port (e.g., "COM16") to applications running on the host PC. The SDK also ships with two utilities - BLEGUI, and DFUTOOL - that are able to use this COM port interface to communicate with the device.
(Getting the drivers installed seems like it should be easy, but the process was finicky for me, and I ended up having to mess around with Device Manager, etc., for a while before getting the COM port to show up reliably when I attached the dongle.)
The basic process for building and installing firmware on the BLED112 is:
Compile your BGScript program to an image file using BGBUILD.EXE
Reboot the dongle into firmware update (DFU) mode using BLEGUI2.EXE
After attaching to the appropriate COM port, select Commands | DFU from the menu.
Update the firmware using DFUTOOL.EXE
Before you do this, make sure you read the "Developing Bluetooth 4.0 single-mode applications" and other technotes from BlueGiga's forum (registration required). Specifically around your project configuration:
WARNING:
If the firmware is to be installed into the BLED112 USB dongle the USB
CDC configuration MUST BE included in the project file. If this is not
included in the project file and the compiled firmware is installed
into the BLED112 USB dongle, the USB interface will be disabled and
the dongle stops from working.
Phew. Not necessarily for the feint of heart. I personally found it more appealing to shell out the money for the DKBLE112, which has the BLE112 module mounted on a board with some other accessories, and a CC Debugger for programming. With this setup, you can flash new images to the chip without worrying so much about screwing things up (there's a "reset" button on the board itself).
Other people have reported using breakout boards that are cheaper than the DKBLE112, such as this one from Jeff Rowberg. They also let you program with the CC Debugger, but I have no experience with them.
Have fun!
Based on the information provided, I found the following technote on the BlueGiga support knowledge base.
https://bluegiga.zendesk.com/entries/22810076--HOW-TO-Run-a-BGScript-application-on-the-BLED112-USB-dongle
Thanks
Greg