How does an O.S. or a high level abstraction layer gain knowledge of the hardware using the device driver? - hardware

When reading about hardware/device independence this statement from wikipedia (http://en.wikipedia.org/wiki/Device_independence#Desktop_computing) states that:
The application software does not need to know anything about the hardware on which it was to be used. Instead it discovers the capabilities of the hardware through the standardized abstraction layer, and then use abstracted commands to control the hardware.
I wanted to know about the lower level interaction between the BIOS routine/device driver/HAL/OS and the device controller about discovering the hardware capabilities.
Kindly help me out to understand the communication between these entities that takes place which helps in hardware independence.

Hardware devices, normally, connect to the main controller through a standard bus of some kind.
For example - PCI, PEX, USB.
Each connected device on the bus will be allocated with a device #, bus #, function #, etc, by the bus controller.
Modern bus contollers either provide the main controller with the ability to perform a scan, or send an event when a device is hot plugged into the bus.
Per each discovered device, it is possible, using the bus controller standard commands (such as read/write registers of a device, by device ID, bus number, etc), to interrogate the device for details such as:
Manufacturer ID
Device ID
Class (controller / networking device / Human interface / imaging device / and so on)
Per bus type, all these details must be available in the same way for every connected HW device, thus enabling the OS to use an abstraction layer.
Once a device has been discovered and identified, the OS will call all the specific bus registered device drivers' probe function, which use the details mentioned above to decide if can handle it.
When a device driver probe succeeds, an instance of the driver is allocated and can be used directly by the application that needs to access the HW.
For example:
USB PC CAM connects to USB port. An event is sent to the main CPU by the USB bus controller. The CPU will use the standard USB bus controller functions to learn the manufacturer & device ID/s, device class, functions, etc, and will call all the USB registered device drivers probe functions.
If an appropriate device driver is installed (registered), it will successfully create an instance of the device and a video application (such as skype) can use it directly, through DLLs supplied by the driver SW.
Hope this helps.

Related

How to get device path and mount path using usbdi callbacks?

I am in the progress of implementing a service which will detect usb plugin/removal using usbdi callback functions. Callback function has a parameter "usbd_device_instance_t * usbInstance" from which i can get device vendor id,product id and the device class information. But how do i get a mount point in case of a mass storage device and a device path in case of a HID device?
In QNX 6.6 and 7.0, usblauncher writes a map of detected devices, launched drivers, and their arguments such as mount point to the PPS tree. The USB Launcher Service reference manual has complete documentation on the location and formatting of these entries. You could scan them to find out what high level details you need.
That said, the usblauncher script engine also provides a place where you could add custom on-connect commands directly; that might be easier than writing a new service.

Seclection of USB device Class

We are developing a device Which consists of CAN and USB (device mode).Via USB, CAN messages (baud rate of messages can be up to 1Mbps and frequency of messages can be up to 1 message/5milli second) and other datas (example settings data) will transmit between PC and our H/W(Both directions).
I am using Texas instruments TM4C123GH6PM MCU.TI gives support to 6 standard classes given below
1) Audio Device Class
2) CDC Device Class
3) Composite Device Class
4) Device Firmware Upgrade Device Class
5) HID Device Class
6) Mass Storage Device Class
They also give support to a class called "Bulk Device Class" which has 1 bulk in endpoint and 1 bulk out end point.
Which is the better way for implementing USB driver for my application (HID Device Class or Bulk Device Class or CDC Device Class or any other method) so that I can transmit all the messages to and from the PC as fast as possible.
We are also planning to develop a PC tool to display CAN messages and configure the H/W?
I am thinking about going to CDC Device Class? Because I think bulk transfer method is better than interrupt transfer method for my application and only Bulk Device Class and CDC Device Class are using it.
Compare to Bulk Device Class, CDC is a standard class and it does not need any driver and application development is also easy.
I don't have any previous experience on USB. Am I taking the correct decision? Please help me?
Your USB device does not have any specific function/protocol and its only used to transfer raw data. For that I believe its better to use Bulk only class which has only two endpoints and easier to use.
For other classes you will have to implement class specific functional descriptors too which will not be a trivial task.
But if you have any time sensitive data then its a different case because bulk endpoint does not guarantee timely delivery. Then its better to use CDC in that case where you will have an interrupt endpoint which can be used.

USB host recognition

I'm developing an embedded USB device which needs to be available to two different hosts.
The first is a normal PC, where it will be used as a MSC (mass storage) device, and the second is a specific hardware which the USB device needs to comunicate with a CDC profile.
during the enumeration, the USB device send descriptor table where it declares its capabilities.
Is there a way in the enumeration process to know to which host the device was connected to ?
The simplest solution perhaps would be to implement a "USB Composite Device", where the single device presented both the MSC and CDC class interfaces simultaneously. The host PC would see both interfaces, but you could simply leave one unused. The "specific hardware" would probably simply ignore the MSC class if it had no support for it.

USB HID device detection

I am trying to access an USB HID device under Ubuntu(kernel-3.0). I want to write a program which could notify me whenever an USB device is attached to the bus i.e is there any event generated whenever an USB device is plugged in which I can monitor. I have looked into DBus and HAL without any success. But I don't want linux to load its current modules(USBHID and HID) when the device is plugged in. I also want to ask if the mentioned modules are also the device drivers used for HID devices.
My sole purpose is to run a script whenever an USB device is plugged into the bus which will indirectly call the above mentioned modules.
I am writing my code in C. I am quite new to linux. So it would be of great help if anyone could point me in the right direction.
Thanks..
The UDisks deamon will send the D-Bus signal "DeviceAdded" when a USB drive is inserted, and probably another "DeviceAdded" for each partition on the drive. If you have automount you would also get a "DeviceChanged" signal when the partition(s) are mounted. You can then query the UDisks interface, as well as individual devices about their properties, for example. You can find more info on the UDisks interface here: http://hal.freedesktop.org/docs/udisks/UDisks.html
One way to get more familiar with what goes on with block devices (or whatever) on D-Bus, is to install and use D-Feet to inspect the bus. UDisks appear on the System bus. You can see what is there and inspect the properties for individual devices as well as the UDisks interface itself.
Another way, which would also allow you to see what signals are transmitted on the bus, is to run dbus-monitor from the command line.

Multiple Driver for USB Device

Is it possible for a USB device to support multiple drivers? I'd like to support my own proprietary driver but also CCID as a second choice. When the device is plugged in, the user can select which one to use. The driver to use is determined by what the USB descriptor says, right? If that is so, is it possible to indicate that both drivers are supported? Is the idea of supporting two drivers doable?
On Windows, having two supported drivers is possible. In fact, to get Microsoft Logo certification, it is mandatory that the USB device supports this functionality. (Requirement CONNECT-0123)
However, the UI behavior you describe isn't offered by Microsoft. Driver selection is automatic.
Your USB device can indicate it supports two interfaces. In that case, both drivers will be loaded.
I am sure that it is not possible for a device to use two drivers at the same time but what is possible is for the device to enumerate using one class type and driver and then during its operation, in response to some command over the USB or operation of the device, for it to disconnect and then re-enumerate as a different type of device using the second driver.
As an example the product that I am developing normally enumerates as a CDC (serial port emulation) but when I need to reload the code it re-enumerates as a different device type and uses the chip vendor supplied driver to perform the code download. Once this completes then the device re-enumerates itself again as a CDC device type and resumes its serial port emulation.
You therefore need to provide a "command" interface that will trigger the transition between the two operating modes and to ensure that the two drivers are installed on the host computer ready for the mode switch.