Is your feature request related to a problem? Please describe.
I am using the ESP32-S3 internal hardware USB (and TinyUSB device stack) for communicating with the device during normal operation and monitoring, however flashing it using the same hardware usb requires physical intervention (holding boot and pressing reset button). I therefore prefer to flash it using the UART interface with an FTDI chip that has access to the DTR, RTS pins, and then monitor it using the chips hardware USB.
Unfortunately there is only one idf.port setting which governs the convenient 'Build, Flash, and Start a Monitor on your Device' command, which requires flashing and monitoring to always be on the same port.
Describe the solution you'd like
An additional setting which provides more specificity of the task for which the port is being set. Possibly an optional idf.monitorPort setting which, if defined, takes precedence over the idf.port setting for creating the monitor, and is respected by the createNewIdfMonitor function:
Describe alternatives you've considered
I could implement my own custom extension which completely replaces the esp-idf command entirely, or a fork, but this feels like overkill for a simple setting that is potentially only a couple of lines or so and is potentially useful for others in the mainline of the extension.
Is your feature request related to a problem? Please describe. I am using the ESP32-S3 internal hardware USB (and TinyUSB device stack) for communicating with the device during normal operation and monitoring, however flashing it using the same hardware usb requires physical intervention (holding boot and pressing reset button). I therefore prefer to flash it using the UART interface with an FTDI chip that has access to the DTR, RTS pins, and then monitor it using the chips hardware USB.
Unfortunately there is only one
idf.port
setting which governs the convenient 'Build, Flash, and Start a Monitor on your Device' command, which requires flashing and monitoring to always be on the same port.Describe the solution you'd like An additional setting which provides more specificity of the task for which the port is being set. Possibly an optional
idf.monitorPort
setting which, if defined, takes precedence over theidf.port
setting for creating the monitor, and is respected by thecreateNewIdfMonitor
function:https://github.com/espressif/vscode-esp-idf-extension/blob/9725ba34078c8cd52314d7bd692ca70dc10eab66/src/espIdf/monitor/command.ts#L46
Describe alternatives you've considered I could implement my own custom extension which completely replaces the esp-idf command entirely, or a fork, but this feels like overkill for a simple setting that is potentially only a couple of lines or so and is potentially useful for others in the mainline of the extension.