Solve ports conflicts with same address and different protocol

[silvanocerza]

Fix ports not being stored correctly causing ports found by multiple discovery with same address but different protocol conflicting with each other and not being shown correctly in Board Selector dropdown list and Select Board dialog.

Ports separation in Tools > Ports menu is unchanged.

Fixes #711.

[silvanocerza]

@ben-qnimble could you test this please?

You'll find a built artifact for each platform here as soon as the build process has finished.

[ben-qnimble]

Thanks @silvanocerza for the quick change! I can confirm that now ports with shared addresses but different protocols are now listed separately and no not fight each other.

I don't know if this is a separate issue or related to your fix, but if I select, say, COM5 with protocol 'something' then when I upload, the device disconnects and both COM5 ports disappear (as expected) and when the device reconnects, both COM5 ports show up again, but the selected port is now COM5 protocol 'serial' and not 'something'. What is means is that if you click upload, make some change and click upload again the upload will potentially fail is it is connected to a different port than was originally selected.

Thanks,

[silvanocerza]

I don't know if this is a separate issue or related to your fix, but if I select, say, COM5 with protocol 'something' then when I upload, the device disconnects and both COM5 ports disappear (as expected) and when the device reconnects, both COM5 ports show up again, but the selected port is now COM5 protocol 'serial' and not 'something'. What is means is that if you click upload, make some change and click upload again the upload will potentially fail is it is connected to a different port than was originally selected.

This is probably caused by the 1200bps touch, probably I should handle reselection of the correct port too.

Thanks.

[per1234]

the selected port is now COM5 protocol 'serial' and not 'something'.

There are several issues related to the IDE's handling of the port selection after the port is lost (as is normal and expected during an upload to a native USB board). That includes this issue as well as those linked from it: #710

So I don't think this is specific to a port being discovered by multiple discoveries.

[silvanocerza]

I confirm what @per1234 is saying, I investigated a bit and it's not an easy fix reselecting the correct board, I risk causing even more conflicts. 😕

[ben-qnimble]

I did a pull request (#765) into this branch to add more filtering on reconnecting ports so on reconnect, the IDE don't connect to a port whose protocol does not match the protocol of the previously selected port.

[ben-qnimble]

Hi @silvanocerza I really appreciate your quick patch for this issue and I wanted to see if there was anything I could do to help move this patch forward into the main branch.

Thanks!

[silvanocerza]

Hey @ben-qnimble, am waiting for a code review, as soon as it's approved I'll merge it.
Sorry for the long wait.

[fstasi]

Suggested change

	const sortedIDs = Object.keys(ports);
	sortedIDs.sort((left: string, right: string): number => {
	const sortedIDs = Object.keys(ports).sort((left: string, right: string): number => {