Is it possible to program the Arduino to disconnect its USB connection in code?
I'd like to emulate someone unplugging the device's USB cable - currently done by physically unplugging the USB cable. I am concerned that repeatedly unplugging and replugging the USB cable (for testing purposes) is going to wear something out, and would prefer (if possible) to be able to do it from code - triggered by a switch.
I tried one of the set_sleep_mode(SLEEP_MODE_PWR_DOWN); examples and it shut the Arduino down no worries, but whatever connection is present meant Windows did not register this shut down as a disconnect event.
I am still looking through the sleep docs / reference, but if anyone knows a yes/no answer that would help immensely.
Come to think of it - I want to disconnect USB connection, but then reconnect later.
So sleep or managing to actually power the device down completely won't work (I don't think) as I need an interrupt or something to wake it back up again.
Unless I had a switch on the 5V supply or something?
It would be more flexible to disconnect USB in-code, but even a physical switch arrangement powering off would be better than constantly plugging-in and unplugging the device.
No. You do not have access back into the USB/Serial chip to do that. The microcontroller only sees the Rx, Tx, and DTR lines.
You'd have to add a jumper from an IO pin to the Reset pin on the USB/Serial adapter to have a chance at making disconnect work.
Reset for 16U2 chips is accessible on its ICSP header.
On FTDI equipped boards (Duemilanove), the Reset pin is wired to +5, so no chance there.
The connectors are rated for thousands of insertions/deletions. You should not have to worry about those.
CrossRoads:
The connectors are rated for thousands of insertions/deletions. You should not have to worry about those.
Thanks - was not sure how robust the connectors are.
One of the reasons I am developing my emulator is because I can then control it via software, allowing me to set up testing scenarios for automated testing. Hence the desire to disconnect USB from code, as it is a critical element out in the field that needs to be handled gracefully.
I am thinking a physical power-off solution (relay or similar) implemented via another IC (ATtiny or similar) may be one way to do it, but I am now transgressing into dubious ROI territory.
I am going to add one or a couple of these to give me a couple more USB serial ports: https://www.sparkfun.com/products/9716 (only $3 more than the mouser one you suggested, and much better form factor).
Would it be possible (assuming I get them installed and working) to hack that board and put a switch between the micro-USB connector and the FT232RL chips power pin?
I am not up to speed on the terminology, but I could possibly wire up a digital output pin from the mega that (shunts / removes) the power of the FT232RL. I can keep the mega running and just "disable" the Sparkfun USB card. My Mega Serial can stay connected for debug / communication purposes, and rely on testing via the breakout boards (Mega Serial1 & Serial2).
Sure, download the eagle file & have at it.
Course, the chip will still be connected to 5V signals on the header side from the board, and most chips are not guaranteed to not be damaged if their IO pins have voltage that exceeds their power pins by more then 1/2V.
And the chip may even appear to still be powered up if the Rx/Tx pins can feed enough current thru the FTDI's IO pin protection diodes.
Try controlling the 16U2 reset first. Connect Reset to Gnd with a jumper wire, see if the PC goes bing-bong like when you pull the cable.
Robin2:
Your original post implied that you were only wondering about a "code" solution because you were concerned about undue wear on the connections.
...R
aarondc:
Doesn't allow me to do it in-code, which is the goal here.
I was wondering about a code solution because I want to do it in code. I was also concerned with connector longevity, but that does not trump the goal of doing it in code for the sake of doing it in code.
Subsequent posts expanded on some of the reasons for wanting to do it in code.
