You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For many commands, the --port <port> option is necessary and very useful to target only one device when many are attached on different ports.
Complication
Sometimes USB port numbers get stuck open and the next time a device is plugged into or reset on that port, the port number increments. This breaks any kind of scripts that might know what devices are on what port. The particle usb commands do not solve this problem by themselves since they only put a device into DFU mode or Listening Mode, but a command like particle serial inspect will attempt to target many devices not in Listening Mode as well.
Question
How can we target devices on usb ports without knowing the port number in advance?
Answer
We can use the particle USB descriptor mechanism to locate devices by name and return the port they are on for use with the --port option. One example might be particle serial inspect --port electron28 that would attempt to find this port, and when it fails revert to scanning the connected devices via particle usb list and substituting the port of a found device. Or possibly introduce a new and intuitive option --device which would look like particle serial inspect --device electron28. Another example particle flash --serial bootloader.bin --device electron28 --yes (This last example coupled with the no-touch feature request #417 would be amazing as well). A final example: particle update --device electron28 --auto aka no-touch
The text was updated successfully, but these errors were encountered:
For a Raspberry Pi-based Boron tester, I modified my udev rules to symlink a friendly name to a device file. So this method only works in Linux and doesn't work on all my Linux boxen, but does work on a RPi. I just wanted to add it here in case it helps. I'm not sure if there's a similar convention or possibility on Mac OS and Windows, but this was pretty cool for me. This is the relevant part of my /etc/udev/rules.d/50-particle.rules.udev file:
# Photon/P1/Electron
# This will also create a symlink like /dev/Particle-Photon-$deviceID when a device is inserted
SUBSYSTEM=="tty", \
ATTRS{idVendor}=="2b04", \
ATTRS{idProduct}=="[cd]00[68a]", \
GROUP="plugdev", \
MODE="0666", \
ENV{ID_MM_DEVICE_IGNORE}="1", \
SYMLINK+="particle-$attr{product}-$attr{serial}"
# Argon/Boron/Xenon
SUBSYSTEM=="tty", \
ATTRS{idVendor}=="2b04", \
ATTRS{idProduct}=="[cd]00[cde]", \
GROUP="plugdev", \
MODE="0666", \
ENV{ID_MM_DEVICE_IGNORE}="1", \
SYMLINK+="particle-$attr{product}-$attr{serial}"
I adapted that from the udev file that ships with the CLI.
Situation
For many commands, the
--port <port>
option is necessary and very useful to target only one device when many are attached on different ports.Complication
Sometimes USB port numbers get stuck open and the next time a device is plugged into or reset on that port, the port number increments. This breaks any kind of scripts that might know what devices are on what port. The
particle usb
commands do not solve this problem by themselves since they only put a device into DFU mode or Listening Mode, but a command likeparticle serial inspect
will attempt to target many devices not in Listening Mode as well.Question
How can we target devices on usb ports without knowing the port number in advance?
Answer
We can use the particle USB descriptor mechanism to locate devices by name and return the port they are on for use with the
--port option
. One example might beparticle serial inspect --port electron28
that would attempt to find this port, and when it fails revert to scanning the connected devices viaparticle usb list
and substituting the port of a found device. Or possibly introduce a new and intuitive option--device
which would look likeparticle serial inspect --device electron28
. Another exampleparticle flash --serial bootloader.bin --device electron28 --yes
(This last example coupled with the no-touch feature request #417 would be amazing as well). A final example:particle update --device electron28 --auto
aka no-touchThe text was updated successfully, but these errors were encountered: