Auto-detection of serial ports.

[GoogleCodeExporter]

The IDE should automatically detect which serial port(s) correspond to an 
Arduino board.  On Mac 
OS X, this could be through the device name.  On Windows, there are system 
calls to find out which 
COM ports correspond to USB-to-serial devices.

Original issue reported on code.google.com by dmel...@gmail.com on 1 Apr 2010 at 6:19

[GoogleCodeExporter]

dmellis, your Windows fix certainly does not work for all cases.  What if the 
user 
is not using a "USB-to-serial" device?  Maybe instead, the IDE should report 
all COM 
ports and the name given to them by the system.  This way the numerous options 
for 
Arduino communication will work.  The only downfall is that the user needs to 
find 
the right one.

Original comment by n.mcdona...@gmail.com on 2 Apr 2010 at 9:51

[GoogleCodeExporter]

This is a great feature which will really help novice users to get the right 
serial
port selected!

Please make whatever criteria is used (eg, USB vendor/product ID numbers)
configurable from boards.txt, and please default to the current "every serial 
port"
approach if they are not present in the selected board's configuration.

In the future, if a different FTDI chip with a different product ID number, or a
completely different USB-serial chip is used, it will be easy to specify what
hardware is expected for each board.

Original comment by paul.sto...@gmail.com on 29 Apr 2010 at 5:04

[GoogleCodeExporter]

Additionally / alternatively, the IDE should pop up a dialog box when you 
attempt to upload and the current serial port doesn't exist.  This would then 
allow you to pick the serial you wished to use.

Original comment by dmel...@gmail.com on 5 Jul 2010 at 6:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by dmel...@gmail.com on 7 Jan 2011 at 4:02

• Added labels: Milestone-Post-1.0
• Removed labels: Milestone-1.0

[GoogleCodeExporter]

Issue 916 has been merged into this issue.

Original comment by dmel...@gmail.com on 18 May 2012 at 7:11

[GoogleCodeExporter]

I'm imaging this would work by looking for the right serial port if, when you 
upload, the currently selected port doesn't exist.  This would select the 
serial port without requiring any explicit action from the user.  To do this, 
we need a method for figuring out which serial ports represent an Arduino 
board, which may different across platforms.  On Mac, we can probably look for 
particular device names.  On Windows, we may need to scan the registry for 
information about the ports.  On Linux, we might also be able to use the device 
name.  If we find more than one candidate, we should probably pop up a dialog 
box as we do now.

Original comment by dmel...@gmail.com on 18 May 2012 at 7:15

[GoogleCodeExporter]

Sorry, this is a duplicate post which I posted in Issue 916. In which case do 
you want to continue discussion, 916 or 223?
-----

I agree that it should be better if there is an efficient method to select the 
correct serial port automatically without any user operation. How do you do 
that?

by USB VID/PID
--------------

Arduino Uno can be detected by searching USB VID/PID. However, this cannot 
applied to other Arduino models. For Arduino models with FTDI chip, it cannot 
be distinguished with many many other devices with FTDI chip. For Arduino 
models without USB serial converter chip, it cannot be detected without forcing 
users to use a specific USB serial converter module.

by talking with every serial ports
----------------------------------

This means that you have to scan and open every serial ports, send some probe 
bytes and test if it is Arduino or not by checking the reply from the serial 
port. This sounds nice, but I don't think this is perfect.

When opening serial port, the program may stuck on some serial port (system 
call hungs before timeout). When sending the probe bytes (this also needs 
serial port speed change), this can cause bad effect to non-Arduino devices 
connected to PC. You have to assert DTR before sending the probe character 
because users' sketch won't answer to the probe character. This DTR asserting 
may also cause bad effect to non-Arduino devices.

Multiple Arduinos
-----------------

Even by any 'automatic' method, this may fail if the user wants to use multiple 
Arduinos.

Original comment by sgk...@gmail.com on 19 May 2012 at 8:27

[GoogleCodeExporter]

