<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div>A neat and elegant solution, and a cool little tool.<div class=""><br class=""></div><div class="">Note that there is supposedly also:</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><span style="color: rgb(46, 139, 87); font-family: Monaco, "Andale Mono", "Courier New", Courier, mono; font-size: 11.699999809265137px; background-color: rgb(255, 255, 255);" class="">make flash ESPPORT=... ESPBAUD=...</span></div></blockquote><div class="">to override the menuconfig setting.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><div><br class=""></div><div>P.S. I avoid this by ensuring I only plug in one at a time ;-)</div><div><br class=""><blockquote type="cite" class=""><div class="">On 19 Feb 2018, at 9:18 AM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Perhaps none of you (other than Mark) have multiple OVMS v3 devices to<br class="">connect to your computer. I have an OVMS v3.0 plus a smaller DEVKIT-C<br class="">module that Mark sent to me to begin the infrastructure work before<br class="">the developer boards were available. I want to run some other code on<br class="">the DEVKIT-C module, so I plugged it into my Mac laptop via the same<br class="">powered hub that I bought to support the OVMS v3.0 board.<br class=""><br class="">I discovered that the driver for the Silicon Labs CP2102 USB-to-UART<br class="">bridge controller assigns a device name like /dev/tty.SLAB_USBtoUART19<br class="">to the second device that is connected. The number 19 represents how<br class="">many times one of these devices has been connected, so if I unplug the<br class="">second device and plug it back in again its device name will change to<br class="">/dev/tty.SLAB_USBtoUART20. Since that device name is configured into<br class="">sdkconfig that means a reconfig and full rebuild each time I need to<br class="">unplug! Bah.<br class=""><br class="">So I went searching on the Silicon Labs forum and found that a support<br class="">request to do something more sane was filed three years ago and has<br class="">yet to be addressed. But one post included a workaround which is to<br class="">use a python script to scan the system information about the USB<br class="">hierarchy to find the location ID corresponding to each of these<br class="">device names. The location ID of the port where the device is plugged<br class="">in remains constant. Depending upon how the devices are being used,<br class="">that can allow using a script to learn the device name currently<br class="">assigned to each of the physical devices (assuming that a given<br class="">physical device is always plugged into the same port).<br class=""><br class="">I took this idea and modified components/esptool_py/Makefile.projbuild<br class="">to invoke an added program tools/findcp2102.py to look up the serial<br class="">port as a location ID and translate it to the current device name.<br class="">For example, in the sdkconfig file in my work tree for the DEVKIT-C I<br class="">have changed CONFIG_ESPTOOLPY_PORT="20-2.1" which (currently) gets<br class="">translated to /dev/tty.SLAB_USBtoUART20 when I run make (or make<br class="">flash or make monitor).<br class=""><br class="">If the tools/findcp2102.py program is run with no argument it will<br class="">list the location ID and device name for all the connected CP2102<br class="">devices. I can know which device name belongs to each physical device<br class="">according to the order in which I plugged them in, so that gives me<br class="">the associated location ID. It is also possible to see these location<br class="">IDs in the Mac's System Report, but the numbering scheme is different.<br class=""><br class="">I've committed this change to the openvehicles/esp-idf repository.<br class="">The change is implemented such that is has no effect if the serial<br class="">port spec is not found as a USB location ID, so it should cause no<br class="">harm.<br class=""><br class=""> -- Steve<br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></body></html>