[3djc]

Add debug-only CLI commands so a running radio can be driven and inspected from tools (pair with a framebuffer grab via jlink):

Input injection (CLI_INPUT_INJECT):

key <label> [ms]
trim <label><+|-> [ms]
touch <x> <y> [ms] [x2 y2]
rotary <steps>

SD card file access (CLI_FILE_ACCESS):

lsl <dir>                      "<d|f> <size> <name>" per entry
fread <path> <offset> <len>    one line of hex (keep len <= 1 KB, see below)
fput <path> <offset> <len>     <len> raw bytes follow the command line, up to 4 KB; offset 0 truncates
fwrite <path> <offset> [hex]   small hex writes, offset 0 truncates
rm <path>
mkdir <path>

Both are behind CLI && DEBUG && !BOOT, so non-debug builds are unchanged. In debug builds the CLI RX buffer grows from 256 B to ~4 KB to hold an fput block.

Tested on a TX16S MK3: random binary files of 100 B to 200 KB round-trip exactly, about 220 KB/s write and 28 KB/s read.

Known limit: the USB CDC TX ring (usbd_cdc.cpp) duplicates bytes when a single reply is roughly 2 KB or more, so fread replies should stay at or below 1 KB. This is not changed here.

It helps me on my local dev where I'm creating a setup allowing AI to check the result of its work on a real radio :)

🤖 Generated with Claude Code

[pfeerick]

Would this replace #7668 (which claims to itself replace #7337)

[3djc]

Not the same scope is it ? This is to use real radio, not simu

[pfeerick]

sorry, missed that, ok, so input to live radio... nice!

[pfeerick]

All that is really missing is you need to be able to make it to send back screen captures, then it can actually properly start the drive the radio itself. Nice to finally see some work towards that goal we talked about this time last year of automatable testing 😆