I agree that it doesn't make sense to actually talk to every serial port.  I'm 
not planning on doing that.

My thought is to look for USB-serial devices and/or appropriate VID/PID pairs 
and/or device names (on Linux and especially Mac).  As you point out, this 
isn't perfect, but I think it will work in most cases.  

Maybe as an additional heuristic, we can keep track of the order that new 
serial devices appear in and default to the most recently connected one (if 
there are more than one that match the previous heuristic).  

Original comment by dmel...@gmail.com on 20 May 2012 at 4:51

[GoogleCodeExporter]

It is a good news that you are not planning to implement the port-scan method. 
Thank you.

I've just sent an email about other issues on the ML.

Original comment by sgk...@gmail.com on 21 May 2012 at 5:34

[GoogleCodeExporter]

FYI, I've been implementing a similar Arduino auto-detection algorithm on top 
of the nodejs node-serialport library which exposes manufacturer and pnpid of 
serial ports.  I'm currently searching these for string matches 'Arduino' and 
'Teensy' and 'PJRC'.  

For reference, see code at: 
https://github.com/JayBeavers/node-reflecta/blob/master/reflecta.js

Original comment by j...@hikinghomeschoolers.org on 19 Sep 2012 at 5:12

[GoogleCodeExporter]

FYI, I've been doing auto-detection using the output of node-serialport which 
is a nodejs library for cross platform CDC communications.  I took a look at 
the libusb APIs to see if they could be used directly, but I couldn't find any 
map from the USB device to the CDC device path.

node-serialport uses three different techniques for enumerating CDC devices 
(see 
https://github.com/voodootikigod/node-serialport/blob/master/serialport.js, 
function list*).

On Linux, it enumerates /dev/serial/by-id and parses out the device path and 
pnpId.  It cannot correlate this to device descriptor, vid/pid, etc.

On OSX, it uses system_profiler and parses the output.  It uses this to 
generate the cdc device path, manufacturer, vid/pid.

On Windows, it uses WMI (Windows Management Information) APIs to pull out the 
cdc path, manufacturer, and pnpid.  From some background reading, it looks like 
a Windows Pnpid can be parsed into to VID/PID.

Original comment by j...@hikinghomeschoolers.org on 21 Sep 2012 at 7:42

[GoogleCodeExporter]

FYI, I've just pushed this feature on to branch
https://github.com/arduino/Arduino/tree/ide-1.5.x-rxtx2.2 (works on linux and 
mac)

All it does is looking at the list of serial ports (as listed by RXTX) and 
compare each of them to the list of attached USB devices
If a match is found and its VendorID + ProductID matches one of those listed on 
available boards, then a LABEL (and nothing more) is added to the serial port 
name

The net result is a menu entry that looks like "/dev/ttyACM0 (Arduino Uno)"

boards.txt required a new field: "vid_pid", a list of vid+pid for each board

Please, give it a spin and report any feedback

Some notes: not every board plays nice with it. For example, Duemilanove 
reports itself as a FTDI device (so I just print nothing).
Boards using 32u4 have different vid+pid when starting up (bootloader mode) but 
the same one when started (sketch mode). This has the bad UX effect of plugging 
in an Explora, having it recognized as such and after a couple of seconds 
having it listed as a Leonardo.

Original comment by federico...@gmail.com on 28 Jan 2013 at 5:48

[GoogleCodeExporter]

Great to see progress on this!

I didn't look into the code but wanted to comment on the boards.txt format. We 
already have BOARD.build.vid and BOARD.build.pid keys, used by the Leonardo and 
other 32U4-based boards (so they know what VID/PID to report to the computer). 
Can we use those, existing keys instead of adding new ones? Maybe add an extra, 
optional field like BOARD.bootloader.vid and BOARD.bootloader.pid if there's a 
need to specify a separate VID/PID pair for the bootloader?

