News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Usb communication

Started by george999, November 27, 2007, 05:43:09 PM

Previous topic - Next topic

george999

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?

zooba

include    setupapi.inc
includelib setupapi.lib


Both files are included with MASM32 (at least they are with the version I have).

george999

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.

u

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 :) .
Please use a smaller graphic in your signature.

Mark Jones

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?
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

zooba

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

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
Please use a smaller graphic in your signature.