First off I have very very little experience with how USB functions let alone writing a driver; essentially trying to make this project a learning experience.
My setup consists of the SparkFun Pro Micro board and a Windows machine. I have a potentiometer wired up to the Pro Micro and my end goal is to send the value of the potentiometer to the host machine and use the value to change things like system volume etc...
The Arduino library came with a Serial library and I can send things over USB using that. I currently have a working Arduino program that sends 1 byte every 1 second, and a C program on the windows machine that "connects" to the COM port and reads the byte coming through (this part I have working fine).
The issue is that when the Pro Micro is connected to the computer it appears on a randomly selected COM port and I don't think you can tell which COM ports hold which device (not sure about this bit).
My end goal is when the Pro Micro is connected to the PC the host program should automatically recognize the Pro Micro and start processing the data that is coming from it. Setting it up as a HID device and making it appear in Device Manager as my own custom device is something I'd be interested in doing, especially for the learning experience but I feel that it might overcomplicate things.
Can anyone point me in the right direction as to what I should do/look into?
maybe use windows internal tools like the COM port database (https://msdn.microsoft.com/en-us/library/ff546481.aspx) or re-assign COM ports using windows registry, see
How does windows map the virtual com port to a device
https://superuser.com/questions/851192/change-com-port-number-programmatically
http://www.ftdichip.com/Support/Documents/AppNotes/AN_132_Re-Assigning_COM_Port_Numbers_Using_Registry.pdf
if you want to know the backgrounds: the arduino implements the USB CDC ACM class (Communication Device Class - Abstract Control Model https://en.wikipedia.org/wiki/USB_communications_device_class) and emulates a COM port. Windows recognizes this class and loads the apropriate driver which is usbser.sys (https://msdn.microsoft.com/de-de/library/windows/hardware/dn707976%28v=vs.85%29.aspx) when the driver is loaded the new (virtual) COM port is accessible
the best sources are How does windows map the virtual com port to a device, https://superuser.com/questions/851192/change-com-port-number-programmatically and http://www.ftdichip.com/Support/Documents/AppNotes/AN_132_Re-Assigning_COM_Port_Numbers_Using_Registry.pdf
I would suggest using libusbp, a C library that can be used to find the name of a COM port, given the USB vendor ID and product ID. There is even an example in the "examples" folder that does just that:
https://github.com/pololu/libusbp
Related
I'm using a LPC178 development board and I want to read a file present on a Windows PC. My dev board only has a RS2323 interface to communicate with.
How can I go about transferring the file from my PC to my MCU using a RS232 (serial) link? I found a reference which explains how to transfer data between a MCU and PC but it isn't about file transfers.
Afaik there is no easy solution for this like calling something like "copy" or "fopen" over RS232. I would be happy to be proven wrong here.
The fastest solution might be to write a little programm running on your Windows Host, which listens to your RS232 communication and pipes your communication into/out of the file based on your communication protocol. This can be done with standard file operations in the language of your choice, for example C, C++ or Python.
Your problem is one of the oldest in the book. How do you transfer files without fancy operating system abstractions. For RS232 (or any other serial method) there exists many file transfer protocols.
One of them is kermit. This is a protocol from 1981 and can transfer binary and text files. It is able to be embedded in a micrcontroller and there exists programs to transfer/receive using kermit.
alternative old site for reference
In the simplest case you would use a file transfer protocol such as XMODEM, YMODEM, ZMODEM or Kermit - these protocols were designed in the days before networking and the Internet were ubiquitous and deal with simple point-to-point transfers between two computers. They are supported bu most terminal emulator tools such as TeraTerm Pro or PuTTY so no specific PC software need be written, just the microcontroller end.
A more complex but flexible solution is to implement a TCP/IP stack and a PPP driver, and an FTP application layer - probabaly only practical if using a third-party TCP/IP stack and application layer. You can then use any FTP client for the PC end, so again no PC software required. While this may be overkill if all you need to do is transfer files, it has the advantage of allowing you to use the the single serial port concurrently for other data streams and application protocols such as Telnet. The disadvantage perhaps is that while Windows does support PPP it is buried within the dial-up networking and to be frank a pain to get working.
Very first step you have to do is ensure serial communication is working fine.
Send a byte continuously from mcu to PC and display it on some io console (for example: HyperTerminal, Dock light )
Receive a byte to mcu from PC and echo it back to PC.
Once you are sure that serial communication is working fine then select some file transfer protocol and implement it.
While you can select any of the available protocols or write your own protocol and implement it.
For purpose of discussion i select Xmodem protocol.
If you consider some other protocol you may stop reading answer here.
XMODEM is a simple file transfer protocol.
Refer http://web.mit.edu/6.115/www/amulet/xmodem.htm for detailed information.
You may implement Xmodem mcu side by reading protocol. Or may consider using open source also ( if available )
PC side i prefer to use HyperTerminal io console as it is compatible with Xmodem.
In HyperTerminal all that i have to do is configure settings and select file for transfer to mcu.
Now transfer any file to mcu using Xmodem protocol from PC.
What you do with received file in mcu is up to you : )
Non-programmable Xbee modules should be configured through a PC (with XCTU) or other devices like Arduino... but can the programmable xbee modules (like xbee-pro zb s2b) autoconfigure themselves, without being connected to another device like a PC or Arduino, by running code stored in their memory?
I mean, can they run orders like the ones you run through XCTU but programming them in the internal memory code? Like scan energy of every channel, select a channel, set a PAN ID, configure the different parameters of the device...
Thank you
Yes, the development kit includes an API for sending AT commands from the co-processor to the radio on those boards.
There's also a passthrough mode that relays the host computer serial port through to the radio processor, which can help with initial setup/configuration of the modules like you might do during manufacturing.
To answer your question:
I mean, can they run orders like the ones you run through XCTU but programming them in the internal memory code?
No. You can not program a sequence of orders/commands into the internal memory of the device. To do anything meaningful the device needs to be "driven" from a host PC or MCU that can send the AT Commands.
If you want 1 device solution that does not require a Host MCU then you will need to use a ZigBee SoC (System on Chip), such as the CC2538 - http://www.ti.com/product/cc2538 running a ZgBee SDK (Software Development Kit) - http://www.ti.com/tool/z-stack (ZStack-Home). However this will require you to develop the ZigBee application SW.
Regards,
TC.
I bought a usb otoscope from the internet and I want to create an application that uses it. When I plug it into the computer, it reads the device as a USB Camera, and I can use the very barebones software supplied to communicate with it. I'm very new to the idea of communicating with usb all together. I've tried to look at some sites like this: http://www.jespersaur.com/drupal/book/export/html/21, that tell me how to reverse engineer a device. I don't know if I'm going down the right path with this...
I've downloaded USB Snoopy and I can't seem to get it to sniff the packets correctly. I also have Crunchbang linux installed on a different computer but I don't know how to sniff it on that either (especially because the drivers are native to windows). All I want is some sort of API/Interfacing functions for me to call and use. How do I go about doing such a thing? I'm able to locate the device on the device manager in windows, and it tells me hardware ID's and such. I can supply any information if necessary. Thank you.
EDIT - Small description I found of the otoscope: http://microscopesimgv.blogspot.com/2012/08/oasis-ehev2-usbplus-20mp-handheld-usb.html
would this tool help you any?libusbx is a cross-platform user mode library that provides generic access to USB devices
CHEERS!
I am using a combination of hardware and virtual serial ports in a ANSI C Windows 7 environment. In this project, there will be two applications: The first application is being developed and will be connected both to a hardware COM port and to a virtual COM port. The second is a legacy application (has already been developed and cannot be changed) It will be connected only to the same virtual COM port via a virtual NULL modem.
In the first application, COM event handlers can be used for listening to and handling messages generated from a serial message generator connected to the hardware COM port. However, virtual COM ports do not generate COM events, and so I am limited to using timing loops to periodically check the simulated in and out queues of the virtual port. This is fine for controlling COM traffic in the first application, but the second application will need to see a COM event to enable it to process incoming serial traffic.
Is there a way to generate Windows COM (RS232) events programmatically in one application such that a legacy application that is expecting COM events, can see them?
By events, I am referring to those recognized by a typical comcallback, such as:
LWRS_RXCHAR, LWRS_RXFLAG, LWRS_TXEMPTY, LWRS_CTS, etc.
I don't know if this will work, but you can try to make a loopback on the legacy COM interface? Then you can write to it and it will trigger COM events.
Just closing the loop here (a little late), Thanks for the attempt #Evert.
The solution was to select the right vendor. We needed a good kernel mode driver to produce the right configuration of virtual com port. Eltima (www.eltima.com) provided a product that did just that. Great product with a usable API. Problem solved
How should I approach implementing a USB device driver for Windows? How should I take into account different versions of windows e.g:
- Windows XP
- Windows Vista
- Windows 7
Is there open source solutions which could be used as a starting point? I'm a total newbie to windows driver development.
We have an embedded device with USB device port and we would like to have as low latency communication from the application level to the device as possible without sacrificing the data throughput. The actual data transferred is ADC/DAC data. Basically there is a lot of data which we need to transfer to a Windows machine as fast as possible.
We need more information about the device to point you in the right direction, but here are a few steps to get you started:
register with Microsoft Connect so you can download the Windows Driver Kit
register with osr-online as you'll find great articles, plenty of information, and a newsgroup dediciated just to Windows drivers -- this place is a goldmine
buy Developing Drivers with WDF, which will help you make sense of driver development on Windows and give you a good foundation to read articles from OSR and Microsoft
Hope that you can use UMDF (user-mode drivers) as you can use C++ and just write COM code. If you're doing anything with USB that requires kernel-space....you've got a lot of reading and learning to do for the next year!
To answer your question on versions, the Driver Kit has tools that will help you manage creating different drivers. If you write a good driver, it should run on all three OS with no problems, and the differences will just be in the config area (not the binary)
Basically, it depends on how complex your device is. What type of driver are you trying to write? File system? MP3 player? Camera? Modem?
If you end up having to write a kernel mode driver, let me know and I can point you to some good articles and what not.
I should also add that for around US $5,000, you can buy a license for WinDriver, a tool that takes all of the hard stuff out of driver development. You can use C++ or C# user-mode code to communicate with their driver that is custom generated for your device. This is the way to go if you have a tight deadline.
You can take a look at windows variant of libusb *here*. There are wrappers for many programming languages on official libusb site and on the web.
Start here: Windows Driver Kit Introduction
If you have some form of control over the device side, have it implement an interface for which Windows already provides drivers. E.g. the USB HID class (literally Human Input Device, but neither the Human nor the Input is mandatory) already has Windows drivers, and there is a reasonable Win32 API on top. You're not going to get data rates anywhere near 480 Mbps, though.