Fixing timing issue with resetting Esplora

[kigster]

It appears that at least on my Mac some assumptions about Esplora are slightly different:

• As soon as we set COM1 to 1200 baud, Esplora resets nearly instantaneously, and while I do see these ports disappear momentarily, I was unable to catch that in code even after checking every 1ms after closing serial port. It does get reset, it's just that by the time we expect serial ports to disappear, it's already too late and they are all back. Literally I called Serial.list() right after reset, and it was too late. Could be some OS-level blocking happening on the serial interface that's causing this.

I worked around this case by switching the non-detection case of the wait_for_com_Port_to_appear() function into a warning instead, and allowing us to continue after 2 seconds of unsuccessfully trying to detect port disappearance. 2 seconds should be plenty on even the slowest computers, but it leaves plenty of time for Esplora to start receiving the program (Esplora keeps bootloader open for input for 8 seconds after reset). So in my case, Eclipse just pauses for 2 seconds and then continues to the next step, and this simply works. I wish there was a way to detect the disappearance, but I think that as soon as we call Serial.list() after resetting the port, we are already missing the opportunity and the serial ports are back.

An alternative could be to introduce environment variable that simply disables call to wait_for_com_Port_to_appear() function even if the board is Esplora/Leonardo/etc. That, at least, gives users flexibility to configure this behavior.

Additionally, please note that on my iMac Esplora (and every other Arduino board) provides not one, but two USB/serial ports cu.xxx and tty.xxx. Some of the assumptions in the wait_for_com_Port_to_appear function seems to assume that only one serial port is added/removed by the board. I am referring to this check:

while (OriginalPortsCopy.size() != 1);

[kigster]

Hopefully fixes #173

[jantje]

looks good. The 2 com ports is indeed a possible problem I did not yet consider.
The list is probably better taken before the reset. I remember thinking that but as it worked ....
Thanks for the analysis and fix.
Jantje

[jantje]

In case you didn't know. As the commit has been merged the nightly build (starts around 3:00 CET) will pick it up and the new version will be available tomorrow.

[kigster]

Great! Thanks so much. I'll pull that tomorrow then.

[jantje]

build didn' work due to my bad. But it is now available.

[kigster]

I was wondering – do you think this check (to wait for ports to disappear and then re-appear) is useful? Should the plugin just send the reset to COM and proceed to avrdude assuming all is good?

After the patch it waits up to 2 seconds before proceeding, and it would only be useful if some platforms take a long time to reset the serial, and therefore it's worthwhile waiting for ports to go away and come back. But if this was added more as a safe guard, my vote is to remove it altogether, which would make uploading a lot faster. In the case where reset didn't work avrdude would print out a pretty descriptive message

[jantje]

I'm tempted to say that is a good idea.
However:

1. arduino has implemented this the same way. it is clear that the speed is board/os dependent. Maybe a due on a linux or windows needs this.
2. I live with the adagio: if it isn't broken ... don't fix it.
3. There is a lot of testing to be done which involves lots of hardware. Not something I like doing.
   I like the safety precaution "if it takes to long continue" you have implemented. That makes the upload more robust. As the dual com port boards were the only ones for which problems have been reported I feel : "it is not broken"
   But this is a idea to keep in mind in case it breaks/needs fixing.