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
