Feature Request: List of available com ports on GUI without having to click on Tools->Serial Port menu

[JacobChrist]

Due to a Java bug / limitation. It not possible to detect that a com port has been removed from the system. When the terminal window is open (but hidden behind other windows) and you remove then replace the device the IDE will not find the new com port because it had it open already. This is often discovered when you try to program the newly connected device and you get an error at upload (after an already lengthy compile) requiring the process to start over. If the available com ports were shown on the GUI at all times then you can get a visual indication that MPIDE picked up the new com port when it was plugged in.

Jacob

[EmbeddedMan]

Jacob,

I second this. Would be very useful.

However, I believe the problem is not with Java, but with the way Windows handles serial ports. As long as anyone has a given com port open, the com port stays in existence (and is reported as such by the OS to Java) even if the USB device that created the COM port in the first place is no longer on the bus.

One solution that I've seen some terminal emulators use (EVERYbody has this same gripe) is to register for USB insertion/removal events with the Windows USB sub system. Then, when the USB device that created the port gets removed, the application (Java in this case with the Serial Monitor) can check to see if it currently has that COM port open, and then immediately close it. This automatic behavior would, I believe, solve the problem you describe above in a way that's transparent to the user and would always work. However, I've never tried it (figuring out what the right calls are to register for these types of events) so I don't know how difficult it is.

*Brian

[JacobChrist]

I have some VB code that doesn't have this issue in windows. That is to say, I can detect the removal of the port using Windows API's. We've tried to figure out how to do this with some Java code we have: http://pontech.dyndns.org/webstart/ but with no success (doesn't mean its not possible, we just couldn't figure it out and it seemed like a limitation in the RxTx libs).

Jacob

On Sat, Dec 1, 2012 at 6:24 AM, Brian Schmalz notifications@github.comwrote:

Jacob,

I second this. Would be very useful.

However, I believe the problem is not with Java, but with the way Windows handles serial ports. As long as anyone has a given com port open, the com port stays in existence (and is reported as such by the OS to Java) even if the USB device that created the COM port in the first place is no longer on the bus.

One solution that I've seen some terminal emulators use (EVERYbody has this same gripe) is to register for USB insertion/removal events with the Windows USB sub system. Then, when the USB device that created the port gets removed, the application (Java in this case with the Serial Monitor) can check to see if it currently has that COM port open, and then immediately close it. This automatic behavior would, I believe, solve the problem you describe above in a way that's transparent to the user and would always work. However, I've never tried it (figuring out what the right calls are to register for these types of events) so I don't know how difficult it is.

*Brian

— Reply to this email directly or view it on GitHubhttps://github.com/chipKIT32/chipKIT32-MAX/issues/303#issuecomment-10917656.

Jacob Christ ProLinear/PONTECH, Inc. 1-877-985-9286 Phone 1-413-235-1651 Fax http://www.pontech.com

[EmbeddedMan]

Ahh, OK, so it is a Java thing. I've heard that the RxTx libs are not perfect.

Hmm. Sounds like we need a Java expert. :-)

*Brian

[ricklon]

Any updates made to the RXtx library recently that could help?

--Rick

On Saturday, December 1, 2012, Brian Schmalz wrote:

Ahh, OK, so it is a Java thing. I've heard that the RxTx libs are not perfect.

Hmm. Sounds like we need a Java expert. :-)

*Brian

— Reply to this email directly or view it on GitHubhttps://github.com/chipKIT32/chipKIT32-MAX/issues/303#issuecomment-10918611.

Co-founder Fair Use Building and Research (FUBAR) Labs http://fubarlabs.org

[EmbeddedMan]

Well, here's the changelog : http://rxtx.qbang.org/wiki/index.php/Change_Log#rxtx-2.1-7_Feb_4.2C_2006

I'm not even sure how to figure out what version is in MPIDE.

*Brian

[JacobChrist]

In Linux I think you install it independently of MPIDE. I think it gets packaged with Java in Windows.

Jacob

On Sat, Dec 1, 2012 at 10:22 AM, Brian Schmalz notifications@github.comwrote:

Well, here's the changelog : http://rxtx.qbang.org/wiki/index.php/Change_Log#rxtx-2.1-7_Feb_4.2C_2006

I'm not even sure how to figure out what version is in MPIDE.

*Brian

— Reply to this email directly or view it on GitHubhttps://github.com/chipKIT32/chipKIT32-MAX/issues/303#issuecomment-10920194.

Jacob Christ ProLinear/PONTECH, Inc. 1-877-985-9286 Phone 1-413-235-1651 Fax http://www.pontech.com

[EmbeddedMan]

Right, but how do you know which version is included in our current MPIDE build? I pulled apart the .jar file and looked at the manifest file, but there was no version information there that was useful. Maybe we just have to try to call some of the new functions in the latest version and see if an error is thrown.

*Brian

On Sat, Dec 1, 2012 at 1:00 PM, Jacob Christ notifications@github.comwrote:

In Linux I think you install it independently of MPIDE. I think it gets packaged with Java in Windows.

Jacob

On Sat, Dec 1, 2012 at 10:22 AM, Brian Schmalz notifications@github.comwrote:

Well, here's the changelog : http://rxtx.qbang.org/wiki/index.php/Change_Log#rxtx-2.1-7_Feb_4.2C_2006

I'm not even sure how to figure out what version is in MPIDE.

*Brian

— Reply to this email directly or view it on GitHub< https://github.com/chipKIT32/chipKIT32-MAX/issues/303#issuecomment-10920194>.

Jacob Christ ProLinear/PONTECH, Inc. 1-877-985-9286 Phone 1-413-235-1651 Fax http://www.pontech.com

—

Reply to this email directly or view it on GitHubhttps://github.com/chipKIT32/chipKIT32-MAX/issues/303#issuecomment-10920634.