Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Define USB host / driver and app in the USB device configuration?

elwolvel

New Member
NEW to usb programming, lot of reading and long microsoft program examples.
Your articles in USB, clear and easy to read.
My questions only due to not having any programming experience with usb, (Only RS232)
1- all writing refer to host. I could not be sure the reference to host means app or driver or OS.
2- this statement "After successful enumeration, the device will be known to the host and an application will be needed to make use of the USB communication."
That the only sentence I found that separate the term host form app....

3- simple answers yes or no would go long way:
can we define the host: host = OS which sense the usb device D+/- connection,
then the driver selected by OS.
now configuration by driver or by app?

Sample very long programs not clear they driver sample only or app included in the code (super MUTT)?

enumeration, configuration, etc.. proper sequence by host: define host as driver or this an app do all that?

App control transfer = start asking for info to get configuration and setup config, interface,?

Where this starts and doe the app called "Host" while sense device and set up its nformation, using host = driver, till finally the app become aware of USB device driver loaded and USB-comm now possible ... start with control transfer, then stream data, ....

lor of question but one unclear , what the host means = OS, driver combination and where app begins it function.

Specifically, the auto-play sample, I can understand that the driver (I assume) will trigger
the app to starts.. that also, means that the app itself has such code/not obvious/ and it begins the configuration setup interface selection, ....

MY last question: I am trying to access CMOS-camera-C-mount type, for vision.
The vendor SW proprietary:
1- does this code can accept another cameras from different vendors, and apply their api as #include?
2- if we build standard usb program: does the different vendor(s) driver(s) can be installed and used with the standard app to mix different usb cameras and devices, and thus each enumeration "discover=detect" the component and address through its vendor driver and set up and issue commands for each addressed known component.? Does this scheme valid and will work correctly.

This will be appreciated greatly,
wolvel
 

rjenkinsgb

Well-Known Member
Most Helpful Member
Normal USB is a master-slave system.

The host is simply the "master" end, that has the control and intelligence.

I believe the enumeration part is the host scanning possible devices at each port and storing the address path to the device; each USB port can support 127 devices via chained hubs, if I remember right?

Then configuring a driver based on the device ID and making available whatever services that device has - serial, HID (mouse etc.) audio or whatever.

IF the drivers for different makes of device make them appear as standard devices in the appropriate class and with unique IDs, an appropriate program or app should work with any of the type(s) it's made for.

Some cheap gadgets do not have proper unique IDs so you cannot use more than one on one host..
 

elwolvel

New Member
Hello,
Thank you for your response.
If the manufacturers of a camera has a driver, but proprietary API, means the functions content within DLL, and not known to us, how they actually do the function calls in the API (means the long pages codes for the USB comm and establish its enum...etc...)
Also, the manufacturer state the deriver can be used with third party software.
Is that means, we can use "LIBUSB" and microsoft samples to build an app, and add to it, canvas C# to place graphs and plot the image points?

One unique question: does the driver when accessed by "libusb" functions, can we "assume", that the manufacturers API, doing the same, and thus their function calls to do setup and commands, open and acquire and stop, will be on the same level of "Variable" contents, as they should be distinct and unique thus, not being changed, their types and byte size, etc.. will be the same ?
Unrelated question as why I find QT mentions and used in many application, instead of visual studio? the reason, some visual studion application state they using QT for graphic (I know they GUI and has graphic module separately), Is this because the window sdk multimedia not easy to use this this preferred in camera application, even some call their application Qxxxx?
Thank you for your help, appreciated.
 

rjenkinsgb

Well-Known Member
Most Helpful Member
Think of the driver as a translation or adaption layer, that converts between the direct device interface, whatever that may be, and the operating system standardised interface for that type or class of device.

The language / API between the driver and device can be anything; all any user programs sees is a device that communicated via the system APIs for that type of unit.

I'm not sure what you mean by the next part.


QT is a cross-platform system; using that means the same code can be built with minimal changes for Windows, Linux, Mac, Android etc.

Also, Visual Studio generally compiles to an intermediate code, not directly to machine code. It has to be interpreted or recompiled on the machine that finally runs the program, much like Java.

Programs written with GCC & QT etc. compile directly to machine code for the target CPU so do not need the .net runtime to run or recompile them when used.

Oddly enough, microsoft released C# very soon after they got barred from pre-including Java in windows, due to them repeatedly making non-standard changes to the language that could prevent programs running on other systems.
 

elwolvel

New Member
Thank you very much for you helpful answers.
picture of the system clear, Only 2 points need to clarify:
"Device-usb -- host-usb – OS driver(device maker or window generic)-kernel -- <--> device discovered and its link established by driver-OS (type of enumeration, address for the pipes to use by app)"

Does hardware address (not the vendor descriptors) that the basis for app to ID=address the device (becomes the named-handle in the app): done by driver -OS or by app? Because this the way app function use for interaction? Not clear in usb writings!

"all any user programs sees is a device that communicated via the “system APIs” for that type of unit."
system API = has to be window sdk libusb that used by app to build communication functions? Correct?

Thank you very much, we just make sure the driver of vendor installed and we do lot trying to build an app form the examples given and apply libusb and window multimedia.

I just found that driver learning, there superMUTT, a test board used to teach how to build driver.
This tricky example: because the objective to write driver, BUT, in the example they have to communicate with usb controller through the driver they build. Then these functions if it has its code content, would be proper function to = app interaction function with driver--device?

Thank you for your clear and helpful explanations.
 

rjenkinsgb

Well-Known Member
Most Helpful Member
Does hardware address (not the vendor descriptors) that the basis for app to ID=address the device (becomes the named-handle in the app): done by driver -OS or by app? Because this the way app function use for interaction? Not clear in usb writings!

"all any user programs sees is a device that communicated via the “system APIs” for that type of unit."
system API = has to be window sdk libusb that used by app to build communication functions? Correct?

I believe the names are defined during the driver setup by the OS, as they are all fixed data [at least for the duration of the device connection], eg. in windows "device manager".

The info to cross-reference the hardware IDs to OS API IDs must be in the data defined by the driver as that loads.
 

Latest threads

Top