Create needs to unify with desktop IDE for COM ports

[BallscrewBob]

SO I recently did a major reset of all the com ports and double checked them all using the desktop IDE and all the boards were fine. I was up to COM17 ( yep that's how many were live if you count the two IP's for the YUN ).
Started to test a couple of issues from the forum and was using CREATE (prod) Despite having said yes to the drivers some time ago and fully expecting them to be all available right from the start that does not appear to be the case.

Been getting driver install pop ups which could only be initiated from CREATE as I get to different boards.

That would not normally be an issue apart from the fact that the CREATE driver is seeing the desktop driver and due to that it is skipping past the com port that was already designated.

There lies the issue in that ports that were used by the desktop IDE are no longer valid most of the time and the COM port count keeps rising.

If I do the standard admin check for unused ports I can see what ports were originally assigned and no longer being used.

The next time I use the desktop IDE it picks up on the changes and the boards jump to the CREATE defined COM port.

This also affects boards that have BOOTLOADER COM ports as they too will double up, one originally given and the one given by CREATE.

Suggestion to stick to a single "unified" driver and single COM port for that driver except where needed for bootloader in which case just the two COM ports that were originally defined by either CREATE or desktop IDE.

Sorry if it sounds a little complex but it is a bug and can result in COM port counts way above what is needed and can on occasion cause upload issues.

Windows in theory supports 256 com ports but in practice I have often seen issues with com ports above 30 (here and on client machines and also a few mentions in the forums).

This is only the early stage pics and the COM list will continue to grow In my case it is possibly a worst case scenario with having so many boards live.

[facchinm]

Theoretically, the drivers shipped with the agent are extracted from the IDE ones and packaged altogether. In fact, we didn't refresh the driver list with the latest drivers (so there could be a date mismatch).
Anyway, I think that the problem may be related with serial numbers. In fact, Windows allocates a new serial port number for every "slightly different" board. So, if the serial number is changing (due to any PluggableUSB module usage) the list will grow and grow.
Is it possible? Have you been using Mouse/Keyboard/MIDI libraries on these boards?

[BallscrewBob]

Have not used any keyboard midi or similar sketch or library...generally it can happen with any sketch some of which may not use any external library. Away from home right now so will tie in with any specific questions when I get home

…

On Sep 4, 2017 10:56, "Martino Facchin" ***@***.***> wrote: Theoretically, the drivers shipped with the agent are extracted from the IDE ones and packaged altogether. In fact, we didn't refresh the driver list with the latest drivers (so there could be a date mismatch). Anyway, I think that the problem may be related with serial numbers. In fact, Windows allocates a new serial port number for every "slightly different" board. So, if the serial number is changing (due to any PluggableUSB module usage) the list will grow and grow. Is it possible? Have you been using Mouse/Keyboard/MIDI libraries on these boards? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#169 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH1Q-sQI6I0lI8AB8mO6jta3DfjlDAGCks5sfA-SgaJpZM4O9c5L> .

[BallscrewBob]

The only USB items that are used on this box are the usual suspects which is a LOT of arduinos on a test board. Regular mouse and keyboard have not been unplugged for about a year. Printer is on a network so its not that. Main culprits seem to be the 101 and MKR's but they are permanently plugged in so the changing to slightly different board aspect would be null and void for those as they do not change.

It takes a while to actually reproduce this issue but it is doable.

1. Take a fresh machine and install the desktop IDE.
2. Add each Arduino board one at a time until you are done.
3. verify each board with a single sketch such as "bare minimum"
4. Check com assignments in device manager and note them.
   5 Now add CREATE agent and let it detect the boards and install drivers as needed.
5. Repeat step 3 but with CREATE.
6. You may notice "additional drivers" are requested for some boards and this will start the issue rolling.
7. Continue with exactly the same set up for a few weeks and repeat steps 3 and 6 using different sketches. The list will continue to expand sporadically.

Note that use of USB thumb drives has been ruled out at this end as even a possible cause.
My USB hubs are housed inside the test bed enclosure and are never accessed. (2 x 7 port) Power supplies are above the minimum requirement as they are also caged supplies (2 x 5v 5A)

Com changes occur only during or immediately after an upload to a port eg. If I selected the MKR1000 on COM 5 and did an upload then there is a chance that the next time I try to upload that port number changed with the additional driver request for the MKR1000 to a port number that was different from the original.

Case in point the the MKRZERO's shown here. Only have two only ever had two

[zmoog]

Hey @umbynos can you double check the current behaviour on Windows 10? 🙇

[github-actions]

This issue has been marked as stale because it has been open 14 days with no activity. Remove stale label or comment, otherwise it will be closed in 7 days

[github-actions]

This issue has been closed becasue has been stale for 7 days. If you think this issue deserves some attention feel free to reopen it