mbed-tools
mbed-tools copied to clipboard
ARMmbed
mbed-tools should allow me to pass -u option to show unmounted devices
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I want mbed-tools detect to allow me to list unmounted devices
Describe the solution you'd like A clear and concise description of what you want to happen.
able to pass -u option to show unmounted devices
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
I'm using mbed-ls for now which has the -u option
Additional context Add any other context or screenshots about the feature request here.
none
Why do you want to "list unmounted devices"? What other ways than using mbed-ls are there to list unmounted devices?
Because I want to be able to see the devices without mounting them. I can also use pyocd to list devices.
I feel I'm still missing some context.
-
Why do you want to see the devices without mounting them?
-
To figure out what the device is, its serial number, or other information, don't you have to permit at least temporarily mounting the device so you can read DETAILS.TXT or MBED.HTM(L) which contains this sort of metadata?
-
What data do you want listed for unmounted devices? Not all the same metadata will be available without mounting the device and reading the information from it.
- I cannot mount them
- no, it works fine with mbed-ls and pyocd without mounting
- platform_name serial_port target_id
Basically this:
mbedls -u
| platform_name | platform_name_unique | mount_point | serial_port | target_id | interface_version |
|---------------|----------------------|-------------|--------------|--------------------------------------------------|-------------------|
| NRF52840_DK | NRF52840_DK[0] | unknown | /dev/ttyACM2 | 110200005020312037474851313037313632303797969903 | unknown |
| NRF52840_DK | NRF52840_DK[1] | unknown | /dev/ttyACM1 | 110200005020312037474851323037313632303097969903 | unknown |
| NRF52840_DK | NRF52840_DK[2] | unknown | /dev/ttyACM0 | 110200005020312031375452303031203831303997969903 | unknown |
If the device can't be mounted, how do you expect to use it? I'm still missing some context about your use case.
How that target_id is determined without being able to read from the USB mass storage device is also a bit of a mystery, although if pyocd can do it, maybe we can too (or we can add some instructions on how to use pyocd to list unmounted devices).
It's unclear what the use case is yet, so it's hard to judge if this is a "beginner mode" sort of problem that we should help with from Mbed CLI 2 or if it is an advanced sort of use case.
I don't know. You asked me to open this feature request. I really can't tell you if it's something that you want to offer in mbed-tools. I'm OK just using mbedls which works fine.
mbed-tools detect aims to be a replacement for the deprecated mbedls tool. If there is a reason why anyone would be prevented from switching to mbed-tools detect, any feature critical to our target user's workflow, we'd really like to know that reason.
As of now, we don't understand why this feature is useful, i.e. what problems does it help solve? The problem isn't "because the devices can't be mounted." The problem might be something like: "because I disabled auto-mount on my PC and don't want to mount the device to have it listed" or "the device isn't Mbed-enabled and doesn't implement a USB mass storage device, but I still want to see it in the device list". The question to answer is "when would anybody ever find -u useful?" It's because we don't know the actual bigger problem that we don't know how to prioritize this. This is why the GitHub default feature request template asks if the feature request is related to a problem you are trying to solve: to provide helpful context.
Depending on what the actual bigger problem is, we may want to, instead of implement a -u option, rather add some documentation about how to solve the actual bigger problem with pyocd or another tool. We might also want to always list what we guess are devices but can't confirm because we don't have access to the USB mass storage device, although we aren't sure if this would show too many false positives (could we avoid listing a FT232 dongle or a generic USB CDC ACM implementing device, for example.)
I think we just want to list devices without a mount point if we can find the product code from the USB serial, which I'm assuming is what mbedls is doing when you give it the -u option. The problem seems to be the policy for detecting what we think is an "mbed enabled device" is too strict, and things that should be optional are treated as invariant.