Even if there's a need for a list that could possibly include more than two 
items, the vid_pid format feels really awkward; I think it would be better to 
split them into separate fields, even if that means that each field is a list 
(e.g. BOARD.vid=2341,2341 and BOARD.pid=0036,8036).

Original comment by dmel...@gmail.com on 28 Jan 2013 at 7:11

[GoogleCodeExporter]

The new field was motivated by the fact that the two Due have the same vid+pid 
under the "build" key while they differ depending on which port it's used to 
connect them.
Is this the case the BOARD.bootloader.vid key addresses?

The vid_pid format was chosen for development simplicity (ok, laziness :P ): 
I'm not sure how easy is to document a format that requires correspondence 
between two fields. My opinion is weak though.

Original comment by federico...@gmail.com on 29 Jan 2013 at 8:40

[GoogleCodeExporter]

Totally unclear: let me rephrase that
If you connect a Due to the native usb port, OS will see VID 2341 and PID 003E, 
as written under the build.vid and build.pid keys of boards.txt
But if you connect it to the programming port, OS will see a different PID: 003D

So I needed a way to address such difference. How does BOAD.bootloader.vid help 
me? Is this difference related to the bootloader?

Original comment by federico...@gmail.com on 29 Jan 2013 at 8:52

[GoogleCodeExporter]

On the Due, we have separate boards menu entries for the native USB port and 
the programming port, each of which can have its own BOARD.build.vid and 
BOARD.build.pid keys. So it seems like you wouldn't need a list there.

