This is specific to one type of microcontroller which is designed to function as a USB DEVICE, not a HOST. The 'host' and 'device' are very very very different things. Matt On Mon, Apr 9, 2012 at 4:58 PM, Xiaofan Chen <xiaofanc@xxxxxxxxx> wrote: > On Mon, Apr 9, 2012 at 11:52 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> On Mon, 9 Apr 2012, Anil Nair wrote: >> >>> > Disconnecting and reconnecting are physical acts -- they require >>> > somebody to unplug and replug a cable. There is no way to do these >>> > things in software. (Not unless your computer has a robot hand that >>> > can unplug and replug USB cables :-) >>> > >>> > Soft Detach can be performed by USB using microcontroller as mentioned >>> By microchip's application note TB058, if ti can be implemented at >>> microcontroller level can't it be replicated at PC level? Sorry if i am >>> wrong i only looked it from another prespective. >> >> I have never heard of Soft Detach. Is it equivalent to disconnecting? >> >> Besides, what about computer systems that don't use microcontrollers >> made by Microchip? > > Microchip's USB Stack has this function. > Reference: http://www.microchip.com/forums/m414263.aspx > > From Microchip's USB Stack. > > Function: > void USBDeviceDetach(void) > > Summary: > This function configures the USB module to "soft detach" itself from > the USB host. > > Description: > This function configures the USB module to perform a "soft detach" > operation, by disabling the D+ (or D-) ~1.5k pull up resistor, which > lets the host know the device is present and attached. This will make > the host think that the device has been unplugged. This is potentially > useful, as it allows the USB device to force the host to re-enumerate > the device (on the firmware has re-enabled the USB module/pull up, by > calling USBDeviceAttach(), to "soft re-attach" to the host). > > Precondition: > Should only be called when USB_INTERRUPT is defined. See remarks > section if USB_POLLING mode option is being used (usb_config.h option). > > Additionally, this function should only be called from the main() loop > context. Do not call this function from within an interrupt > handler, as > this function may modify global interrupt enable bits and settings. > > Parameters: > None > > Return Values: > None > > Remarks: > If the application firmware calls USBDeviceDetach(), it is strongly > recommended that the firmware wait at least >= 80ms before calling > USBDeviceAttach(). If the firmeware performs a soft detach, and then > re-attaches too soon (ex: after a few micro seconds for instance), some > hosts may interpret this as an unexpected "glitch" rather than as a > physical removal/re-attachment of the USB device. In this case the host > may simply ignore the event without re-enumerating the device. To > ensure that the host properly detects and processes the device soft > detach/re-attach, it is recommended to make sure the device remains > detached long enough to mimic a real human controlled USB > unplug/re-attach event (ex: after calling USBDeviceDetach(), do not > call USBDeviceAttach() for at least 80+ms, preferrably longer. > > Neither the USBDeviceDetach() or USBDeviceAttach() functions > are blocking > or take long to execute. It is the application firmware's > responsibility for adding the 80+ms delay, when using these API > functions. > > Note: The Windows plug and play event handler processing is fairly > slow, especially in certain versions of Windows, and for certain USB > device classes. It has been observed that some device classes need to > provide even more USB detach dwell interval (before calling > USBDeviceAttach()), in order to work correctly after re-enumeration. > If the USB device is a CDC class device, it is recommended to wait > at least 1.5 seconds or longer, before soft re-attaching to the host, > to provide the plug and play event handler enough time to finish > processing the removal event, before the re-attach occurs. > > If the application is using the USB_POLLING mode option, then the > USBDeviceDetach() and USBDeviceAttach() functions are not available. > In this mode, the USB stack relies on the "#define > USE_USB_BUS_SENSE_IO" > and "#define USB_BUS_SENSE" options in the > HardwareProfile ñ [platform name].h file. > > When using the USB_POLLING mode option, and the > "#define USE_USB_BUS_SENSE_IO" definition has been commented out, then > the USB stack assumes that it should always enable the USB module at > pretty much all times. Basically, anytime the application firmware > calls USBDeviceTasks(), the firmware will automatically enable the USB > module. This mode would typically be selected if the application was > designed to be a purely bus powered device. In this case, the > application is powered from the +5V VBUS supply from the USB port, so > it is correct and sensible in this type of application to power up and > turn on the USB module, at anytime that the microcontroller is > powered (which implies the USB cable is attached and the host is also > powered). > > In a self powered application, the USB stack is designed with the > intention that the user will enable the "#define USE_USB_BUS_SENSE_IO" > option in the HardwareProfile ñ [platform name].h file. When this > option is defined, then the USBDeviceTasks() function will > automatically > check the I/O pin port value of the designated pin (based on the > #define USB_BUS_SENSE option in the HardwareProfile ñ [platform name].h > file), every time the application calls USBDeviceTasks(). If the > USBDeviceTasks() function is executed and finds that the pin defined by > the #define USB_BUS_SENSE is in a logic low state, then it will > automatically disable the USB module and tri-state the D+ and D- pins. > If however the USBDeviceTasks() function is executed and finds the pin > defined by the #define USB_BUS_SENSE is in a logic high state, then it > will automatically enable the USB module, if it has not already been > enabled. > > > -- > Xiaofan > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
