makefiles/tools/serial.inc.mk: Allow detection of debug adapter #19119
Conversation
maribu
added
Area: build system
maribu
requested review from
aabadie,
jia200x and
haukepetersen
as code owners
github-actions
bot
added
Area: boards
|
AIU to test this I need a device that is programmed through the very UART the device exposes as its terminal port. What confuses me is that already on master, if ttyACM0 is taken by somethign different, I can already run Does that already use a different mechanism, or it it actually doing things wrong by uncoordinatedly using ${PORT} as a flag in |
|
Ah, OK, now I see: It would work fine already if the programmer is PORT based, but not if it's serial based. I have no boards to test this with (the one I did was PORT based), but anyhow, that case didn't get worse, and I trust your testing with the boards that use it. |
| PORT_DETECTED := $(shell $(TTY_SELECT_CMD) || echo 'no-tty-detected') | ||
| PORT ?= $(PORT_DETECTED) | ||
| TTY_DETECTED := $(shell $(TTY_SELECT_CMD) || echo 'no-tty-detected no-serial-detected') | ||
| PORT_DETECTED := $(firstword $(TTY_DETECTED)) |
There was a problem hiding this comment.
Do we ever expect OSes to assign TTY names that contain whitespace, or devices to expose serials that do?
I don't see any direct security concerns, so I'll just leave that as a note and not a blocker.
There was a problem hiding this comment.
ttys.py will quote any output that would contain the "seperation char", which by default is the space. I have to admit that I don't know for sure if $(firstword "foo bar" "blah blah") does indeed yield "foo bar", or just "foo.
|
This needs to be squashed |
For scripts it can be useful to output not only one, but multiple formats (e.g. to obtain both path and serial of a TTY). The script now support passing multiple formats. Note that only simple formats can be combined, as the JSON and markdown table won't mix well with any other format.
Boards with an integrated debugger/programmer that also provides the serial as UART <--> USB adapter, the TTY serial matches the serial of the programmer. This adapts the `serial.inc.mk` to set the `DEBUG_ADAPTER_ID` to the TTY serial if (and only if) `MOST_RECENT_PORT` *and* `DEBUG_ADAPTER_ID_IS_TTY_SERIAL` both have a value of `1`. Boards with an integrated programmer are expected to set `DEBUG_ADAPTER_ID_IS_TTY_SERIAL` to `1` in their `Makefile.include`.
Set `DEBUG_ADAPTER_ID_IS_TTY_SERIAL` to `1` for those boards to allow automatic detection of the debug adapter with `MOST_RECENT_PORT=1`.
maribu
force-pushed
the
dist/tools/usb-serial
branch
from
2ae1a62
to
64d4aec
Compare
|
Done. I also updated the microbit-v2, as it also contains an embedded debugger where the debug adapter ID equals the serial ID. |
|
bors merge |
|
Build succeeded: |
Contribution description
This PR adds the ability to automatically detect the debug adapter for boards with an integrated programmer/debugger, if that debugger also provides the TTY.
This extends the TTY detection that can be enabled with
MOST_RECENT_PORT=1to setDEBUG_ADAPTER_IDto the TTY's serial, but only ifDEBUG_ADAPTER_ID_IS_TTY_SERIALis set to1by the board (as not all boards have an integrated programmer/debugger).Testing procedure
Connect a HiFive-1B and a nRF52840DK at the same time and try
make BOARD=<nrf52840dk|hifive1b> MOST_RECENT_PORT=1 -C examples/default flash termfor both. The programmer will not reliably select the correct programmer inmaster. With this PR, it will.Issues/PRs references
None