The BOARD.bootloader.vid and BOARD.bootloader.pid comment was referring to the 
Leonardo (and Micro, etc), where there's one VID/PID for the bootloader and 
another for the sketch. Having a separate key will allow us to indicate in the 
menu which of the two is present (e.g. "Arduino Leonardo" vs. "Arduino Leonardo 
(bootloader)"). 

If we really do need a list of values, there are some precedents elsewhere in 
the preferences that would be good to stick to. For example, the Arduino 
preferences.txt file can store multiple sketches that the user had open. 
They're formatted:

last.sketch0.path=
last.sketch0.location=
last.sketch1.path=
last.sketch1.location=
...

Something like this would, for example, allow us to provide an additional name 
/ qualifier for each VID/PID pair (e.g. "bootloader" or "programming port" or 
"native port").

Original comment by dmel...@gmail.com on 29 Jan 2013 at 4:23

[GoogleCodeExporter]

Arduino has always used a paradigm of "everything is a serial port", which has 
worked well for the functionality delivered so far.  The last thing I want to 
do is overly complicate your work, but please do keep an open mind that future 
product might implement non-serial protocols.

Original comment by paul.sto...@gmail.com on 29 Jan 2013 at 4:55

[GoogleCodeExporter]

What about this:

...
leonardo.name=Arduino Leonardo
leonardo.vid.0=2341
leonardo.pid.0=0036
leonardo.vid.1=2341
leonardo.pid.1=8036
leonardo.upload.tool=avrdude
...

Having a dot between "vid" and "0" avoids having a field like 
last.sketch.count, since counting the number of keys under the key "vid" 
suffices to know that number

I would also like your opinion about the Esplora issue (in sketch mode it 
shares the same vid+pid of the Leonardo and therefore is reported as such, 
leading to potential confusion)

Me and Cristian were thinking about postponing this patch until release 1.5.4.
In 1.5.3 (the next next) we'll deploy an updated boards.txt with a vid+pid 
specific to the Esplora. Uploading a sketch, they will be updated as well. 
Esplora users will then start "fixing" the vid+pid, preparing the field for 
this patch.
1.5.4 will then include this patch and the potential confusion won't affect 
every Esplora user that has used version 1.5.3
Such shell game will reduce the number of Esplora users that may be potentially 
confused.

Original comment by federico...@gmail.com on 30 Jan 2013 at 9:44

[GoogleCodeExporter]

FYI, development has moved to a different branch
https://github.com/arduino/Arduino/commits/ide-1.5.x-board-autodetect

Original comment by federico...@gmail.com on 30 Jan 2013 at 12:06

[GoogleCodeExporter]

That all sounds reasonable.

If I were doing it, I'd probably stick with the vid1 and vid.count syntax for 
consistency, but either way seems much better than the vid_pid syntax.

If you're using the hex values of the VID and PID, I think you should include 
explicit "0x" prefixes (e.g. "0x2341") to make it clear that they're not 
decimal values (and to allow someone to specify the VID or PID in decimal if 
they wanted). 

The two-release approach (for the Esplora) seems okay. I think it's also worth 
explaining how the sketch VID/PIDs work in the documentation somewhere, because 
it's possible that people will run into this problem regardless.

Original comment by dmel...@gmail.com on 30 Jan 2013 at 2:40

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

FYI code is now at 
https://github.com/ffissore/Arduino/tree/ide-1.5.x-board-autodetect (my fork). 
It works on linux, mac and windows

Question: having selected a port with a Arduino Uno attached but having left 
the previous board selection of a Mega, should I make the IDE complain or just 
leave it go until the error message is printed?

@dmellis: probably the whole esplora argument was wrong. I got two different 
versions of it from two different guys, so I'll wait to have one board from the 
factory to see what comes out of the box.

Original comment by federico...@gmail.com on 5 Feb 2013 at 8:26

• Changed state: Started

[GoogleCodeExporter]

a quick update: I've just tried with a brand new Esplora and it works just fine.

the problem came from the fact that you can upload a sketch on an Esplora while 
having selected a Leonardo from the boards menu: since they share the same 
processor, the sketch will be uploaded and executed correctly.
But since each time we upload a sketch (on some boards) we also update PID and 
VID and that's what has been done with the first esplora I tried, it reported 
itself as a Leonardo

I think the IDE should complain if you try to upload a sketch when board and 
port don't match

Original comment by federico...@gmail.com on 12 Feb 2013 at 9:19

[GoogleCodeExporter]

A Proposed Scheme for Associating Boards and Serial-Ports:

 When NO serial port is currently selected:

  1. A click on "upload" would result in a (one-time) pop-up which requests the user to disconnect and reconnect the target board (or click on cancel to select a serial-port manually).

  2. After identifying the serial-port, the dialog would ask for a "user-name" for the board (and to verify the current board-type selection).   A user-name could be generic or unique to a project or a target location or managed any way the user desires.

  3. The user-name is automatically added to "boards.txt" (and a NEW "user-boards" menu) to permanently associate this particular board with its serial-port.  After this, the user only has to select the user-name to set EVERYTHING for this particular board.  The user-name should also be available as a build variable so the source-code can use it; e.g., this could be used to avoid needing EEPROM for identifying a particular board, e.g, for a unique network address, since the compiled-image could contain unique-info for each board.

  4. This scheme should allow MULTIPLE user-names (as well as different board-types) to be associated with ONE serial-port, e.g., to remotely-program multiple boards over a network using ONE serial-port.  Multiple user-names associated with the same serial-port also supports multi-using a single board for different-named-projects over time.

  5. Advanced-users could customize the scheme by editing "boards.txt" to manually make specific associations (this should be easy to implement NOW, would use the existing board menu, and would still be quite valuable on its own), e.g.,

       myArduino.serial.port=/dev/tty.usbserial-A1017JIC

  6. Needs an easy way for the user to "delete" user-names when no longer needed (to shorten the user-boards menu).

  7. Has NO impact on the current way to select boards and serial ports when a user-name is not desired (except need a way to de-select the current serial-port).

Original comment by bobthoma...@gmail.com on 1 Oct 2013 at 12:48

[GoogleCodeExporter]

Fixed in Arduino IDE 1.5.6 for Linux and Mac.
It will be available for Windows from Arduino IDE 1.5.7.

C

Original comment by c.mag...@arduino.cc on 2 Jul 2014 at 1:10

• Changed state: Verified