I want to get info from a mobile phone.I have done this through serial port(with serial cable),but through usb port I can't make it work.I can use CreateFile,WriteFile...etc,like i've done with serial port?
Sorry for my bad english.
About USB access :
http://www.masm32.com/board/index.php?topic=3322.0
Thank you,but I couldn't find any precise example there,just a lot of USB specifications,but not examples.
It depends entirely on the driver. You're more likely to use DeviceIoControl than Write/ReadFile. However, it depends on how it has been implemented.
Either individual functions are implemented as part of the driver, in which case you'll use DeviceIoControl with whatever control codes are used for that driver, or the driver simply passes through blocks of data, in which case there'll be a library/specification somewhere (probably not public) that describes how to communicate.
It's all about using API calls, so examples in C/C++ are just as useful, and there's plenty of those in MSDN and the Windows Driver Kit.
Cheers,
Zooba :U
Before i posted here i have searched with google and in msdn,but i still don't have any idea.On serial port I know what i have to do:
-open port (Createfile)
-configure port(baudrate,bytesize,etc.)
-read and write to port(ReadFile,WriteFile).
But on Usb I don't know from where to start and where to end.
Google ? USB C++
http://www.google.com/search?q=usb+c%2B%2B&ie=utf-8&oe=utf-8
askm
USB is far more complicated than serial or parallel ports. I recommend downloading the Windows Driver Kit and looking through the sample applications. They're mostly in C/C++ but, as I said before, it's mostly based around API calls so the differences are limited.
Cheers,
Zooba :U
george999,
It depends on how the device is recognized by Windows. I have used the CreateFile/WriteFile/ReadFile for communication with printers, both parallel and usb. If your device is recognized by Windows, you can use CreateFile with the device name.
hth,
farrier
george999:
Try:
USB Complete: Everything You Need to Develop Custom USB Peripherals by Jan Axelson
http://www.amazon.com/USB-Complete-Everything-Develop-Peripherals/dp/1931448027
You can get the ebook version on knowfree.net (http://knowfree.net) or b213.net (http://b213.net)
Ok,thank you.I downloaded the book and i readed some...It uses one function that i don't know--HidD_GetHidGuid.What include files I have to put in my code so i can use this function?
Quote from: george999 on November 30, 2007, 03:38:45 PM
Ok,thank you.I downloaded the book and i readed some...It uses one function that i don't know--HidD_GetHidGuid.What include files I have to put in my code so i can use this function?
HidD_GetHidGuid is an export of HID.DLL not currently included in the libraries, so you will have to do it the conventional way. Try code of this kind:
invoke LoadLibrary, chr$('hid.dll')
.if eax==0
mov eax, 12345 ; any number telling you no HID on this pc
ret
.endif
mov hDLL, eax
invoke GetProcAddress,hDLL, chr$('HidD_GetHidGuid')
mov dll_GetHid, eax
... do your stuff ...
push last_par
push middle_par
push first_par
call dll_GetHid
... do your stuff ...
invoke FreeLibrary,hDll
george999,
It depends on how the device is recognized by Windows. I have used the CreateFile/WriteFile/ReadFile for communication with printers, both parallel and usb. If your device is recognized by Windows, you can use CreateFile with the device name.
hth,
farrier
Windows recognizes the phone like "Phone(COM3)" .I have a valid handle to comunicate to phone,but when I call Writefile the program freezes and i have to force close it.
The problem is not to get a handle,but how to send data.
I use a pure usb cable,not usb to serial.
george999,
It seems strange that the phone is recognized as a COM3 device when attached via a USB cable! When the phone is first plugged in, does Windows acknowledge it with a pop up window, saying "Device recognized"?
When you execute the CreateFile command, what is the return value in eax? This will tell you if the phone is recognized. Then if the phone is recognized, try the simplest command to illicit a response from the phone. For instance, name of phone or model number.
hth,
farrier
Quote from: farrier on December 03, 2007, 09:54:30 PM
It seems strange that the phone is recognized as a COM3 device when attached via a USB cable!
It seems entirely reasonable to me. Telephony devices (modems, etc.) are often expected by older programs to be connected via a serial port, so for compatibility with older programs it makes a lot of sense to implement them this way.
COM ports are logical ports, rather than physical ports. Windows can easily set one up for your device no matter how it is connected.
Cheers,
Zooba :U
CreateFile it's returns value 48.So the handle seems to be valid.No meather what command I send to modem the program it's freezing...
Hello,
Quote
Ok,thank you.I downloaded the book and i readed some...It uses one function that i don't know--HidD_GetHidGuid.What include files I have to put in my code so i can use this function?
The library hid.lib is part of the WINDDK (The link to donwload it is closed but you can download the DDK)
The function is describe in the hidsdi.h with all functions beginning by HidD_...
There is just a translation to do.
Quote
void __stdcall
HidD_GetHidGuid (
OUT LPGUID HidGuid
);
The recent WDK does not appear to be available for download, but the Server 2003 SP1 DDK is available here (http://www.microsoft.com/whdc/devtools/ddk/default.mspx), and it includes at least three versions of hid.lib
BTW, in addition to the 64-bit stuff, this version includes a 32-bit ML and LINK, both version 7.10.4035.
And also MASM 5.10A, a 16-bit linker (5.60.220), and:
Microsoft (R) C/C++ Optimizing Compiler Version 8.00c, along with what appear to be a normal set of libraries and header files.
And multiple other 16-bit tools.
zooba,
You're probably right, like with a USB to Serial conversion device. I'm guessing that the phone emulates the COM port on its' side of the USB connection.
george999,
Are you using COM3 or another device name in the CreateFile call? Immediately after the CreateFile, call GetCommState to check the whole COM port response.
Show the part of your code establishing the connection with the phone. It may help us help you.
farrier
usb DCB {?}
usbto COMMTIMEOUTS {?}
f db "COM3",0
...............
invoke CreateFile,addr f,GENERIC_READ or GENERIC_WRITE,FILE_SHARE_READ or FILE_SHARE_WRITE,NULL,OPEN_EXISTING,0,NULL
mov hf,eax
mov usb.DCBlength,SIZEOF usb
invoke GetCommState,hf,addr usb
mov usb.BaudRate,CBR_115200
mov usb.ByteSize,8
mov usb.Parity,NOPARITY
mov usb.StopBits,ONESTOPBIT
invoke SetCommState,hf,addr usb
invoke GetCommTimeouts,hf,addr usbto
mov usbto.ReadIntervalTimeout,MAXWORD
mov usbto.ReadTotalTimeoutMultiplier,0
mov usbto.ReadTotalTimeoutConstant,0
mov usbto.WriteTotalTimeoutMultiplier,0
mov usbto.WriteTotalTimeoutConstant,0
invoke SetCommTimeouts,hf,addr usbto
invoke WriteFile,hf,addr buf,11,addr bw,0
I used an usb monitor and it seems that before sending my buffer it's sending some buffer that i don't know from where it's coming.
george999,
What return value are you getting from:
GetCommState
SetCommState
GetCommTimeouts
SetCommTimeout
You might also try communicating with the phone without changing any of the parameters: Baudrate; ByteSize; Parity; Stopbits, etc. until you have established reliable communications. Look at the values return by GetCommState, to see if they look reasonable.
farrier
GetCommState
SetCommState
GetCommTimeouts
SetCommTimeout
All functions returns 1.
I think i am on a wrong way because the cable it's usb not serial or usb to serial cable.I guess I have to use something else.However i searched to other forums where people asked something similar and they got no answer.It seems that usb communication it's Top Secret for a newb like me :lol
USB itself isn't a secret, the secret part is the firmware on the device itself. You either need to determine the commands sent from the driver to the device are or find some reference.
Even if you're not actually using a USB-serial converter, it is entirely possible that the modem actually has one inside. This is especially likely since it appears as a COM port. I would expect that the usual interfaces would work, since that makes sense for compatibility with existing programs.
Have you tried your code with a modem connected to a serial port?
Maybe, the buffer you are getting is information from the phone telling the otherside what parameters to use, or the status of the phone?
Then the phone is waiting for a response. Since you are then trying to CreateFile, the phone ignores this response.
Have you tried to capture what the buffer from the phone is sending?
NPNW
You can take a look at the USB 2.0 Spec here.
It may contain the different protocol specs that the USB device, and or phone is using to setup communication.
www.usb.org (http://www.usb.org)
This second reference talks about the protocols and lead me to the first link.
www.interfacebus.com/Design_Connector_USB.html (http://www.interfacebus.com/Design_Connector_USB.html)
NPNW
From what I have been able to read. From the USB 2.0 spec.
The USB device is trying to negotiate power, and speed. This is probably the buffer information that is being sent.
Since it doesn't get a proper response, it is waiting for the correct sequence.
That is why the writefile doesn't work.
NPNW
If you go to tools at the USB site it looks like you can send commands to a device to test it.
http://www.usb.org/developers/tools/.
Here is a link to a white paper that has code for the WDM driver to init and communicate with a USB device.
Might give you some ideas of what is going on.
http://www.usb.org/developers/whitepapers/irp_mn.pdf
NPNW
Here are the references that the writer of the driver recommends if anyone has links or copies.
References
[1] Windowsâ,,¢ 2000 DDK; Setup, Plug & Play, Power Management, Design Guide, Part 2:
Plug and Play; 3.0 Starting, Stopping, and Removing Devices; 3.1 Starting a Device; 3.1.1
Starting a Device in a Function Driver
[2] Windows 2000â,,¢ DDK; Setup, Plug & Play, Power Management, Design Guide, Part 2:
Plug and Play; 2.0 Rules for Handling PnP IRPS; 2.3 Postponing PnP IRP Processing Until
Lower Drivers Finish
[3] Windows 2000â,,¢ DDK; Kernel-Mode Drivers; Design Guide; Part 5: USB Drivers; 2.0
Configuring USB Devices
NPNW
zooba,
With serial cable it's working without any problem.
NPNW,
Thank you for your help...but...i am tired reading theory,from where i can't understand anything.I'm looking for a concrete example...
george999,
I think I suggested this before: after CreateFile, make sure your DCB buffer is cleared--set to zero--then invoke GetCommState and check the BaudRate, ByteSize, StopBits, etc. and check to see if these numbers are reasonable. If they are reasonable, don't change them, and then try to communicate. Tell us what values GetCommState returns!
Once again I think zooba is correct! The phone itself is acting as a USB to serial port converter so that the computer sees a COM3 when you plug the phone into the USB port. When you first plug the phone in, what notification message do you see?
farrier
If your code is working with another modem, then obviously the drivers are not fully compatible.
Do you have any other programs that work with the USB modem? Will regular Windows dial-up networking work with it or do you need a special program running?
Using a device over USB should be completely transparent. The same API calls are used to access it, especially if it is emulating a COM port. You only need to read up on USB itself if you are writing a driver or firmware (and if you want to do that you'll spend a lot of time reading before you can do it).
Cheers,
Zooba :U
I am trying cu enum devices,but when i call SetupDiGetClassDevs it gives me "error LNK2001: unresolved external symbol _SetupDiGetClassDevsA@16".In Vc I have to put "#pragma comment(lib, "setupapi.lib") " in my code and it's working.How I do that in Masm so will link setupapi.lib?
include setupapi.inc
includelib setupapi.lib
Both files are included with MASM32 (at least they are with the version I have).
I have included only setupapi.inc without setupapi.lib :lol .Now I have another problem :
how I should declare this:
HDEVINFO hDevInfo;
SP_DEVINFO_DATA DeviceInfoData; ?
I tried:
LOCAL hDevInfo:HDEVINFO
but gives me error undefined symbol : HDEVINFO.
http://www.hhdsoftware.com/
I just finished making my own USB device with a PIC MCU, and the above tool (the USB monitor) helped me immensely in studying USB and finding what I should do. Which cannot be said about the goddamn USB specifications. No wonder they offer special paid tuition to interpret the specs ::).
The power-consumption and interface-speed are auto-configured on the first sent packet (plus a combination of 1 pull-up resistor in the device), there's nothing you can do about it. But I bet the speed-mode is the "full speed". Low-speed gives only 800 bytes/s (10ms * 8 bytes max), and "High-Speed" is usually a bit too expensive to implement in a phone. Full-speed is 64000bytes/s iirc (1ms * 64 bytes), so maybe you should set the COM speed to 64000*8 bps ? Or 63*1000*8 bps, if each packet (up to 64 bytes) contains the packet-size in the first byte.
Really, I don't like the USB standard, it could have been made much better imho :) . 1800 lines of macro-asm code (for microcontrollers with USB hardware circuitry) to get the simplest USB device working - should tell something is really wrong with this standard, that was forced on us :) .
Quote from: Ultrano on December 06, 2007, 09:58:09 PM
1800 lines of macro-asm code (for microcontrollers with USB hardware circuitry) to get the simplest USB device working - should tell something is really wrong with this standard, that was forced on us :)
Hmm, do you mean 1800 lines of PIC-16 assembler code? On a series with USB hardware? Surely the hardware should handle more than this -- I've tinkered with several PIC series (not a USB one yet), and they are all very efficient in terms of code size. Is the protocol really that abstract and complex?
It's not that it is abstract, but there are a lot of details that are left to the device to decide, rather than being forced upon it by the protocol. Things like sleep mode behaviour, power consumption and various transfer modes need to be specified by the device. This is a good thing, IMHO, since it means the same protocol can be used for devices from keyboards to hard drives to live video feeds.
I would expect that a large portion of the code is provided as a skeleton/template, since a lot of it doesn't change between devices. However, if you ever have to build a device that requires some of these bits to be different, you'll be very thankful that USB allows that flexibility.
Ultrano,
I agree, the specs could be a lot clearer. In most cases when you are using the device though, details like that are transparent. They are only relevant to hardware designers, and firmware and driver writers.
george,
HDEVINFO is a handle type, so you can safely substitute DWORD (on a 32-bit machine).
Cheers,
Zooba :U
Quote from: Mark Jones on December 07, 2007, 03:09:50 AM
Quote from: Ultrano on December 06, 2007, 09:58:09 PM
1800 lines of macro-asm code (for microcontrollers with USB hardware circuitry) to get the simplest USB device working - should tell something is really wrong with this standard, that was forced on us :)
Hmm, do you mean 1800 lines of PIC-16 assembler code? On a series with USB hardware? Surely the hardware should handle more than this -- I've tinkered with several PIC series (not a USB one yet), and they are all very efficient in terms of code size. Is the protocol really that abstract and complex?
Here's one of the smaller examples I've found on the net and studied, before deciding to simply use C18 and get all my timing-critical code outside of the USB chip lol.
http://pe.ece.olin.edu/ece/projects/lab2_18F2455.zip