@Corjan @Ralph
Hi guys,
There is an issue with AM 'locating' - (re-locating) Arduinos depending on the Serial USB Controller on board.
If you 'flash', for example, an Arduino Mega with the AT8 / AT16 USB Serial controller then the Port enumeration will always remain the same as when first connected and is then physical port independent. So, you flash it via AM on, say, COM8 (whatever it enumerate to when first connected and is shown in the flash options), and let us choose the name 'Arduino A ' (device 'X') and no matter where you then plug the arduino into the PC hardware usb ports, or into a hub, the device will always be tied to 'virtual' COM8 (purely due to the Serial USB controller in use.)
If the process is followed on a Mega or any other supported device with, for example, the ubiquitous CH340X Serial USB controller then the 'COM8' as in the example above, is tied to the PHYSICAL port in use so the 'com port' is now 100% PHYSICAL hardware port dependent. Major difference.
If a CH34X device is plugged into the same exact PHYSICAL Hardware USB port then the enumeration will remain as first found, ie: It will, in this instance, return to com 8.
If the Arduino is plugged into another physical hardware port - including via a hub etc, then the com port enum will change and be tied to this hardware exact combination and a new 'virtual' COM port number will be assigned to that PHYSICAL port.
Having AM specifically look for a device on 'com 'x' ' on startup is therefore simply not going to work in the case of a CH34X type device being moved to a different physical port as happens all the time in development - and would also happen if you changed the port on, or replaced a HUB etc at any time - or indeed re-installed your O/S. ...
I believe AM , on startup, should definitely NOT be looking at specific ports that it has flashed on previously. It should fully enum - look at all ports currently connected and check to see if they have the appropriate handshaking and naming (Arduino 'A') ('B') etc.
Otherwise AM will simply NOT see those boards unless they are in EXACTLY the same physical hardware port which is simply not practical.
It would be very much appreciated if this could be remedied asap.
Thanks
Joe
USB Arduino enumeration issues.
USB Arduino enumeration issues.
Joe. CISSP, MSc.
Re: USB Arduino enumeration issues.
The (last) method you described was how version 3 used to work, but this caused issues and quite a lot of complaints. What happens is that while Air Manager is/was scanning for devices, it claims that COM port for a little while. If you had other hardware with a COM port, like a RealSimGear device, for which their software was looking for a specific port, it sometimes could not open that port, because it was taken by Air Manager. So their software failed to connect.
You can debate if their software should keep trying, but often with vendors it did not work that way, so we were the ones who had to adapt.
All in all, COM ports are not that great
You can debate if their software should keep trying, but often with vendors it did not work that way, so we were the ones who had to adapt.
All in all, COM ports are not that great
Re: USB Arduino enumeration issues.
I do not see how you need to adapt to anything Ralph. It is purely a matter of checking the connected ports for your own handshaking signals.
The way it is at the moment would not survive a re-install of the OS without major chaos. It is also not really acceptable that a device cannot be recognised after it has simply moved hardware ports. Relying on a specific COM Port number is not sustainable.
It should have absolutely nothing to do with any bad practice that other may do. It is a matter of recognising your own attached devices on which ever port they end up assigned to. If an application behaves as it should then there is absolutely no issue.
There was a recent post where a user had some issues after updating AM and had to completely re-flash all arduinos and completely re-assign all I/Os
I don't believe that was picked up as to what the real reason was. I seem to remember he had re-installed the OS as well which would cause this very issue.
It isn't just an inconvenience is is actually a rather big issue not good practice unfortunately.
Also, there isnt really any issue with com ports in general. The only issue is what people program around them
Joe
The way it is at the moment would not survive a re-install of the OS without major chaos. It is also not really acceptable that a device cannot be recognised after it has simply moved hardware ports. Relying on a specific COM Port number is not sustainable.
It should have absolutely nothing to do with any bad practice that other may do. It is a matter of recognising your own attached devices on which ever port they end up assigned to. If an application behaves as it should then there is absolutely no issue.
There was a recent post where a user had some issues after updating AM and had to completely re-flash all arduinos and completely re-assign all I/Os
I don't believe that was picked up as to what the real reason was. I seem to remember he had re-installed the OS as well which would cause this very issue.
It isn't just an inconvenience is is actually a rather big issue not good practice unfortunately.
Also, there isnt really any issue with com ports in general. The only issue is what people program around them
Joe
Joe. CISSP, MSc.
Re: USB Arduino enumeration issues.
Also, things like 'realsimgear' etc should ALL have their own specific identifiers. Again, that should not be an issue.
Any port claim and release should be fully managed. AM never really seems to release a com port properly as can be seen when using AM in combination with programming in Arduino. This is a definite issue that needs addressing.. it is my sanity at stake here ! 
Joe
Any port claim and release should be fully managed. AM never really seems to release a com port properly as can be seen when using AM in combination with programming in Arduino. This is a definite issue that needs addressing.. it is my sanity at stake here !
Joe
Joe. CISSP, MSc.
Re: USB Arduino enumeration issues.
Hi,
The Arduino needs some time during startup where you shouldn't send any data. If you do, it stops in the bootloader.
So when AM used to scan the COM ports, it would take hold of a COM port for that time, preventing other apps accessing the COM port.
We had quite some people that where not happy with that, that is why we changed it to fixed COM ports. This is how most applications handle this.
But just like Ralph stated, COM ports suck. It is better to use the Raspberry Pi Pico instead,
Corjan
The Arduino needs some time during startup where you shouldn't send any data. If you do, it stops in the bootloader.
So when AM used to scan the COM ports, it would take hold of a COM port for that time, preventing other apps accessing the COM port.
We had quite some people that where not happy with that, that is why we changed it to fixed COM ports. This is how most applications handle this.
But just like Ralph stated, COM ports suck. It is better to use the Raspberry Pi Pico instead,
Corjan
Re: USB Arduino enumeration issues.
Hi Corjan,
I don't necessarily agree that that is how most applications handle that ? - in fact, I know of none that do
(but I am not a windows programmer, I only see the results in operation)
I also definitely don't believe com ports 'suck'
. They are one of the most useful interfaces available for hobbyist use if not THE most important - by far I would say, and have no prospect of being removed or overtaken by anything else.
Once the com - port has initialised - ie - it is showing in Device Manager and available, then all the normal Arduinos should not have any issues with the bootloader. Some of the 32U devices tend to 'listen' for alternate boot for a few seconds but not - as far as I have ever been aware - the standard and most often used Mega, UNO and Nano so I cannot see how that would cause an issue ?. Even the 32U rely on specific sequencing so I cannot see a false entry ?. I believe from enumeration a programmed arduino will be active in less than 100ms ? - even then, it wont try to enter boot... I am baffled on that.
My understanding would be that it is not the com port number that should be being addressed as this is purely virtual. I know of no other application that relies on a specific comm port 'number' for a VCP. The known part is surely your protocol ? no ?
People producing commercial gear should be using their own USB Vendor ID etc. I don't see any reason for AM to be looking at non relevant ID's.
You would only have a very very small list of appropriate vendor ID's to even consider if you covered the complete Arduino range with the various optional USB SERIAL converters. In fact, if you were to rely on the Vendor ID's for the Hardware tied / variable 'number' assignment com ports then you would actually only need to look for one only outside of your fixed ones. That would be 1a86. If that is found then query it - the issue is solved then. Again, I am not sure where you get the 'bootloader' issue from - can you enlighten me on that please ?.
As an aside, the PICO is a good board but not possible to use for Messageport unfortunately.
Joe
I don't necessarily agree that that is how most applications handle that ? - in fact, I know of none that do
(but I am not a windows programmer, I only see the results in operation)I also definitely don't believe com ports 'suck'
. They are one of the most useful interfaces available for hobbyist use if not THE most important - by far I would say, and have no prospect of being removed or overtaken by anything else.Once the com - port has initialised - ie - it is showing in Device Manager and available, then all the normal Arduinos should not have any issues with the bootloader. Some of the 32U devices tend to 'listen' for alternate boot for a few seconds but not - as far as I have ever been aware - the standard and most often used Mega, UNO and Nano so I cannot see how that would cause an issue ?. Even the 32U rely on specific sequencing so I cannot see a false entry ?. I believe from enumeration a programmed arduino will be active in less than 100ms ? - even then, it wont try to enter boot... I am baffled on that.
My understanding would be that it is not the com port number that should be being addressed as this is purely virtual. I know of no other application that relies on a specific comm port 'number' for a VCP. The known part is surely your protocol ? no ?
People producing commercial gear should be using their own USB Vendor ID etc. I don't see any reason for AM to be looking at non relevant ID's.
You would only have a very very small list of appropriate vendor ID's to even consider if you covered the complete Arduino range with the various optional USB SERIAL converters. In fact, if you were to rely on the Vendor ID's for the Hardware tied / variable 'number' assignment com ports then you would actually only need to look for one only outside of your fixed ones. That would be 1a86. If that is found then query it - the issue is solved then. Again, I am not sure where you get the 'bootloader' issue from - can you enlighten me on that please ?.
As an aside, the PICO is a good board but not possible to use for Messageport unfortunately.
Joe
Joe. CISSP, MSc.
Re: USB Arduino enumeration issues.
Hi,
Yeah, I don't think all Arduino's require the bootloader delay.
But since there is no way to know what kind of Arduino is connected, you are forced to wait.
I always prefer native USB, since you don't have to send anything on the application layer to know what kind of hardware you are dealing with.
Corjan
Yeah, I don't think all Arduino's require the bootloader delay.
But since there is no way to know what kind of Arduino is connected, you are forced to wait.
I always prefer native USB, since you don't have to send anything on the application layer to know what kind of hardware you are dealing with.
Corjan